EU Cyber Resilience Act – Action Guide
Cyber Resilience Act: What needs to be done?
The CRA imposes clear obligations on manufacturers, importers and distributors of connected products. This page sets out a practical sequence of steps – without regulatory jargon.
Step 1
Check applicability: does the CRA apply to my organisation?
The Cyber Resilience Act (EU 2024/2847) applies to all manufacturers, importers and distributors of products with digital elements – specifically: hardware and software that has or enables a network connection. In scope are devices of all kinds (IoT, routers, smart home, industrial hardware), embedded software, firmware and application software placed on the market as a standalone product.
Generally out of scope are pure SaaS services without a local software component, medical devices (MDR/IVDR), aviation products (EASA) and motor vehicles (UNECE WP.29) – these are subject to their own security regulations. In practice the boundary is not always clear: B2B software integrated into another manufacturer’s product and cloud services with a local agent component sit in a regulatory grey area that requires legal assessment.
Output of step 1: a list of all products for which the CRA applies – with justification. This list is the basis for all subsequent steps. Without a clear applicability assessment no meaningful resource planning is possible.
Step 2
Determine product class: standard, Class I or Class II?
The CRA differentiates by risk class, which prescribes different conformity routes. Standard products – the majority of all connected products – can undergo self-assessment by the manufacturer. Class I products (critical) such as password managers, browsers, VPN clients, identity management software, network switches and home-automation devices require either assessment by a notified body or adherence to a harmonised European standard.
Class II products (highly critical) – including firewalls, industrial routers, hardware security modules (HSM), operating systems, microcontrollers with security functions and software for critical infrastructure – mandatorily require assessment by a notified body. This assessment is demanding, time-consuming and must be planned: notified bodies have capacity constraints and lead times grow as deadlines approach.
Classification follows Annexes III and IV of the CRA Regulation. For products that do not fit cleanly into a category, a combined technical and legal assessment is decisive. Mis-classification – particularly under-classifying a Class II product as standard – is a significant liability risk.
Step 3
Gap analysis: where do we stand today?
A structured gap analysis compares existing processes, tools and documentation with CRA requirements on a product-by-product basis. Typical findings: no formal threat modelling, no automated SBOM generation, no vulnerability disclosure process, incomplete or non-machine-readable dependency documentation, missing incident-response processes for product vulnerabilities.
At the same time, the gap analysis surfaces what is already in place: ISO 27001 certifications cover parts of vulnerability management; existing SDLC processes often already contain security reviews; vulnerability-scanning tools are frequently already deployed, just not structured into a CRA conformity path.
Output of step 3: a prioritised list of the most critical gaps and a realistic roadmap aligned to the September 2026 and December 2027 deadlines. Priority is on the gaps with the highest regulatory risk and the longest implementation horizon – security-by-design processes take significantly longer than producing technical documentation.
Scope and approach of a CRA gap analysis in detailStep 4
Introduce Security by Design
Security by Design is the central requirement of the CRA: security aspects must be addressed systematically from the very first design decision, not as an afterthought. In practice this means: threat modelling as a fixed part of product development (STRIDE, PASTA or attack trees), secure coding standards (OWASP Secure Coding Practices, CERT/SEI C/C++ Coding Standard) and automated security testing in the CI/CD pipeline.
Automated security testing covers at a minimum: Static Application Security Testing (SAST) to detect code-level weaknesses during the build, Software Composition Analysis (SCA) to detect vulnerabilities in third-party components and – where applicable – Dynamic Application Security Testing (DAST) and fuzzing. These tests must not only be introduced but also documented: results, finding handling, exceptions.
Security by Design is the most time-consuming part of CRA implementation, because it changes processes and culture – not just tools. Development teams need training. Processes have to be adapted. Regression tests have to be expanded. Plan for at least 6–12 months for substantive adoption in an existing engineering organisation.
Step 5
Build an SBOM: Software Bill of Materials as a CRA obligation
The CRA requires manufacturers to produce and maintain a machine-readable Software Bill of Materials (SBOM) for every product. The SBOM is the parts list of all software components: libraries, frameworks, dependencies and runtimes – with exact version information. Accepted formats are SPDX (ISO/IEC 5962) and CycloneDX.
Technical SBOM generation is tractable with modern tools (Syft, cdxgen, SPDX tools, build plug-ins for Maven, Gradle, npm, pip) and should be implemented as an automated build step rather than a manual process. The decisive next step is continuous matching of the SBOM against current vulnerability databases (NVD, OSV, GHSA) to detect newly reported CVEs in deployed components immediately.
A working SBOM system produces new vulnerability alerts every day – and therefore requires a defined triage process: which CVEs are actually exploitable in the specific product? What is the priority? Who decides, and by when? Without this process an SBOM is regulatorily worthless. VEX documents (Vulnerability Exploitability eXchange) enable structured documentation of these decisions.
Step 6
Set up reporting processes: ENISA obligations from September 2026
From September 2026, manufacturers must report actively exploited vulnerabilities in their products to ENISA and the competent national authority within 24 hours of becoming aware. An early warning report follows within 72 hours and a final report within 14 days. These deadlines are non-negotiable and presuppose that a functioning detection, triage and escalation process is already operational.
Prerequisites for meeting these deadlines: a vulnerability monitoring system that detects new CVEs in real time; clear responsibilities for initial assessment (is the vulnerability actively being exploited in our product?); and a prepared reporting procedure with knowledge of the national authority and ENISA notification process. Anyone building this infrastructure only after an acute vulnerability emerges cannot meet the 24-hour deadline.
In parallel with the ENISA reporting obligation, the CRA requires a publicly accessible Vulnerability Disclosure Policy (VDP). This policy governs how third parties (security researchers, customers) can report vulnerabilities and how the manufacturer handles them. The VDP is a low-effort but frequently missing building block – and a signal to authorities, customers and the market that the organisation takes security seriously.
Step 7
Technical documentation and CE conformity assessment
The CRA requires technical documentation for every product, evidencing all security-relevant design decisions, risk analyses, implemented measures, test results and vulnerability handling. This documentation is not a one-off document but a living artefact: it must be updated at every release, every material change and with each newly discovered vulnerability.
Based on the technical documentation and the conformity assessment performed, the manufacturer issues an EU Declaration of Conformity (DoC) and affixes the CE marking to the product. For standard products the manufacturer can carry out the conformity assessment itself (self-assessment) provided harmonised standards are applied. For Class I and Class II products the involvement of a notified body is mandatory or at least partially required.
Notified bodies for the CRA are certified assessment organisations accredited by national accreditation authorities (in Germany the DAkkS). Availability is limited; capacity tightens as the 2026 and 2027 deadlines approach. Any organisation requiring a notified-body assessment should plan early – realistically with 6–12 months lead time.
CRA Checklist
- 01
Check applicability
Products with digital elements + network function identified
- 02
Determine product class
Standard / Class I / Class II classified
- 03
Gap analysis
Distance to CRA requirements assessed, priorities set
- 04
Security by Design
Threat modelling, secure coding, SAST/DAST in CI/CD
- 05
Build SBOM
Automated SBOM generation + continuous CVE monitoring
- 06
Reporting processes
ENISA disclosure, 24h/72h/14d deadlines operational
- 07
CE conformity
Technical documentation, DoC, notified body if required
Deadlines at a glance
CRA entered into force
Reporting obligations active (ENISA 24h/72h/14d)
Full CRA effect: all requirements
Related pages
Request a gap analysis
In 4–6 weeks you receive a full stocktake, clear prioritisation and a robust roadmap.
Request nowSummary
What needs to be done – in seven steps
1. Clarify applicability: which products fall within the CRA scope?
2. Determine product class: standard, Class I or Class II?
3. Gap analysis: where are the most critical gaps?
4. Security by Design: threat modelling + secure SDLC processes
5. Build an SBOM: automated generation + CVE monitoring
6. Reporting processes: ENISA disclosure + Vulnerability Disclosure Policy
7. CE conformity: technical documentation + Declaration of Conformity
Frequently asked questions about the Cyber Resilience Act
Do I need to act now, or can I wait until 2027?
Waiting is the most expensive strategy. Introducing security-by-design processes, SBOM infrastructure and a working vulnerability management practice typically takes 12–24 months. Anyone starting late in 2026 risks not only the December 2027 deadline but also the September 2026 reporting obligation, which already presupposes a functioning incident disclosure system. Organisations that start now also gain the strategic advantage of using CRA conformity as a B2B differentiator ahead of competitors.
What is the concrete consequence if a product is not CRA-compliant by December 2027?
Non-compliant products lose lawful access to the EU single market. National market surveillance authorities can order recalls, sales bans and fines of up to EUR 15 million or 2.5 % of global annual turnover – whichever is higher. Importers and distributors face their own obligations: they may not place non-compliant products on the market and are liable for imported products where the manufacturer is established outside the EU.
How much effort does SBOM implementation involve in practice?
The technical generation of an SBOM itself can be done in a single sprint using modern tooling (Syft, CycloneDX plug-ins for Maven/Gradle/npm). The real effort lies in continuous operation: CVE matching against current vulnerability databases, triage of hits, risk decisions and documenting the response. Without an integrated process the SBOM is only a static list – not a compliance artefact. We recommend implementing SBOM generation and monitoring as an automated CI/CD step rather than a manual periodic process.
Does every product need its own SBOM?
Yes – product-specific, not company-wide. Every product with digital elements requires its own SBOM that accurately reflects all the components it contains. For product families with a shared codebase, a base SBOM per product version with product-specific additions can be structured. Importantly: the SBOM must be versioned, machine-readable and kept current – updated at every release cycle.
What is the difference between manufacturer, importer and distributor obligations?
Manufacturers carry the most extensive obligations: security by design, SBOM, vulnerability management, ENISA notification, conformity assessment and CE marking. Importers bringing products from non-EU manufacturers into the EU must ensure those products meet CRA requirements – and are liable to European market surveillance authorities if the non-EU manufacturer is unreachable. Distributors must check that the products they sell carry CE marking and that CRA documentation is in place. No distribution or procurement strategy that places non-compliant products on the market will be lawful after December 2027.
Kontakt aufnehmen
Approach CRA implementation in a structured way
From applicability assessment to SBOM integration, reporting processes and CE conformity – we guide manufacturers, importers and distributors through every CRA requirement.