CRA cybersecurity risk assessment

Risk assessment role

For the purpose of complying with paragraph 1, manufacturers shall 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 digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.

Regulation (EU) 2024/2847, Article 13(2)

Article 13 requires the risk assessment to follow the product lifecycle and to be updated as appropriate during the support period.

What the assessment explains

Under Article 13(3), the assessment must consider intended purpose, reasonably foreseeable use, conditions of use, the operational environment, assets to be protected, and expected use time.

• which Annex I Part I requirements apply to the product;
• how those product requirements are implemented;
• how the general risk-based cybersecurity requirement in Annex I Part I point (1) is applied;
• how the Annex I Part II vulnerability-handling requirements are applied;
• why a requirement is not applicable, when that is the manufacturer's conclusion.

Example: assessing a firmware update path

Consider a fictional connected controller that receives firmware from an update service. An attacker may try to replace the image before installation. The assessment needs to establish whether this is possible and what the modified firmware could do.

1. Establish the update path for the controller model and firmware release. Identify who can supply an image, how it reaches the device and what checks occur before installation.
2. Describe the threat: an attacker substitutes a firmware image before installation. The asset is the integrity of executable code; the consequence depends on the functions the controller can change.
3. Assess the existing controls: determine where the image is verified, which signing keys are trusted, and what happens after failed verification. A design statement alone does not establish the behaviour of the released version.
4. Link measures to verification: retain the approved update design and tests for modified images, incorrect signatures, and failure recovery. Record the tested firmware and configuration.
5. Explain the remaining risk using the attack conditions and expected consequences. Identify any assumption that still needs confirmation and any further measure needed. Review the conclusion when the update mechanism or threat changes.

A data flow diagram (DFD) and STRIDE can help identify attack paths for this analysis. The risk decision still needs the product facts and verification results. For example, the team should confirm signature checking against the design and the tested firmware before relying on it to reduce risk.

Technical documentation link

Article 13(4) puts the cybersecurity risk assessment into the technical documentation. Annex VII then requires the documentation to include an assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered, and maintained.

Standard support

The draft prEN 40000-1-2 page explains the current horizontal principles document for cyber-resilience risk management. It can help structure the work, but the legal duty still comes from Article 13 and Annex I.