CRA im Consumer-IoT & Smart-Home

Warum der CRA Smart-Home-Hersteller direkt trifft

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 mit der gesamten Bandbreite der Herstellerpflichten aus Anhang I.

Die Frage „bin ich betroffen?" ist in dieser Branche schnell beantwortet: Für vernetzte Geräte lautet sie grundsätzlich ja. Der Schmerz sitzt in der Lieferkette: Wo Smart-Home-Geräte mit dünnen Margen in hohen Stückzahlen auf zugekauften OEM-Boards entstehen, ist die Firmware schnell 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 unter eigenem Namen oder eigener Marke in Verkehr bringt, gilt als Hersteller (Art. 21) und trägt die vollen Anhang-I-Pflichten für ein Board, das er nicht selbst entwickelt hat. „Wir kaufen das doch nur ein" entlastet unter dem CRA nicht. 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 stark 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. Für die Einstufung zählt die Kernfunktion des Geräts (Art. 7 Abs. 1). Die präzisen technischen Beschreibungen der wichtigen und kritischen Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392.

Selbstbewertung ohne Einschränkung bleibt nur für Geräte ohne Anhang-III-Funktion, etwa smarte Leuchten und Steckdosen. Selbstbewertung heißt dabei: keine notifizierte Stelle, aber vollständige technische Dokumentation in Eigenverantwortung. Router, Sicherheitskameras, Babyphones, Türschlösser, Alarmanlagen und Sprachassistenten sind Klasse I; solange keine harmonisierte Norm veröffentlicht ist, braucht es für sie eine notifizierte Stelle (Modul B+C oder H), sofern nicht gemeinsame Spezifikationen oder ein europäisches Schema (mindestens Stufe „mittel“) vollständig angewandt werden. Klasse II (Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“, z. B. Firewalls, IDS/IPS) und Anhang-IV-kritisch (z. B. Hardware-Security-Module, Smart-Meter-Gateways) spielen im klassischen Consumer-Smart-Home eine untergeordnete Rolle.

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, überschneidet sich aber inhaltlich mit Anhang I und ist eine naheliegende Referenz für den Konformitätsnachweis. Falls sie oder eine darauf aufbauende Norm als harmonisierte Norm im Amtsblatt veröffentlicht wird, löst ihre volle Anwendung die Konformitätsvermutung aus und öffnet für Klasse-I-Geräte den Selbstbewertungspfad (Modul A), ebenso wie gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Stufe „mittel“); ohne eines davon gilt Modul B+C oder H. Harmonisierte Normen zum CRA sind beauftragt (M/606), am 9. Oktober 2026 aber noch nicht im Amtsblatt veröffentlicht.

Die Abgrenzung zu benachbarten Regimen klärt, wer wann was tun muss:

• RED Delegated Act (VO (EU) 2022/30): Für bestimmte Funkanlagen, vor allem solche, die über das Internet kommunizieren können, gelten seit dem 1. August 2025 dessen Cybersicherheitsanforderungen (Art. 3.3 d/e/f). Die Delegierte VO (EU) 2026/339 hebt die VO 2022/30 mit Wirkung vom 11.12.2027 auf; ab dann deckt der CRA diese Anforderungen ab. Bis dahin gelten für diese Funkprodukte die RED-Anforderungen, seit dem 11.09.2026 zusätzlich die Meldepflicht nach Art. 14 CRA. Wer die Nachweise einmal sauber aufbaut, kann sie für beide Regime nutzen.
• NIS2: adressiert wesentliche und wichtige Einrichtungen, nicht die Produkt-Cybersicherheit. Ein Smart-Home-Hersteller ist über den CRA in der Herstellerpflicht. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Getrennte Rechtsakte, nicht gleichsetzen.
• AI Act: gilt zusätzlich, sobald ein KI-System verbaut ist; der Umfang der Pflichten hängt von der Risikostufe ab, etwa Transparenzpflichten nach Art. 50 oder weitergehende Pflichten bei bestimmten biometrischen Auswertungen.
• Sektorausnahmen: Ausgenommen sind Produkte, auf die MDR, IVDR oder die Typgenehmigungsverordnung (EU) 2019/2144 Anwendung finden, nach der Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte und Schiffsausrüstung (Art. 2 Abs. 2 bis 4). Ein Health-Wearable, das unter die MDR fällt, ist also nicht zusätzlich vom CRA erfasst. Der Consumer-Fitness-Tracker ohne medizinische Zweckbestimmung fällt dagegen unter den CRA, als am Körper tragbares Produkt zur Gesundheitsüberwachung sogar in Anhang III Klasse I (Nr. 19).

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, ggf. 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 Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Eine allgemeine Veröffentlichungspflicht besteht nicht - die SBOM muss aber gegenüber der Behörde bereitstellbar sein. Damit sie im Alltag nützt, sollte 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 Unterstützungszeitraum. Dieser orientiert sich an der erwarteten Nutzungsdauer: in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer (Art. 13 Abs. 8); für Smart-Home-Hardware, die länger im Feld bleibt, entsprechend mehr.

Praktisch bedeutet das: die SBOM des Zulieferers anfordern und prüfen, EOL-Komponenten identifizieren und ersetzen oder kompensieren, und einen verlässlichen OTA-Update-Pfad nachweisen. Diese drei Bausteine sind die Grundlage, um ab dem 11.12.2027 Anhang I nachweisen zu können.

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

Seit 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 schon jetzt stehen, lange bevor das erste Gerät ab dem 11.12.2027 die vollen Produktanforderungen erfüllen muss. Bei einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall gilt eine gestufte Kaskade:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat - Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Der Kurzschluss „24h / 72h / 14 Tage" ist falsch: Die 14 Tage gelten für die ausgenutzte Schwachstelle, ein schwerwiegender Vorfall hat einen Monat. Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Den internen Meldeprozess muss der Hersteller unabhängig davon selbst aufbauen und vorhalten. Für eine Branche mit großen Stückzahlen 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 kam der 11.09.2026: Seitdem gelten die Melde- und Berichtspflichten (Art. 14). Gemeint ist gezielt die Meldepflicht; der „ganze CRA" gilt erst ab Dezember 2027. Wer glaubt, bis 2027 Zeit zu haben, übersieht, dass ein PSIRT-/CVD-Prozess und die Fähigkeit zur 24-Stunden-Frühwarnung bereits heute 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; für Klasse-I-Geräte gehört dazu, die notifizierte Stelle früh einzuplanen. Die technische Dokumentation ist mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum aufzubewahren (Art. 13 Abs. 13).

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 als Sicherheitskameras wichtige Produkte der Klasse I (Anhang III Nr. 17); der Anbieter plant die notifizierte Stelle ein. Weil er unter eigener Marke in Verkehr bringt, gilt er als Hersteller und trägt die volle Anhang-I-Pflichtenlage.

Schritt 1 - SBOM: Er fordert die CycloneDX-SBOM des OEM an 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 Unterstützungszeitraum nach (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8). Schritt 3 - ETSI EN 303 645: Default-Passwörter werden abgeschafft, ein Schwachstellen-Meldekanal eingerichtet. Schritt 4 - PSIRT: Seit dem 11.09.2026 muss ein Prozess stehen, der bei einer aktiv ausgenutzten Schwachstelle die Frühwarnung (unverzüglich, spätestens nach 24 Stunden), die Meldung (spätestens nach 72 Stunden) und den Abschlussbericht (14 Tage) über die einheitliche Meldeplattform bedienen kann. Schritt 5 - technische Doku und Konformitätsbewertung: Risikobewertung nach Art. 13 und Anhang I (per Threat-Modeling erarbeitet), Baumusterprüfung oder Qualitätssicherungsbewertung durch die notifizierte Stelle, Konformitätserklärung und CE folgen bis zum 11.12.2027. So zeigt sich früh, wo die Lieferkette den Nachweis noch nicht liefert.

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: technische Einschätzung, welche Ihrer Geräte PDE sind, welche voraussichtlich Standard bleiben, welche (Router, Kameras, Türschlösser, Sprachassistenten) in Anhang III Klasse I fallen, und wo bis zum 10.12.2027 noch die RED-DA neben dem CRA gilt. Einstieg über unseren Betroffenheits-Check.
• SBOM-Setup: Aufbau maschinenlesbarer SBOMs, etwa in CycloneDX oder SPDX, Anforderung und Prüfung 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 Anbindung an die einheitliche Meldeplattform - sofort, denn die Meldepflicht gilt seit 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 über die Vorbereitung der Konformitätsbewertung bis zur EU-Konformitätserklärung.

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.