Cyber Resilience Act for IoT, Embedded & Smart Products

Connected products with digital elements - from smart locks and routers to wearables and industrial controllers - fall, in principle, within the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847). The condition is that their intended purpose or reasonably foreseeable use includes 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 access to the EU market. 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)). Cloud or back-end processing also counts where the manufacturer has designed and developed its software, or had it designed and developed under its responsibility, and the product could not perform one of its functions without it (remote data processing, Art. 3(2)). Excluded are, among others, medical devices and in-vitro diagnostics (MDR/IVDR), products within the scope of the motor vehicle type-approval Regulation (EU) 2019/2144 and aviation products certified under Regulation (EU) 2018/1139 (Art. 2(2) and (3)). For products under other sectoral rules, the Commission may limit or exclude application by delegated act (Art. 2(5)). A purely standalone SaaS or cloud application is in principle outside the CRA; the NIS2 Directive covers cloud computing services, as a rule only where the provider is at least a medium-sized enterprise (recital 12 CRA). The boundary is not always clear-cut at the edges.

Our CRA applicability check gives a first orientation per product.

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 schematically to be understood as follows - when in doubt, classify conservatively and have it reviewed:

For orientation: third-party assessment is required in every case for Class II and critical products, and for Class I whenever harmonised standards, common specifications or a European scheme are not applied in full. Default-category products self-assess. 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: disseminate security updates without delay and free of charge (a different arrangement is possible with business users for tailor-made products); separate security from feature updates where feasible; secure update distribution.
• Support period: set so that it reflects the expected time of use, at least 5 years (shorter only where the expected use is shorter). 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. Examples of machine-readable formats are CycloneDX and SPDX (ISO/IEC 5962); what counts for the requirement is the content, at least the top-level dependencies.
• 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 for the support period, whichever is longer.
• Reporting duties (Art. 14): report actively exploited vulnerabilities and severe incidents having an impact on the security of the product to the CSIRT designated as coordinator and to ENISA: early warning without undue delay and in any event within 24 hours, notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available (vulnerabilities) or one month after the notification (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 the whole support period (at least 5 years); (5) prepare technical documentation and the conformity route. Aligning radio equipment with Annex I CRA today while evidencing RED compliance via EN 18031 lets you reuse the risk assessment and documentation as a starting point in 2027.

Background and overview: Cyber Resilience Act.