IoT Devices and the CRA: Classification and Requirements

IoT Devices Are a Core CRA Target

The EU Cyber Resilience Act was, in significant part, written with IoT devices in mind. The proliferation of connected devices with poor security — default passwords, no update mechanisms, unencrypted communications — drove the regulation's creation. IoT devices are firmly in scope as products with digital elements.

Classification of IoT Devices

Most consumer IoT devices (smart speakers, connected appliances, wearables) fall in the default category and can self-certify. However, some IoT devices fall into Class I or Class II:

Class I IoT devices (Annex III, List 1):

• Consumer routers and modems
• Smart meters with cybersecurity functions
• IoT devices intended for child monitoring

Class II IoT devices (Annex III, List 2):

• Industrial IoT in critical infrastructure
• Safety-critical industrial automation systems

Most Challenging Annex I Requirements for IoT

Secure by Default (Req 2)

Historically, IoT devices shipped with default credentials shared across the entire product line — the same username and password printed on millions of units. The CRA ends this: unique credentials per device or mandatory first-use change is required.

Update Mechanisms (Part II, Req 3/4)

Many resource-constrained IoT devices have no secure update mechanism at all. Implementing signed OTA (over-the-air) updates with rollback protection on microcontroller-class hardware requires careful design and often additional flash storage.

Security Logging (Req 10)

Logging security events requires persistent storage and transmission capability. On constrained devices, this may mean sending logs to a cloud backend — which in turn requires secure channel configuration and privacy consideration (the logs themselves may contain personal data).

Five-Year Support (Part II, Req 5)

Consumer IoT devices are often sold cheaply and at scale. Committing to five years of security updates means maintaining a patching infrastructure for potentially millions of devices across multiple hardware generations. This has significant implications for product lifecycle planning.

Implementation Considerations for Constrained Devices

• Secure boot: even on Cortex-M class microcontrollers, secure boot with key storage is achievable with modern MCUs that include hardware security modules
• SBOM on constrained firmware: tools like Yocto and Buildroot can generate SBOMs of firmware images; third-party tools like Syft handle container and binary analysis
• TLS on constrained devices: mbedTLS and WolfSSL provide TLS 1.3 implementations that run on 64KB RAM devices
• Remote attestation: consider whether your device architecture can support remote attestation to verify firmware integrity from the cloud