CRA in consumer IoT & smart home

Why the CRA hits smart-home makers directly

A Wi-Fi router, a doorbell camera or a smart lock is the archetype of what the Cyber Resilience Act (Regulation (EU) 2024/2847) calls a "product with digital elements" (PDE): hardware that is connected to a network permanently or intermittently and runs software. Consumer IoT therefore sits inside the scope almost by definition, with the full range of Annex I manufacturer obligations.

In this sector, "am I in scope?" is quickly answered: for connected devices the answer is yes in principle. The pain sits in the supply chain: where smart-home devices are built on bought-in OEM boards and sold in high volumes on thin margins, the firmware quickly becomes a years-grown mix of Linux/RTOS, OpenSSL/mbedTLS, BusyBox and dozens of OSS libraries that nobody in-house has a complete bill of materials for. Exactly these points - provable software provenance, update capability over years, handling of exploited vulnerabilities - are what the CRA makes binding.

Particularly awkward: anyone placing products on the market under their own name or brand is deemed the manufacturer (Article 21) and bears the full Annex I obligations for a board they did not design. "We only buy it in" brings no relief under the CRA. This text provides orientation and is not legal advice for the individual case.

Typical PDE products and their likely Annex III classification

The conformity burden depends heavily on whether a device falls into the default category (self-assessment under Module A) or is listed in Annex III as an "important product". The table below sketches the likely classification of typical smart-home products - schematically, without a categorical case-by-case assurance. What counts for the classification is the device's core function (Article 7(1)). The precise technical descriptions of the important and critical categories are set out in Implementing Regulation (EU) 2025/2392.

Unrestricted self-assessment remains only for devices without an Annex III function, such as smart lights and plugs. Self-assessment means: no notified body, but full technical documentation under your own responsibility. Routers, security cameras, baby monitors, door locks, alarm systems and voice assistants are class I; as long as no harmonised standard has been published, they need a notified body (Module B+C or H) unless common specifications or a European scheme (at least “substantial”) are fully applied. Class II (Module B+C, Module H or a European scheme of at least “substantial”, e.g. firewalls, IDS/IPS) and Annex IV critical (e.g. hardware security modules, smart-meter gateways) play a minor role in classic consumer smart home.

The sector standard ETSI EN 303 645 and delineation from RED-DA, NIS2 and the AI Act

The relevant sector standard for consumer IoT is ETSI EN 303 645 - the established baseline with core requirements such as "no universal default passwords", a documented update mechanism, secure communication and a channel for reporting vulnerabilities. The standard is not per se a CRA obligation, but it overlaps substantively with Annex I and is an obvious reference for the conformity case. If it, or a standard built on it, is published as a harmonised standard in the Official Journal, its full application triggers the presumption of conformity and opens the self-assessment path (Module A) for class I devices, as do common specifications or a European cybersecurity certification scheme (at least “substantial”); without one of them, Module B+C or H applies. Harmonised standards for the CRA have been requested (M/606) but were not yet published in the Official Journal on 9 October 2026.

Delineation from neighbouring regimes clarifies who does what and when:

• RED Delegated Act (Reg. (EU) 2022/30): since 1 August 2025 its cybersecurity requirements (Art. 3.3 d/e/f) have applied to certain radio equipment, in particular equipment that can communicate over the internet. Delegated Regulation (EU) 2026/339 repeals Reg. 2022/30 with effect from 11 Dec 2027; from then on the CRA covers these requirements. Until then the RED requirements apply to these radio products, and since 11 Sep 2026 the reporting obligation under Art. 14 CRA applies in addition. Build the evidence once and you can use it for both regimes.
• NIS2: addresses essential and important entities, not product cybersecurity. A smart-home maker is in the manufacturer duty via the CRA. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. Separate legal acts, do not equate them.
• AI Act: applies in addition as soon as an AI system is built in; the scope of duties depends on the risk level, for example transparency obligations under Art. 50 or further duties for certain biometric analyses.
• Sector exemptions: exempt are products to which the MDR, the IVDR or Type-Approval Regulation (EU) 2019/2144 apply, aviation products certified under Regulation (EU) 2018/1139, and marine equipment (Article 2(2) to (4)). A health wearable that falls under the MDR is therefore not additionally covered by the CRA. The consumer fitness tracker without a medical intended purpose, by contrast, falls under the CRA, and as a wearable intended for health monitoring even under Annex III class I (No. 19).

SBOM and supply-chain reality: the real effort driver

The software bill of materials (SBOM) is realistically the most laborious Annex I duty for this sector. A typical smart-home stack bundles a Linux or RTOS base, a TLS stack (OpenSSL or mbedTLS), BusyBox as user space, possibly a chip-vendor BSP, and dozens of OSS libraries on top. The problem is structural: producing on a cheap OEM board means inheriting its software history - including frozen, long end-of-life OpenSSL branches that no longer receive security updates, and components whose provenance nobody can cleanly document any more.

The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. There is no general obligation to publish it - but it must be available to the authority. To be useful in day-to-day work it should deliver: unambiguous component identification (name, version, supplier), linkability to vulnerability databases (so a new CVE can be automatically mapped to an affected product), and maintainability across the entire support period. That period follows the expected period of use: as a rule at least five years, shorter only where the expected period of use is shorter (Article 13(8)); for smart-home hardware that stays in the field longer, correspondingly more.

In practice this means: obtain and check the supplier SBOM, identify and replace or compensate EOL components, and demonstrate a reliable OTA update path. These three building blocks are the basis for demonstrating Annex I from 11 December 2027.

Reporting capability and PSIRT: implementing the Art. 14 cascade correctly

Since 11 September 2026 the reporting obligations of Art. 14 have applied, the very first hard manufacturer duty. For a smart-home maker this means: a working PSIRT/CVD process must already be in place now, well before the first device has to meet full product requirements from 11 December 2027. For an actively exploited vulnerability or a severe incident, a staged cascade applies:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• 14 days - final report for an actively exploited vulnerability, counted from the availability of a corrective or mitigating measure.
• 1 month - final report for a severe incident, counted from the 72-hour notification.

The shorthand "24h / 72h / 14 days" is wrong: the 14 days apply to the exploited vulnerability, a severe incident has one month. Reporting goes via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. The manufacturer must build and maintain its internal reporting process regardless. For a sector with large volumes in the field and an OSS-heavy codebase, the real challenge is mapping a new CVE to your own product quickly at all - this is where the SBOM feeds directly into reporting capability.

Deadlines: what comes first

Two dates structure the preparation. First came 11 September 2026: since then the reporting obligations (Art. 14) have applied. This covers specifically the reporting duty; "the whole CRA" only applies from December 2027. Anyone who thinks they have time until 2027 overlooks that a PSIRT/CVD process and the ability to issue a 24-hour early warning must already be in place today. Then follows 11 December 2027 with full applicability of all product requirements - security by design/default, SBOM, technical documentation, EU declaration of conformity and CE marking. In practice: build organisational reporting capability first, and in parallel start on product-technical conformity (which needs the longer lead time); for class I devices this includes planning the notified body early. The technical documentation must be retained for at least ten years after placing on the market or for the longer support period (Article 13(13)).

Scenario: an IP-camera maker, worked through

A mid-sized vendor sells IP indoor cameras and doorbell cameras under its own brand. The boards come from an OEM in the Far East, the firmware is supplied as a binary image. Scope: the cameras are PDE and, as security cameras, important products of class I (Annex III No. 17); the vendor plans for a notified body. Because it places the products on the market under its own brand, it is deemed the manufacturer and carries the full Annex I set of obligations.

Step 1 - SBOM: it requests the OEM's CycloneDX SBOM and finds the TLS stack running on a frozen OpenSSL branch with no security maintenance. That is a blocker to be resolved before December 2027 - via an updated BSP or by replacing the component. Step 2 - updateability: it demonstrates a signed OTA update path across the defined support period (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)). Step 3 - ETSI EN 303 645: default passwords are abolished, a vulnerability reporting channel is set up. Step 4 - PSIRT: since 11 September 2026 a process must be in place that can serve the early warning (without undue delay, within 24 hours at the latest), the notification (within 72 hours at the latest) and the final report (14 days) via the single reporting platform for an actively exploited vulnerability. Step 5 - technical documentation and conformity assessment: risk assessment under Art. 13 and Annex I (developed via threat modelling), type examination or quality assurance assessment by the notified body, declaration of conformity and CE follow by 11 December 2027. This shows early where the supply chain does not yet deliver the evidence.

What Blackfort does for you

Blackfort Technology supports smart-home manufacturers and importers along exactly this chain - pragmatically and mapped to your portfolio:

• Scope and applicability analysis: a technical assessment of which of your devices are PDE, which are likely to stay default, which (routers, cameras, door locks, voice assistants) fall under Annex III class I, and where RED-DA still applies alongside the CRA until 10 Dec 2027. Start via our applicability check.
• SBOM setup: building machine-readable SBOMs, for example in CycloneDX or SPDX, requesting and checking the supplier SBOM, EOL/OSS risk analysis (the OpenSSL classic) and linking to vulnerability databases.
• PSIRT/CVD: setting up the reporting and coordinated-vulnerability-disclosure process aligned with the Art. 14 cascade, including connection to the single reporting platform - immediately, as the reporting obligation has applied since 11 September 2026.
• Risk assessment and threat modelling: the documentation-bound risk assessment under Art. 13 and Annex I, methodically as threat modelling for connected end devices.
• Technical documentation: from ETSI EN 303 645 coverage through preparation of the conformity assessment to the EU declaration of conformity.

Talk to us about your specific portfolio: get in touch. Background and deadlines at a glance are on our CRA page; smaller makers find additional orientation under CRA for SMEs. This article is a technical orientation and does not replace legal advice in the individual case.