Cyber Resilience Act step by step: readiness for manufacturers

A practical CRA readiness path for manufacturers: confirm scope and classification, close Annex I gaps, run vulnerability handling and reporting, and plan conformity assessment and CE marking before December 2027.

This guide is for manufacturers of connected hardware and software, and for the product security, engineering and compliance teams who have to make the Cyber Resilience Act (CRA) work. The roles of importers, distributors and open-source stewards are covered too. By the end you will have a confirmed scope and role per product, a classification decision, an Annex I gap analysis, a working vulnerability handling and reporting process, and a plan for documentation, conformity assessment and CE marking.

Before you start

The CRA is product legislation in the CE marking tradition, not an organisational standard like ISO 27001. Compliance is assessed per product. You need a portfolio list that includes software-only products, firmware, companion apps and cloud back ends; a named product security owner (usually a PSIRT lead) with influence over release decisions; and access to architecture diagrams, build pipelines and dependency manifests. The legal text is on EUR-Lex^[1], and the Commission publishes guidance and FAQs on its implementation page^[3]. For an overview, see our Cyber Resilience Act page.

Step 1: Confirm scope and your role per product

The CRA covers products with digital elements whose intended or reasonably foreseeable use includes a data connection to a device or network, including the remote data processing a product needs to perform its functions. Products covered by specific sector rules, such as medical devices, motor vehicles and civil aviation, are excluded. Standalone SaaS generally falls under NIS2 rather than the CRA.

• Record per product whether it is in scope, and any exclusion you rely on.
• Determine your role. A manufacturer develops or has the product developed and markets it under its own name. An importer places a non-EU manufacturer’s product on the EU market. A distributor makes it available further down the chain. An open-source software steward is a legal person that systematically supports free and open-source software intended for commercial activities.
• Watch for role shifts: an importer or distributor that rebrands or substantially modifies a product takes on manufacturer obligations.
• List products already on the market. They only face the full requirements if substantially modified after 11 December 2027, but Article 14 reporting applies to them.

Step 2: Classify each product

Most products fall in the default category. Annex III lists important products. Class I includes operating systems, browsers, password managers, VPNs, routers, SIEM systems and smart home security products such as door locks and cameras. Class II includes hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors and microcontrollers. Annex IV lists critical products: hardware devices with security boxes, smart meter gateways, and smartcards and secure elements.

Implementing Regulation (EU) 2025/2392 of 28 November 2025 gives the technical description of each category and entered into force on 21 December 2025^[2]. What counts is the product’s core functionality. A product that merely integrates a listed component does not become an important product for that reason alone.

• Compare each product’s core functionality with the descriptions in the implementing regulation, not only the short labels in the annexes.
• Write a short rationale per product, especially for borderline cases.

Step 3: Assess risk and map the gaps to Annex I

Article 13 requires a cybersecurity risk assessment that informs planning, design, development, production, delivery and maintenance, and that determines how each Annex I requirement applies. Annex I Part I asks, in summary, for products delivered without known exploitable vulnerabilities, with a secure default configuration, with security updates (automatic by default where appropriate), access control, confidentiality and integrity protection, data minimisation, availability, a limited attack surface, incident impact reduction, security logging and secure data removal.

• Threat-model each product or product family across hardware, firmware, software and back end.
• For each Annex I requirement, record applicability, how it is met, evidence and remaining gap. Justify anything marked not applicable.

The companion template includes an Annex I checklist covering every Part I and Part II requirement, a classification worksheet and a timeline.

Step 4: Set up vulnerability handling, including an SBOM

Annex I Part II applies for the whole support period. Manufacturers must document components, including a software bill of materials (SBOM) in a common machine-readable format covering at least top-level dependencies; remediate vulnerabilities without delay; test regularly; disclose fixed vulnerabilities; maintain a coordinated vulnerability disclosure (CVD) policy and a reporting contact; distribute updates securely; and provide security updates free of charge with advisories.

• Generate SBOMs per build (SPDX or CycloneDX) and store them per release. You do not have to publish them.
• Set the support period: at least five years unless the product is expected to be used for less, and visible to buyers.
• Publish a CVD policy and security contact, for example via security.txt, and run a PSIRT intake with triage targets.
• Report vulnerabilities you find in integrated components, including open-source code, to their maintainers.

Step 5: Make reporting work now

Since 11 September 2026, manufacturers must notify every actively exploited vulnerability and every severe incident affecting product security through ENISA’s Single Reporting Platform^[4]. The report reaches the coordinating CSIRT of the Member State of the main establishment and ENISA at the same time.

Stage	Actively exploited vulnerability	Severe incident
Early warning	24 hours after becoming aware	24 hours after becoming aware
Notification	72 hours after becoming aware	72 hours after becoming aware
Final report	14 days after a corrective measure is available	One month after the notification

• Define who decides that a vulnerability is actively exploited, and when the clock starts.
• Register on the platform and rehearse a submission.
• Prepare report templates and a process to inform affected users. Our incident reporting playbook aligns CRA reporting with NIS2, DORA and GDPR.

Step 6: Choose the conformity assessment route

Under Article 32, default products may use internal control (module A). Important class I products may use module A only if harmonised standards, common specifications or a certification scheme at level “substantial” have been fully applied; otherwise they need modules B and C or module H with a notified body. Class II products always need a third party. Critical products must use a European cybersecurity certification scheme where a delegated act requires it, otherwise the class II routes. Important free and open-source products may use module A if their technical documentation is public.

• Track harmonised standards. At the time of writing the Commission plans the first deliverables in 2026 and more in 2027^[3].
• If you need a notified body, book early. Their rules apply from 11 June 2026 and capacity will be tight near December 2027.

Step 7: Compile the technical documentation

Article 31 and Annex VII require documentation covering the product and intended purpose, design and production, the vulnerability handling process, the SBOM, the risk assessment, the support period rationale, standards applied, test reports and the declaration of conformity. Keep it for ten years after placing on the market, or for the support period if longer. Annex II sets the user information, including the vulnerability contact and the end of support.

In Secrato, this step maps to Policy & Evidence Management, where each Annex I control result and its evidence link to the product’s documentation set.

Step 8: Declare conformity, affix CE marking and maintain

After the assessment, draw up the EU declaration of conformity (Article 28, Annex V) and affix the CE marking (Article 30). For software it may be placed on the declaration or the accompanying website. Compliance continues during the support period: keep handling vulnerabilities, keep each security update available for at least ten years or the remaining support period if longer, and assess whether changes are substantial modifications that need a new assessment.

• Brief importers and distributors on what they must check before selling.
• Review the risk assessment and Annex I matrix with every major release, and hold a yearly management review.

How this connects to other frameworks

The CRA regulates the product; NIS2, ISO 27001 and CyFun regulate the organisation. Secure development, vulnerability management, supplier management and incident response under ISO 27001 Annex A or NIS2 Article 21 still provide much of the process evidence the CRA expects. Until harmonised CRA standards exist, IEC 62443-4-1 and 4-2 (industrial) and ETSI EN 303 645 (consumer IoT) are useful references.

Frequently asked questions

Does the CRA apply to products we already sell?

Products placed on the market before 11 December 2027 only need to meet the full requirements if substantially modified afterwards. Article 14 reporting applies to them from 11 September 2026.

Do we have to publish our SBOM?

No. It is part of the technical documentation and must be provided to market surveillance authorities on request.

We only develop open-source software. Are we a manufacturer?

Not necessarily. Open-source software supplied outside a commercial activity is out of scope. A foundation that systematically supports it for commercial use may be a steward, with a lighter regime and no fines. If you monetise the product itself, you are probably a manufacturer.

Is SaaS in scope?

Standalone SaaS generally is not. A cloud back end that a device needs to perform its functions is part of that product.