Cyber Resilience Act for IoT, Embedded & Smart Products

Connected products with digital elements – from smart locks and routers to wearables and industrial controllers – fall, as a rule, within the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847). The trigger is a direct or indirect logical or physical data connection to a device or network (Art. 2(1), Art. 3(1)). For makers of IoT and embedded products this means: cybersecurity becomes a prerequisite for CE marking and therefore for market access in the EEA. This page offers technical-organisational orientation – not legal advice.

Are your products affected?

A “product with digital elements” (PDE) is any software or hardware product together with its remote data processing solutions (Art. 3(1)). A cloud/back-end component whose absence would stop a product function, provided by the manufacturer, also counts as an integral part of the PDE (Art. 3(2)). Excluded are, among others, medical devices (MDR/IVDR), motor vehicles and products under equivalent Union rules (Art. 2). A purely standalone SaaS/cloud application generally does not fall under the CRA but under NIS2 – though the boundary is not always clear-cut at the edges.

Check your basic applicability with our CRA applicability check.

Product classes: how strictly is conformity assessed?

The CRA has four tiers (Art. 32, Annexes III/IV). The classification determines the conformity route. It is typically to be understood as follows – when in doubt, classify conservatively and have it reviewed:

Important: a notified body is mandatory only for Class II and critical products – not “all products need a notified body”. Details on classification are available under CRA product classes. The technical category descriptions are set out in Commission Implementing Regulation (EU) 2025/2392.

Core duties & action areas for IoT makers

From Annex I and the manufacturer duties (Art. 13/14), the following action areas are particularly relevant for connected products:

• Secure default configuration: ship with secure defaults (security-by-default), no hard-wired default passwords, minimised attack surface.
• Secure, free updates: provide security updates without delay and free of charge; separate security from feature updates where feasible; secure update distribution.
• Support period: as a rule at least 5 years (or the shorter expected use). For long-lived embedded devices, plan this early into roadmap and BOM.
• Vulnerability handling incl. SBOM: identify and document vulnerabilities and components – including an SBOM in a commonly used, machine-readable format, at least for top-level dependencies. The Regulation mandates no specific format (CycloneDX, SPDX etc. satisfy this as recognised formats).
• CVD policy: a mandatory coordinated-vulnerability-disclosure policy including a contact address for reporting.
• Technical documentation (Annex VII) & CE: architecture, SBOM, CVD policy, update distribution, risk assessment mapped to Annex I; EU Declaration of Conformity (Art. 28), CE marking (Art. 30). Retention at least 10 years (or the support period).
• Reporting duties (Art. 14): report actively exploited vulnerabilities and severe incidents to the CSIRT/ENISA – early warning within 24 h, notification within 72 h, final report within 14 days after a fix is available (vulnerabilities) or within one month (incidents).

Timeline: these deadlines apply

Recommended roadmap: (1) classify the product portfolio and clarify applicability; (2) gap analysis against Annex I; (3) set up an SBOM pipeline and CVD policy; (4) establish update and support processes for ≥5 years; (5) prepare technical documentation and the conformity route. Anyone designing radio equipment to be CRA-compliant today also covers the RED interim and avoids the 2027 migration.

Background and overview: Cyber Resilience Act.