EU CRA für Embedded Systems
Embedded-Produkte, die bis zum letzten Sicherheitsupdate konform bleiben.
Ob Firmware, Bootmanager, Mikrocontroller oder fertiges Gerät: Für Embedded-Hersteller entscheiden Produktklasse und Unterstützungszeitraum, wie viel Arbeit jede Variante unter dem Cyber Resilience Act macht.
Autor: Maximilian HeckGeprüft von: Dr. Martin McCafferyStand:
- Volle Anwendung
- 11. Dezember 2027
- Frühwarnung
- 24 Stunden · Art. 14 Abs. 2 a
- Unterstützungszeitraum
- mind. 5 Jahre · Art. 13 Abs. 8
- Höchste Klasse in dieser Branche
- Kritisches Produkt
Wie lange müssen Hersteller Sicherheitsupdates für Embedded-Produkte bereitstellen?
Hersteller von Embedded-Produkten legen den Unterstützungszeitraum nach der voraussichtlichen Nutzungsdauer fest, und nach Art. 13 Abs. 8 EU CRA beträgt er mindestens fünf Jahre. Kürzer darf er nur sein, wenn das Produkt voraussichtlich weniger als fünf Jahre in Betrieb ist. Eine wesentliche Änderung setzt den Unterstützungszeitraum laut EU-Kommissions-Guidance (C(2026) 5252, Abschnitt 5) nicht automatisch neu in Gang. Jede Sicherheitsaktualisierung bleibt nach Art. 13 Abs. 9 EU CRA mindestens zehn Jahre nach ihrer Bereitstellung verfügbar, oder bis zum Ende des Unterstützungszeitraums, falls das später ist. Die Begründung für den gewählten Zeitraum gehört in die technische Dokumentation nach Anhang VII.
Produktklassen
Welche Embedded-Produkte fallen unter den EU CRA, und in welche Klasse?
Der EU CRA erfasst jedes Embedded-Produkt, dessen Zweck eine direkte oder indirekte, logische oder physische Datenverbindung zu einem Gerät oder Netz einschließt (Art. 2 Abs. 1 EU CRA); auch ein USB-Anschluss ist eine solche Verbindung. Die Klasse richtet sich nach der Kernfunktion des Produkts, das Sie in Verkehr bringen, und nicht nach dem späteren Einsatzort (Art. 7 Abs. 1 EU CRA). Die Zuordnungen sind eine Einschätzung anhand typischer Kernfunktionen.
Verteilung in dieser Branche
Produkt auswählen
Sensor- oder Aktor-Firmware ohne Sicherheitsfunktion
Warum diese Klasse
Keine Kategorie aus Anhang III oder IV; Selbstbewertung nach Art. 32 Abs. 1 EU CRA (Modul A).
Konformitätsweg
- 1Risikobewertung
- 2Eigene Konformitätsbewertung (Modul A)
- EU-Konformitätserklärung + CE
Konformitätsbewertung in Eigenverantwortung, Art. 32 Abs. 1 EU CRA.
Einschätzung anhand typischer Kernfunktionen. Maßgeblich sind Zweckbestimmung und Aufbau Ihres Produkts.
Alle Produktbeispiele als Tabelle+
| Produkt | Klasse nach EU CRA | Begründung |
|---|---|---|
| Sensor- oder Aktor-Firmware ohne Sicherheitsfunktion | Standardprodukt | Keine Kategorie aus Anhang III oder IV; Selbstbewertung nach Art. 32 Abs. 1 EU CRA (Modul A). |
| Motorregler, HMI-Panel oder Datenlogger mit Ethernet- oder USB-Port | Standardprodukt | Die Datenverbindung bringt das Gerät in den Anwendungsbereich; gelistet ist es in Anhang III nicht. |
| Bootmanager, eigenständig vertrieben | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 8. |
| RTOS oder Embedded-Linux-Distribution als eigenes Produkt | Wichtiges Produkt, Klasse I (Anhang III) | Betriebssysteme, Anhang III Klasse I Nr. 11. |
| Mikrocontroller, Mikroprozessoren, ASIC und FPGA mit sicherheitsrelevanten Funktionen | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 13, 14 und 15. |
| Embedded-Gateway mit Router-Kernfunktion, Netzwerkschnittstellen-Modul | Wichtiges Produkt, Klasse I (Anhang III) | Router, Modems und Switches Nr. 12; physische Netzschnittstellen Nr. 10 in Anhang III Klasse I. |
| Manipulationssichere Mikrocontroller und Mikroprozessoren | Wichtiges Produkt, Klasse II (Anhang III) | Anhang III Klasse II Nr. 3 und 4; Bewertung mit notifizierter Stelle nach Art. 32 Abs. 3 EU CRA. |
| Embedded-Hypervisor, Firewall- oder IDS-Appliance | Wichtiges Produkt, Klasse II (Anhang III) | Anhang III Klasse II Nr. 1 und 2. |
| Secure Element oder Chipkarten-Controller | Kritisches Produkt (Anhang IV) | Chipkarten und ähnliche Geräte einschließlich Sicherheitselemente, Anhang IV Nr. 3; Verfahren nach Art. 32 Abs. 4 EU CRA. |
| Hardware-Sicherheitsmodul (HSM) oder Smart-Meter-Gateway | Kritisches Produkt (Anhang IV) | Geräte für fortgeschrittene Sicherheitszwecke einschließlich sicherer Kryptoverarbeitung, Anhang IV Nr. 2. |
Ihr Produkt ist nicht dabei? Die Reifegradanalyse gibt eine erste Einordnung für Ihr eigenes Produkt. EU-CRA-Assessment starten →
Nicht unter den EU CRA fallen Ersatzteile, die identische Komponenten nach derselben Spezifikation ersetzen (Art. 2 Abs. 6 EU CRA), und Produkte, die ausschließlich für nationale Sicherheit oder Verteidigung entwickelt wurden (Art. 2 Abs. 7).
Pflichten
Was der EU CRA von Embedded-Herstellern verlangt
Ab dem ersten Release laufen alle sechs Pflichten mit, bis der Unterstützungszeitraum endet; die Aufbewahrungspflicht reicht darüber hinaus.
- 01
Komponenten kennen, Release für Release
Anhang I Teil II Nr. 1 EU CRA verlangt, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem mit einer Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. In einer Firmware sind das typischerweise Bootloader, RTOS oder Kernel, Krypto- und Netzwerkbibliotheken und das SDK des Chipherstellers. Weil jeder Build andere Versionen enthalten kann, führen viele Hersteller die Stückliste je Release.
- 02
Fehler beheben, solange der Unterstützungszeitraum läuft
Art. 13 Abs. 8 EU CRA; Anhang I Teil II Nr. 2 und 8
Schwachstellen im Produkt und in seinen Komponenten behandelt der Hersteller über den gesamten Unterstützungszeitraum unverzüglich, in der Regel mit einer Sicherheitsaktualisierung (Art. 13 Abs. 8 und Anhang I Teil II Nr. 2 EU CRA). Wo es technisch machbar ist, kommen Sicherheitsupdates getrennt von neuen Funktionen. Verteilt werden sie kostenlos (Nr. 8).
- 03
Sichere Wege ins Feld
Für die Verteilung von Updates fordert Anhang I Teil II Nr. 7 EU CRA sichere Mechanismen, über die Schwachstellen rechtzeitig behoben oder eingedämmt werden, bei Sicherheitsupdates gegebenenfalls automatisch. Welche Technik das leistet, lässt die Verordnung offen. Üblich nach dem Stand der Technik sind signierte Images, A/B-Partitionen und ein Schutz gegen das Zurückspielen alter Stände.
- 04
Sorgfalt bei zugekauftem Code
Art. 13 Abs. 5 und 6 EU CRA
Wer fremden Code integriert, ob Binär-Blob aus dem Chip-SDK oder Open-Source-Bibliothek wie mbedTLS und lwIP, lässt nach Art. 13 Abs. 5 EU CRA die gebotene Sorgfalt walten, damit die Komponente die Cybersicherheit des Produkts nicht beeinträchtigt. Taucht in einer solchen Komponente eine Schwachstelle auf, geht die Meldung an den, der sie herstellt oder wartet (Art. 13 Abs. 6).
- 05
24 Stunden für die Frühwarnung
Innerhalb von 24 Stunden nach Kenntnis meldet der Hersteller eine aktiv ausgenutzte Schwachstelle als Frühwarnung an das koordinierende CSIRT und die ENISA (Art. 14 Abs. 2 a EU CRA). Diese Pflicht gilt seit dem 11. September 2026. Die ausführlichere Meldung folgt nach 72 Stunden (Buchstabe b).
- 06
Zehn Jahre Aufbewahrung
Technische Dokumentation und EU-Konformitätserklärung liegen für die Marktüberwachung mindestens zehn Jahre nach dem Inverkehrbringen bereit, bei einem längeren Unterstützungszeitraum so lange wie dieser (Art. 13 Abs. 13 EU CRA).
Angrenzende Regulierung
Welche Regeln neben dem EU CRA für Embedded-Produkte gelten
Bei Embedded-Systemen entscheidet häufig das Endprodukt, ob der EU CRA überhaupt greift.
Medizinprodukte, VO (EU) 2017/745 und 2017/746
Der EU CRA nimmt Medizinprodukte und In-vitro-Diagnostika aus, samt der darin laufenden Embedded-Systeme (Art. 2 Abs. 2 a und b EU CRA).
Fahrzeuge, VO (EU) 2019/2144
Steuergeräte in Fahrzeugen, für die die Typgenehmigungsverordnung gilt, liegen außerhalb des EU CRA (Art. 2 Abs. 2 c EU CRA).
Luftfahrt und Schiffsausrüstung
Nach VO (EU) 2018/1139 zertifizierte Luftfahrtprodukte (Art. 2 Abs. 3 EU CRA) und Schiffsausrüstung im Sinne der RL 2014/90/EU (Art. 2 Abs. 4) sind ebenfalls herausgenommen.
Maschinenverordnung (EU) 2023/1230
Für Maschinen sieht Art. 2 EU CRA keine Ausnahme vor. Eine Maschine mit eingebetteter Steuerung unterliegt deshalb beiden Verordnungen.
Funkanlagenrichtlinie 2014/53/EU, Delegierte VO (EU) 2022/30
Erwägungsgrund 30 EU CRA hält fest, dass die grundlegenden Cybersicherheitsanforderungen des EU CRA alle Elemente von Art. 3 Abs. 3 d, e und f der Funkanlagenrichtlinie umfassen. Für die Cybersicherheit von Funkmodulen ist damit der EU CRA der Maßstab.
KI-Verordnung (EU) 2024/1689
Ein als Hochrisiko-KI-System eingestuftes Edge-KI-Modul, das Anhang I des EU CRA erfüllt und dies in der EU-Konformitätserklärung nachweist, gilt bei den Cybersicherheitsanforderungen aus Art. 15 KI-VO als konform (Art. 12 Abs. 1 EU CRA).
IEC 62443-4-1 und -4-2
Die Normenreihe hilft bei der Umsetzung. Eine Konformitätsvermutung knüpft Art. 27 Abs. 1 EU CRA jedoch nur an harmonisierte Normen, deren Fundstellen im Amtsblatt veröffentlicht sind.
Aus der Praxis
Wo Embedded-Hersteller Zeit verlieren
Ein Stack, viele Produkte
Bootloader, RTOS, TLS-Bibliothek und Chip-SDK laufen in vielen Varianten gleichzeitig. Eine neue CVE in der gemeinsamen Bibliothek trifft deshalb alle auf einmal, und für jede Variante muss sich zeigen lassen, ab welchem Firmware-Stand der Fix drin ist.
Code ohne Quelltext
Funk-Stacks, Treiber und Krypto-Beschleuniger kommen vom Chiphersteller oft nur als Binärdatei. Für Stückliste und Sorgfalt nach Art. 13 Abs. 5 EU CRA zählen Name, Version und Herkunft jeder dieser Komponenten.
Das Gerät überlebt das SDK
Pflegt der Chiphersteller sein SDK kürzer, als das Gerät im Feld bleibt, versiegen irgendwann die Fixes von upstream. Art. 13 Abs. 8 EU CRA lässt zu, die Unterstützungszeiträume zugekaufter Kernkomponenten bei der Festlegung des eigenen Zeitraums zu berücksichtigen; die Überlegung gehört in die technische Dokumentation.
Bestandsgeräte ohne Update-Kanal
Ältere Geräte ohne sicheren Update-Weg lassen sich nicht einfach patchen. Wird dort eine Schwachstelle aktiv ausgenutzt, bleiben Eindämmung und Meldung, und beides braucht einen Ablauf, der steht, bevor der Fall eintritt.
Mit Kunnus
Wie Kunnus Embedded-Hersteller unterstützt
Kunnus deckt die EU-CRA-Schicht der Konformität ab: Einstufung, Stückliste, Schwachstellen, Meldungen und technische Dokumentation. Maschinen-, Funk- und EMV-Anforderungen bleiben in Ihrem bestehenden CE-Prozess.
Rechenbeispiel
Wie lässt sich der EU CRA bei vielen Embedded-Varianten wirtschaftlich umsetzen?
Nach der EU-Kommissions-Guidance (C(2026) 5252, Abschnitt 2.1) sind Varianten mit unterschiedlichen Komponenten, Konfigurationen oder Funktionsumfängen eigenständige Produkte. Varianten mit gleicher Architektur, gleichem sicherheitsrelevantem Design, gleicher Zweckbestimmung und gleichem Risikoprofil dürfen sich Risikobewertung, technische Dokumentation und EU-Konformitätserklärung teilen (Abschnitt 7.4). Wirtschaftlich wird die Umsetzung, wenn Hersteller ihre Varianten nach sicherheitsrelevanten Unterschieden gruppieren und den gemeinsamen Stack einmal pflegen.
- 1Portfolio1 Mikrocontroller-Plattform, 12 Varianten: 3 Funkoptionen (WLAN, LTE-M, ohne Funk) × 2 Speicherausbauten × 2 Marken
- 2Gruppen3, getrennt nach Funkschnittstelle. Speicherausbau und Marke trennen laut EU-Kommissions-Guidance (Abschnitt 7.4) nicht, abweichende Kommunikationsschnittstellen schon.
- 3Firmware-Stände12 Varianten × 3 Releases pro Jahr = 36 Stände mit eigener Stückliste je Jahr, 180 über einen Unterstützungszeitraum von 5 Jahren (Art. 13 Abs. 8 EU CRA)
- 4Geteilter StackBootloader, RTOS, TLS-Bibliothek, Netzwerk-Stack und Chip-SDK in allen 12 Varianten
- 5Eine CVE in der TLS-Bibliothekbetrifft 12 Produkte gleichzeitig; Bewertung, Fix und gegebenenfalls die Meldung nach Art. 14 EU CRA laufen für alle parallel
- 6Gepflegt wird1 Stack, 3 Risikobewertungen und Dokumentationssätze, 12 eindeutig benannte Varianten in den Konformitätserklärungen
Beispiel mit angenommenen Zahlen, keine Marktdaten. Ob Varianten Unterlagen teilen dürfen, hängt davon ab, ob ihre Unterschiede cybersicherheitsrelevant sind (EU-Kommissions-Guidance, Abschnitt 7.4).
Häufige Fragen
Ist Firmware ein Produkt mit digitalen Elementen, auch wenn sie nur mit der Hardware ausgeliefert wird?+
Firmware, die fest mit der Hardware ausgeliefert wird, ist Teil des Hardwareprodukts und wird mit ihm bewertet. Art. 3 Nr. 1 EU CRA definiert ein Produkt mit digitalen Elementen als Software- oder Hardwareprodukt einschließlich Komponenten, die getrennt in Verkehr gebracht werden. Eigenständig verkaufte Firmware, etwa ein lizenziertes RTOS oder ein kommerzieller Bootloader, ist deshalb selbst ein Produkt. Als Betriebssystem oder Bootmanager steht sie zudem in Anhang III Klasse I (Nr. 11 bzw. Nr. 8).
Wann ist mein Modul eine Komponente und wann ein Produkt, und was ändert die Außendarstellung?+
Ein Funk- oder Rechenmodul ist nach Art. 3 Nr. 6 EU CRA eine Komponente, weil es für die Integration in ein anderes System bestimmt ist. Bringt der Modulhersteller es getrennt in Verkehr, ist es nach Art. 3 Nr. 1 zugleich ein eigenes Produkt mit digitalen Elementen. Wer als Hersteller gilt, hängt an Name und Marke: Nach Art. 3 Nr. 13 ist es, wer ein Produkt unter eigenem Namen oder eigener Marke vermarktet. Wer ein zugekauftes Modul unter eigener Marke anbietet, übernimmt damit die Herstellerpflichten.
Macht ein Mikrocontroller der Klasse I mein Endprodukt zu einem wichtigen Produkt?+
Ein Mikrocontroller mit sicherheitsrelevanten Funktionen steht in Anhang III Klasse I Nr. 14 EU CRA. Das Gerät, in das er eingebaut wird, wird dadurch nicht automatisch zum wichtigen Produkt: Art. 7 Abs. 1 Satz 2 EU CRA stellt klar, dass die Integration für sich genommen kein Verfahren nach Art. 32 Abs. 2 oder 3 auslöst. Maßgeblich ist die Kernfunktion des Endprodukts. Ist das Endprodukt selbst ein Router oder ein Bootmanager, gilt dessen Klasse.
Was gilt für Schwachstellen, die sich nur durch eine Hardware-Änderung beheben lassen?+
Anhang I Teil II Nr. 2 EU CRA verlangt, Schwachstellen unverzüglich zu behandeln und zu beheben; Nr. 7 spricht davon, Schwachstellen zu beheben oder einzudämmen. Lässt sich eine Schwachstelle im Silizium nicht per Firmware schließen, kommt nach unserer Lesart von Nr. 7 die Eindämmung in Betracht, etwa ein abgeschalteter Dienst oder eine geänderte Konfiguration, und die Risikobewertung wird nach Art. 13 Abs. 7 aktualisiert. Hat der Hersteller eine Hardware-Änderung entwickelt, gibt er die einschlägigen Unterlagen nach Art. 13 Abs. 6 an den Hersteller der Komponente weiter.
Welche Pflichten gelten für Open-Source-Komponenten in der Firmware?+
Für Open-Source-Komponenten wie Zephyr, FreeRTOS, mbedTLS oder lwIP gilt die Sorgfaltspflicht aus Art. 13 Abs. 5 EU CRA genauso wie für zugekaufte Komponenten: Sie dürfen die Cybersicherheit des Produkts nicht beeinträchtigen. Der Gerätehersteller führt sie in der Stückliste und überwacht sie auf Schwachstellen. Findet er eine, meldet er sie nach Art. 13 Abs. 6 dem Projekt. Hat er selbst einen Fix entwickelt, gibt er auch diesen weiter.
Gilt der EU CRA für Ersatzplatinen und für Geräte, die schon im Feld sind?+
Ersatzteile, die identische Komponenten nach derselben Spezifikation ersetzen, sind nach Art. 2 Abs. 6 EU CRA ausgenommen; identisch bemisst sich laut EU-Kommissions-Guidance (Abschnitt 4.1) an den sicherheitsrelevanten Eigenschaften. Geräte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Anforderungen nur nach einer wesentlichen Änderung (Art. 69 Abs. 2 EU CRA). Für die Meldepflicht nach Art. 14 macht Art. 69 Abs. 3 eine Ausnahme: Sie gilt seit dem 11. September 2026 auch für diese Bestandsgeräte.
In welche Klasse fallen Ihre Embedded-Produkte?
Mit dem EU-CRA-Assessment erhalten Sie in wenigen Minuten eine erste Einschätzung zu Klasse, Pflichten und nächsten Schritten für Ihr Portfolio.
Weiterlesen
Weitere Branchen
EU-CRA-Compliance in anderen Branchen
Quelle: Verordnung (EU) 2024/2847 (Cyber Resilience Act), Amtsblatt der EU. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Diese Seite ist eine Orientierung zum Cyber Resilience Act für diese Branche, keine Rechtsberatung. Ob und wie die Verordnung für ein konkretes Produkt greift, hängt von dessen Zweckbestimmung und Aufbau ab.