CRA für IoT-Hersteller: Pflichten und Risiken

Warum IoT-Hersteller den CRA besonders ernst nehmen müssen

Der Cyber Resilience Act (EU-Verordnung 2024/2847) ist kein generisches IT-Sicherheitsgesetz, das alle digitalen Produkte gleichbehandelt. Vernetzte Geräte — also IoT-Produkte — nimmt er gezielt ins Visier. Nachvollziehbar: Unsichere IoT-Geräte waren an einigen der folgenreichsten Cyberangriffe der letzten Jahre beteiligt, von Mirai-basierten Botnetzen bis zu kompromittierten Industriesteuerungen.

Was viele IoT-Hersteller systematisch unterschätzen: Jedes Gerät im Feld muss separat updatefähig sein. Ein Firmware-Update, das Techniker über USB einspielen, zählt nicht als OTA-fähig — und damit nicht als CRA-konform, sobald das Gerät eine Netzwerkverbindung hat und ins Feld geht. Diese eine Anforderung macht für viele bestehende Produktgenerationen eine Hardware-Revision erforderlich. Das ist keine Kleinigkeit.

Welche IoT-Produkte unter den CRA fallen

Grundsätzlich fällt jedes Produkt mit digitalen Elementen unter den CRA, das über eine direkte oder indirekte Netzwerkverbindung verfügt (Artikel 2 Absatz 1).¹ Für IoT bedeutet das konkret: Sobald ein Gerät WLAN, Bluetooth, Ethernet, Mobilfunk (LTE/5G), Zigbee, Z-Wave oder eine andere Netzwerkschnittstelle hat, ist es CRA-relevant — unabhängig davon, ob die Netzwerkfunktion das Kernmerkmal oder ein Nebenmerkmal ist.

Reine Offline-Produkte ohne jede Netzwerkfähigkeit sind ausgenommen. In der Praxis sind das immer weniger Geräte.

Anhang III Klasse I: Welche IoT-Produkte gelten als “Important”?

Anhang III Klasse I des CRA listet spezifische IoT-Produktkategorien, die als sicherheitsrelevant eingestuft werden und damit strengeren Anforderungen an das Konformitätsbewertungsverfahren unterliegen:¹

Smart-Home-Hubs: Geräte, die andere Smart-Home-Geräte steuern — z. B. ein Zigbee-Gateway das Lampen, Thermostate und Schlösser koordiniert. Die Klassifizierung als Important Class I gilt für den Hub selbst, nicht für die angebundenen Endgeräte.
Consumer-IoT-Produkte mit Datennetzverbindung (Wearables im Gesundheitsbereich, vernetzte Spielzeuge mit Sprach- oder Standortfunktion)
Sicherheitsprodukte für Gebäude (intelligente Türschlösser, Alarmsysteme)
Router und Modems für Wohn- und Büroumgebungen

Industrial-IoT-Geräte, die keine der oben genannten Sicherheitsfunktionen erfüllen, fallen typischerweise in die Default-Klasse — also Selbstbewertung ohne Notified Body. Das senkt den Prüfaufwand, ändert aber nichts an den inhaltlichen Anforderungen aus Anhang I. Auch ein Default-IIoT-Gerät braucht Risikoanalyse, SBOM und laufendes CVE-Monitoring.

Konkretes Beispiel: MQTT-Gateway für Produktionshallen

Ein Maschinenbau-Zulieferer, der industrielle MQTT-Gateways als Teil einer Predictive-Maintenance-Lösung verkauft — Geräte, die Temperatur- und Drucksensoren in Produktionshallen auslesen und per LTE an eine Cloud-Plattform senden — ist damit direkt CRA-pflichtig. Auch wenn er sich eher als Systemintegrator denn als “Gerätehersteller” versteht. Das ist der Punkt, den viele übersehen.

Einschätzung (nicht rechtsverbindlich): Wahrscheinlich Default-Klasse, sofern das Gateway keine Sicherheitsfunktion (Firewall, Zugangssteuerung) erfüllt und nicht als Sicherheitskomponente für kritische Infrastrukturen eingesetzt wird.

Aber: Default bedeutet nicht wenig Aufwand:

Risikoanalyse für das Gerät (inkl. LTE-Schnittstelle, MQTT-Protokoll, Cloud-Anbindung)
SBOM für die eingebettete Firmware (OpenWrt, FreeRTOS oder ähnliche)
OTA-Updatefähigkeit über die gesamte Lebensdauer (mindestens 5 Jahre)
Unique Credentials pro Gerät (kein werkseitig identisches Passwort)
CVE-Monitoring für alle eingebetteten Bibliotheken

Die fünf größten CRA-Herausforderungen für IoT-Hersteller

1. Firmware-Updates over-the-air (OTA) — Pflicht, nicht Option

Anhang I Teil I Nummer 2 CRA verpflichtet Hersteller, sicherzustellen dass Sicherheitslücken durch Updates behoben werden können.¹ Die Formulierung ist bewusst offen — aber in der Praxis bedeutet ein vernetztes Gerät ohne OTA-Fähigkeit ein erhebliches Compliance-Risiko.

Was OTA konkret erfordert:

Kryptographisch signierte Update-Pakete (damit kein manipuliertes Firmware-Image eingespielt werden kann)
Rollback-Funktion bei fehlgeschlagenem Update (damit das Gerät nicht unbedienbar wird)
Zuverlässige Zustellinfrastruktur (Update auch bei instabiler Verbindung)
Dokumentierter Update-Prozess in der technischen Dokumentation

Viele IoT-Startups, die embedded-Software für Heizungssteuerungen oder Gebäudesensorik entwickeln, haben OTA auf der Roadmap — aber noch nicht implementiert. Bis Dezember 2027 reicht eine Roadmap nicht mehr. Wer heute noch physische USB-Updates als Hauptpfad nutzt: Das ist kein CRA-konformer Weg für vernetzte Geräte, die im Feld bleiben.

2. Secure Boot — Pflicht nach Anhang I

Secure Boot ist kein optionales Hardening-Feature für IoT-Geräte unter dem CRA. Anhang I Teil I Nummer 3 Buchstabe b fordert explizit, dass Produkte “nur autorisierte und integritätsgeprüfte Software ausführen”.¹ Das ist eine direkte gesetzliche Anforderung, keine Empfehlung.

Für die meisten ARM-basierten Mikrocontroller und Prozessoren ist Secure Boot technisch möglich — die Frage ist, ob Hersteller es in der Serienproduktion auch tatsächlich aktivieren. Viele Entwicklungsteams überspringen diesen Schritt, weil er den Firmware-Entwicklungsprozess verkompliziert. Das klingt nach einem Detail. In einer Marktaufsichtsprüfung ist es keines.

3. Unique Credentials per Gerät

Anhang I Teil I Nummer 3 Buchstabe g des CRA verbietet Standard-Zugangsdaten, die geräteübergreifend identisch sind.¹ Jedes Gerät muss mit individuellen Credentials ausgeliefert werden — oder beim Erststart einen erzwungenen Credential-Setup-Prozess durchlaufen.

Praktische Konsequenz: Wer heute Geräte mit werkseitigem Passwort admin/admin oder 12345678 ausliefert, muss den Produktionsprozess anpassen. Das betrifft auch viele OEM-Designs, bei denen die Firmware vom Chiphersteller stammt — die Default-Credentials des Chiplieferanten gelten nicht als “unique per Gerät”. Ein Industrie-4.0-Anbieter, der seine Sensorhardware mit Standardfirmware eines asiatischen Modulherstellers ausliefert, trägt dafür die volle Verantwortung.

4. CVE-Monitoring für alle eingebetteten Libraries

Embedded Firmware besteht typischerweise aus Dutzenden bis Hunderten von Open-Source-Komponenten: OpenSSL, mbedTLS, zlib, libcurl, BusyBox, uClibc und viele mehr. Jede dieser Bibliotheken kann CVEs akkumulieren. Anhang I Teil II des CRA verpflichtet Hersteller, ein Schwachstellenmanagementsystem zu unterhalten, das regelmäßig auf neue CVEs prüft und Prozesse für die Behebung definiert.¹

Für einen IoT-Hersteller mit fünf verschiedenen Gerätegenerationen und 50+ eingebetteten Bibliotheken ist das ein erheblicher Daueraufwand — nicht ein einmaliges Audit. Was viele CRA-Berater nicht sagen: Das CVE-Monitoring läuft über die gesamte unterstützte Produktlebensdauer. Wer ein Gerät 2025 auf den Markt bringt und fünf Jahre Support zusagt, monitort bis 2030.

5. SBOM für embedded Firmware — besonders komplex

Eine Software Bill of Materials (SBOM) für eingebettete Firmware zu erstellen ist wesentlich aufwändiger als für eine Web-Applikation. Der Build-Prozess für embedded Linux (z. B. Yocto, Buildroot) oder RTOS-basierte Systeme ist oft wenig transparent bezüglich aller tatsächlich eingebundenen Komponenten.

Anhang I Teil II Nummer 1 CRA fordert die SBOM in einem “maschinenlesbaren Format”.¹ Konkret bedeutet das: CycloneDX oder SPDX. Tools wie Yocto SPDX Plugin oder Syft können den Prozess automatisieren — setzen aber eine strukturierte Build-Pipeline voraus, die viele kleinere IoT-Hersteller noch nicht haben. Wer heute mit einem improvisierten Buildroot-Setup arbeitet, kann keine belastbare SBOM daraus erzeugen. Das ist kein Tooling-Problem. Das ist ein Architekturproblem.

Die Lieferketten-Dimension: Chip- und Modulhersteller

IoT-Hersteller sind nicht nur Abnehmer von Komponenten — sobald ihre Geräte in größere Systeme integriert werden, werden sie selbst zu Zulieferern. Und umgekehrt: Wer Chips oder Kommunikationsmodule von Drittherstellern verbaut, muss deren CRA-Konformität sicherstellen.

Konkret: Ein LoRaWAN-Modul von einem asiatischen Hersteller, das ein Maschinenbauunternehmen in sein Industriegateway verbaut, muss die CRA-Anforderungen erfüllen — und wenn es das nicht tut, trägt der Gateway-Hersteller die Verantwortung. Lieferantenverträge müssen jetzt CRA-Compliance-Klauseln enthalten. Einkäufer bei Tier-1-Elektronikherstellern verlangen das bereits in aktuellen Ausschreibungen.

Erste Großkunden fordern CRA-Nachweise bereits in Ausschreibungen. Wer als IoT-Hersteller in 2026 noch keinen nachvollziehbaren Compliance-Prozess vorweisen kann, wird aus Lieferantenlisten gestrichen — unabhängig vom gesetzlichen Stichtag Dezember 2027.

Was IoT-Hersteller jetzt tun sollten

1. Produktportfolio klassifizieren Für jedes Gerät im Portfolio prüfen: Ist es CRA-relevant? Welche Klasse trifft zu? Wichtig: Jede Gerätegeneration separat bewerten — ein Gerät, das fünf Jahre alt ist und noch drei Jahre Support bekommt, fällt ebenfalls unter den CRA.

2. OTA-Update-Fähigkeit bewerten Kann jedes im Feld befindliche Gerät Firmware-Updates remote empfangen und installieren? Wenn nein: Bis wann ist das nachrüstbar, und zu welchen Kosten? Diese Analyse gehört jetzt in die Produktstrategie.

3. Build-Prozess für SBOM-Fähigkeit vorbereiten Ein SBOM-tauglicher Build-Prozess (Yocto SPDX, Buildroot Graph-out oder äquivalent) lässt sich nicht kurzfristig einführen. Wer bis Ende 2026 eine belastbare SBOM vorlegen will, muss 2026 mit der Umstellung beginnen.

4. Unique-Credential-Prozess in der Produktion implementieren Die Einführung von Unique Credentials erfordert Änderungen am Produktionsprozess — typischerweise: Generierung auf Werksseite, Einbrennen in Secure Element, Dokumentation in Produktionsdatenbank. Das ist ein Hardware-naher Prozess, der Vorlaufzeit braucht.

5. Lieferantenverträge auf CRA-Compliance-Klauseln prüfen Jeder Modul-, Chip- und Software-Lieferant sollte eine CRA-Konformitätszusage geben können. Bestehende Verträge müssen Einkäufer auf diese Anforderung hin prüfen und ggf. anpassen.

Weiterführende Themen

Wie funktioniert die Klassifizierung genau? → CRA Risikoklassen: Default, Important, Critical
Was muss eine SBOM enthalten? → SBOM erstellen: Anforderungen nach CRA
Alle inhaltlichen Sicherheitsanforderungen → CRA Anhang I im Detail

Den kostenlosen CRA-Check können Sie nutzen, um eine erste indikative Einschätzung Ihrer Produktklasse und Pflichten zu erhalten. Für Hersteller die bereits wissen, dass sie CRA-pflichtig sind, bietet das Evidence Pack strukturierte Templates für Risikoanalyse, SBOM-Dokumentation und technische Dokumentation nach CRA-Anforderungen.

Quellen

EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Anhang I Teil I (Nummern 2, 3), Anhang I Teil II (Nummer 1), Anhang III Klasse I: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
ENISA — Cybersecurity for IoT devices and the Cyber Resilience Act: https://www.enisa.europa.eu/topics/cyber-resilience-act
BSI — CRA: Anforderungen an IoT-Produkte und eingebettete Systeme: 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: https://www.etsi.org/deliver/etsi_en/303600_303699/303645/
NTIA — SBOM Minimum Elements (Referenz für CycloneDX/SPDX): https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom

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.