CRA Compliance for IoT and Connected Devices

The EU Cyber Resilience Act was designed with connected devices in mind. IoT products — smart home devices, industrial sensors, wearables, connected appliances — are squarely in scope. They also face unique compliance challenges that pure software products do not: firmware update logistics, hardware constraints, long device lifetimes, and physical security considerations.

This guide covers what IoT manufacturers need to know about CRA compliance and how to address the specific challenges that connected devices present.

Why IoT Is a Primary CRA Target

The CRA's explanatory memorandum specifically calls out the poor state of IoT security as a key motivation for the regulation. Recitals of Regulation 2024/2847 highlight that many connected products are placed on the market with inadequate security, lack update mechanisms, and are abandoned by manufacturers long before the devices reach end of life.

The numbers back this up. IoT devices are consistently among the most targeted endpoints in cyberattacks, and botnets like Mirai demonstrated that insecure consumer devices can be weaponized at scale.

IoT Product Classification Under the CRA

Most consumer IoT devices (smart lights, thermostats, fitness trackers, robot vacuums) fall in the default category and require self-assessment. However, several IoT-related product types fall under higher categories:

Important Class I (Annex III, Part I):

• Home automation systems with security functionality
• Smart door locks and access control devices
• Network-connected cameras (baby monitors, security cameras)
• Routers and network gateways
• Wearable medical devices (may also fall under MDR)

Important Class II (Annex III, Part II):

• Industrial IoT devices and sensors
• Industrial automation and control systems
• Firewalls and intrusion detection appliances

Critical (Annex IV):

• Smart meter gateways
• Hardware security modules

Consult the product classification guide to determine exactly where your device falls. The classification determines whether you can self-assess or need third-party certification.

Firmware Updates and OTA Security

The CRA requires manufacturers to provide security updates throughout the product's support period. For IoT devices, this means implementing a secure over-the-air (OTA) update mechanism. This is not optional — a connected device without an update mechanism cannot meet CRA requirements.

Your OTA update system must ensure:

• Authenticity: updates must be cryptographically signed so the device can verify they come from the legitimate manufacturer
• Integrity: the device must verify the update has not been tampered with during transmission
• Rollback protection: prevent attackers from downgrading firmware to a version with known vulnerabilities
• Failure resilience: a failed update must not brick the device. Implement A/B partition schemes or recovery mechanisms.
• User notification: inform users when updates are available and what they address

Security updates must be provided free of charge. You cannot charge users for patches to security vulnerabilities.

Device Lifecycle and Support Period

The CRA requires manufacturers to define and communicate a support period during which security updates will be provided. For IoT devices, this is particularly important because devices often remain in use for years — a smart thermostat might be installed for a decade.

When defining your support period, consider:

• The expected operational lifetime of the device
• The lifetime of the hardware platform and its supply chain
• Your ability to maintain and test firmware updates for the device
• Market expectations for the product category

The CRA states the support period should be proportionate to the expected product lifetime. A smart home hub with a 10-year expected lifetime should have a correspondingly long support commitment.

Document your support period clearly in product documentation and on packaging. When the support period ends, inform users that the device will no longer receive security updates.

Secure Default Configuration for IoT

The secure development requirements in Annex I Section 1 apply to IoT with specific implications:

• No default passwords. Every device must require a unique password set during initial setup, or ship with a unique per-device credential printed on the device label.
• Minimal attack surface. Disable unused network services, close unnecessary ports, and ship with the minimum functionality needed for the device's purpose.
• Encrypted communication. All network communication must use encryption by default. Unencrypted protocols (plain HTTP, unencrypted MQTT) are not acceptable as defaults.
• Local data protection. Data stored on the device must be protected against physical extraction where feasible.

SBOM for Firmware

Generating an SBOM for IoT firmware is more complex than for a typical software application. Firmware often includes:

• An embedded operating system (Linux, RTOS, Zephyr)
• System libraries and drivers
• Application code
• Third-party middleware and protocol stacks
• Bootloader components

Use tools like Syft or Trivy to scan your firmware build artifacts. For embedded Linux systems, tools like SPDX SBOM Generator can extract component information from the build system (Yocto, Buildroot).

Track your firmware SBOM alongside your device hardware revision. Different hardware revisions may ship different firmware with different component compositions.

Vulnerability Monitoring for IoT

IoT firmware dependencies often include system-level libraries (OpenSSL, BusyBox, the Linux kernel) that have different vulnerability ecosystems than application-level packages. Your vulnerability monitoring must cover:

• Application dependencies (npm, pip, cargo packages)
• System packages (Debian/Alpine packages, Yocto recipes)
• Kernel and bootloader vulnerabilities
• Hardware-specific vulnerabilities (CPU, chipset, radio firmware)

When a vulnerability is detected in a shipped firmware component, assess whether it is exploitable in your specific configuration. Not every Linux kernel CVE affects every device — but document your analysis. If the vulnerability is actively exploited, ENISA reporting within 24 hours is mandatory.

CE Marking for IoT Devices

IoT devices already subject to other EU regulations (Radio Equipment Directive, Machinery Regulation, Medical Device Regulation) may already carry CE marks for those requirements. The CRA adds cybersecurity requirements to the CE marking process.

You will need to ensure your CE marking covers CRA conformity in addition to any existing directive requirements. The EU Declaration of Conformity must reference the CRA alongside other applicable regulations.

Smart Home Devices: A Practical Example

A smart home hub is a good example of the CRA's impact on IoT. Here is what compliance looks like:

1. Classification: likely default category or Important Class I if it has security functions
2. SBOM: generated from firmware build system, covering the embedded Linux stack, application code, and all libraries
3. Secure defaults: unique setup password, encrypted Wi-Fi and cloud communication, automatic updates enabled
4. Update mechanism: signed OTA updates with rollback protection and failure recovery
5. Support period: minimum 5 years, documented on packaging and in the app
6. Vulnerability monitoring: continuous scanning of SBOM against vulnerability databases
7. Disclosure policy: SECURITY.md in the firmware repository, security contact on the company website
8. ENISA reporting: processes in place to detect and report actively exploited vulnerabilities within 24 hours

For a complete preparation plan, see our CRA compliance checklist.

Complaro supports IoT manufacturers with firmware SBOM analysis, continuous vulnerability monitoring across embedded component ecosystems, and automated ENISA reporting. Get started free.