The strongest CRA risk assessment is a traceable engineering process rather than a one-time scoring worksheet. Every important risk should connect product context, an attack or failure scenario, affected assets, Annex I requirements, selected controls, verification evidence and residual risk. That traceability makes later technical documentation and conformity assessment much easier.
Step 1: Define the Product and Assessment Boundary
Begin by defining exactly what product with digital elements the assessment covers. Identify the commercial product, hardware and software elements, relevant cloud or remote components, software versions affecting compliance and important external dependencies. The boundary should be specific enough that later threat scenarios and controls can be connected to real components. A vague boundary can cause teams to overlook security-relevant services or assume that another organisation is responsible for a component that is actually part of the manufacturer's product or compliance evidence.
- Identify the marketed product.
- Identify relevant hardware and software components.
- Identify remote or cloud components within the product model.
- Identify important external dependencies.
- Record product and software versions.
Step 2: Define Intended Purpose
Article 13 requires the risk assessment to consider intended purpose. Define what the product is meant to do, who is expected to use or administer it and which environments or operating assumptions form part of that intended use. Avoid describing the purpose so broadly that it provides no security context. A useful description identifies the product functions that matter to cybersecurity and the level of privilege or trust associated with those functions. Intended purpose later provides the reference point for data minimisation, access decisions and several Annex I applicability questions.
- Describe intended product functions.
- Identify intended users and administrators.
- Identify expected deployment environments.
- Identify important security assumptions.
- Identify functions whose compromise has material consequences.
Step 3: Identify Reasonably Foreseeable Use and Misuse
The assessment should not depend on every user following an ideal deployment. Consider reasonably foreseeable use, including predictable exposure, configuration and operational patterns. Security teams can review support records, similar products, common deployment models and known attacker behaviour to identify situations users are likely to encounter. The purpose is not to invent remote hypothetical misuse but to identify realistic conditions that can change cybersecurity risk. Record the assumptions because later product instructions or secure defaults may need to address them.
- Identify common deployment patterns.
- Identify predictable insecure configuration choices.
- Identify foreseeable interface exposure.
- Identify likely administrative mistakes.
- Record scenarios that materially alter cybersecurity risk.
Step 4: Identify Conditions of Use and Operational Environment
Article 13 expressly identifies conditions of use and gives the operational environment as an example. Record whether the product is expected to operate on public networks, managed enterprise systems, local networks, industrial environments, mobile devices, embedded platforms or other relevant contexts. Identify environmental controls the product depends on, such as network segmentation, platform authentication or physical access restrictions. Assumptions should be realistic and documented. A control that works only in a managed environment should not silently be treated as effective in an unmanaged deployment.
- Identify network exposure.
- Identify platform and operating-system assumptions.
- Identify physical-access assumptions.
- Identify environmental security controls.
- Identify external services required for secure operation.
Step 5: Identify Assets to Be Protected
Article 13 also identifies assets to be protected as part of the risk-analysis context. Assets can include personal and non-personal data, credentials, cryptographic keys, software integrity, configuration, privileged functions, essential product functions, update infrastructure and connected systems. Asset identification helps teams determine why a threat matters. A vulnerability in a low-value isolated component can have a different consequence from a similar weakness in a component holding administrative credentials or controlling a critical product function.
- Identify sensitive data.
- Identify credentials and cryptographic material.
- Identify software and configuration integrity assets.
- Identify essential and basic functions.
- Identify connected systems affected by product compromise.
Step 6: Map Trust Boundaries and Attack Surfaces
Architecture diagrams should show where untrusted or differently trusted actors and components interact. Relevant boundaries can include network interfaces, APIs, administrative interfaces, local processes, hardware ports, update paths, cloud integrations, file imports and third-party services. Attack-surface mapping helps identify where threats can enter the product and where existing controls are expected to stop them. The exercise should use the actual production architecture rather than a simplified conceptual diagram that omits operational interfaces.
- Map external interfaces.
- Map administrative interfaces.
- Map service-to-service boundaries.
- Map update and maintenance channels.
- Map third-party integration boundaries.
Step 7: Develop Threats and Attack Scenarios
For each important asset and attack surface, identify credible threat scenarios. A scenario should explain how an attacker or security failure could affect the product rather than merely naming a generic threat category. Examples can include unauthorised administrative access, malicious update substitution, credential theft, command manipulation, denial-of-service, exploitation of an exposed parser, compromise of a dependency or tampering with configuration. Future Cluster 8 pages can document the scenario structure in more depth, but even the initial assessment should preserve enough detail to connect the scenario to controls and evidence.
- Identify attacker goals.
- Identify entry points.
- Identify required conditions.
- Identify affected assets.
- Identify potential security consequences.
Step 8: Identify Vulnerabilities and Existing Weaknesses
Threat scenarios become more useful when connected to actual or plausible weaknesses. Review architecture, source code, dependencies, configuration, authentication, access controls, exposed interfaces and development practices. Vulnerability information can come from internal testing, public advisories, suppliers, researchers and product history. The assessment should distinguish a known vulnerability from a general threat and from a weakness that has not yet been assigned a public identifier. The CRA vulnerability-handling obligations continue during the support period, so new information can require reassessment after release.
- Review first-party code and design.
- Review third-party components.
- Review configuration weaknesses.
- Review known vulnerability information.
- Record product-specific exploitability conclusions.
Step 9: Assess Cybersecurity Risk
Evaluate the cybersecurity risk presented by each material scenario using a consistent method appropriate to the organisation and product. The CRA does not prescribe one universal scoring formula. A manufacturer can consider likelihood or feasibility together with impact, while preserving enough context that the result is meaningful. Factors can include attacker access, privileges, complexity, exploit maturity, affected assets, availability consequences, data exposure, integrity consequences, scale and possible health or safety effects. The method should support prioritisation rather than produce a false impression of mathematical precision.
- Use a defined assessment method.
- Assess attack feasibility or likelihood.
- Assess cybersecurity impact.
- Consider product-specific consequences.
- Record assumptions behind the rating.
Step 10: Map Annex I Requirements
Use the risk assessment to determine how Annex I applies. Article 13 requires the assessment to indicate whether and how the requirements in Part I point 2 are applicable and how they are implemented. It must also indicate how the general requirement in Part I point 1 and the Part II vulnerability-handling requirements are applied. A requirement-to-risk mapping can reveal where several threat scenarios depend on the same security control or where an Annex I requirement has not yet been addressed by the design.
- Review Annex I Part I point 1.
- Review every relevant Part I point 2 requirement.
- Review Annex I Part II vulnerability handling.
- Record applicability decisions.
- Document clear justification for non-applicability.
Step 11: Select and Document Risk Treatment
For risks requiring action, identify controls or design changes that reduce the probability or consequence of the scenario. Controls can include secure defaults, authentication, access control, encryption, integrity checks, service reduction, resilience, isolation, logging, monitoring, secure updates and vulnerability-management processes. Record the control owner, implementation status and rationale. Where the risk depends on deployment or user controls, document the assumption and determine whether user information is sufficient or whether the product should enforce a stronger default.
- Select proportionate technical or process controls.
- Assign an implementation owner.
- Record control rationale.
- Identify external assumptions.
- Record planned verification.
Step 12: Verify Controls and Assess Residual Risk
Controls should be verified through methods appropriate to the security property. Architecture review, source review, automated security testing, penetration testing, fuzzing, configuration inspection, update testing, resilience testing and process review can all provide evidence. After verification, reassess the scenario to determine the residual cybersecurity risk. A control that exists but does not work as intended should not be credited fully in the risk assessment. Unresolved residual risk should be visible and approved through the manufacturer's governance process.
- Define control verification.
- Perform security-relevant tests.
- Record actual results.
- Reassess residual risk.
- Escalate unacceptable remaining risk.
Step 13: Include the Assessment in Technical Documentation
Article 13 requires the cybersecurity risk assessment to be included in the technical documentation required by Article 31 and Annex VII. The assessment should therefore be versioned, readable and connected to the product architecture and test evidence. A reviewer should be able to understand the product context, identified risks, applicable Annex I requirements, treatments and residual risks without reconstructing the analysis from disconnected engineering tickets. Related evidence can remain in controlled repositories if the technical documentation identifies it reliably.
- Version the assessment.
- Identify the covered product release.
- Link to architecture documentation.
- Link to risk-treatment evidence.
- Link to verification reports.
Step 14: Define Reassessment Triggers
The CRA requires the documented assessment to be updated as appropriate during the support period. Define practical triggers before release. These can include new product functions, architecture changes, new external interfaces, changed deployment environments, major dependency updates, newly discovered vulnerabilities, new exploitation information or changes to vulnerability-handling processes. A reassessment trigger does not necessarily require rewriting the whole document. It should require the manufacturer to evaluate the affected risks and update the record where the conclusion has changed.
- Product architecture changes.
- New or changed interfaces.
- New dependencies.
- New vulnerability information.
- Changed operational environment.
- Changed support or update process.
Use the Assessment as an Engineering Record
The assessment is most useful when engineering, product security and compliance teams can use the same record. Risks should have stable identifiers, owners, treatment status and evidence references. This allows design reviews and release gates to identify unresolved security issues without maintaining separate compliance-only documents. It also makes later product changes easier to assess because teams can see which original assumptions and controls are affected. The objective is traceability from product context through risk and control to evidence.
- Use stable risk identifiers.
- Assign risk and control owners.
- Link risks to Annex I requirements.
- Link controls to tests and evidence.
- Use the assessment during release decisions.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.