The risk assessment is mandatory
Article 13(2)-(3) requires manufacturers to perform a cybersecurity risk assessment, take its outcome into account during planning, design, development, production, delivery and maintenance, and include it in the technical documentation. Every "appropriate to the risk" phrase in Annex I resolves against this document.
It is also the assessment that determines whether an Annex I requirement is not applicable to your product. You cannot simply omit a requirement — you justify its non-applicability here.
A method that works for embedded
1. Define the system and its boundaries. Draw the data flow: sensors, MCU, radio, gateway, cloud, mobile app, production line, service technician. Mark every trust boundary crossing. Do not omit the manufacturing and repair paths — a device programmed over an open UART on the bench is in scope for an attacker.
2. Enumerate assets. Firmware integrity, device identity keys, user credentials, telemetry, safety-relevant actuation, the availability of the essential function itself.
3. Enumerate threats. STRIDE per boundary crossing is the pragmatic default; add embedded-specific classes that STRIDE tends to miss:
- Physical attacks: chip decapsulation, flash desoldering, bus probing on SPI/I2C.
- Fault injection: voltage and clock glitching to skip a signature check.
- Side channels: timing and power analysis against crypto.
- Supply chain: malicious or counterfeit components, compromised vendor SDK.
- Debug and test: JTAG/SWD left enabled, test-mode commands surviving to production.
4. Rate. Any consistent scheme is acceptable if documented. CVSS for known vulnerabilities; for design threats, likelihood × impact, or the attack-potential model from IEC 62443-4-1 / ISO/SAE 21434 if you already use one.
5. Decide and trace. For each threat: mitigate, accept with justification, or transfer. Link each mitigation to the Annex I requirement it satisfies and to the design element that implements it. Traceability is what turns a threat model into evidence.
Keep it alive
The assessment must be updated as appropriate across the product's lifetime. Trigger a review on: architecture change, new external interface, new third-party component, a relevant published vulnerability class, and any substantial modification. Date and version the document; auditors look at whether it moved.
Standards worth leaning on
- IEC 62443-4-1 — secure product development lifecycle; maps closely to CRA process duties.
- IEC 62443-4-2 — technical security requirements for components; maps closely to Annex I Part I.
- ETSI EN 303 645 — consumer IoT baseline; excellent for consumer-facing devices.
- ISO/IEC 27005 — risk management method if you need a formal framework.
None of these is (yet) a harmonised standard giving presumption of conformity, but aligning with them makes your assessment recognisable and your gap analysis cheap when harmonised standards land.