Cyber Resilience Act Cybersecurity Risk Assessment: Article 13 and Annex I in Practice

Julian Meroi · Published 23 October 2026 · Last reviewed 3 November 2026

Every manufacturer of a product with digital elements must assess the product’s cybersecurity risks and use the result throughout planning, design, development, production, delivery and maintenance. The aim is to minimize cybersecurity risks, prevent incidents and minimize their impact, including on the health and safety of users. The obligation applies to every in-scope product, whatever its category. Article 13(1)-(2), Commission FAQ, section 4.1.1.

The risk assessment decides which product requirements in Annex I apply and how they are met, and it goes into the technical documentation when the product is placed on the market. This guide explains what it must contain and how to work through it, with a hypothetical example. Article 13(4).

The CRA’s main obligations apply from December 11, 2027. Products placed on the market before that date fall under its requirements only if they are substantially modified from that date, while the Article 14 reporting obligations already apply. Article 71(2), Article 69(2)-(3).

What the risk assessment must contain

Article 13(3) sets the minimum. The documented risk assessment must:

• analyze cybersecurity risks based on the product’s intended purpose and reasonably foreseeable use, its conditions of use, such as the operational environment or the assets to be protected, and the length of time it is expected to be in use;
• indicate whether, and if so how, each security requirement in Annex I Part I point (2) applies to the product, and how it is implemented as informed by the assessment;
• indicate how the manufacturer applies Annex I Part I point (1), the requirement to ensure an appropriate level of cybersecurity based on the risks;
• indicate how the manufacturer applies the vulnerability handling requirements in Annex I Part II.

It must be documented and updated as appropriate during the support period. Article 13(3), Annex I.

The CRA does not prescribe a methodology. According to the Commission services’ FAQ, the method should let a market surveillance authority verify how risks were identified, evaluated and mitigated, and the threat model should fit the product’s intended purpose and foreseeable use: a product intended for critical infrastructure may need to consider advanced, state-backed attackers, while a consumer product typically has a lower risk profile. Commission FAQ, section 4.1.2.

Define what you are assessing

The whole product. The assessment covers the entire product with digital elements, including any remote data processing solution that forms part of it. Our CRA product classification guide explains how to settle that boundary. Article 3(1), Commission guidance, paragraph 178.

Use, foreseeable use and misuse. The CRA defines three related ideas:

• intended purpose: the use the manufacturer intends, including the context and conditions of use stated in its instructions, sales material and technical documentation;
• reasonably foreseeable use: use that is not necessarily the stated purpose but is likely to result from reasonably foreseeable human behavior or technical operations or interactions;
• reasonably foreseeable misuse: use contrary to the intended purpose that may result from reasonably foreseeable human behavior or interaction with other systems.

The assessment must cover the first two. Circumstances under intended use or foreseeable misuse that may lead to significant cybersecurity risks must also appear in the user information. The FAQ gives the example of a professional product, such as an industrial sensor, that non-professionals may end up using. Article 3(23)-(25), Annex II, point 5, Commission FAQ, sections 4.1.4-4.1.5.

Variants. Variants of one product family can share a single risk assessment where they have the same architecture, security-relevant design and intended purpose, and face the same risks. Differences in communication interfaces, software stacks, update mechanisms or remote connectivity must be reflected in it. Commission guidance, paragraphs 174-177.

Work through Annex I, requirement by requirement

The vulnerability handling requirements in Annex I Part II apply throughout the support period. The product requirements in Part I point (2) apply as determined by the risk assessment. Where one does not apply, the technical documentation must contain a clear justification. The FAQ gives two typical reasons: the requirement is incompatible with the nature of the product, or there is no risk that needs mitigating, for example data-protection measures for a product whose intended purpose and foreseeable use involve no personal data. Article 13(4), Commission FAQ, section 4.1.3.

The questions in this table are an example of implementation based on Article 13(3) and Annex I. The CRA does not prescribe these questions; the Annex I page carries the full legal wording, which controls.

Some requirements can be met only partly because of the product’s intended purpose, for instance where it must interoperate with existing systems that support only an older protocol. The Commission guidance expects the manufacturer to document the constraint, assess the associated risks, put in place compensating measures, and reassess periodically whether the constraint still exists. Our CRA technical documentation guide shows how to record this. Commission guidance, paragraphs 31-32 and example 10.

Decide when residual risk is acceptable

Residual risk cannot be eliminated, but under the CRA it is not judged against the company’s own risk appetite. The test is whether the product ensures an appropriate level of cybersecurity based on the risks, given its intended purpose and reasonably foreseeable use. The Commission guidance states that internal risk tolerance, commercial strategy and cost considerations are not relevant to that question, and that the CRA does not allow risk to be transferred to users or third parties to make up for design shortcomings. Commission guidance, paragraphs 157-161.

Risk treatment can include:

• reducing the attack surface;
• implementing technical safeguards;
• limiting or adapting functionality;
• defining the intended purpose more precisely;
• shaping foreseeable use through risk communication, user guidance or interface design.

User information supports secure deployment and informs users of residual risks; it does not replace product measures. The guidance gives two examples: an industrial sensor without physical-attack protection whose intended purpose is limited to trusted environments, stated clearly in its instructions, and a business application that relies on the operating system’s mature built-in encryption. Where risks cannot be adequately addressed, the design, functionality or intended purpose has to change. Commission guidance, paragraphs 160-163 and examples 66-67.

Annex I Part I point (1) covers identified risks that the other Part I requirements do not already address. Where all relevant risks are treated through the other requirements, point (1) is met; otherwise additional product measures are needed. Commission guidance, paragraphs 164-166.

Risks from outside the product and from components

External risks. The assessment must consider risks that originate outside the product, such as networks, back-end systems and outages. The CRA does not regulate that external infrastructure; the manufacturer addresses those risks through product-level measures. The guidance’s examples include cryptographic authentication of remote commands, integrity checks on configuration changes, security logs or alerts on abnormal behavior, and ensuring an outage does not leave the product in an insecure state. Commission guidance, paragraphs 167-169 and 172.

Third-party components. Components integrated into the product are part of the risk assessment, and Article 13(5) adds a separate duty of due diligence so that they do not compromise the product’s cybersecurity. In practice, identify what the product needs from each component, for example cryptographic functions, update mechanisms or secure communications, and verify in a risk-based way that the component provides it, using its manufacturer’s documentation or your own tests. Article 13(5), Commission guidance, paragraphs 170-173.

Standards. Applying a harmonized standard does not replace the risk assessment. The FAQ notes that the manufacturer remains responsible for assessing all risks and must check whether a standard covers them; where it covers only part, other specifications or solutions are needed. The next section explains how the EN 40000 standards fit in. Commission FAQ, section 4.1.7, Article 27.

How the EN 40000 standards support the risk assessment

Under the Commission’s standardization request M/606, the European standards organizations are preparing a family of horizontal standards, EN 40000 “Cybersecurity requirements for products with digital elements”, that apply across product categories. Product-category (vertical) standards for the products listed in Annexes III and IV are being prepared alongside them. M/606 work programme, CEN, CENELEC and ETSI.

The evidence column is our suggestion for organizing the work, based on Article 13, Annex I and the published scopes. It does not reproduce or replace the standards’ own requirements.

Status, as recorded by CEN and DIN on October 23, 2026:

• EN 40000-1-2:2026 was ratified on November 2, 2026. On November 3, 2026, the CEN record showed it as approved, with the final text due for distribution on November 18, 2026 and national implementation required by May 31, 2027. Earlier drafts were titled “Principles for cyber resilience”. The CEN record states that no citation in the Official Journal under the CRA is expected. CEN project record, EN 40000-1-2.
• prEN 40000-1-3 is under approval, and the CEN record states that a citation in the Official Journal is expected. CEN project record, prEN 40000-1-3.
• EN 40000-1-4 is still in development; the M/606 work programme (April 2025 version) sets its adoption deadline at October 30, 2027. The draft uses the EN 18031 series, written for radio equipment, as an input. DIN project record.

Standards move through several separate steps: adoption by the European standards organizations, publication by national standards bodies, and citation of the reference in the Official Journal. Only the last gives a presumption of conformity, and only for the requirements a standard covers. Check the current record before relying on any part. Article 27(1).

Using EN 40000-1-2 with your own assessment. EN 40000-1-2 describes a risk-based process for the whole product lifecycle. It gives a structure for the steps this guide covers: set the scope, intended and foreseeable use, operating environment, assets, dependencies and trust boundaries; identify and evaluate risks; decide which Annex I requirements apply; select and justify measures; verify that they work; and keep the assessment current. It does not do the assessment for you. A standards committee writes for products in general or for a product category; your assessment concerns your product, its users and its environment. A category label or a completed checklist does not show on its own that your product’s risks are adequately treated.

From risks to requirements and processes. The outputs of the risk assessment feed two other activities. For the product requirements in Annex I Part I(2), EN 40000-1-4 is being drafted as a set of requirements with assessment criteria, to be selected according to the identified risks; vertical standards add or tighten requirements for specific product categories. For the processes in Annex I Part II, EN 40000-1-3 covers vulnerability handling over the support period. Information from vulnerability handling, tests and suppliers then flows back into the risk assessment. The final texts will settle how closely each vertical standard cross-references EN 40000-1-4, so check the published versions.

Reusing existing evidence. Secure-development and test evidence from other frameworks can feed this work where it covers the same product, version and risks. Work done against EN 18031 for radio equipment is a natural input for EN 40000-1-4. IEC 62443 assessments can also contribute, within their own scope; our IEC 62443 and Cyber Resilience Act guide explains how. Neither family is equivalent to EN 40000, so map each item of evidence to the specific CRA requirement it supports. How conformity is then demonstrated depends on the product’s category, explained in our CRA product classification guide.

Example: a connected sensor with a cloud dashboard

Example Sensor 1.0 is a hypothetical network-connected environmental sensor for commercial buildings. It ships with firmware 1.0 and a cloud dashboard developed by the manufacturer, which the sensor needs in order to report its readings, so the dashboard is assumed to be part of the product. Its intended purpose is installation by building technicians on a building’s operational network. Its category is assumed to have been determined already; nothing below depends on it.

One risk, traced from assumption to review. This shows the reasoning behind one treatment decision.

• Product and assumptions: firmware 1.0 and dashboard release 1.0. Building networks are foreseeably shared with office devices and visitor equipment.
• Asset and threat: the sensor’s configuration, which sets where it sends readings and which alarms it raises. An attacker on the building network intercepts or injects configuration messages between the dashboard and the sensor.
• Evaluation: the attack needs only access to the local network, which is foreseeable here, so feasibility is significant. A forged configuration could silence alarms or redirect data, so the impact on the building operator is high. Left untreated, the risk is not acceptable.
• Applicable requirements: Annex I Part I(2)(f), integrity of commands and configuration, and (d), protection from unauthorized access.
• Treatment decision: sign each configuration message with a key held by the dashboard’s signing service. The signed content includes the sensor’s device identifier and a configuration version number that increases with every change. The sensor applies a message only if the signature verifies, the identifier is its own and the version is higher than the last one it applied, which it keeps across restarts; it rejects and logs anything else. The signature shows that the message comes from the dashboard and has not been altered, and the version check stops an old, validly signed message from being replayed.
• Verification and expected evidence: tests from a device on the same network that send unsigned and altered messages, replay an earlier signed message, and send a message signed for a different sensor, with the expected result that the sensor rejects and logs each one and keeps its current configuration, including after a restart. Planned evidence: the test plan and, once run, the test report for firmware 1.0.
• Remaining risk and review trigger: this measure does not address a compromise of the dashboard’s signing service itself, which would let an attacker sign hostile configuration. That is a separate risk, assessed against the dashboard as part of the product, with its own measures such as isolating the signing service and controlling who can approve configuration changes. Review the assessment when the key management changes, when a new message type is added, or when tests or vulnerability reports show weaknesses.

The rest of the same assessment, in summary. The rows give at least one risk for each point of Part I(2), in order of the point, and they are a sample: a real assessment usually identifies several risks under each point and examines the dashboard in the same depth as the sensor.

This is an example of implementation based on CRA Article 13(3) and Annex I. The CRA does not mandate this trace, these columns, any scoring or these measures; the evidence listed is planned, not completed, and these rows are a sample that does not make a complete risk assessment.

The full assessment for Example Sensor 1.0 would record every risk identified for the sensor and the dashboard, justify any point of Part I(2) that does not apply, state how Part I(1) and Part II are applied, and record the due diligence on its third-party components. Our CRA SBOM requirements guide shows how to build and check the component inventory behind the first row.

What the evidence looks like in practice. For the product, keep the architecture and its assumptions, the reasoning behind each risk decision, the applicability and non-applicability decisions, design and configuration records, and product test results. For the processes, keep the outputs of vulnerability intake, triage, remediation, disclosure and update distribution. When new vulnerability reports, test results or supplier information arrive, record them, update the risk assessment and the affected measures, and update the technical documentation. Our CRA technical documentation guide covers how to organize that file. Article 13(7).

Keep the assessment current

The risk assessment is updated as appropriate during the support period. Manufacturers must also systematically document relevant cybersecurity aspects, including vulnerabilities they become aware of and relevant information from third parties, and update the assessment where applicable. The FAQ adds that the results of the regular security tests and reviews required by Annex I Part II(3) should feed back into it, and that where the assessment relies on user information to address a risk, that information must be updated too. Article 13(3), Article 13(7), Commission FAQ, sections 4.1.6 and 4.1.8.

Products designed before the Cyber Resilience Act applies

A product designed before December 11, 2027 but placed on the market after that date does not necessarily need to be redesigned. The risk assessment determines which Part I requirements apply and how. Where existing measures already address the risks, the manufacturer can rely on them. Where the design history cannot show how risks were considered, the assessment must demonstrate that the product as it stands has adequate measures. The conformity assessment, EU declaration of conformity and CE marking still apply. Commission guidance, paragraphs 33-36.

How Meroi Security can help

Meroi Security can carry out or review a product’s cybersecurity risk assessment against Article 13 and Annex I, document applicability and justifications, and connect the measures to the technical documentation and conformity assessment. Explore our Cyber Resilience Act compliance services.