CRA im Consumer-IoT & Smart-Home

Warum Smart-Home-Hersteller vom CRA besonders hart getroffen werden

Ein WLAN-Router, eine Türklingel-Kamera oder ein Smart-Lock ist der Prototyp dessen, was der Cyber Resilience Act (Verordnung (EU) 2024/2847) ein „Produkt mit digitalen Elementen" (PDE) nennt: Hardware, die dauerhaft oder zeitweise mit einem Netz verbunden ist und Software ausführt. Consumer-IoT sitzt damit fast per Definition im Anwendungsbereich der Verordnung — und zwar über die gesamte Bandbreite der Herstellerpflichten aus Anhang I, nicht nur mit einem Häkchen auf einem Datenblatt.

Der reale Schmerz dieser Branche ist selten die Frage „bin ich betroffen?" — die Antwort lautet in aller Regel ja. Der Schmerz sitzt in der Lieferkette: Smart-Home-Geräte werden mit dünnen Margen in hohen Stückzahlen verkauft, laufen oft auf günstigen OEM-Boards aus Fernost, und die Firmware ist ein über Jahre gewachsenes Konvolut aus Linux/RTOS, OpenSSL/mbedTLS, BusyBox und Dutzenden OSS-Bibliotheken, für die niemand im Haus eine vollständige Stückliste hat. Genau diese Punkte — nachweisbare Software-Herkunft, Update-Fähigkeit über Jahre, Umgang mit ausgenutzten Schwachstellen — macht der CRA verbindlich.

Besonders unangenehm: Wer nur importiert und unter eigener Marke vertreibt, kann in die Herstellerrolle rücken und trägt dann die volle Verantwortung für ein Board, das er nicht selbst entwickelt hat. „Wir kaufen das doch nur ein" ist unter dem CRA keine Entlastung, sondern oft der Einstieg in die schärfste Pflichtenlage. Dieser Text ordnet ein und ersetzt keine Rechtsberatung im Einzelfall.

Typische PDE-Produkte der Branche und ihre wahrscheinliche Anhang-III-Einordnung

Die Konformitätslast hängt maßgeblich davon ab, ob ein Gerät in die Standardkategorie fällt (Selbstbewertung nach Modul A) oder in Anhang III als „wichtiges Produkt" gelistet ist. Die folgende Tabelle skizziert die voraussichtliche Einordnung typischer Smart-Home-Produkte — schematisch, ohne kategorische Einzelfallzusage. Die präzisen technischen Beschreibungen der wichtigen und kritischen Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392; die konkrete Einordnung eines Geräts kann sich mit Präzisierungen der Kommission noch verschieben.

Für die große Mehrheit der Smart-Home-Endgeräte bleibt es also bei der Selbstbewertung — was nicht heißt „ohne Aufwand", sondern „ohne notifizierte Stelle, dafür mit vollständiger technischer Dokumentation in Eigenverantwortung". Der Router ist im typischen Produktportfolio der wahrscheinlichste Kandidat für den Pfad über eine notifizierte Stelle, sobald keine vollständig anwendbare harmonisierte Norm vorliegt. Klasse II (immer notifizierte Stelle, z. B. Firewalls, IDS/IPS) und Anhang-IV-kritisch (z. B. Hardware-Security-Module, Smart-Meter-Gateways) sind im klassischen Consumer-Smart-Home eher die Ausnahme.

Branchennorm ETSI EN 303 645 und die Abgrenzung zu RED-DA, NIS2 und AI Act

Der einschlägige Sektor-Standard für Verbraucher-IoT ist ETSI EN 303 645 — die etablierte Baseline mit Kernforderungen wie „keine universellen Default-Passwörter", dokumentierter Update-Mechanismus, sichere Kommunikation und Meldekanal für Schwachstellen. Die Norm ist nicht per se CRA-Pflicht, deckt aber viele Anhang-I-Anforderungen inhaltlich ab und ist als Referenz für den Konformitätsnachweis praktisch unverzichtbar. Sobald sie (bzw. eine darauf aufbauende Norm) als harmonisierte Norm im Amtsblatt gelistet ist, entfaltet ihre volle Anwendung die Konformitätsvermutung — und öffnet für Klasse-I-Geräte den Selbstbewertungspfad.

Die Abgrenzung zu benachbarten Regimen entscheidet, wer wann was tun muss:

• RED Delegated Act (VO (EU) 2022/30): Für funkgebundene Geräte gelten dessen Cybersicherheitsanforderungen (Art. 3.3 d/e/f). Der CRA überlagert dieses Regime perspektivisch bzw. löst es ab. In der Übergangsphase ist die Doppelregulierung zu managen — Ziel ist ein Nachweis, der beide Anforderungswelten bedient, nicht doppelte Zertifizierung.
• NIS2: adressiert Betreiber wesentlicher/wichtiger Einrichtungen, nicht die Produkt-Cybersicherheit des Herstellers. Ein Smart-Home-Hersteller ist über den CRA in der Herstellerpflicht — NIS2 ist ein getrennter Rechtsakt und darf nicht gleichgesetzt werden.
• AI Act: greift erst, wenn ein Gerät regulierte KI-Funktionen enthält (z. B. bestimmte biometrische Auswertungen). Für die meisten Smart-Home-Standardfunktionen ist er nicht einschlägig; wo doch, gilt er zusätzlich zum CRA.
• Sektorausnahmen: Medizinprodukte (MDR/IVDR), Kfz-Typgenehmigung, zivile Luftfahrt und Schiffsausrüstung sind vom CRA ausgenommen. Ein als Medizinprodukt zugelassenes Health-Wearable fällt also nicht zusätzlich unter den CRA — der Consumer-Fitness-Tracker in der Regel schon.

SBOM- und Lieferketten-Realität: der wahre Aufwandstreiber

Die Software-Stückliste (SBOM) ist für diese Branche die realistisch aufwändigste Anhang-I-Pflicht. Ein typischer Smart-Home-Stack bündelt ein Linux- oder RTOS-Fundament, einen TLS-Stack (OpenSSL oder mbedTLS), BusyBox als User-Space, oft ein vom Chip-Hersteller geliefertes BSP und darüber Dutzende OSS-Bibliotheken. Das Problem ist strukturell: Wer auf einem günstigen OEM-Board produziert, erbt dessen Software-Historie — inklusive eingefrorener, längst End-of-Life-OpenSSL-Zweige, die keine Sicherheitsupdates mehr erhalten, und Komponenten, deren Herkunft niemand mehr sauber belegen kann.

Der CRA verlangt eine maschinenlesbare SBOM in CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 (so die BSI-Richtlinie TR-03183-2 v2.1.0), mindestens auf Ebene der Top-Level-Abhängigkeiten, als Teil der technischen Dokumentation. Eine allgemeine Veröffentlichungspflicht besteht nicht — die SBOM muss aber gegenüber der Behörde bereitstellbar sein. Konkret muss sie leisten: eindeutige Komponentenidentifikation (Name, Version, Lieferant), Verknüpfbarkeit mit Schwachstellendatenbanken (damit ein neues CVE automatisiert einem betroffenen Produkt zugeordnet werden kann) und Nachführbarkeit über den gesamten Support-Zeitraum. Dieser Support-Zeitraum orientiert sich an der erwarteten Produktlebensdauer; als Leitlinie gelten mindestens fünf Jahre — für Smart-Home-Hardware, die oft länger im Feld bleibt, eher mehr.

Praktisch bedeutet das: Die SBOM des Zulieferers einfordern und verifizieren, EOL-Komponenten identifizieren und ersetzen oder kompensieren, und einen belastbaren OTA-Update-Pfad nachweisen. Ohne diese drei Bausteine lässt sich ein Consumer-IoT-Produkt ab dem Stichtag der vollen Produktanforderungen nicht mehr rechtssicher in Verkehr bringen.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt umsetzen

Ab dem 11.09.2026 greifen die Melde- und Berichtspflichten aus Art. 14 — die erste harte Herstellerpflicht überhaupt. Für einen Smart-Home-Hersteller heißt das: ein funktionierender PSIRT-/CVD-Prozess muss stehen, bevor das erste Gerät ab dem 11.12.2027 die vollen Produktanforderungen erfüllen muss. Bei einer aktiv ausgenutzten Schwachstelle oder einem schweren Sicherheitsvorfall gilt eine gestufte Kaskade:

• 24 Stunden — Frühwarnung (early warning) ab Kenntnisnahme.
• 72 Stunden — vollständige Meldung inklusive bereits ergriffener Korrektur-/Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat — Abschlussbericht bei einem schweren Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Der weit verbreitete Kurzschluss „24h / 72h / 14 Tage" ist falsch: Die 14 Tage gelten für die ausgenutzte Schwachstelle, ein schwerer Vorfall hat einen Monat. Gemeldet wird über die ENISA Single Reporting Platform (SRP), die den Vorgang an den CSIRT der Hauptniederlassung und an ENISA verteilt — eine Einmalmeldung. Die Plattform wird zum 11.09.2026 bereitgestellt; dass sie Mitte 2026 noch nicht voll operativ ist, entbindet nicht von der Pflicht, den internen Prozess bis dahin aufzubauen. Für eine Branche mit vielen Geräten im Feld und einer OSS-lastigen Codebasis ist die eigentliche Herausforderung, ein neues CVE überhaupt schnell dem eigenen Produkt zuzuordnen — hier zahlt die SBOM direkt auf die Meldefähigkeit ein.

Fristen: was zuerst kommt

Zwei Daten strukturieren die Vorbereitung. Zuerst kommt der 11.09.2026: ab dann gelten die Melde- und Berichtspflichten (Art. 14). Das ist kein „ganzer CRA ab September 2026" — es ist gezielt die Meldepflicht. Wer glaubt, bis 2027 Zeit zu haben, übersieht, dass ein PSIRT-/CVD-Prozess und die Fähigkeit zur 24-Stunden-Frühwarnung bereits gut ein Jahr früher stehen müssen. Danach folgt der 11.12.2027 mit der vollen Anwendbarkeit aller Produktanforderungen — Security-by-Design/Default, SBOM, technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung. Praktisch heißt das: erst die organisatorische Meldefähigkeit aufbauen, parallel die produkttechnische Konformität (die den längeren Vorlauf braucht) starten. Die technische Dokumentation ist übrigens zehn Jahre nach Inverkehrbringen aufzubewahren.

Szenario: ein Hersteller von IP-Kameras, durchgespielt

Ein mittelständischer Anbieter vertreibt unter eigener Marke IP-Innenkameras und Türklingel-Kameras. Die Boards stammen von einem OEM in Fernost, die Firmware liefert der Zulieferer als Binärimage. Betroffenheit: Die Kameras sind PDE und voraussichtlich Standardkategorie — Modul-A-Selbstbewertung. Weil der Anbieter unter eigener Marke vertreibt und keinen EU-Hersteller vorschaltet, rückt er in die Herstellerrolle und trägt die volle Anhang-I-Pflichtenlage.

Schritt 1 — SBOM: Er fordert die CycloneDX-SBOM des OEM ein und stellt fest, dass der TLS-Stack auf einem eingefrorenen OpenSSL-Zweig ohne Sicherheitspflege läuft. Das ist ein Blocker, der vor Dezember 2027 gelöst sein muss — durch ein aktualisiertes BSP oder Ablösung der Komponente. Schritt 2 — Updatefähigkeit: Er weist einen signierten OTA-Update-Pfad über den definierten Support-Zeitraum (Leitlinie: mindestens fünf Jahre) nach. Schritt 3 — ETSI EN 303 645: Default-Passwörter werden abgeschafft, ein Schwachstellen-Meldekanal eingerichtet. Schritt 4 — PSIRT: Für den 11.09.2026 steht ein Prozess, der bei einer aktiv ausgenutzten Schwachstelle die 24-Stunden-Frühwarnung, 72-Stunden-Meldung und den 14-Tage-Abschlussbericht über die ENISA-SRP bedienen kann. Schritt 5 — technische Doku: Risikobewertung nach Art. 13 und Anhang I (per Threat-Modeling erarbeitet), Konformitätserklärung und CE folgen bis zum 11.12.2027. Ergebnis: ein Produkt, das rechtssicher am Markt bleibt — statt kurz vor dem Stichtag festzustellen, dass die Lieferkette den Nachweis nicht hergibt.

Was Blackfort für Sie tut

Blackfort Technology begleitet Smart-Home-Hersteller und -Importeure entlang genau dieser Kette — pragmatisch und auf Ihr Portfolio gemappt:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Geräte sind PDE, welches ist voraussichtlich Standard, welcher Router rückt Richtung Anhang III Klasse I — und wo greift RED-DA statt/neben dem CRA. Einstieg über unseren Betroffenheits-Check.
• SBOM-Setup: Aufbau maschinenlesbarer SBOMs in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1, Einforderung und Verifikation der Zulieferer-SBOM, EOL-/OSS-Risikoanalyse (der OpenSSL-Klassiker) und Verknüpfung mit Schwachstellendatenbanken.
• PSIRT/CVD: Aufbau des Melde- und Coordinated-Vulnerability-Disclosure-Prozesses passend zur Art.-14-Kaskade, inklusive ENISA-SRP-Anbindung — rechtzeitig vor dem 11.09.2026.
• Risikobewertung und Threat-Modeling: die dokumentationspflichtige Risikobewertung nach Art. 13 und Anhang I, methodisch als Threat-Modeling für vernetzte Endgeräte.
• Technische Dokumentation: von der ETSI-EN-303-645-Abdeckung bis zu Konformitätserklärung und CE-Vorbereitung.

Sprechen Sie mit uns über Ihr konkretes Portfolio: Kontakt aufnehmen. Hintergrund und Fristen im Überblick finden Sie auf unserer CRA-Seite; kleinere Hersteller finden zusätzliche Orientierung unter CRA für KMU. Dieser Beitrag ist eine fachliche Einordnung und ersetzt keine Rechtsberatung im Einzelfall.