Definition: Cyber Resilience Act (CRA)
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU regulation requiring manufacturers of hardware and software products with digital elements to meet mandatory cybersecurity requirements before placing them on the EU market.
Core characteristics of the Cyber Resilience Act
The CRA covers almost every connected product sold in the EU, from industrial sensors to standalone software, unless it already falls under sector-specific rules such as medical devices. It sorts products into default, important, and critical risk classes with escalating requirements.
- Applies to hardware and software with digital elements placed on the EU market
- Requires security-by-design and secure-by-default configuration
- Mandates a documented vulnerability handling process for the product’s lifetime
- Obliges manufacturers to report exploited vulnerabilities and severe incidents on fixed deadlines
Cyber Resilience Act vs. NIS2
The CRA is frequently confused with NIS2, but the two regulate different actors. NIS2 governs how operators of critical infrastructure run their own IT security, while the CRA governs the manufacturers who build the products those operators buy. A Mittelstand company can face both at once, as an operator under NIS2 and a manufacturer under the CRA.
Importance of the CRA in enterprise AI
The CRA matters for enterprise AI because software components, including AI-enabled features embedded in products, fall within its vulnerability duties regardless of the product’s primary function. ENISA’s 2026 SBOM Adoption survey found 43 percent of organizations say the CRA significantly accelerated their software bill of materials investment, a prerequisite for the reporting it demands. Vendors selling into financial services often face the CRA alongside DORA, which adds ICT third-party oversight on top of product security duties.
Methods and procedures for the Cyber Resilience Act
Meeting the CRA rests on three structured workstreams.
Product classification and conformity assessment
The first step is determining a product’s risk class, since the applicable procedure depends on it. Default-class products can self-assess, while important and critical products need a notified body for third-party assessment.
- Classify each product against the default, important, and critical categories
- Run the conformity assessment procedure that matches the class
- Document the decision and keep it current across product updates
Security-by-design implementation
Manufacturers must build cybersecurity in from the design phase, covering secure default configuration, access protection, and data minimization. This includes a software bill of materials, related to the AI Bill of Materials required for AI systems, so every component stays traceable.
Vulnerability and incident reporting workflow
The CRA sets a tiered reporting clock: an early warning within 24 hours of an actively exploited vulnerability or severe incident, fuller notification within 72 hours, and a final report within 14 days of a fix or one month for incidents. Building this workflow before September 2026 separates readiness from scrambling once the Single Reporting Platform goes live.
Important KPIs for the Cyber Resilience Act
Tracking CRA readiness requires indicators across documentation, response speed, and product coverage.
Operational readiness metrics
- SBOM coverage: percentage of products with a current software bill of materials
- Vulnerability disclosure policy: published and reachable by security researchers
- Incident drill frequency: at least annually before September 2026
- Product classification: percentage of portfolio assessed against CRA risk classes
Governance and accountability metrics
Bitkom’s 2026 position paper on the German implementing law flags management accountability for vulnerability handling as a leading readiness signal. Companies with an existing ISO 27001 information security management system typically reach this bar faster.
Product security quality
Beyond the reporting clock on paper, manufacturers should track detection-to-notification time in drills and how quickly patches reach customers after disclosure.
Risk factors and controls for the Cyber Resilience Act
Underestimating scope
The most common failure is assuming the CRA only applies to obvious IoT devices, when it also covers standalone software and industrial control components.
- Reassess scope whenever a product gains network connectivity
- Include white-label and OEM products sold under a company’s own brand
- Treat uncertainty as a reason to check, not assume exemption
Legacy product exposure
The September 2026 reporting duty applies to products already on the market, so manufacturers with years-old product lines face obligations for components they no longer actively develop. Retiring or extending support becomes a compliance decision, not only a commercial one.
Unmanaged software supply chain
Third-party and open-source components pulled into a product without tracking create the blind spot the CRA’s vulnerability duty is designed to eliminate. Every dependency needs the same monitoring as code written in-house.
Practical example
A 140-employee industrial sensor manufacturer in Bavaria found during its CRA scoping exercise that roughly sixty product variants qualified as products with digital elements, most without a vulnerability handling process. It had never registered a security contact point for researchers. Within five months it built a compliance program on its existing quality management system, prioritizing products still under active sale.
- Vulnerability disclosure policy published and monitored by a dedicated inbox
- Software bill of materials generated for every actively sold product line
- Incident reporting workflow rehearsed ahead of the September 2026 deadline
- Product classification documented and reviewed at each firmware release
Current developments and effects
Reporting deadline approaching
The 11 September 2026 reporting deadline is the first CRA obligation to bite, activating ENISA’s Single Reporting Platform for the 24-hour early warning duty. Manufacturers who have not mapped their portfolio against it are running out of runway.
- Single Reporting Platform operational from 11 September 2026
- Early warning covers actively exploited vulnerabilities and severe incidents only
- No grace period once the date passes
German implementation debate
Bitkom’s 2026 position paper on the national implementing law argues against additional German requirements beyond the EU baseline, warning that extra rules would disadvantage German manufacturers. The debate mirrors concerns raised during NIS2’s transposition.
CRA and AI-enabled products converging
As manufacturers embed AI features into connected products, CRA vulnerability handling increasingly overlaps with EU AI Act obligations for the same product. An AI agent platform like Superkind, which logs every action an agent takes against connected systems, produces the audit trail that supports both duties.
Conclusion
The CRA moves cybersecurity from a voluntary good practice to a binding market-access requirement for nearly every connected product sold in the EU. Its phased timeline gives manufacturers a real window to prepare, but the September 2026 reporting duty already applies to products on the market today, not just future releases. Mittelstand manufacturers that treat classification, vulnerability handling, and reporting readiness as one program rather than three separate projects will clear both deadlines with less disruption. As AI features become standard in connected products, that same discipline keeps compliance manageable rather than a recurring scramble.
Frequently Asked Questions
What is the Cyber Resilience Act (CRA)?
The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU law requiring manufacturers of hardware and software with digital elements to build in cybersecurity, handle vulnerabilities, and report incidents within fixed deadlines. It entered into force in December 2024, with obligations phasing in through 2026 and 2027.
Does the CRA apply to a Mittelstand company with fewer than 100 employees?
Yes. The CRA has no employee-count threshold; a small manufacturer with one connected product line is still fully in scope.
How is the CRA different from NIS2 and the EU AI Act?
NIS2 regulates how operators of critical infrastructure run their own IT security, while the CRA regulates the manufacturers who build the products those operators buy. The EU AI Act regulates AI systems specifically, while the CRA covers cybersecurity for digital products generally.
What does CRA compliance cost a Mittelstand manufacturer?
Costs vary with portfolio size and security maturity, but manufacturers commonly report initial programs in the low-to-mid six-figure euro range. Companies with an existing ISO 27001 system typically spend less.
Do we need dedicated cybersecurity staff to comply with the CRA?
Not necessarily. Many manufacturers combine existing quality staff with an external security partner for classification, though the CRA requires a reachable contact point for researchers and regulators.
How does the CRA relate to GDPR and data protection?
They apply in parallel but cover different risks. GDPR governs personal data processing, while the CRA governs the security of the product itself. A breach involving personal data can trigger both duties at once.
