EU Cyber Resilience Act Compliance for IoT and Connected Device Manufacturers
The EU Cyber Resilience Act (CRA) introduces mandatory cybersecurity obligations for any product with digital elements that connects to another device or network — and full enforcement begins December 2027. If you build, import, or distribute connected hardware, the clock is already running.
What Is the Cyber Resilience Act?
The Cyber Resilience Act (Regulation EU 2024/2847) is the EU’s first horizontal, mandatory cybersecurity framework for products with digital elements. It entered into force on 10 December 2024.
Unlike the Radio Equipment Directive (RED), which only applied cybersecurity requirements to internet-connected radio hardware, the CRA applies to any product with digital components — hardware or software — that connects to any other device or network, either directly or indirectly, and critically, it does not require internet connectivity.
The existing EU legislative framework created a patchwork of requirements that left non-embedded software entirely unaddressed and failed to cover hardware outside the scope of RED or the Medical Devices Regulation — even though software vulnerabilities are increasingly the primary channel for cybersecurity attacks. The CRA closes that gap with a single framework that applies across the full product lifecycle.
Does the CRA Apply to Your Product?
This is the question most manufacturers in the connected device space are currently working through — and the answer is often broader than expected.
The CRA applies to any product with digital components — hardware or software — that connects to any other device or network, either directly or indirectly. Crucially, the CRA does not require internet connectivity. If your stock scanner talks to a local warehouse network, if your logistics device syncs with a proprietary backend, if your embedded controller communicates with a supervisory system — you are in scope.
Covered products include embedded systems such as industrial controllers, sensors and appliances that rely on integrated software, smart home devices and connected gadgets, and software platforms including cloud-based services that support remote data processing from connected devices and are supplied in a commercial context.
On the SaaS question: Software delivered purely as a service — with no component placed on the market as a product — is generally outside CRA scope. However, if software enables remote data processing as an integral part of a connected product, and is supplied commercially, it is in scope. The line between “service” and “product with digital elements” is not always obvious and depends on how the software is supplied and used.
On open-source software: The CRA’s exemption applies to free and open-source software that is not supplied “in the course of a commercial activity.” This is not simply a question of whether software is monetised — a project can be non-monetised and still fall within scope depending on the commercial context of its supply.
The scope question alone — including which product category applies and what conformity pathway follows from it — is a substantive compliance exercise.
Product Categories and Conformity Assessment
Around 90% of products with digital elements fall under the default category, for which manufacturers can self-assess against the CRA’s essential requirements.
Products classified as Important are divided into two classes. Important Class I products can still self-assess where harmonised standards are applied. Important Class II products require mandatory third-party assessment by a Conformity Assessment Body. Critical products face the strictest assessment requirements. Identifying which category your product falls into — and what that means for your conformity pathway — is a meaningful determination, not a straightforward one.
Why This Is Different From What Came Before
The CRA is not a stricter version of RED. It is a categorically different type of obligation.
RED’s cybersecurity provisions — which became mandatory for internet-connected radio equipment in August 2025 — focused on market entry: could the device meet defined security requirements when placed on the market? The CRA demands something far more extensive.
While RED focused on device security before market entry, the CRA introduces a framework that applies throughout the entire product lifecycle, including post-market vulnerability management, incident reporting, software update obligations, and supply chain accountability extending to every third party involved in the product.
From December 2027, the RED cybersecurity delegated regulation (EU 2022/30) is formally repealed. Until then, both RED and CRA requirements apply in parallel for in-scope radio equipment. The CRA does not absorb RED’s provisions — it replaces them with its own framework, which ceases the RED cybersecurity obligations rather than incorporating them.
For companies whose products have long operational lifespans — warehouse hardware, logistics devices, industrial controllers, retail IoT — this is not a documentation exercise. It is a structural operational commitment that has to be built into how products are designed, supported, and eventually retired.
How the CRA Sits Alongside GDPR and NIS2
A common point of confusion: the CRA does not replace GDPR or NIS2. They operate at different layers.
NIS2 focuses on cybersecurity standards for organisations operating essential services in specific sectors. The CRA establishes requirements for the manufacturers and distributors of digital products themselves. If your company both manufactures connected devices and operates as an essential or important entity under NIS2, both frameworks apply simultaneously — with different obligations flowing from each.
The CRA is expressly without prejudice to GDPR, meaning product cybersecurity and personal data compliance cannot be treated as separate concerns where products process personal data.
Key Dates
| Date | What happens |
|---|---|
| August 2025 | RED cybersecurity requirements already in force for internet-connected radio equipment |
| 11 September 2026 | CRA incident reporting obligations take effect — manufacturers must notify ENISA of actively exploited vulnerabilities and severe incidents within 24 hours |
| 11 December 2027 | Full CRA compliance mandatory — non-compliant products cannot be placed on the EU market. RED cybersecurity delegated regulation formally repealed. |
Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
Frequently Asked Questions
Does the CRA apply to a device that only communicates on a local network, not the internet? Yes. Unlike RED, the CRA does not require internet connectivity. Any device that communicates with another device or system — including over a closed local or proprietary network — falls within scope if it has digital elements.
Does CRA compliance replace RED compliance? Not until December 2027. Until then, both frameworks apply in parallel for in-scope radio equipment. From December 2027, the RED cybersecurity delegated regulation is formally repealed and the CRA becomes the governing framework. The CRA replaces RED’s cybersecurity provisions — it does not incorporate them.
Does the CRA apply to the software running on a connected device, not just the hardware? Yes. The CRA covers software and firmware that runs on or is supplied with connected devices, including device operating systems, embedded firmware, mobile apps used to control IoT products, desktop management tools, and cloud-based interfaces that interact with these devices, where those are supplied as part of a product with digital elements.
If a product was already CE marked under RED, does it automatically comply with the CRA? No. The CRA applies to all products with digital elements placed on the EU market, regardless of when they were designed or CE marked under previous directives. The CRA introduces new cybersecurity obligations not covered under existing CE legislation, including secure development, vulnerability management, and incident reporting.
Does the CRA apply to importers and distributors, or only manufacturers? All three. The CRA extends obligations beyond manufacturers to include importers, distributors, and all third parties in the product lifecycle. In some circumstances, importers and distributors can be treated as manufacturers if they substantially modify a product or place it on the market under their own name.
How long must manufacturers support products after sale, and how long must they retain documentation? These are two distinct obligations. On support: manufacturers must provide security updates and handle vulnerabilities for at least five years after a product is placed on the market, or for the expected product lifetime if that is longer — whichever is greater. On documentation: technical documentation must be retained for ten years after the product is placed on the market, or the support period, whichever is longer.
The Compliance Challenge
The CRA’s obligations — scope determination, conformity assessment pathway, technical documentation, vulnerability disclosure processes, incident reporting for actively exploited vulnerabilities and severe incidents, and supply chain due diligence — interact with each other and with existing regulatory frameworks in ways that are rarely straightforward.
The CRA forms one component of a broader EU digital governance architecture that includes NIS2, DORA, the AI Act, the eIDAS 2 framework, and the EUCC certification scheme. Navigating that architecture, and understanding exactly where your products sit within it, is not a task that resolves itself.
December 2027 is closer than it looks, and the groundwork — product scoping, gap analysis, conformity pathway decisions — takes time.
Not sure where your products stand? That’s exactly the conversation to have now. Get in touch