CRA für Embedded-Systeme: Besondere Pflichten

Warum Embedded-Entwickler das härteste CRA-Problem haben

Embedded-Entwickler stehen vor dem bittersten CRA-Problem: Für Systeme, die 10–15 Jahre im Feld laufen, müssen sie 5 Jahre Security-Updates garantieren — mit Hardware, die dafür nie ausgelegt war.

Keine Übertreibung. Das ist der strukturelle Konflikt zwischen der Realität der Embedded-Entwicklung und den Anforderungen der EU-Verordnung 2024/2847. Desktop-Software läuft auf Geräten mit aktuellem Betriebssystem, die regelmäßig ausgetauscht werden. Embedded-Systeme hingegen stecken jahrzehntelang im Einsatz — als Steuereinheit in Produktionsanlagen, als Sensor in einem Gebäudeautomationssystem, als Gateway in einer Wasseraufbereitungsanlage.

Diesen Unterschied kennt der CRA nicht. Er setzt für alle Hersteller von Produkten mit digitalen Elementen denselben Mindeststandard: Schwachstellenmanagement, Updates, SBOM, Meldepflicht. Was für ein SaaS-Startup mit rollenden Deployments trivial ist, zwingt den Embedded-Entwickler zur fundamentalen Überarbeitung von Entwicklungsprozess, Architektur und Geschäftsmodell.

Welche Embedded-Produkte konkret unter den CRA fallen

Den Anwendungsbereich des CRA definiert Artikel 2 Absatz 1: Produkte mit digitalen Elementen, die eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließen.¹ Für Embedded-Systeme bedeutet das:

Eindeutig CRA-relevant:

• Industrielle Sensoren und Aktoren mit Ethernet, WLAN, Bluetooth oder anderen Kommunikationsschnittstellen
• Gateways die Feldbus-Protokolle (Modbus, PROFIBUS, CANopen) auf IP übersetzen
• Smart-Home-Geräte: vernetzte Thermostate, Türschlösser, Rauchmelder
• Industrielle Steuerungseinheiten (SPS/PLC) mit Netzwerkanbindung
• Vernetzte Messgeräte und Prüfsysteme
• Router, Switches, Access Points die als Produkt verkauft werden

Ausdrücklich ausgenommen — aber mit wichtigen Einschränkungen:

• Medizinprodukte nach MDR (EU-Verordnung 2017/745) und IVDR (EU-Verordnung 2017/746) — aber: nur das Produkt selbst, nicht zugehörige Komponenten, die eigenständig verkauft werden
• Kraftfahrzeug-Komponenten nach UN-R 155/UN-R 156 — aber: nur Komponenten die dem Fahrzeugsicherheitsrahmen unterliegen, nicht alle eingebettete Software in Fahrzeughilfssystemen
• Zivile Luftfahrt nach EU-Verordnung 2018/1139

Die MDR/Automotive-Ausnahme: eng auslegen

Was hier viele falsch verstehen: Wer Komponenten an Medizinprodukte- oder Automobilhersteller liefert, glaubt oft, automatisch unter die jeweilige Ausnahme zu fallen. Stimmt nicht.

Die Ausnahmen des CRA gelten für das Endprodukt, das unter das jeweilige sektorspezifische Recht fällt — nicht für alle Komponenten, die in diesem Sektor eingesetzt werden. Ein Hersteller von drahtlosen Temperatursensoren für medizinische Geräte, der diese eigenständig an mehrere OEM-Kunden verkauft, bringt ein eigenständiges Produkt mit digitalen Elementen in Verkehr. Der Sensor selbst ist kein Medizinprodukt nach MDR. Er fällt unter den CRA.¹

Ähnliches gilt für Automotive: Ein Tier-2-Lieferant, der Steuerungssoftware für Fahrzeugkomponenten als eigenständiges Modul verkauft, muss prüfen, ob sein Produkt unter UN-R 155 fällt oder eigenständig CRA-pflichtig ist. Die Abgrenzung ist nicht trivial — in Grenzfällen sollte rechtliche Einschätzung eingeholt werden.

Die vier größten technischen Herausforderungen

1. SBOM für Binaries aus proprietären Toolchains

Für Embedded-Entwickler ist die Software Bill of Materials technisch wesentlich schwieriger zu erstellen als für Web- oder Desktop-Entwickler. Der Grund: Embedded-Code entsteht oft aus einer Toolchain, die keine standardisierten Metadaten für Komponenten produziert.

Typische Situation: Ein ARM-Cortex-Prozessor läuft mit FreeRTOS, zLib, Mbed TLS und einem proprietären HAL (Hardware Abstraction Layer). Der Toolchain-Hersteller liefert ein fertig kompiliertes Binary — ohne Angabe, welche Versionen welcher Bibliotheken darin stecken.

Was der CRA verlangt: Eine maschinenlesbare SBOM im Format CycloneDX oder SPDX (ISO 5962:2021), die alle enthaltenen Komponenten mit Version, Lizenz und verfügbaren CVE-Quellen listet.¹ Auf Anfrage muss der Hersteller diese der Marktaufsichtsbehörde vorlegen können.

Was das in der Praxis bedeutet:

• Vollständiges Dependency-Tracking bereits im Build-System — nicht als nachträglicher Schritt
• Für proprietäre Toolchains: Vertragsklauseln mit dem Toolchain-Anbieter, die eine SBOM als Lieferpflicht definieren
• Für Drittanbieter-Bibliotheken (uClibc, BusyBox, OpenSSL für ARM): manuelle Pflege der Komponentenliste, da automatisierte SBOM-Tools wie Syft für Embedded-Binaries nur begrenzt funktionieren
• CVE-Monitoring für jede gelistete Komponente — automatisiert über Dependency-Track oder ähnliche Tooling

Ein industrieller Sensor mit 20 Bibliotheken klingt überschaubar. In der Praxis stecken in einem typischen Linux-basierten Embedded-System mit BusyBox mehrere hundert Softwarekomponenten. Das ist der Punkt, den viele übersehen.

2. CVE-Monitoring für Embedded-Komponenten

Für Desktop-Software gibt es ausgereifte Tooling-Ökosysteme für CVE-Monitoring. Für Embedded-Komponenten ist das Bild fragmentierter.

Kritische Komponenten mit regelmäßigen CVEs, die für Embedded-Entwickler relevant sind:

• uClibc / musl libc: Alternativen zur glibc auf ressourcenbeschränkten Systemen — haben beide in der Vergangenheit schwerwiegende CVEs gehabt
• BusyBox: Findet sich in fast jedem Linux-basierten Embedded-System. CVEs in BusyBox können Dutzende Einzelkomponenten betreffen.
• OpenSSL / Mbed TLS / WolfSSL: TLS-Bibliotheken für Embedded haben eigene CVE-Tracks, aber Patches sind nicht immer für ältere Prozessor-Architekturen binärkompatibel.
• FreeRTOS / Zephyr / RIOT OS: Steigende CVE-Aktivität, insbesondere bei Netzwerk-Stacks.

Was der CRA verlangt (Artikel 13, Anhang I): Hersteller müssen Schwachstellen in verwendeten Komponenten kontinuierlich überwachen, Patches bereitstellen und ab dem 11. September 2026 aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an ENISA melden.¹

Konkret heißt das: Ein Hersteller von industriellen MQTT-Gateways braucht ab September 2026 einen dokumentierten Prozess, der mindestens wöchentlich die NVD (National Vulnerability Database), VDE-CERT und CERT-Bund-Meldungen gegen seine SBOM abgleicht. Kein optionaler Schritt. Pflicht.

In der Praxis erleben wir, dass genau dieser Prozess bei Embedded-Herstellern im Maschinenbau noch vollständig fehlt — nicht aus Unwillen, sondern weil die nötigen Tools für Embedded-Binaries schlicht nicht so ausgereift sind wie für Webprojekte.

3. OTA-Updates auf ressourcenbeschränkten Geräten

OTA-Updates schreibt der CRA nicht zwingend vor. Er verlangt, dass Hersteller Sicherheitsupdates bereitstellen und Nutzer informieren. Aber: Ein Update nützt nur, wenn es sich auch einspielen lässt.

Die Realität in der Embedded-Welt: Viele Geräte haben keinen Update-Mechanismus, weil Produktdesigner ihn von Anfang an nicht eingeplant haben. Ein Mikrocontroller mit 64 KB Flash, der über einen proprietären Feldbus kommuniziert, hat keinen trivialen OTA-Pfad. Das ist kein Randfall — das ist Alltag in der embedded Software für Heizungssteuerungen, in der Gebäudeautomation, in industriellen Messgeräten.

**Mindestanforderungen des CRA für Updates (Artikel 13 Absatz 8):**¹

• Security-Updates müssen vom Nutzer installiert werden können
• Sie müssen separat von Funktionsupdates verfügbar sein
• Bei sicherheitsrelevanten Updates muss der Nutzer informiert werden
• Die Update-Möglichkeit muss für die gesamte Supportzeit (mindestens 5 Jahre) erhalten bleiben

Praktische Implikationen für Embedded-Hersteller:

• Neue Produkte brauchen einen signierten Update-Mechanismus ab der ersten Version — kein Nachrüsten möglich bei physikalisch limitierter Hardware
• Für Produkte im Feld ohne Update-Mechanismus: entweder Nachrüstung über Service-Techniker dokumentieren (kann CRA-konform sein, wenn der Prozess definiert ist) oder Produktabkündigung vor 2027
• Firmware-Signierung ist Pflicht — unsignierte Updates erfüllen die Integritätsanforderung aus Anhang I Punkt 5 nicht

Wer heute noch keine Firmware-Signierung und keinen OTA-Pfad hat, muss diese Investition in neue Produkte einplanen. Das ist nicht optional.

4. 5-Jahres-Supportpflicht für langlebige Hardware

Das ist der fundamentalste Konflikt zwischen CRA und der Realität der Embedded-Industrie.

Vorgeschrieben sind 5 Jahre Security-Updates nach Inverkehrbringen — oder kürzer, wenn der erwartete Nutzungszeitraum des Produkts kürzer ist.¹ In der Consumer-Elektronik ist das eine ernsthafte, aber handhabbare Anforderung. In der Industrie sieht die Situation anders aus: Ein Industrierouter, eine SPS oder ein Messgerät bleibt typischerweise 10–20 Jahre im Einsatz. Hersteller verkaufen Hardware-Modelle oft über 5–8 Jahre aktiv.

Was das konkret bedeutet:

• Der 5-Jahres-Zeitraum startet mit dem ersten Inverkehrbringen eines Produktmodells — nicht mit dem Kauf durch den Endkunden
• Bis Dezember 2027 eingeführte Produkte, die bis 2032 supportpflichtig sind, müssen heute schon mit dieser Supportzeit geplant werden
• Für Hersteller die mehrere Generationen eines Produkts pflegen: Die Supportkosten für ältere Generationen dürfen nicht durch CRA-Pflichten wegbrechen

Empfehlung für Embedded-Hersteller: Jedes neue Produkt braucht ab jetzt eine explizite Support-Lifetime-Erklärung im technischen Datenblatt — und einen Vertrag mit dem Kunden, der klärt, was nach dem 5-Jahres-Minimum gilt. Das klingt nach bürokratischem Aufwand. Ist es auch. Aber gleichzeitig ist es ein Geschäftsmodell-Thema: Wer Industrie-Hardware mit 15-Jahres-Lebenserwartung verkauft, muss die Supportkosten für 5 Jahre einpreisen oder Extended-Support-Verträge anbieten. IoT-Startups, die gerade ihre ersten vernetzten Industrieprodukte auf den Markt bringen, sollten das von Anfang an in ihre Preismodelle einrechnen — nachrüsten ist teurer.

RTOS und Bare-Metal: Unterschiede in der Praxis

Linux-basierte Embedded-Systeme (Yocto, Buildroot) profitieren von einer aktiven Community, regelmäßigen Security-Patches und Tools für SBOM-Erstellung. Der Nachteil: größere Angriffsfläche, komplexere Abhängigkeitsgraphen.

RTOS-Systeme (FreeRTOS, Zephyr, ThreadX) haben eine kleinere Angriffsfläche, aber weniger Compliance-Tooling. CVE-Monitoring muss manueller erfolgen. FreeRTOS-CVEs werden über das FreeRTOS-Projekt auf GitHub und NVD gemeldet — aber nicht mit derselben Reife wie der Linux-Kernel-Track.

Bare-Metal-Systeme (kein Betriebssystem, direkter Register-Zugriff) haben die kleinste Angriffsfläche — aber SBOM und Komponenten-Tracking müssen Entwickler vollständig manuell durchführen. Jede eingebundene Bibliothek muss explizit erfasst und mit CVE-Quellen verknüpft werden. Kein Tool nimmt das ab.

Handlungsempfehlungen für Embedded-Teams

Sofort (unabhängig von der CRA-Frist):

1. Produktinventar erstellen: Alle vernetzten Produkte die bis Dezember 2027 aktiv verkauft werden, mit Prozessor-Architektur und Kommunikationsschnittstellen
2. SBOM-Lückenanalyse: Welche Produkte haben heute eine maschinenlesbare SBOM? Was fehlt?
3. Update-Mechanismus auditieren: Hat jedes Produkt einen Firmware-Update-Pfad? Ist er signiert?

Bis Q4 2026 (wegen Meldepflicht ab September 2026): 4. CVE-Monitoring-Prozess einrichten und dokumentieren — auch wenn er noch manuell ist 5. Vulnerability-Disclosure-Policy veröffentlichen 6. 24-Stunden-Meldeprozess für aktiv ausgenutzte Schwachstellen definieren (wer macht was, welcher Kanal zu ENISA)

Bis Q2 2027: 7. Vollständige technische Dokumentation nach Anhang VII für alle CRA-Produkte 8. Konformitätsbewertung abschließen und CE-Kennzeichnung aktualisieren

Kostenlosen CRA-Check starten um die Risikoklasse Ihres Embedded-Produkts zu ermitteln und zu prüfen, welches Konformitätsbewertungsverfahren gilt.

Quellen

1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Artikel 13, Artikel 14, Anhang I, Anhang III: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Cyber Resilience Act, technische Anforderungen und SBOM: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. NVD — National Vulnerability Database (NIST): https://nvd.nist.gov/
4. OWASP — CycloneDX Specification: https://cyclonedx.org/specification/overview/
5. Linux Foundation — SPDX (ISO/IEC 5962:2021): https://spdx.dev/
6. ENISA — Good Practices for Security of IoT: https://www.enisa.europa.eu/publications/good-practices-for-security-of-iot
7. VDE-CERT — CVE-Koordinierung für Industrieprodukte: https://www.vde.com/de/vde-cert