Every conformity claim under the Cyber Resilience Act rests on one document. Article 13(2) of Regulation (EU) 2024/2847 requires manufacturers to undertake an assessment of the cybersecurity risks associated with a product with digital elements, and Article 13(3) requires that assessment to be documented and kept up to date. The regulation tells you what the assessment must achieve. It does not tell you how to build one. This post sets out a working methodology that an engineering team can run and that produces the evidence the regulation asks for.
The risk assessment sits between two subjects we have covered before. It is the starting point of the secure development lifecycle we described in security by design across the product lifecycle, and it is the risk-management backbone that links vulnerability reporting to the rest of your product security programme. Here we focus on the document itself, what it must contain, how to produce it, and where it lives.
What Article 13 requires the assessment to contain
Article 13(3) sets the minimum content. The assessment must comprise an analysis of cybersecurity risks based on the intended purpose of the product and its reasonably foreseeable use. It must take account of the conditions of use, such as the operational environment and the assets to be protected. And it must consider the length of time the product is expected to be in use.
Three further properties follow directly from the article.
- It must inform the whole lifecycle. Article 13(2) requires you to take the outcome of the assessment into account during the planning, design, development, production, delivery and maintenance phases of the product. An assessment written after the design is frozen fails this test on its face. The assessment has to exist early enough to change engineering decisions, and you must be able to show that it did.
- It must be documented. An assessment that lives in the heads of your senior engineers, or in a slide deck from a kickoff workshop, does not meet the obligation. The output is a formal artefact with an owner, a version history, and a defined place in your technical documentation.
- It must be kept current. Article 13(3) requires the assessment to be updated as appropriate during the product's support period. Treat it as a living document with defined update triggers rather than a launch deliverable.
The assessment decides which Annex I requirements apply
The most consequential sentence in Article 13(3) is easy to skim past. The assessment must indicate whether, and if so in what manner, the product security requirements set out in Annex I Part I are applicable to your product, and how they are implemented as informed by the assessment. It must also indicate how you apply the vulnerability handling requirements in Annex I Part II.
This is the mechanism that makes the CRA risk based rather than checklist based. The Part I product properties, which cover secure default configuration, protection against unauthorised access, confidentiality and integrity of data, data minimisation, availability, attack surface limitation, exploitation mitigation, security logging, and secure data removal, apply on the basis of the risk assessment and where applicable. Your assessment is the document that establishes applicability.
The practical consequence is that the assessment must reach a recorded verdict on every Part I property. Either the requirement applies and the assessment states how the product implements it, or it does not apply and the assessment states the risk-based reason why. A silent omission is a gap that a market surveillance authority or a notified body can query, and "we did not consider it" is not a defensible answer.
A structured threat model satisfies the analysis obligation
The regulation names no method. Any approach that produces a genuine analysis of threats, weaknesses, impacts, and controls can work. In practice, a structured threat model built with STRIDE applied per component and per data flow is the most reliable way to generate that analysis systematically, and it maps cleanly onto the Annex I structure.
The method runs in three steps.
- Decompose the product. Draw a data flow diagram covering every component, data store, data flow, and external entity, and mark the trust boundaries between them. This step reuses the product description your technical documentation already requires, including network interfaces, protocols, third-party components, and any cloud services the product depends on.
- Apply STRIDE to each element. For every component and every data flow, work through the six categories. Spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The per-element discipline is what makes the model complete. A team that brainstorms threats freely will find the interesting ones and miss the boring ones, and the boring ones are where products get breached.
- Record every finding. Each threat gets an identifier, the element it affects, the STRIDE category, a description of the attack path, and the control that addresses it or the rationale for accepting it.
The reason this satisfies Article 13(3) is the mapping. Spoofing findings drive the authentication and access control requirements. Tampering findings drive integrity protection. Repudiation findings drive security-relevant logging. Information disclosure findings drive confidentiality and data minimisation. Denial of service findings drive availability and resilience. Elevation of privilege findings drive access control and attack surface reduction. A completed STRIDE pass over the whole data flow diagram is, in effect, a demonstration of which Annex I Part I requirements apply to your product and why.
Score likelihood and impact to prioritise controls
A list of threats is analysis. A risk assessment adds judgement about which threats matter. The standard instrument is a likelihood and impact matrix, and a simple one is enough.
Score each recorded threat on two axes, typically 1 to 5. Likelihood reflects how exposed the affected element is, what capability and access an attacker needs, and whether exploitation techniques for this class of weakness are publicly known. Impact reflects the harm if the attack succeeds, including harm to users' data, disruption to the product's essential functions, effects on other connected devices and networks, and, where relevant, health and safety. Article 13(2) names the minimisation of incident impact, including in relation to health and safety, as an explicit goal of the assessment, so your impact scale should record it explicitly.
The product of the two scores bands each risk. High-band risks require a control implemented in the design. Medium-band risks require a control or a documented mitigation plan. Low-band risks may be accepted, with the acceptance and its rationale recorded in the assessment. Every control should carry a reference back to the Annex I requirement it implements, because that cross-reference is what turns an internal engineering document into conformity evidence. Residual risk that remains after controls are applied belongs in the document too, with the reasoning for why it is acceptable.
One distinction is worth keeping sharp. CVSS scores vulnerabilities that exist. This scoring exercise rates threats at design time, before any specific vulnerability is known. Both belong in your programme, and they answer different questions.
Keep it current and file it in the technical documentation
Article 13(3) requires the assessment to be updated as appropriate during the support period. "As appropriate" needs a definition in your process, and workable update triggers are concrete. A new product version that changes components, interfaces, or data flows. A change in the SBOM. A vulnerability report arriving through your coordinated disclosure channel that reveals a threat the model missed. New threat intelligence relevant to the product category. An incident, in your own product or a comparable one. Each trigger prompts a review, and each review produces a new version of the document.
Article 13(4) then closes the loop. When you place the product on the market, the risk assessment goes into the technical documentation, whose required content is specified in Annex VII. The technical documentation must be retained for ten years after the last unit is placed on the market, so the assessment carries a long archival tail. Version every revision, date it, and keep the superseded versions, because the history of the document is itself evidence that the update obligation was met.
What this means for manufacturers
The reporting obligations under Article 14 apply from 11 September 2026, and the full conformity obligations, including the risk assessment duty, apply to products placed on the EU market from 11 December 2027. The assessment has a longer lead time than the deadline suggests, because it must precede and shape design decisions. A product that will ship in 2028 needs its risk assessment during planning in 2026 and 2027.
The working sequence is short. Decompose the product into a data flow diagram. Run STRIDE per component and per data flow. Score each finding for likelihood and impact. Map every control to the Annex I requirement it implements, and record a verdict on every Part I property. File the result in the Annex VII technical documentation, and define the triggers that will keep it current through the support period.
You can start this week with a whiteboard and a spreadsheet. The essential ingredients are a method applied with discipline and a document that stays alive after launch. Manufacturers who build the assessment this way also gain something beyond the conformity file. The same document tells your engineers where the product is weakest, and that knowledge is useful regardless of regulation.