IoT CRA compliance is an end-to-end trust problem. The manufacturer needs to secure the device before commissioning, the pairing and ownership process, local and remote interfaces, cloud control, update delivery and recovery, and the transition between users or support states. Evidence should show how these controls work for the exact hardware and firmware placed on the market rather than treating IoT cybersecurity as a cloud-only or firmware-only problem.
Define the IoT Product Beyond the Physical Enclosure
An IoT product can combine hardware, embedded firmware, a mobile or desktop companion application and manufacturer-controlled remote processing. The CRA analysis should identify which elements are part of the product with digital elements and which external services merely interact with it. Where remote data processing meets the CRA definition, the security case should include the cloud dependency instead of stopping at the device enclosure.
Inventory Every Device Interface
IoT attack surfaces often include Wi-Fi, Bluetooth, Zigbee, Thread, cellular links, Ethernet, USB, serial ports, debug headers, local web interfaces, mobile-app APIs and cloud management channels. The technical documentation should identify enabled interfaces, trust assumptions and security controls. Unused production interfaces should be considered explicitly because an exposed debug or maintenance path can undermine otherwise strong network security.
Treat Commissioning as a Security-Critical State
Initial setup is often when an IoT device establishes Wi-Fi credentials, cloud ownership, user accounts, cryptographic keys or trust with a companion application. Manufacturers should threat-model first-use and re-commissioning paths, including how a device proves its identity, how the legitimate owner gains control and how an attacker is prevented from claiming an unconfigured or reset device.
Separate Device Identity From User Identity
A connected device usually needs its own technical identity in addition to user authentication. Product-specific design should document how device credentials are provisioned, stored, rotated or revoked and how backend services distinguish one device from another. Shared factory credentials or uncontrolled reuse of secrets can turn compromise of one unit into compromise of a fleet, so credential architecture should be tested at production scale.
Map Local and Remote Authorisation Separately
A function may be available locally over Bluetooth or a LAN while the same function is also reachable through a cloud API. Those paths can have different identity, session and privilege models. Manufacturers should document which operations can change configuration, expose data, install software or control physical behaviour and ensure that each path enforces the intended authority rather than assuming cloud authentication protects local interfaces automatically.
Secure the Firmware and Boot Chain
For embedded IoT products, firmware integrity is a central product property. The manufacturer should document how boot software establishes trust in executable code, how firmware images are authenticated, which keys or trust anchors are used, how rollback or recovery behaves and what happens after an interrupted update. The CRA does not prescribe one boot technology, so the evidence should justify the selected design against the product's risks.
Build Security Updating Around Real Fleet Conditions
IoT devices can be intermittently connected, battery powered, bandwidth constrained or deployed behind consumer routers for long periods. Update design should account for image authenticity, transport integrity, installation failure, power loss, insufficient storage and devices that miss several releases. Evidence should show how a vulnerable installed device reaches a supported secure state, not merely that an update server exists.
Include Companion Apps and Cloud APIs in Threat Analysis
An IoT device can be secure at the radio layer yet remain vulnerable through an over-privileged mobile API or weak cloud authorisation. Map device-to-cloud, app-to-cloud and local app-to-device flows, including tokens, account recovery, API object authorisation and remote commands. The product security case should make clear which component authorises a sensitive action and which evidence verifies that decision.
Manage Components Across Firmware and Services
IoT products commonly contain bootloaders, real-time operating systems, radio stacks, cryptographic libraries, vendor SDKs and cloud-side dependencies. Maintain component information that can support vulnerability impact analysis across those layers. When a component vulnerability is reported, the manufacturer should be able to identify affected device models, firmware branches and remote services without reconstructing the dependency tree from scratch.
Design Ownership Transfer and Factory Reset as Security Functions
Connected products can move between households, employees or customers. A factory reset should be reviewed for what credentials, personal data, cloud associations and access grants it removes, while an ownership-transfer process should prevent the previous owner from retaining unintended control. These behaviours affect confidentiality, access control and secure use throughout the product lifecycle.
IoT Does Not Automatically Mean Annex III
The CRA does not create a general Annex III category called IoT devices. Classification depends on core functionality. An IoT product may fall into a listed category because it is, for example, a router, a smart-home product with security functionality, a qualifying connected toy or another listed important product. A generic connected sensor does not become class I merely because it communicates over the Internet.
Keep IoT Evidence at Device-Fleet Granularity
Useful evidence includes hardware revision, firmware version, boot and update design, interface inventory, protocol threat model, device credential lifecycle, cloud endpoints, companion-app versions, SBOM, security tests and support status. The manufacturer should be able to move from a reported vulnerability to the exact installed populations and remediation path that are affected.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.