CRA in consumer IoT & smart home

Why smart-home makers are hit particularly hard by the CRA

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 — and across the full range of Annex I manufacturer obligations, not just as a checkbox on a datasheet.

The real pain in this sector is rarely "am I in scope?" — the answer is usually yes. The pain sits in the supply chain: smart-home devices sell in high volumes on thin margins, often run on cheap OEM boards from the Far East, and the firmware is 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 who only imports and sells under their own brand can step into the manufacturer role and then carries full responsibility for a board they did not design. "We only buy it in" is no relief under the CRA — it is often the entry point into the strictest set of obligations. 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 largely 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. The precise technical descriptions of the important and critical categories are set out in Implementing Regulation (EU) 2025/2392; the exact classification of a device may still shift with Commission clarifications.

For the large majority of smart-home end devices, self-assessment applies — which does not mean "without effort" but "without a notified body, yet with full technical documentation under your own responsibility". In a typical portfolio the router is the most likely candidate for the notified-body path once no fully applicable harmonised standard is available. Class II (always a notified body, e.g. firewalls, IDS/IPS) and Annex IV critical (e.g. hardware security modules, smart-meter gateways) are the exception 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 substantively covers many Annex I requirements and is practically indispensable as a reference for the conformity case. Once it (or a standard built on it) is listed as a harmonised standard in the Official Journal, its full application triggers the presumption of conformity — and opens the self-assessment path for class I devices.

Delineation from neighbouring regimes decides who does what and when:

• RED Delegated Act (Reg. (EU) 2022/30): its cybersecurity requirements (Art. 3.3 d/e/f) apply to radio equipment. The CRA overlaps and will supersede this regime over time. During the transition the dual regulation is to be managed — the goal is a single body of evidence that serves both requirement worlds, not double certification.
• NIS2: addresses operators of essential/important entities, not the product cybersecurity of the manufacturer. A smart-home maker is in the manufacturer duty via the CRA — NIS2 is a separate legal act and must not be equated.
• AI Act: only bites where a device contains regulated AI functions (e.g. certain biometric analyses). For most standard smart-home functions it does not apply; where it does, it applies in addition to the CRA.
• Sector exemptions: medical devices (MDR/IVDR), motor-vehicle type approval, civil aviation and marine equipment are exempt from the CRA. A health wearable approved as a medical device is therefore not additionally in CRA scope — the consumer fitness tracker usually is.

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, often 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 machine-readable SBOM in CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 (per BSI guideline TR-03183-2 v2.1.0), at least at the level of top-level dependencies, as part of the technical documentation. There is no general obligation to publish it — but it must be available to the authority. Concretely it must 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 support period follows the expected product lifetime; as guidance, at least five years — for smart-home hardware that often stays in the field longer, rather more.

In practice this means: obtain and verify the supplier SBOM, identify and replace or compensate EOL components, and demonstrate a reliable OTA update path. Without these three building blocks a consumer-IoT product can no longer be lawfully placed on the market from the full-product-requirements date.

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

From 11 September 2026 the reporting obligations of Art. 14 apply — the very first hard manufacturer duty. For a smart-home maker this means: a working PSIRT/CVD process must be in place 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 from becoming aware.
• 72 hours — full notification including corrective/mitigating measures already taken.
• 14 days — final report for an actively exploited vulnerability, counted from the availability of a corrective measure.
• 1 month — final report for a severe security incident, counted from the 72-hour notification.

The common 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 ENISA Single Reporting Platform (SRP), which routes the case to the CSIRT of the main establishment and to ENISA — a single submission. The platform is to be provided by 11 September 2026; the fact that it is not fully operational in mid-2026 does not remove the duty to build the internal process by then. For a sector with many devices 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 comes 11 September 2026: from then the reporting obligations (Art. 14) apply. This is not "the whole CRA from September 2026" — it is specifically the reporting duty. 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 be in place a good year earlier. 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). The technical documentation, incidentally, must be retained for ten years after placing on the market.

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 likely default category — Module A self-assessment. Because the vendor sells under its own brand without an EU manufacturer upstream, it steps into the manufacturer role and carries the full Annex I set of obligations.

Step 1 — SBOM: it obtains 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 (guidance: at least five years). Step 3 — ETSI EN 303 645: default passwords are abolished, a vulnerability reporting channel is set up. Step 4 — PSIRT: for 11 September 2026 a process is in place that can serve the 24-hour early warning, 72-hour notification and 14-day final report via the ENISA SRP for an actively exploited vulnerability. Step 5 — technical documentation: risk assessment under Art. 13 and Annex I (developed via threat modelling), declaration of conformity and CE follow by 11 December 2027. Result: a product that stays lawfully on the market — instead of discovering just before the deadline that the supply chain cannot 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: which of your devices are PDE, which is likely default, which router moves towards Annex III class I — and where RED-DA applies instead of/alongside the CRA. Start via our applicability check.
• SBOM setup: building machine-readable SBOMs in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1, obtaining and verifying 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 ENISA-SRP connection — in good time before 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 to declaration of conformity and CE preparation.

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.