According to ENISA's Threat Landscape 2024, supply chain attacks against critical infrastructure increased 17% year-on-year, with software components as the leading vector. The EU Cyber Resilience Act is the legislative response: mandatory cybersecurity requirements for every connected product sold on the EU market, with fines of up to 15 million euros or 2.5% of global annual turnover for non-compliance.
This is not another IT security checkbox. The CRA shifts liability upstream, onto the manufacturers and software vendors who build products, rather than the organisations that deploy them. If your organisation makes, sells, or depends on connected products used in critical infrastructure, the compliance clock started when the regulation entered into force in December 2024.
This guide explains what the CRA requires, who it applies to, how it sits alongside DORA and NIS2, and what the practical BCM implications are for critical infrastructure operators.
What is the EU Cyber Resilience Act?
The EU Cyber Resilience Act entered into force in December 2024, introducing mandatory cybersecurity requirements for products with digital elements sold on the EU market. It sits alongside DORA and NIS2 as part of the EU's broader push to raise baseline cyber and operational resilience standards across the single market. Unlike DORA, which governs how financial entities manage their digital risk, the CRA governs the security properties of the products themselves.
A product with digital elements is any hardware or software product that can connect to a network, directly or indirectly. Industrial control systems, medical devices, smart building management systems, routers, firewalls, enterprise security software, and consumer IoT devices all fall within scope. If it connects and you sell it in the EU, the CRA applies.
What the CRA is not
The CRA is not an extension of GDPR. It does not govern personal data. It governs the security of the product itself: how it is designed, how vulnerabilities are discovered and patched, how incidents are reported to regulators, and how long security updates are provided after sale.
It is also not the same as NIS2, which governs how organisations operate their own network and information systems. A company can be subject to NIS2 as an essential entity and also subject to the CRA as a manufacturer of connected products. Both apply simultaneously, and neither replaces the other.
Key dates
The regulation has two compliance deadlines. September 2026 is when vulnerability disclosure and incident reporting obligations to ENISA become mandatory. December 2027 is the deadline for all other obligations: security by design, CE marking, conformity assessment, and ongoing update requirements.
Who the CRA applies to
The regulation places obligations on three categories of economic operator. The weight of compliance falls unevenly across them, with manufacturers carrying the heaviest burden.
Manufacturers
If you design, develop, or produce a connected product and place it on the EU market, you are responsible for its security throughout the product's supported lifetime. This means conducting a cybersecurity risk assessment before market placement, implementing security by design and by default, providing security updates for a minimum of five years, and maintaining a software bill of materials (SBOM) for all software components.
Manufacturers must also operate a vulnerability disclosure policy and have a process for receiving, triaging, and remediating reported vulnerabilities. Notification to ENISA is required within 24 hours of becoming aware of an actively exploited vulnerability or a significant security incident.
Importers and distributors
Importers who bring CRA-covered products from outside the EU take on a subset of manufacturer obligations when the original manufacturer is not established in the EU. Distributors must verify that products carry a CE marking indicating CRA compliance and must not place non-compliant products on the market.
Critical infrastructure operators as users
Operators in energy, water, transport, health, and finance are primarily affected as users rather than manufacturers. Their obligation is due diligence: verify CRA compliance from product vendors before deployment, apply security updates within the manufacturer's specified timelines, and include CRA compliance status in third-party risk assessments. A missed patch on a CRA-covered component used in a critical system creates both a regulatory exposure and a BCM risk.
Product classes under the CRA
Not all connected products carry the same compliance burden. The CRA defines three tiers based on risk, each with a different conformity assessment route.
| Class | Examples | Conformity route | Third-party audit? |
|---|---|---|---|
| Default | Most consumer and business software, basic IoT devices | Self-assessment | No |
| Class I (important) | Identity management software, browsers, password managers, network monitoring tools, SIEM systems | Self-assessment against harmonised standard or notified body | Optional |
| Class II (critical) | OS for servers and industrial environments, hypervisors, PKI components, industrial control systems, hardware security modules | Notified body mandatory | Yes |
For most enterprise software vendors, the default category applies. For vendors of security tooling, industrial automation, or infrastructure components, Class I or Class II will likely apply. Notified body capacity is limited and engaging one early is advisable for Class II products.
CRA, DORA, and NIS2: how they fit together
The three regulations address different layers of the same problem and can all apply to the same organisation at the same time. Understanding the boundaries prevents compliance gaps and avoids double-counting work.
| Regulation | What it governs | Who it applies to | Key deadline |
|---|---|---|---|
| CRA | Security properties of connected products | Manufacturers, importers, distributors selling into the EU | Dec 2027 (full); Sep 2026 (reporting) |
| DORA | ICT risk management processes in financial entities | Banks, insurers, investment firms, ICT third-party providers in the EU | January 2025 (in force) |
| NIS2 | Cybersecurity operations and incident reporting | 18 sectors: energy, transport, health, digital infrastructure, and others | October 2024 (transposition deadline) |
A financial institution subject to DORA that also deploys CRA-covered products faces both simultaneously. DORA governs the institution's operational resilience program; the CRA governs the security properties of the products it uses. The incident reporting timelines under NIS2 and the CRA are both 24 hours but are triggered by different events and reported to different authorities.
What the CRA means for your BCM program
The CRA introduces a new category of operational disruption that most business continuity programs have not explicitly accounted for: compliance-triggered product unavailability. Three implications are worth building into your program now.
Vendor patch obligations as a BCM dependency
Under the CRA, manufacturers must provide security updates for the supported lifetime of their product. Your BCM program should map critical connected products to their manufacturers, track CRA compliance status for each, and include recovery strategies for the scenario where a key vendor loses EU market access. This is a new dependency type: not a supplier going out of business, but a supplier becoming non-compliant and being ordered to withdraw.
Compressed incident reporting windows
The CRA requires manufacturers to notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability. For critical infrastructure operators using those products, this creates a compressed response window. Your incident management process needs to account for the possibility that a vendor notification simultaneously triggers your own reporting obligation under NIS2 or DORA, sometimes within the same 24-hour period.
SBOM visibility into supply chain risk
The CRA requires manufacturers to maintain a software bill of materials. For operators, this creates an intelligence opportunity: you can request SBOMs from vendors and map their components into your dependency graph. A vulnerability in an open-source library used in a component you operate becomes visible before it becomes an incident, not after.
What organisations should do now
The December 2027 deadline is closer than it appears once you account for gap assessment time, SBOM development, conformity assessment queues, and supply chain remediation. The actions differ depending on your role in the supply chain.
If you manufacture connected products
Start your gap assessment against the essential cybersecurity requirements in CRA Annex I. Identify which product class applies. If you are in Class II, begin engaging a notified body now as accredited bodies have limited capacity. Develop your SBOM for all products that will remain on the EU market after December 2027, and establish a formal vulnerability disclosure program before September 2026.
If you operate critical infrastructure
Audit your connected product inventory against CRA scope. For each product, identify the manufacturer and request their compliance roadmap. Build CRA compliance status into your third-party risk management process, your annual BIA, and your dependency map. Define recovery strategies for the scenario where a product is withdrawn from the market.
If you are a software vendor selling into the EU
Software products that connect to a network are in scope. Begin with a legal classification assessment, then a security architecture review against the essential requirements. Customers in regulated sectors will begin requesting your CRA compliance roadmap during procurement from 2026 onwards. Having one prepared is a commercial advantage, not just a compliance obligation.
How BCM software supports CRA readiness
A business continuity management platform does not make you CRA-compliant. But it gives you the infrastructure to manage the BCM risks the CRA creates.
Dependency mapping lets you trace which critical processes rely on CRA-covered products, so a vendor compliance failure surfaces as a BCM risk before it becomes an operational disruption. Incident management connected to BC plans means a 24-hour reporting window does not catch your team unprepared. And ongoing BIA refresh ensures recovery strategies account for product withdrawal scenarios, not just the fire-drill exercises from last year's tabletop.
See our guide on the 10 best business continuity softwares
Related articles
DORA compliance: a complete guide
