Cyber Resilience Act Guide: How to Implement the CRA in 10 Steps

Before you take a single product through the CRA, you need an overview of your entire portfolio. This guide therefore starts with an inventory. First, list every product you sell or offer in the EU: hardware, firmware, off-the-shelf software, apps and companion apps, as well as the related remote data processing. In addition, record variants and versions, because every new product version has to meet the requirements.

Cyber Resilience Act: which products are in scope?

For each product, then check whether the CRA applies. It covers "products with digital elements" made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Art. 2). For this first triage, the current product description is enough; step 1 then sharpens the intended purpose for each product. Therefore, answer four questions:

• Is it a product with digital elements, i.e. hardware or software?
• Does its intended purpose or foreseeable use include a data connection?
• Do you make the product available on the EU market?
• Does an exemption apply?

For example, sectors with their own rules are exempt, such as medical devices, motor vehicles and civil aviation. Spare parts that replace identical components and are manufactured to the same specifications are also exempt (Art. 2(6)). Pure SaaS is not covered by the CRA (though it may fall under NIS2). Remote data processing that the manufacturer designed and without which the product cannot perform one of its functions, however, is part of the product.

Next, split the affected products into two groups. Products already on the market are subject to the reporting obligations today (step 7). In contrast, all requirements apply to products placed on the market from 11 December 2027. What counts is the individual unit: if you keep selling an existing product after that date, every unit you newly place on the market must therefore comply with the CRA.

Gap analysis: where do you stand today?

For the products in scope, the gap analysis follows. You compare your current state with the CRA requirements: security properties under Annex I Part I, vulnerability handling under Annex I Part II, reporting process, documentation and support period. The result is a prioritised list of open points. Ideally, start with the products already on the market, because the reporting obligations apply to them now. Furthermore, look early at important and critical products, since they often need a notified body and therefore a longer lead time.

Finally, capture the result as a roadmap: for each product, the open requirements, the people responsible and a target date. Involve product management, engineering, quality management, sales and legal from the start, because the CRA affects processes across the entire product lifecycle. The roadmap is therefore the basis for all further steps in this guide, which you then work through product by product.

For products that are already on the market, the article Cyber Resilience Act requirements for existing products describes four possible strategies. For a quick self-assessment, use the Cyber Resilience Act readiness check.

Before you think about standards, documents or reports, one question first needs a clear answer: what is your product for? The Cyber Resilience Act calls this the intended purpose: the use for which the manufacturer intends the product, including the specific context and conditions of use (Art. 3(23)). What counts is what you state in the instructions for use, promotional or sales materials and statements, and the technical documentation. In addition, the reasonably foreseeable use (Art. 3(24)) and the reasonably foreseeable misuse (Art. 3(25)) count as well.

Why the intended purpose decides so much

As a result, few details in the CRA have as many consequences:

• Scope: Whether the CRA applies at all depends on whether the intended purpose or foreseeable use includes a data connection to a device or network (Art. 2).
• Risk assessment: It analyses the risks based on the intended purpose and the reasonably foreseeable use (Art. 13(3)). This includes the operational environment and the assets to be protected. For example, a sensor in a living room has a different risk profile from the same sensor in an industrial plant.
• Support period: It reflects the expected time of use and explicitly takes into account the nature of the product, including its intended purpose (Art. 13(8)).
• Data minimisation: Furthermore, the product may only process the data necessary for its intended purpose (Annex I Part I).
• Documentation and user information: The intended purpose belongs in the technical documentation (Annex VII) and in the information for users (Annex II). There you must also point out any known or foreseeable circumstances, under intended use or reasonably foreseeable misuse, that may lead to significant cybersecurity risks.
• Substantial modification: If the intended purpose for which the product was assessed changes, that is a substantial modification and conformity must be reassessed (Art. 3(30)). However, security updates that do not change the intended purpose are not a substantial modification.

Cyber Resilience Act: marketing claims count

Marketing and sales claims also count. Advertising a consumer device on your website as "also suitable for industrial use" widens the intended purpose, and the risk assessment has to cover it. Conversely, the intended purpose is a design lever. If a requirement cannot be fully met, the manufacturer can, for example, restrict use to trusted environments; the CRA recitals name this option explicitly. An intended purpose that is too broad makes implementation expensive, whereas one that is too narrow leaves risks out. Therefore, define it deliberately and concretely, and align it between product management, engineering and marketing. That is why the Cyber Resilience Act makes it the foundation of everything that follows.

Step 0 showed which products fall under the CRA. For each product, two questions now follow: what is your role, and how do you evidence the classification? The Cyber Resilience Act distinguishes manufacturers (Art. 13), importers (Art. 19) and distributors (Art. 20). In addition, manufacturers outside the EU can appoint an authorised representative (Art. 18). Anyone who sells a product under their own name or substantially modifies it takes on the manufacturer's obligations (Art. 21 and 22). Furthermore, open-source software has its own role, the "open-source software steward" (Art. 24).

Also record in writing for each product why it does or does not fall under the CRA, and justify this with the intended purpose from step 1. As a result, the triage from step 0 becomes robust evidence for market surveillance and customers. For the rest of this guide, we assume the manufacturer role.

The product class ultimately determines the conformity route. Specifically, the CRA distinguishes:

• Default products (the vast majority): self-assessment by the manufacturer is possible.
• Important products, class I (Annex III), e.g. password managers, routers, operating systems, smart home products with security functions.
• Important products, class II (Annex III), e.g. hypervisors, firewalls, intrusion detection systems, tamper-resistant microprocessors.
• Critical products (Annex IV), e.g. hardware devices with security boxes, smart meter gateways and smartcards.

In addition, Implementing Regulation (EU) 2025/2392 of 28 November 2025 defines what exactly falls into each category. It contains technical descriptions for Annexes III and IV (Art. 7 and 8).

The Cyber Resilience Act checklist shows which products fall into which category, with concrete examples.

Next comes the core of the CRA: the risk assessment under Art. 13(2) and (3). Manufacturers assess the cybersecurity risks of their product and take the results into account during planning, design, development, production, delivery and maintenance. The aim is to minimise risks, prevent incidents and minimise their impact, including on the health and safety of users. Therefore, if you implement only one step of this guide thoroughly, make it this one.

What the risk assessment must contain

Art. 13(3) and (4) set the minimum content:

• Risk analysis: based on the intended purpose and the reasonably foreseeable use, such as the operational environment and the assets to be protected, taking into account the expected lifetime of the product.
• Applicability of requirements: for each security requirement in Annex I Part I point 2, whether it applies and how you implement it.
• Appropriate level of security: how you apply Annex I Part I point 1, i.e. ensure a level of cybersecurity appropriate to the risks.
• Vulnerability handling: how you implement the requirements of Annex I Part II.
• Justification: if an essential requirement does not apply, the technical documentation must include a clear justification.

In addition, the assessment is part of the technical documentation (Art. 31, Annex VII). For high-risk AI systems that also fall under the AI Act, it can furthermore be part of the risk assessment required there (Art. 13(4)).

Cyber Resilience Act: risk assessment with threat modeling

The Cyber Resilience Act does not prescribe a specific method. In practice, however, threat modeling has proven itself, because it turns the requirements of Art. 13 and Annex I into a repeatable process. It answers four guiding questions:

• What are we working on?
• What can go wrong?
• How are we going to address it?
• Did we do a good enough job?

Methods such as STRIDE, LINDDUN (privacy) or PASTA offer different perspectives. Which one you choose matters less. What counts is that you look at the whole system and do not overlook any critical area. In concrete terms, we recommend six steps:

1. Model the system: Draw a data flow diagram with external actors, processes, data stores, data flows and trust boundaries. Include companion apps and remote data processing.
2. Identify assets: for example personal data, credentials, firmware and security-relevant functions.
3. Identify threats: Examine each element systematically. Focus on points where identities are introduced, sensitive data is stored or trust levels change.
4. Rate risks: Assess impact and likelihood. Take controls already in place into account.
5. Derive measures: Reduce each risk until the residual risk is acceptable, and justify that decision.
6. Map to Annex I: For each requirement, record whether it applies and how you implement it.

Example: from threat to Annex I requirement

Take a connected device with an authentication service. Users log in over HTTPS, and credentials are stored in a database. The model shows three elements: the user as external entity, the authentication service as process and the database as data store. They are connected by the login data flow. This leads to three typical threats:

This chain of threat, control, requirement and technical documentation is exactly what notified bodies and market surveillance authorities will check. The reverse also holds. If a risk does not exist because of the architecture, intended purpose or operating environment, the corresponding control is not required. In that case, you document clearly why the requirement does not apply. This avoids unnecessary complexity while keeping you compliant.

Embedding threat modeling in your development process

Threat modeling is not a one-off exercise but part of your secure development lifecycle (SSDLC). Create the model during architecture design. After that, update it for major features and before each release. New interfaces, a move to new hosting or changed third-party components are also triggers for an update. In these cases, re-assess the risks and confirm that the controls are still adequate. Reusable templates and a shared vocabulary in the team help considerably. That is why the Cyber Resilience Act treats the risk assessment as a living document.

Third-party components and ongoing updates

Also include components from third parties, including open-source software. Manufacturers must exercise due diligence when integrating them, so that such components do not compromise the cybersecurity of the product (Art. 13(5)). Moreover, if you find a vulnerability in a component, report it to the person or entity that manufactures or maintains it (Art. 13(6)). Finally, the risk assessment is not a one-off document. You document it and update it as appropriate throughout the support period, for example after new vulnerabilities, information from third parties or product changes (Art. 13(3) and (7)).

For a detailed walkthrough of the method, see the Cyber Resilience Act threat modeling guide.

Annex I Part I lists the security requirements for the product itself. This guide highlights the most important ones:

• no known exploitable vulnerabilities at release and a secure-by-default configuration
• security updates, where applicable automatic by default with a clear and easy opt-out
• protection against unauthorised access through authentication and access control
• confidentiality and integrity of data, data minimisation
• a minimised attack surface and logging of security-relevant events
• secure deletion of data and settings by the user

CEN, CENELEC and ETSI are currently drafting harmonised standards that give a presumption of conformity. However, none had appeared in the Official Journal as of September 2026. Until then, the Cyber Resilience Act Requirements Standards Mapping by ENISA and the JRC maps each requirement to existing standards such as the IEC 62443 series.

The article Cyber Resilience Act guidance explained covers how the official Commission guidance interprets these requirements.

Cyber Resilience Act: information and instructions to the user (Annex II)

In addition to the technical requirements, the Cyber Resilience Act requires information and instructions to the user. They accompany the product in paper or electronic form (Art. 13(18)). Annex II sets the minimum content:

• the manufacturer's name, postal address, email address and, where available, website
• the single point of contact for reporting vulnerabilities and the coordinated vulnerability disclosure policy
• name, type and any additional information that uniquely identifies the product
• the intended purpose, the security environment, the essential functionalities and the security properties
• known or foreseeable circumstances, including reasonably foreseeable misuse, that may lead to significant cybersecurity risks
• where applicable, the internet address of the EU declaration of conformity
• the type of technical security support and the end date of the support period
• instructions for secure commissioning and use, installing security updates, turning off automatic updates and secure decommissioning, including removal of user data
• how changes to the product can affect the security of data
• for products intended for integration: information that helps the integrator meet Annex I and Annex VII
• if you make the SBOM available to users: where it can be accessed

The information must be clear, understandable and in a language that users and market surveillance authorities can easily understand. Moreover, you keep it available for at least ten years or for the support period, whichever is longer. We therefore recommend planning the user information from the start. Much of the content comes directly from the intended purpose, the risk assessment and the vulnerability handling process.

Annex I Part II requires an ongoing vulnerability handling process. This includes a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies. It also covers timely remediation through security updates, regular testing, a coordinated vulnerability disclosure (CVD) policy and a contact address for reporting vulnerabilities. Furthermore, you must publicly disclose fixed vulnerabilities.

Manufacturers must define a support period during which they handle vulnerabilities and provide security updates (Art. 13(8)). It must reflect the expected time of use, which follows from the intended purpose. As a rule, it lasts at least five years, unless the product is expected to be in use for less time. In addition, you must clearly state the end date (at least month and year) at the time of purchase. Each security update must remain available for at least ten years after its release or for the remainder of the support period, whichever is longer.

The article Cyber Resilience Act vulnerability reporting sets out what happens once a vulnerability is reported to you.

Art. 14 has applied since 11 September 2026 to all products in scope, including those placed on the market before 11 December 2027. Consequently, it is the only step in this guide that is already legally binding today. There are two separate reporting tracks via ENISA's Single Reporting Platform (SRP). As a result, each report reaches the coordinating CSIRT of your Member State and ENISA at the same time.

Deadlines run from the moment the manufacturer becomes aware. Moreover, you must inform affected users about the vulnerability or incident and any mitigation measures (Art. 14(8)). Delegated Regulation (EU) 2026/881 lays down the conditions under which the dissemination of a notification to other CSIRTs can be delayed on cybersecurity grounds. ENISA's SRP FAQ finally answers detailed questions.

The article Cyber Resilience Act reporting deadlines explains when the clock starts.

All previous steps of this guide eventually feed into the technical documentation. You must complete it before the product is placed on the market (Art. 31, Annex VII). It covers the product description, design and architecture, risk assessment, standards applied, vulnerability handling process, test reports and the declaration of conformity. It also includes the SBOM, which you provide to market surveillance authorities on request. Add the Annex II information and instructions to the user from step 5. Furthermore, you must keep all documents for ten years or for the support period, whichever is longer (Art. 13(13)).

The worked example Cyber Resilience Act compliance in practice shows what this looks like for a real product.

The applicable procedure depends on the product class (Art. 32, Annex VIII). Consequently, this is where the classification from step 3 pays off:

• Default products: internal control by the manufacturer (module A); the stricter procedures are also available.
• Important products, class I: module A only if harmonised standards, common specifications or a European cybersecurity certification (assurance level “substantial” or higher) are fully applied. Otherwise, EU-type examination (module B + C) or full quality assurance (module H) applies.
• Important products, class II: module B + C or module H with a notified body, or a European cybersecurity certification at assurance level “substantial” or higher.
• Critical products: European cybersecurity certification where required; otherwise as for class II.

The article Cyber Resilience Act conformity assessment compares the paths in detail, and the role of notified bodies and the BSI explains who is involved.

Incidentally, the rules on notified bodies (Chapter IV) have applied since 11 June 2026. ENISA explains how the EU certification scheme EUCC fits in: CRA implementation via EUCC.

Finally, after a successful assessment, the manufacturer issues the EU declaration of conformity (Art. 28, Annex V) and affixes the CE marking (Art. 30). That is not the end, though. Any substantial modification, such as a new feature that changes the risk profile or a change to the intended purpose, can trigger a new conformity assessment. Security updates that do not change the intended purpose are not a substantial modification. That is why the Cyber Resilience Act calls for an ongoing process, not a one-off project.

The article substantial modification and the support period explains when a change counts as substantial.