CRA für Smart-Home-Hersteller

Smart-Home-Hubs in Anhang III: Warum Important Class I?

Der EU Cyber Resilience Act (EU-Verordnung 2024/2847) unterscheidet vier Produktklassen. Auf den ersten Blick fallen die meisten Smart-Home-Produkte in die Default-Klasse — einfache WLAN-Steckdosen, Leuchtmittel ohne Hub-Funktion oder Temperatursensoren. Smart-Home-Hubs sind davon ausdrücklich ausgenommen.

Anhang III Klasse I des CRA listet “intelligente Heimautomatisierungsprodukte und Alarmsysteme” explizit als sicherheitsrelevante Kategorie.¹ Die Begründung des EU-Gesetzgebers ist nachvollziehbar: Ein Smart-Home-Hub ist kein Endgerät — er ist der Koordinationspunkt für alle angebundenen Geräte. Wird ein Hub kompromittiert, hat ein Angreifer potenziell gleichzeitig Zugriff auf Schlösser, Alarmanlagen, Kameras und Heizung.

Das ist der Punkt, den viele übersehen: Ihr Produkt ist “nur” ein Gateway — aber es hat Zugang zu sicherheitsrelevanten Geräten, die weit mehr als Komfort-Funktionen steuern. Ein IoT-Startup, das einen Matter-Controller für Wohngebäude entwickelt, landet damit automatisch in Important Class I — auch wenn das Gerät selbst nur 80 Euro kostet und aussieht wie ein USB-Stick. Deshalb trifft die Klassifizierung viele Hersteller unvorbereitet.

Welche Produkte fallen unter Important Class I?

Anhang III Klasse I erfasst alle Geräte, die als Koordinationspunkt oder Steuereinheit für andere Smart-Home-Komponenten fungieren — unabhängig vom verwendeten Protokoll. Die Produktkategorie ist überraschend breit.

Typische Produkte die als Smart-Home-Hub klassifiziert werden:

Zigbee-Koordinatoren: Geräte wie ein Zigbee-USB-Dongle mit lokaler Steuerungslogik, ein Zigbee-IP-Gateway oder ein Zigbee-Hub der Lampen, Thermostate und Sensoren koordiniert
Z-Wave-Gateways: Z-Wave-Controller die als lokale Zentrale für ein Z-Wave-Mesh-Netzwerk fungieren
HomeKit-Bridges und -Hubs: Apple HomeKit Accessories die als Steuerungszentrale fungieren oder als Brücke zwischen HomeKit und anderen Protokollen arbeiten
Matter-Controller: Geräte die als lokaler Matter-Controller (Commissioner) agieren und das gesamte Thread/Matter-Netzwerk koordinieren
Kombinierte Hubs: Multi-Protokoll-Gateways die Zigbee, Z-Wave und WLAN-Geräte gleichzeitig verwalten

Nicht betroffen (Default-Klasse):

Einzelne Endgeräte ohne Hub-Funktion fallen typischerweise nicht unter Klasse I — also eine Zigbee-Glühbirne, ein Z-Wave-Thermostat oder ein WLAN-Sensor, sofern diese keine anderen Geräte steuern oder koordinieren.

Die Abgrenzung ist nicht immer eindeutig. Einen “Smart Speaker mit Hub-Funktion” können Behörden je nach technischer Implementierung als Hub einstufen, wenn er tatsächlich als Koordinationspunkt für andere Geräte dient. In der Praxis erleben wir: Hersteller von Industrie-4.0-Gateways unterschätzen das häufig — sie vertreiben ihr Gerät als “WLAN-Bridge” und merken erst bei der Marktaufsichtsprüfung, dass es als Hub klassifiziert wird.

Was Important Class I konkret bedeutet

Important Class I ist keine kosmetische Einstufung. Sie verändert den Konformitätsbewertungspfad und erhöht die inhaltlichen Anforderungen gegenüber der Default-Klasse.

Konformitätsbewertungsverfahren

Für Important Class I Produkte gilt nach Art. 32 CRA:

Mit harmonisierten Normen: Wendet der Hersteller harmonisierte Normen (z. B. EN 18031 oder eine vom CRA anerkannte Normenreihe) vollständig an und decken diese die CRA-Anforderungen ab, reicht eine Selbstbewertung (Modul A) aus.¹
Ohne harmonisierte Normen: Wendet der Hersteller keine harmonisierten Normen an oder decken diese die Anforderungen nicht vollständig ab, ist ein Notified Body für die Konformitätsbewertung erforderlich.

Konkret bedeutet das: Existieren bis Ende 2027 harmonisierte Normen, die die Smart-Home-Hub-Anforderungen abdecken — und wendet der Hersteller diese vollständig an? Wenn nicht, wird ein Notified Body Pflicht. Das klingt nach einem fernen Problem. Ist es nicht.

Ein Maschinenbau-KMU, das sein Gebäudeautomations-Gateway in den EU-Markt bringt, muss diese Frage jetzt beantworten — nicht in zwei Jahren, wenn der Notified Body sechs Monate Vorlaufzeit hat.

Inhaltliche Anforderungen nach Anhang I

Alle CRA-Produkte müssen die Anforderungen aus Anhang I erfüllen — für Important Class I prüft die Marktaufsichtsbehörde die Erfüllung dieser Anforderungen aber strenger:¹

Technische Anforderungen (Anhang I Teil I):

Risikoanalyse für das gesamte Produkt inkl. aller angebundenen Protokolle (Zigbee, Z-Wave, WLAN, BT)
Secure by Default: Keine Standardpasswörter, sichere Werkseinstellungen
Authentifizierung aller lokalen und Cloud-Verbindungen
Verschlüsselung der Kommunikation (lokal + Cloud)
OTA-Updates kryptographisch signiert und zuverlässig zustellbar
Minimale Angriffsfläche: unnötige Dienste und Ports deaktiviert

Schwachstellenpflichten (Anhang I Teil II):

SBOM (Software Bill of Materials) für die gesamte Hub-Software
CVE-Monitoring für alle eingebetteten Komponenten
Vulnerability Disclosure Policy (VDP) öffentlich zugänglich
Sicherheitsupdates für die Produktlebensdauer (mind. 5 Jahre)

Besondere Herausforderungen für Smart-Home-Hersteller

1. Multi-Protokoll-Komplexität bei SBOMs

Ein Zigbee-Gateway mit WLAN-Backhaul enthält typischerweise: Zigbee-Stack (z. B. EmberZNet, OpenThread, Zigbee2MQTT), WLAN-Treiber, Embedded-Linux oder RTOS, MQTT-Client, Cloud-Connector-Bibliothek. Eine vollständige SBOM für all diese Komponenten zu erstellen ist wesentlich aufwändiger als für eine reine Software-Anwendung — besonders wenn der Hersteller proprietäre Chipsatz-Firmware verbaut.

Was viele CRA-Berater nicht sagen: Viele Smart-Home-Hersteller beziehen ihren Zigbee/Z-Wave-Stack als Binärsoftware vom Chiphersteller — und haben schlicht keine vollständige Komponentenliste für diese Teile. Anhang I Teil II Nr. 1 CRA fordert die SBOM in einem “maschinenlesbaren Format” (CycloneDX oder SPDX).¹ Das ist ein bekanntes, lösbares Problem — aber es muss in Lieferantenverträgen adressiert werden, bevor die Hardware in Produktion geht.

Ein konkretes Szenario: Ein embedded-Software-Hersteller für Heizungssteuerungen integriert einen Z-Wave-Chip eines asiatischen Lieferanten. Der Lieferant liefert keine SBOM. Ohne vertragliche Regelung sitzt der Hersteller kurz vor dem Marktstart vor einer unlösbaren Dokumentationslücke.

2. Lokale Verarbeitung vs. Cloud-Abhängigkeit

Einige Smart-Home-Hubs arbeiten primär lokal (Home Assistant, Homey Pro), andere sind stark Cloud-abhängig. Der CRA unterscheidet hier nicht direkt — aber bei Cloud-abhängigen Hubs müssen Hersteller zusätzlich die technischen Anforderungen für Cloud-Verbindungen erfüllen: Authentifizierung, Verschlüsselung, Token-Verwaltung.

Sobald der Cloud-Dienst für den Hub essenziell ist und der Anbieter ihn einstellt, entsteht eine Frage der “Lebensdauer-Unterstützung”. Anhang I Teil I Nr. 10 CRA fordert Sicherheitsupdates über die “erwartete Nutzungsdauer”.¹ Was das für SaaS-abhängige Hardware-Produkte bedeutet, müssen viele IoT-Startups erst noch durchdenken. Konkret bedeutet das: Wer heute einen cloud-abhängigen Hub auf den Markt bringt, verpflichtet sich faktisch zu einer Infrastruktur-Zusage über fünf Jahre — oder muss einen lokalen Fallback-Modus einbauen.

3. Firmware-Updates für im Feld befindliche Geräte

Smart-Home-Hubs laufen typischerweise in Heimnetzwerken, wo Endnutzer kein aktives Update-Management betreiben. Wer die Verantwortung für Sicherheitsupdates trägt, regelt der CRA eindeutig: der Hersteller — nicht der Nutzer. Automatische Updates oder zumindest prominente Update-Hinweise sind keine “Nice-to-haves” mehr, sondern Teil der Konformitätsanforderungen.

Das klingt selbstverständlich. Ist es aber nicht. Hersteller von industriellen MQTT-Gateways, die bisher Firmware-Updates als optionalen Service-Posten behandelt haben, müssen das Geschäftsmodell überdenken — fünf Jahre Patch-Support kostet Geld, das in der Kalkulation stehen muss.

Typischer Compliance-Pfad für Smart-Home-Hersteller

Schritt 1: Produktklassifizierung bestätigen Zunächst muss der Hersteller prüfen, ob sein Hub tatsächlich als “Smart-Home-Hub” im Sinne von Anhang III Klasse I klassifiziert wird — oder ob Argumente existieren, dass es sich um ein Endgerät ohne Hub-Funktion handelt. Diese Frage sollten Hersteller mit einem CRA-Fachberater oder Notified Body vorab klären.

Schritt 2: Normlücke analysieren Welche harmonisierten Normen liegen bis Ende 2027 für Smart-Home-Hubs vor, und decken sie die Anforderungen vollständig ab? Falls nicht: Notified Body frühzeitig beauftragen.

Schritt 3: Risikoanalyse durchführen Strukturierte Analyse aller Angriffsflächen: Protokoll-Interfaces (Zigbee, Z-Wave, WLAN), Cloud-Verbindung, Admin-Interface, physische Ports, Update-Mechanismus.

Schritt 4: SBOM aufbauen Inventarisierung aller Software-Komponenten inkl. Anfrage beim Chiphersteller nach Komponentenlisten für proprietäre Stacks.

Schritt 5: VDP einrichten Öffentliche Vulnerability Disclosure Policy (VDP) erstellen und zugänglich machen — auch für externe Sicherheitsforscher.

Weiterführende Themen

Produktklassen im Überblick → CRA Risikoklassen: Default, Important, Critical
Was eine SBOM enthalten muss → SBOM erstellen: Anforderungen nach CRA
Alle technischen Sicherheitsanforderungen → CRA Anhang I im Detail
OTA-Updates und Lebensdauer-Pflichten → Sicherheitsupdates nach CRA
Notified Body auswählen → Notified Body: Auswahl und Vorbereitung

Den kostenlosen CRA-Check können Sie nutzen um eine erste indikative Einschätzung Ihrer Produktklasse zu erhalten. Für Smart-Home-Hersteller die bereits wissen, dass sie unter Important Class I fallen, bietet das Evidence Pack strukturierte Vorlagen für Risikoanalyse, SBOM-Dokumentation und technische Dokumentation.

Quellen

EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Anhang III Klasse I (Smart-Home-Hubs, Alarmsysteme), Artikel 32 (Konformitätsbewertungsverfahren), Anhang I Teil I (technische Anforderungen), Anhang I Teil II (Schwachstellenpflichten): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
ENISA — Cybersecurity for Smart Home Devices and the Cyber Resilience Act: https://www.enisa.europa.eu/topics/cyber-resilience-act
BSI — CRA-Einschätzungen für Heimautomatisierungsprodukte: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
ETSI EN 303 645 — Cybersecurity for Consumer Internet of Things (Referenznorm für Smart-Home-Produkte): https://www.etsi.org/deliver/etsi_en/303600_303699/303645/
Europäisches Parlament — Cyber Resilience Act: Erwägungsgründe 34–38 (Begründung der Produktklassifizierung): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847

Hinweis: Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Die Einschätzungen basieren auf dem Stand der EU-Verordnung 2024/2847 und öffentlich verfügbaren Auslegungshilfen. Für eine verbindliche Klassifizierung Ihres Produkts empfehlen wir rechtliche und technische Fachberatung.