Digital Business & Future 03.04.2026

7 min Read Time

The EU Cyber Resilience Act (CRA) entered into force in December 2024 and affects every manufacturer placing products with digital elements on the European market. As of September 2026, the first mandatory reporting obligations take effect; by December 2027, all products must comply with the new cybersecurity requirements. For manufacturing SMEs, this means: Every connected sensor, every machine control system, and every software component falls under the regulation. Time to act is running short.

The Key Takeaways

What the CRA Regulates – and Who It Affects

The Cyber Resilience Act is the EU’s first regulation introducing binding cybersecurity requirements for all products with digital elements. Its scope is deliberately broad: It covers connected hardware – including routers, smart home devices, and industrial IoT sensors – as well as pure software, such as apps, operating systems, and firewalls.

For manufacturing SMEs, the implications are far-reaching. Every network-connected machine controller, every sensor with firmware update capability, and every embedded system in a production line falls under the regulation.

Of particular relevance to SMEs: Importers and distributors placing products on the EU market also bear independent obligations. Anyone importing a Chinese IoT module and selling it under their own brand qualifies as a “manufacturer” and must demonstrate full CRA compliance. This affects numerous machinery manufacturers and system integrators embedding third-country components into their solutions.

Even those who do not manufacture such products themselves – but integrate them into their own offerings – bear compliance responsibilities as integrators.

A few categories are explicitly excluded: medical devices (already regulated under the MDR), motor vehicles (subject to UNECE regulations), aviation technology, and certain national security products. Open-source software is only covered if distributed commercially.

“The CRA ensures that hardware and software products reach the market with fewer vulnerabilities – and that manufacturers take security seriously across the entire product lifecycle.”
– European Commission, CRA press release, September 2022

The Three Deadlines: What Applies When

The CRA entered into force on 10 December 2024 and will be implemented in three stages. The first deadline arrives sooner than many companies expect.

11 June 2026: Notification of conformity assessment bodies becomes effective. From this date, national authorities must have designated the bodies authorized to assess high-risk products (Categories I and II).

11 September 2026: Vulnerability and incident reporting obligations begin. Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours. For severe security incidents, the reporting window is 72 hours. This obligation takes effect six months before full application – and represents the first hard deadline for many companies.

11 December 2027: Full application of all requirements. As of this date, only CRA-compliant products bearing the CE marking may be placed on the EU market. Products already on the market prior to this date – and not significantly modified – enjoy grandfathering rights.

Product Categories: Standard, Important, Critical

The CRA classifies products into three risk tiers, determining how conformity assessment must be conducted. Classification directly impacts effort and cost.

Standard products (≈90% of all products): Includes simple IoT sensors, smart home devices without security functions, consumer software, and office equipment. Manufacturers may demonstrate conformity via self-assessment. No external auditor required.

Important products (Category I): Operating systems, firewalls, routers, VPN software, and network management systems. Either assessment against harmonized standards or third-party verification is required.

Critical products (Category II): Hardware security modules, smart meter gateways, industrial control systems, and public key infrastructure. Third-party conformity assessment by a notified body is mandatory.

What Manufacturers Must Implement – Concretely

CRA requirements fall into three main areas: secure development, vulnerability management, and documentation.

Security by Design: Products must be developed from conception onward following the “Secure by Default” principle. This means: minimal attack surface, encrypted communication, no hardcoded passwords, and secure update mechanisms. Manufacturers must demonstrate that security was integrated from the outset – not added as an afterthought.

Vulnerability Management: Manufacturers must provide security updates throughout the product’s lifecycle – and for at least five years after market launch. Actively exploited vulnerabilities must be reported to ENISA within 24 hours. This requires a functional PSIRT process (Product Security Incident Response Team).

Technical Documentation: Each product must be accompanied by comprehensive documentation: risk analysis, description of the security architecture, test reports, SBOM (Software Bill of Materials), and an EU Declaration of Conformity.

One point often underestimated: The obligation to provide security updates free of charge for at least five years. For manufacturers of industrial components with lifecycles spanning ten to twenty years, this entails a substantial long-term commitment. A connected control module shipped today must remain patchable and secure through 2032. That demands a sustainable software architecture and an update infrastructure extending far beyond typical product cycles.

In practice, this also means manufacturers must reassess supplier relationships. If an open-source library embedded in a product is no longer maintained, the manufacturer must either develop patches independently – or replace the component. Here, the SBOM serves as an early-warning system: It reveals dependencies and hidden risks.

The SBOM is especially critical because it must list all software components – including open-source libraries.

SBOM: Why the Software Bill of Materials Is a Game Changer

The Software Bill of Materials (SBOM) is one of the CRA’s central new instruments. In practice, it resembles a food ingredient label: It lists every software component embedded in a product. For many SMEs, this poses a challenge – given the complexity of dependencies in modern software stacks.

A typical embedded system in a machine controller includes a real-time operating system, communications libraries, cryptographic modules, and dozens of other components – many integrated as open source. Each of these components may harbor vulnerabilities the manufacturer must know about – and manage.

The good news: Established standards and tools exist. CycloneDX and SPDX are the two leading SBOM formats. Build tools like Syft or Grype automatically generate SBOMs from code repositories. For companies already using CI/CD pipelines, SBOM generation can be seamlessly integrated into existing build processes – without disrupting developer workflows.

For companies without in-house software development – relying instead on supplier components – the rule is clear: Demand an SBOM from your suppliers. The CRA shifts responsibility along the supply chain. Integrating components without an SBOM into your own products leaves you liable for unknown vulnerabilities.

What CRA Compliance Actually Costs SMEs

Compliance costs depend heavily on product category and the maturity of existing security processes. For standard products subject to self-assessment, industry experts estimate one-time costs of €20,000-€50,000 per product line – mainly for documentation, risk analysis, and SBOM creation.

For Category I and II products requiring external assessment, costs rise to €80,000-€200,000. Ongoing costs for vulnerability management add further burden: A dedicated PSIRT process – including monitoring, patch development, and ENISA reporting – requires at least half a full-time equivalent, often more.

The counterbalance: According to the BSI (Federal Office for Information Security), the average cost of a cybersecurity incident for SMEs is €500,000. A single serious incident exceeds multi-year compliance costs. Add to that the market access advantage: CRA-compliant companies can sell across Europe without restriction – while non-compliant competitors face exclusion.

CRA, NIS2, and AI Act: The Regulatory Triad

The CRA does not operate in isolation. Together with NIS2 (Network and Information Systems Security) and the AI Act, it forms a regulatory triad simultaneously affecting European businesses. For SMEs, this means: Identify overlaps – and leverage synergies.

NIS2 obliges operators of critical and important infrastructure to implement risk management and incident reporting. The CRA obliges manufacturers of the very products those operators deploy. So if you produce IoT sensors for energy providers – or control software for water utilities – you must meet both CRA requirements for your products and consider your customers’ NIS2 obligations.

The good news: Many requirements overlap. Companies already operating an information security management system certified to ISO 27001 have already satisfied much of the CRA’s organizational requirements. The CRA’s SBOM mandate complements the AI Act’s transparency obligations for AI components embedded in products.

Checklist: Five Steps Toward CRA Compliance

December 2027 may sound distant – but the vulnerability reporting obligation beginning in September 2026 kicks in just six months from now. Here’s a pragmatic roadmap.

1. Create a product inventory. Which products with digital elements does your company market? Which include network connectivity, firmware, or software components? This baseline inventory is essential for risk classification.

2. Determine risk class. For each product: Is it standard, Category I, or Category II? Classification determines whether self-assessment suffices – or whether an external assessor is required.

3. Establish a PSIRT process. Starting September 2026, vulnerabilities must be reported within 24 hours. This requires a functional incident response process – with clearly defined responsibilities, ENISA contact details, and a documented reporting procedure.

4. Generate an SBOM. For each product, create a Software Bill of Materials listing all software components – including versions and licenses. Tools like CycloneDX or SPDX automate this process.

5. Implement a Secure Development Lifecycle. “Security by Design” must be embedded into development workflows. This includes threat modeling, code reviews, penetration testing, and secure update mechanisms.

Real-World Example: An SME on the Path to CRA Compliance

A Swabian sensor manufacturer with 80 employees produces temperature and humidity sensors for the food industry. The sensors feature Wi-Fi connectivity, transmit measurement data to a cloud platform, and receive over-the-air firmware updates. Until now, there was no structured vulnerability management – and no SBOM.

Step one: Product inventory. The company identifies three product lines with digital elements – all classified as standard risk (eligible for self-assessment).

Step two: SBOM creation. An external service provider analyzes the firmware code and generates a CycloneDX SBOM. Result: 47 software components – including 12 open-source libraries, three of which have not been updated in over a year. These three must be replaced – or patched in-house.

Step three: PSIRT setup. The head of software development assumes the role of security officer. A streamlined process is defined: vulnerability monitoring via the National Vulnerability Database (NVD), evaluation within 48 hours, and ENISA reporting within 24 hours upon active exploitation.

Step four: Documentation. Risk analysis, security architecture, and test reports are compiled. Total effort: approx. €35,000 and a three-month project timeline.

Conclusion

The Cyber Resilience Act will permanently reshape product development across Europe. For manufacturing SMEs, it is not an optional recommendation – it is a mandatory market access requirement. Any company wishing to sell connected products in the EU must be CRA-compliant by December 2027.

But the first hard deadline is not December 2027 – it is September 2026: That’s when vulnerability reporting begins. Six months is little time to build a PSIRT process from scratch. Those who start now will succeed. Those who wait will scramble under pressure. Investing in CRA compliance is not merely a cost center. It is an investment in product quality, customer safety, and long-term market access in a Europe where cybersecurity has become a foundational prerequisite.

Frequently Asked Questions

Am I affected as a software developer?

Yes – if your software is distributed commercially. The CRA applies to all products with digital elements, including pure software. Only non-commercial open-source software is exempt.

What is an SBOM?

A Software Bill of Materials is a complete inventory of all software components in a product – including open-source libraries, versions, and licenses. The CRA mandates an SBOM as part of technical documentation.

How long must I provide security updates?

For at least five years after market launch – or for the expected product lifetime, whichever is shorter. Updates must be provided free of charge and delivered promptly.

Do I need an external assessment body?

Only for Category II (critical) products – such as smart meter gateways or industrial control systems. Standard products (≈90%) may be self-assessed by the manufacturer.

What happens if I violate the CRA?

Fines of up to €15 million – or 2.5% of global annual turnover. Authorities may also prohibit market access: Non-compliant products may no longer be sold in the EU.

How does the CRA differ from NIS2?

NIS2 regulates operators of infrastructure and services; the CRA regulates manufacturers of products. If your company builds connected products, you must comply with the CRA. If you deploy such products, NIS2 obligations apply to you.

Further Reading

AI Act from August 2026: High-Risk AI in SMEs

GlassWorm Supply-Chain Attack: 400+ Tools Compromised – SecurityToday

Container Supply Chain Security: Docker and SBOM – cloudmagazin

Header Image Source: Anete Lusina / Pexels