CRA cybersecurity risk assessment should not reduce product risk to a generic vulnerability severity score. A defensible assessment considers whether an attack scenario is technically feasible in the real product, what access and preconditions are required, which assets are affected, what cybersecurity consequences can result, which controls already reduce the scenario and what residual risk remains after treatment.
Assess Risk in the Context of the Actual Product
Article 13 requires an assessment of the cybersecurity risks associated with the product with digital elements. The assessment should therefore be product-specific. A public vulnerability score, generic threat category or industry risk statement can provide useful input, but it does not automatically describe the risk presented by the manufacturer's product. Product architecture, intended purpose, reasonably foreseeable use, exposed interfaces, deployment environment, privileges, affected assets and existing controls can materially change the result.
- Assess the marketed product and relevant version.
- Use real product architecture.
- Consider intended and foreseeable use.
- Consider actual exposed interfaces.
- Consider existing security controls.
Distinguish Threat, Vulnerability and Risk
Clear terminology improves risk decisions. A threat is a potential adverse event or action. A vulnerability is a weakness that can enable or contribute to that event. Cybersecurity risk reflects the product-specific possibility and consequence of the event. A remotely reachable attacker is not itself a vulnerability, and a vulnerable library does not by itself establish the exact risk to every product containing it. The assessment should connect these elements so that risk treatment addresses the real attack path rather than only the name of a vulnerability or threat category.
- Threat: potential adverse action or event.
- Vulnerability: weakness that can be exploited.
- Scenario: path from threat to consequence.
- Risk: product-specific significance of that scenario.
Define a Consistent Risk Method
The CRA does not prescribe one universal numerical risk formula. Manufacturers can use qualitative levels, quantitative scores or another documented method appropriate to the product and organisation. The method should be consistent enough that similar scenarios produce comparable conclusions and transparent enough that reviewers can understand why a risk was rated at a particular level. Avoid false mathematical precision where the underlying assumptions are uncertain. A simple but well-documented method can be more useful than a complex formula whose inputs cannot be justified.
- Define risk levels or scoring rules.
- Define assessment criteria.
- Document important assumptions.
- Apply the method consistently.
- Allow justified product-specific judgement.
Assess Attack Feasibility
Attack feasibility asks how realistic it is for the scenario to occur in the product's actual operating conditions. Factors can include whether the interface is remotely reachable, whether authentication is required, which privileges are needed, whether physical access is necessary, the complexity of exploitation, required user interaction and whether reliable exploit techniques are available. The manufacturer can call this likelihood, feasibility or another term in its chosen methodology, but the underlying reasoning should remain visible.
- Network or physical access required.
- Authentication required.
- Privilege required.
- User interaction required.
- Exploit complexity.
- Existing preventative controls.
Assess Cybersecurity Impact
Impact should describe what successful exploitation means for the product, user and connected environment. Relevant consequences can include unauthorised access, confidentiality loss, data or software modification, loss of essential functions, wider network disruption, compromise of credentials, persistence, lateral movement or effects on user health and safety where relevant. Generic severity can be useful context, but the product assessment should identify the actual assets and functions affected.
- Confidentiality impact.
- Integrity impact.
- Availability impact.
- Privilege or access impact.
- Impact on connected systems.
- Health or safety consequences where relevant.
Use Vulnerability Severity as an Input, Not the Whole Risk
Standard vulnerability severity metrics can help manufacturers triage technical weaknesses, but severity and product-specific cybersecurity risk are not identical. A high-severity vulnerability can be unreachable in a particular product configuration. A moderate-severity weakness can create significant risk if it affects a highly privileged, internet-facing component. Record external severity information where useful, then perform the product-specific analysis needed to determine the actual risk to the product with digital elements.
- Record external severity where useful.
- Confirm affected product versions.
- Assess reachability.
- Assess product-specific consequences.
- Document why product risk differs where applicable.
Account for Existing Controls
Existing product controls can reduce attack feasibility, impact or both. Authentication can remove unauthenticated access paths. Network isolation can reduce reachability. Least privilege can reduce consequences after compromise. Integrity verification can prevent malicious modifications from being accepted. When controls are credited in the risk assessment, the manufacturer should identify the relevant implementation and evidence that the control actually operates as assumed. An unverified planned control should not receive the same credit as a tested production control.
- Identify relevant controls.
- Explain how each control affects the scenario.
- Distinguish planned from implemented controls.
- Reference verification evidence.
- Review assumptions after product changes.
Consider Defence in Depth
One attack scenario can encounter several layers of defence. An external API might use authentication, authorisation, input validation, rate limiting, least privilege and monitoring. The risk assessment should avoid assuming that one control completely eliminates the scenario where other failure modes remain credible. Defence-in-depth analysis can identify which control is expected to prevent the initial compromise, which reduces impact and which helps detect or recover from the event.
- Identify preventative controls.
- Identify detection controls.
- Identify containment controls.
- Identify recovery controls.
- Consider correlated control failures.
Record Initial and Residual Risk Separately
A practical risk record can distinguish the risk before planned treatment from the risk remaining after controls have been implemented and verified. This is often described as inherent or initial risk and residual risk, although the CRA does not mandate those labels. The distinction helps reviewers understand why additional controls were selected and whether the final product security posture is considered appropriate. Residual risk should reflect actual implemented controls rather than proposed future work.
- Record pre-treatment risk.
- Identify treatment controls.
- Verify implementation.
- Reassess the scenario.
- Record residual risk.
Use Risk Assessment to Inform Annex I Applicability
Article 13 requires the risk assessment to indicate whether and how Annex I Part I point 2 requirements apply and how they are implemented, as well as how Part I point 1 and Part II vulnerability-handling requirements are applied. The risk record should therefore identify the relevant Annex I requirements for each important scenario. This creates traceability between the product-specific cybersecurity risk and the legal security outcome expected by the CRA.
- Map relevant Part I controls.
- Map Part II processes where applicable.
- Document non-applicability reasoning.
- Connect controls to product-specific risk.
- Preserve the mapping in technical documentation.
Avoid Treating the Risk Matrix as the Risk Assessment
A coloured risk matrix can summarise results but does not replace the underlying analysis. Reviewers should be able to understand the product context, attack scenario, preconditions, assets, consequence, existing controls and rationale behind the rating. A red, amber or green cell without this context provides weak evidence that Article 13 influenced product decisions. Use the matrix as an index into detailed risk records rather than as the complete assessment.
- Preserve scenario detail.
- Preserve assumptions.
- Preserve control references.
- Preserve rating rationale.
- Use summary matrices only as navigation.
Update Risk When the Product or Threat Environment Changes
Risk is not fixed at the initial release. A new remote interface can increase attack feasibility. A dependency vulnerability can create a new scenario. A security update can reduce risk. A changed deployment environment can invalidate an earlier assumption. Article 13 requires the documented cybersecurity risk assessment to be updated as appropriate during the support period. Manufacturers should therefore identify which changes require reassessment of affected risk records.
- Architecture changes.
- New interfaces.
- New vulnerabilities.
- Changed deployment assumptions.
- Control changes.
- New exploitation information.
Evidence for Product Cybersecurity Risk Assessment
A useful evidence package can include threat and attack-scenario records, risk-rating criteria, vulnerability assessments, architecture diagrams, control references, security test results and residual-risk decisions. Each material risk should identify the product version it applies to. Where judgement materially changes a rating, record the rationale. The objective is not to produce excessive paperwork but to create enough traceability that another qualified reviewer can understand how the manufacturer reached the risk conclusion.
- Risk methodology.
- Threat and attack-scenario records.
- Affected assets.
- Risk-rating rationale.
- Mapped controls.
- Verification evidence.
- Residual-risk conclusion.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.