EU Cyber Resilience Act FAQ Cybersecurity Risk Assessment

Article 13 requires the manufacturer to assess the cybersecurity risks associated with a product with digital elements and use the outcome during planning, design, development, production, delivery, and maintenance.

The assessment should show how the manufacturer is minimising cybersecurity risks, preventing incidents, and reducing incident impact, including effects on user health and safety where relevant. It should connect product assumptions, threats, mitigations, tests, and residual risks to the essential requirements in Annex I.

Every in-scope product with digital elements needs one. Classification as an important or critical product affects conformity assessment routes and assurance expectations, but it does not supersede the Article 13 risk assessment.

The Commission FAQ is explicit that default-category, important, and critical products all require a comprehensive cybersecurity risk assessment. The depth of treatment should reflect the product's actual risk profile, intended use, deployment context, and expected exposure.

At minimum, Article 13(3) requires an analysis of cybersecurity risks based on the product's intended purpose, reasonably foreseeable use, conditions of use, and the length of time the product is expected to be in use.

The conditions of use can include the operational environment, the assets to be protected, user skill assumptions, connected systems, and deployment constraints. Those inputs should be specific enough to explain why particular Annex I requirements apply, why others do not, and how selected controls are proportionate to the risks.

They define the threat model and the level of risk treatment expected for the product. The same type of product may require different controls if one version is intended for a residential setting and another is intended for critical infrastructure or another high-exposure environment.

Reasonably foreseeable use is broader than the manufacturer's preferred use case. It covers uses likely to result from foreseeable human behaviour, technical operations, or interactions. The assessment should therefore record excluded assumptions, supported environments, user groups, and foreseeable integrations that materially affect cybersecurity.

Yes. The CRA user-information rules require disclosure of known or foreseeable circumstances linked to intended use or reasonably foreseeable misuse that may lead to significant cybersecurity risks.

For the assessment, that means manufacturers should not rely only on ideal secure deployment. If misuse, misconfiguration, insecure integration, unsupported environments, or predictable user behaviour could create significant cybersecurity risk, the record should show whether the risk is mitigated in the product, constrained by instructions, or treated as a residual risk communicated to users.

Use the assessment to decide which Annex I requirements apply and what evidence shows that each applicable requirement is met. The mapping should cover both product properties in Annex I Part I and the manufacturer's vulnerability-handling processes in Part II.

If an essential cybersecurity requirement is not applicable, the technical documentation must contain a clear justification. Non-applicability does not end the analysis: where the manufacturer identifies a related cybersecurity risk, it must address that risk by other means, such as restricting the intended environment or giving users specific risk information.

Assess risks created by integrated hardware and software components, remote data processing solutions, interfaces, connected systems, and relevant outside dependencies. Component due diligence under Article 13(5) is a separate obligation, but its results should feed the product risk assessment.

Record the component version and function, privilege and exposure, known vulnerabilities, support status, update path, supplier or maintainer evidence, mitigations, and what happens if upstream support ends before the product's support period. The finished-product manufacturer remains responsible for the product as a whole.

Retain the assessment itself and enough linked evidence for a reviewer to follow the decision from product facts to controls. This normally includes the intended purpose and conditions of use, architecture and data flows, assets and trust boundaries, threat scenarios, component and dependency records, applicable and non-applicable Annex I requirements, mitigations, verification results, residual-risk decisions, and the support-period rationale.

Annex VII requires the technical documentation to be continuously updated where appropriate during the support period. Keep version history and decision records so a market surveillance authority or conformity assessment body can tell which product version, risks, requirements, and tests each assessment covered.

Review it when new information can change the product's risks or the evidence supporting conformity. Triggers include a new vulnerability, changed threat or exposure, a component or supplier change, an unsupported dependency, a new interface or remote service, changed intended purpose or conditions of use, a functionality update, a security incident, or test results that invalidate an assumption.

Article 13(7) requires manufacturers to document relevant cybersecurity aspects and, where applicable, update the assessment. A change that affects Annex I Part I compliance or changes the intended purpose can also be a substantial modification, requiring the person making the change to reassess conformity before the modified product is made available.

No single template or named threat-modelling method is prescribed by Article 13. The manufacturer may use a method suited to the product, provided the result covers the legally required inputs, supports the Annex I decisions, is proportionate to the risks, and can demonstrate conformity.

A checklist without product-specific threat, exposure, control, and residual-risk reasoning is not enough. Whatever method is used, keep the reasoning traceable across product versions and connect it to design evidence, tests, vulnerability handling, user information, and the conformity assessment.