CRA Compliance for IoT & Smart Home: Connected Device Security Requirements

Default Category (Most Consumer IoT)

• Smart lightbulbs, speakers, TVs, appliances, fitness trackers
• Self-assessment conformity route (no third-party audit required)
• Must still meet all essential requirements

Important Class I (Network-Connected, Security-Relevant)

• Smart home hubs and gateways, routers, home automation controllers
• Connected cameras and baby monitors
• Smart locks and alarm systems
• Wearable health devices
• Requires harmonised standard compliance OR third-party assessment

Important Class II (Critical Function)

• Industrial IoT gateways, smart meters
• Requires mandatory third-party conformity assessment

• No default passwords: Each device must have a unique password or require the user to set one during setup
• Secure by default: Unnecessary ports closed, unused services disabled, minimal attack surface
• Over-the-air updates: Secure, authenticated update mechanism. Users must be notified of updates. Automatic updates should be the default (with opt-out).
• Data protection: Storage and transmission encrypted. Data minimisation — collect only what's needed for the device's function.
• Resilience: Device must continue to function (at minimum, locally) when internet connectivity is lost
• SBOM: Software Bill of Materials documenting all components — challenging for embedded Linux devices with hundreds of packages

The vulnerability handling requirements apply from 11 September 2026:

• Coordinated disclosure: Public contact point for vulnerability reports. Process to triage, fix, and release patches.
• ENISA reporting: Actively exploited vulnerabilities reported within 24 hours
• Security updates: Provide free security updates for the entire support period. For IoT devices with 5-10 year lifetimes, this is a significant commitment.
• End-of-life: When support ends, make the last firmware version's source code available (for open-source components) so the community can maintain security.

• Legacy products: Devices already on the market must comply by December 2027. Retrofitting security into existing firmware may not be feasible — withdrawal from market may be required.
• Supply chain complexity: IoT devices typically use SoCs from Qualcomm, MediaTek, or Espressif — the device manufacturer depends on the chip vendor for firmware updates
• Cost impact: Security engineering, vulnerability handling, and 5-year update commitments add significant cost. Low-margin consumer IoT products may become uneconomical to sell in the EU.
• Testing infrastructure: Need continuous security testing pipeline — fuzzing, SAST/DAST, firmware analysis — for every release across every product variant