Annex I Part I lists these requirements. Your risk assessment must address each one, even if briefly, explaining how your product meets it or why it does not apply:

(a) Design and development security – documented SDLC, threat modelling, secure coding practices, code review processes
(b) Cryptographic controls – algorithms used, key management, transport encryption. See the Crypto Inventory tab for automated analysis of your SBOM.
(c) Vulnerability handling – coordinated vulnerability disclosure policy, security contact, patch distribution. Cross-reference your Vulnerability Handling section (§2(b)).
(d) State of the art – alignment with current industry standards, best practices, and harmonised standards. Cross-reference your Standards Applied section (§5).
(e) Supply chain security – dependency management, SBOM completeness, supplier due diligence. Your Supply Chain tab provides evidence here.
(f) Physical security – hardware-specific controls if applicable. For pure software products, document why this is not applicable with a brief justification.
(g) Personnel security – secure development team practices, access controls, training
(h) Incident handling – incident response plan, ENISA reporting readiness (Art. 14), escalation procedures
(i) Business continuity – redundancy, backup strategy, disaster recovery for the product's security functions
(j) Accessory controls – operational security measures, monitoring, alerting
(k) Operativeness – continued operation of security functions during degraded conditions
(l) Logging – audit trail capability, security event logging, retention
(m) Risk documentation – the risk assessment itself and how it is maintained over the product lifecycle

Do not mark a requirement as "not applicable" without justification. The CRA expects manufacturers to explain why a requirement does not apply to their specific product. A bare "N/A" will not satisfy a notified body.

Annex I risk assessment

Select a station to begin