Article 13 CRA Risk Assessment: The Document That Holds Everything Together
The cybersecurity risk assessment under Article 13 of the Cyber Resilience Act is not a compliance checkbox - it is the document that determines how every other CRA obligation applies to your product. Without it, you cannot legitimately draw up the EU Declaration of Conformity or affix CE marking. With it, you have a structured, defensible record that connects your product's real-world risks to the specific security measures you have put in place.
This article is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against Regulation (EU) 2024/2847.
Key points
- Article 13(2) requires manufacturers to assess cybersecurity risks and take the results into account across the full product lifecycle: planning, design, development, production, delivery, and maintenance.
- The assessment must be documented, included in the technical documentation (Annex VII), and retained for 10 years.
- It must be updated as appropriate throughout the support period - at minimum five years, or the realistic lifetime of the product.
- The Annex I essential requirements apply "to the extent applicable" based on this assessment. That makes it the mechanism for proportionality - but it cannot be used to skip requirements wholesale.
- No documented risk assessment = no valid CE marking under the CRA.
- Full application of the essential requirements and CE marking: 11 December 2027.
Why the risk assessment is load-bearing
The CRA's Annex I lists the essential cybersecurity requirements every product with digital elements must meet. But the regulation does not apply them as a flat checklist. Implementation of these requirements must be based on a product-specific risk assessment - this does not mean you can bypass certain requirements altogether; instead, it provides a mechanism to determine how each requirement applies in proportion to the identified risks.
If a particular requirement is deemed unnecessary or only partially fulfilled, this must be clearly justified in the technical documentation - documentation that will be reviewed by regulators, customers, and importers and should withstand scrutiny.
In short: the risk assessment is the reason behind every security decision in your product. It is what a market surveillance authority will reach for first.
The risk assessment is also the input to your support period decision. Article 13(8) requires the support period to reflect the time the product is expected to be in use — at minimum five years. The risk assessment must document the reasoning behind whatever period you choose.
What Article 13 actually requires
Manufacturers must undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product, with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.
At minimum, the risk analysis must be based on:
- Intended purpose and reasonably foreseeable use - including foreseeable misuse. Think about who will actually use the product and in what contexts, not just the ideal deployment scenario.
- Conditions of use - the operational environment, the assets the product interacts with, and the sensitivity of the data it processes or transmits.
- Expected lifetime - how long the product will realistically be in use, which directly feeds into the support period under Art. 13(8).
The cybersecurity risk assessment must be documented and updated as appropriate during the support period.
The cybersecurity risk assessment, as well as the means that the manufacturer chooses to implement the essential requirements, need to be included in the technical documentation, and the manufacturer is required to keep that documentation at the disposal of authorities. The retention period is 10 years from the date the product is placed on the market.
The Commission's draft guidance (March 2026)
On 3 March 2026, the European Commission published its first draft guidance on the CRA. With the first CRA obligations starting to apply from June and September 2026, this guidance is the clearest signal yet of how the Commission expects manufacturers and other economic operators to apply the new rules in practice.
The draft guidelines elaborate on key compliance obligations such as risk assessments, reporting duties, and procedures for vulnerability handling. The Commission's draft guidance news page has the full document.
Important caveat: the consultation on the draft guidance closed on 31 March 2026, and the European Commission will now review stakeholder feedback and is expected to publish the final version in due course. Even then, the document will remain non-binding; only the CJEU can provide an authoritative interpretation of the CRA. Treat the draft as a useful signal of Commission intent, not settled law.
What to do: building your Article 13 risk assessment
The CRA does not mandate a specific methodology. You can use ISO/IEC 27005, STRIDE, TARA, or any other structured approach - what matters is that the output is documented, traceable, and proportionate to the product.
Define the product boundary: hardware, firmware, software components, remote data processing, and any interfaces to other systems. Confirm the product falls within the CRA's scope — see the scope checker if you're unsure.
List what needs protecting: data the product stores or transmits, the device's own integrity, user safety, and any downstream systems it connects to. Be specific — "user credentials" is more useful than "data".
For each asset, identify realistic threat scenarios based on the product's intended purpose and reasonably foreseeable misuse. Consider the operational environment: is this a consumer device on a home network, or industrial equipment on an OT network?
Assess likelihood and impact for each threat. Document your reasoning. This is the step that will be scrutinised — vague statements like "risk is low" without justification will not hold up.
Go through each Annex I Part I requirement and record whether it applies, how it applies, and what measure addresses it. Where a requirement does not apply, document why — with reference to the risk analysis, not just an assertion.
Use the risk assessment to justify the support period under Art. 13(8). The minimum is five years; if the product's realistic lifetime is longer, the support period should reflect that.
The risk assessment is a formal document, not a spreadsheet in a shared drive. It must be part of the technical documentation you retain for 10 years and make available to market surveillance authorities on request.
Set triggers for updating the assessment: significant product changes, newly discovered vulnerability classes, changes in the operational environment, or new threat intelligence. The assessment is a living document, not a one-time exercise.
A common misconception: proportionality ≠ exemption
Teams sometimes read "to the extent applicable" in Annex I and conclude that a low-risk product can simply skip inconvenient requirements. That is not how it works.
Without a documented risk assessment, a manufacturer cannot claim CE marking under the CRA. The risk assessment becomes both a compliance document and a strategic blueprint for secure-by-design development - risk assessments should inform architecture decisions, ultimately demonstrating that chosen cybersecurity measures are a logical response to the product's identified risks.
If your risk assessment genuinely shows that a specific Annex I requirement is not applicable to your product, you can document that conclusion and move on. But the conclusion must flow from the analysis - not precede it.
Use this tool to check your risk assessment coverage
The widget below walks you through the minimum inputs the CRA requires and flags any gaps before you finalise your technical documentation.
How this connects to the rest of your CRA compliance
The risk assessment does not sit in isolation. It feeds directly into:
- Annex I implementation - the essential requirements you apply and how you apply them
- Technical documentation (Annex VII) - where the assessment lives, alongside the SBOM and conformity evidence
- EU Declaration of Conformity - which you cannot legitimately sign without a completed assessment
- Support period - which the assessment helps justify under Art. 13(8)
- Conformity assessment route - your product class (default, Important Class I, Important Class II, Critical) determines whether you self-assess or need a notified body
For related reading:
- Do you need an SBOM for the CRA?
- CRA deadlines at a glance
- CRA compliance checklist
- Find your product class
The European Commission's legislative summary is also a useful plain-English companion to the full Regulation (EU) 2024/2847 text.
The Commission's draft guidance and the harmonised standards are both still in progress. Guidance, standard references, and enforcement priorities will shift before December 2027. Subscribe to The CRA Brief to get concise updates when anything material changes — no noise, just the developments that affect your compliance work.
Related reading
The CRA Support Period: It's Not a Flat Five Years
The CRA support period is not a flat five-year rule. It's the expected product lifetime - and at least five years. Here's how to set, justify, and communicate yours.
How to Build a CRA-Compliant Coordinated Vulnerability Disclosure Policy
The CRA requires a CVD policy and a reachable contact point. Here's exactly what to put in it - and how it differs from the mandatory 24h/72h ENISA reporting clock.
CRA Penalties Explained: The Three Fine Tiers, Who Can't Be Fined, and What Else Authorities Can Do
Article 64 of the Cyber Resilience Act sets three tiers of fines - up to €15M or 2.5% of global turnover at the top. Here's exactly what each tier covers, who is exempt, and what else authorities can do beyond fining.