TL;DR:
- The EU Cyber Resilience Act entered into force in December 2024; most product obligations apply from December 2027
- Any hardware or software product with digital elements sold in the EU must meet mandatory cybersecurity requirements — this covers the vast majority of IoT and edge devices
- The Act introduces ongoing security update obligations for the “expected lifetime” of the product, not just at launch — a significant change from previous practice
The EU Cyber Resilience Act (CRA) is the most significant product security legislation to come out of Europe in years. Unlike previous directives that set general principles, the CRA specifies concrete technical requirements and places legal obligations on manufacturers — not just when they bring a product to market, but throughout its operational life.
For IoT and edge computing product makers, this is a substantial compliance task. Products that are in development now and launching in 2027 or later need to be designed with CRA compliance in mind from the start.
Scope: What Products Are Covered
The CRA covers “products with digital elements” — any software or hardware product that connects directly or indirectly to a network or to other devices. This intentionally broad scope captures nearly every IoT and edge device:
- Industrial sensors, gateways, and PLCs
- Smart cameras and video analytics hardware
- Network-connected industrial controllers
- Edge AI inference hardware
- Consumer IoT (thermostats, security cameras, routers)
- Embedded software sold as a standalone product
- Cloud-connected appliances
Notable exclusions include: products that are already regulated under other EU frameworks with equivalent security requirements (medical devices under MDR, automotive under UN ECE regulations, certain aviation equipment), and software developed as open-source under certain conditions.
The CRA distinguishes between “default category” products (most IoT/edge devices) and “important” or “critical” categories. Important products (network switches, industrial automation controllers, firewalls, smart meters) face stricter requirements and third-party conformity assessment. Critical products (HSMs, industrial control systems with safety functions) face the most stringent requirements.
Core Technical Requirements
For default-category products, manufacturers must:
Ship without known exploitable vulnerabilities. Products must be designed and developed to have no known vulnerabilities in their components at time of market placement. This requires a software bill of materials (SBOM) and vulnerability tracking process.
Provide security updates for the expected lifetime. The obligation to provide security patches extends for the minimum support period advertised (at least 5 years for most devices) or for the expected operational lifetime if that’s defined. For industrial equipment with 10–15 year operational lives, this is a significant engineering and business commitment.
Ship with security-by-default configuration. Products must have their most secure configuration as the default — no factory passwords, no unnecessary open ports, no unencrypted communications enabled by default.
Provide a secure update mechanism. Software update mechanisms must use authentication (signing) and integrity verification. Updates must be deployable without user action where technically feasible.
Protect data confidentiality and integrity. Data stored or transmitted by the product must be protected against unauthorised access or manipulation through appropriate cryptographic mechanisms.
Minimise attack surface. Unnecessary features, ports, and services must be disabled by default. The product must be capable of operating in a state where only the minimum necessary network functionality is active.
Log security-relevant events. Products must log sufficient information to support incident investigation — connection events, configuration changes, authentication attempts.
Vulnerability Disclosure and Reporting Obligations
The CRA also introduces mandatory incident reporting, which is new for product manufacturers:
- Actively exploited vulnerabilities must be reported to ENISA (the EU cybersecurity agency) within 24 hours of discovery and notified to affected users
- Severe incidents (those significantly affecting security of the product or users) must be reported to ENISA within 72 hours
- Manufacturers must maintain a coordinated vulnerability disclosure (CVD) process and provide a point of contact for security researchers
This aligns EU requirements more closely with practices already standard in the software industry but not consistently followed in hardware manufacturing.
Software Bill of Materials (SBOM)
Manufacturers must be able to document all software components, including third-party and open-source components, incorporated in their products. The SBOM requirement exists to support:
- Vulnerability tracking (knowing which products are affected when a component vulnerability is disclosed)
- Regulatory audit
- Customer notification when component vulnerabilities affect shipped products
The CRA doesn’t specify an SBOM format, but SPDX and CycloneDX are the de facto standards and either will satisfy the regulatory intent.
Conformity Assessment
Default category products can self-certify by following harmonised European standards (EN standards aligned with the CRA are currently under development by ETSI and CEN/CENELEC).
Important products (Category 1 and 2 in the CRA’s classification) require third-party assessment by a notified body or compliance with a relevant European cybersecurity certification scheme.
The CE marking system will incorporate CRA compliance — products without appropriate CRA conformity cannot carry CE marking from December 2027.
Timeline for Manufacturers
| Date | Obligation |
|---|---|
| December 2024 | CRA enters into force |
| September 2026 | Vulnerability and incident reporting obligations apply |
| December 2027 | All other CRA obligations apply; non-compliant products cannot be placed on the EU market |
The September 2026 date for incident reporting is approaching within months. Manufacturers who ship products into the EU market now should begin establishing their vulnerability disclosure processes and internal incident response procedures before that date.
What to Do Now
Inventory your products. Map which products fall under CRA scope and which category they fall into. The categorisation determines your assessment route.
Start SBOM generation. If you’re not already generating SBOMs, implementing the tooling now — before it’s legally required — gives you time to address gaps in your component tracking.
Audit your update mechanism. Review whether your current firmware/software update pipeline provides signed updates with integrity verification. Unsigned OTA updates won’t be compliant.
Review default configurations. Default passwords, open ports, and unencrypted services need to be eliminated before products ship into the EU post-December 2027.
Establish a CVD process. Define your security contact, your internal triage process, and your escalation path for vulnerabilities. The 24/72-hour reporting windows mean you need a clear process before a vulnerability is discovered.
Monitor EN standard development. The harmonised standards that define exactly how to comply with CRA technical requirements are still being developed. Tracking their progress (via ETSI and CEN-CENELEC) will inform your compliance approach.
The CRA represents a shift from “security is optional” to “security is legally required” for products in the EU market. For manufacturers with strong security practices already in place, compliance is largely a documentation and process formalization exercise. For those who’ve treated security as secondary, the December 2027 deadline requires substantial product engineering work that should start now.