Der Cyber Resilience Act (CRA) der Europäischen Union (EU) markiert eine wegweisende Regulierung für alle Produkte, die digitale Elemente enthalten. Mit der vollständigen Einführung der Regulierung am 11. Dezember 2027 und anderen obligatorischen Anforderungen, die noch früher in Kraft treten, ist es für Ingenieurteams und Produktmanager unerlässlich, die Gesetzgebung zu verstehen. Schließlich tragen die Hersteller die Hauptverantwortung dafür, dass alle Geräte vor der Markteinführung konform sind.
Neben der vollständigen Haftung im Falle von Cybersecurity-Vorfällen sind die Strafen für Nichtkonformität schwerwiegend:
- Geldstrafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, wobei nicht konforme Produkte vom EU-Markt ausgeschlossen, zurückgezogen oder zurückgerufen werden.
- Verlust der CE-Kennzeichnung bedeutet, dass Produkte nicht legal in der EU verkauft werden können.
- Möglicher automatischer Ausschluss von Ausschreibungen und Partnerschaften, da viele Ausschreibungen (RFPs) CRA-konforme Lösungen erfordern.
Darüber hinaus riskieren Hersteller, die nicht konform sind, den Verlust von Marktglaubwürdigkeit und Vertrauen, da Kunden aus kritischen Sektoren (wie Regierungs-, Finanz- und Industrieanwendungen) Produkte meiden, die keine umfassenden Sicherheitsgarantien bieten.
Angesichts dieser Risiken müssen Systemdesigner nun die Sicherheitsimplikationen wichtiger Hardware- und Softwareentscheidungen von Anfang an im Designprozess berücksichtigen, da beide die langfristige Konformität und damit den Marktzugang beeinflussen werden. Dieser Artikel wird die wichtigsten Sicherheitsverpflichtungen eines Herstellers unter dem CRA definieren, bevor er Over-the-Air (OTA)-Updates als eine leistungsstarke Strategie zur Aufrechterhaltung der langfristigen Konformität hervorhebt. Anschließend wird ein robustes Software-Framework skizziert, um diese Updates sicher bereitzustellen, und ein Beispiel für eine kommerziell erhältliche Lösung (COTS) gegeben, die mit diesen Prinzipien übereinstimmt.
Sicherheitsverpflichtungen unter dem CRA
Von Verbrauchsgeräten bis hin zu verteilten Infrastrukturkomponenten leiden moderne Edge-Systeme unter einer zunehmenden Anzahl von Sicherheitslücken. Veraltete Firmware-Probleme und unsichere Kommunikationsprotokolle können zu Datenverletzungen und unbefugtem Zugriff führen, die die Integrität des Geräts gefährden. Dementsprechend schreibt der CRA mehrere Maßnahmen vor, um eine minimale Angriffsfläche zu erhalten:
Erstens müssen Hersteller Geräte vor unbefugter Manipulation schützen und die Softwareintegrität vom ersten Start an sicherstellen. Während der CRA keinen spezifischen Rahmen zur Erreichung dieses Ziels definiert, dient Secure Boot in Kombination mit einer Root-of-Trust (RoT) als grundlegende Basis zur Erfüllung dieser Anforderung.
Secure Boot nutzt Kryptographie, um sicherzustellen, dass nur authentische, verifizierte Software auf dem Gerät läuft. Diese RoT bildet das erste Glied in einer Vertrauenskette, die jede Stufe des Boot-Prozesses authentifiziert, um die Integrität des Geräts sicherzustellen, wie in Abbildung 1 gezeigt. Wenn beispielsweise ein Hash einer Softwarekomponente mit einem privaten Schlüssel verschlüsselt wird, der nicht mit den öffentlichen Schlüsseln in der RoT übereinstimmt – sei es aufgrund von Manipulation oder Korruption – wird der Boot-Prozess entweder gestoppt oder höhere Systemfähigkeiten (wie Netzwerkzugriff) eingeschränkt, um die Verbreitung potenzieller Malware oder Botnets zu verhindern.
Hersteller müssen die Integrität durch kontinuierliches Schwachstellenmanagement und rechtzeitige Sicherheitsupdates während des gesamten Produktlebenszyklus sicherstellen. Der CRA definiert einen vorgeschriebenen Unterstützungszeitraum von mindestens 5 Jahren oder der erwarteten Lebensdauer des Produkts, wenn diese kürzer ist, und verlangt, dass Hersteller ein festgelegtes End-of-Support-Datum bei der Markteinführung angeben.
Wenn eine aktiv ausgenutzte Schwachstelle entdeckt wird, müssen Hersteller diese ihrem nationalen Computer Security Incident Response Team (CSIRT) und der Europäischen Agentur für Netz- und Informationssicherheit (ENISA), der EU-Agentur für Cybersicherheit, melden. Diese Meldeverpflichtung tritt am 11. September 2026 in Kraft, mit den folgenden Zeitrahmenanforderungen:
- 24 Stunden: Frühwarnberichte müssen an ENISA und das nationale CSIRT gesendet werden.
- 72 Stunden: Eine formelle Schwachstellenbenachrichtigung muss erstellt werden, die den Exploit und seine Auswirkungen auf ein System beschreibt.
- 14 Tage: Ein Abschlussbericht muss eingereicht werden, sobald ein Sicherheitspatch verfügbar ist.
Kontinuierliches Schwachstellenmanagement erfordert naturgemäß ein gewisses Maß an Echtzeit-Bedrohungsüberwachung. Öffentliche Frameworks wie das Common-Vulnerabilities-and-Exposures-(CVE)-System können Herstellern helfen, neue Bedrohungen in Drittanbieter-Softwarekomponenten zu erkennen und zu patchen, noch bevor diese aktiv in den eigenen Geräten ausgenutzt werden.
Zur Unterstützung der oben genannten Anforderungen schreibt der CRA außerdem vor, dass Hersteller für jedes Update technische Dokumentation vorhalten. Insbesondere muss eine Software Bill of Materials (SBOM) in einem maschinenlesbaren Format wie CycloneDX oder SPDX bereitgestellt werden, die mindestens alle Top-Level-Abhängigkeiten abdeckt. Dieses Format ermöglicht es automatisierten Tools, jeden Software-Build mit CVE-Datenbanken abzugleichen, um neue Schwachstellen zu identifizieren, sobald sie gemeldet werden. DevSecOps-Teams können anschließend Patches bereitstellen, die interne Probleme beheben, ohne Drittanbieter-Software einzuführen.
Zusätzlich zu SBOMs erfordert CRA-Konformität eine umfassende Dokumentation, darunter eine übergeordnete Sicherheitsrisikobewertung, Systemarchitekturdiagramme mit einer Beschreibung des Entwicklungsprozesses sowie Beschreibungen des Prozesses zur Schwachstellenbehandlung (siehe Abbildung 2). Diese werden genutzt, um zu verifizieren, dass das System gemäß den CRA-Leitlinien secure-by-design ist. Protokollierte Dokumentation muss über den gesamten Lebenszyklus eines Geräts hinweg aufbewahrt und Auditoren, Marktüberwachungsbehörden und benannten Stellen für zehn Jahre nach Markteinführung oder für die Dauer eines längeren Supportzeitraums zur Verfügung gestellt werden.
Schließlich ermöglicht eine formale Konformitätserklärung (Declaration of Conformity, DoC) Herstellern die Nutzung der CE-Kennzeichnung für den Marktzugang in der EU. Das DoC-Dokument enthält unter anderem den Namen und die Adresse des Herstellers, eine eindeutige Produktidentifikation sowie Verweise auf spezifische Standards und technische Spezifikationen, die zum Nachweis der Compliance verwendet wurden. Für bestimmte digitale Produkte, die unter die CRA-Kategorien „Important Class I“, „Important Class II“ und „Critical“ fallen, müssen zudem Angaben zu einem Drittprüfer enthalten sein, der die Compliance verifiziert. Zu diesen Geräten zählen industrielle Steuerungssysteme, IoT-Gateways und Software für privilegierten Zugriff, bei denen Sicherheitsverletzungen größere Infrastrukturschäden verursachen können.
Mit der Unterzeichnung einer DoC übernehmen Hersteller die volle Verantwortung für die CRA-Compliance. Angesichts der Tiefe dieser Verpflichtungen bieten OTA-Updates den effektivsten Weg, um Patches schnell bereitzustellen und die Integrität vernetzter Geräte aufrechtzuerhalten. Kontinuierliche OTA-Updates erfordern jedoch eine ausgereifte Softwarearchitektur, die gezielt auf CRA-konforme Updates ausgelegt ist.
Softwareinfrastruktur für regelmäßige OTA-Sicherheitspatches entwickeln
Im Rahmen des CRA stehen DevSecOps-Teams unter erheblichem Zeitdruck, wenn sie nach der Entdeckung von Sicherheitsproblemen diese lokalisieren, charakterisieren und beheben müssen. Um das Sicherheitsmanagement zu erleichtern, profitieren eingebettete Geräte von den folgenden architektonischen Anpassungen:
- Integriertes Telemetrie-Reporting: Durch das Sammeln von Gerätezustandsdaten und deren Übermittlung an eine Cloud-Plattform können Hersteller Bugs oder Exploits in vernetzten Geräten schnell erkennen. Telemetrie-Reporting ermöglicht es Teams außerdem, die Wirksamkeit neuer Patches in begrenzten realen Tests zu überprüfen, bevor sie flottenweit ausgerollt werden.
- Hochgradig modulare, containerisierte Softwarearchitektur: Bedrohungsisolation unterstützt eine reduzierte Angriffsfläche, falls ein Gerät kompromittiert wird. So verhindert Containerisierung beispielsweise, dass ein Angriff auf die Benutzeroberfläche Zugriff auf den Kerncode des Betriebssystems erhält. Außerdem können einzelne Softwarekomponenten weiterlaufen, während andere aktualisiert werden, wodurch operative Ausfallzeiten reduziert werden. In ähnlicher Weise beschleunigt modulare Software die Lokalisierung von Schwachstellen und reduziert den OTA-Datenbedarf — und damit die Kosten — im Vergleich zu monolithischen Code-Updates.
- Rollback-Mechanismen: OTA-Unterbrechungen und Störungen können verhindern, dass Patches korrekt installiert werden, was zum Bricking führen könnte. Rollback-Mechanismen stellen sicher, dass ein Gerät bei einem fehlgeschlagenen Update jederzeit in einen funktionsfähigen Zustand zurückkehren kann, sodass Hersteller die CRA-Verpflichtung erfüllen und die Geräteintegrität erhalten können.
Verständlicherweise erfordern sichere OTA-Updates durchgängig verschlüsselte End-to-End-Tunnel, um sicherzustellen, dass Patches während der Übertragung nicht kompromittiert werden können und dass ausschließlich signierte und verifizierte Firmware auf einem Gerät ausgeführt wird. Um die Dokumentationsanforderungen für jeden bereitgestellten Patch zu erfüllen, profitieren Hersteller von Softwareentwicklungs-Frameworks, die automatisierte SBOM-Erstellung und Protokollierung bereitstellen.
Die Implementierung CRA-konformer Frameworks kann jedoch eine erhebliche Belastung für Entwickler darstellen, die Software von Grund auf neu entwickeln — insbesondere angesichts der schnell näher rückenden regulatorischen Fristen. Glücklicherweise können COTS-Lösungen Teams dabei unterstützen, Compliance-Anforderungen rechtzeitig zu erfüllen.
COTS-Software-Frameworks für CRA-Ausrichtung nutzen
COTS-Software-Frameworks bieten mehrere Vorteile, die im Kontext des CRA besonders relevant sind. Der Erste ist eine beschleunigte Entwicklung zur Verkürzung der Time-to-Market. Während die rechtliche Verantwortung für Compliance weiterhin beim Hersteller liegt, können bewährte Drittanbieterlösungen auch das Risiko regulatorischer Blind Spots reduzieren. Darüber hinaus können Hersteller durch die Zusammenarbeit mit kommerziellen Partnern zusätzliche langfristige Unterstützung für ihre Softwareinfrastruktur erhalten, was die Belastung für Entwickler weiter verringern kann.
Ein Beispiel für eine solche Lösung ist SECOs Clea OS, eine anpassbare Softwarearchitektur, die für industrielle, sichere Systeme entwickelt wurde und viele Funktionen bietet, die CRA-Compliance erleichtern. Basierend auf dem Open-Source-Yocto-Projekt bietet Clea OS Reproduzierbarkeit und Rückverfolgbarkeit für CRA-Audits und verfügt über Funktionen zur automatisierten SBOM-Erstellung, um verpflichtende Dokumentationsanforderungen zu unterstützen.
Im Gegensatz zu vielen geschlossenen Betriebssystemen ist Clea OS als schlanke und kontrollierte Linux-OS-Grundlage konzipiert, die unnötige Komponenten minimiert, um die Angriffsfläche zu reduzieren und die allgemeine Sicherheit und Resilienz zu verbessern. Containerisierung wird durch Docker ermöglicht, um Bedrohungen zu isolieren und einen 24/7-Betrieb während des Patchings zu unterstützen. Dies wird zusätzlich durch A/B-Partitionierung ergänzt, um sicherzustellen, dass stets ein funktionsfähiges Firmware-Image auf dem Gerät vorhanden ist und bei einem fehlgeschlagenen Update ein Rollback der aktiven Firmware möglich ist.
Darüber hinaus unterstützt Clea OS Secure Boot, digital signierte OTA-Updates, kontinuierliches Echtzeit-Gerätemonitoring in Kombination mit dem breiteren Clea-Ökosystem von SECO (wie in Abbildung 3 dargestellt) sowie ein Cyber Security Package. Indem Hersteller in die Lage versetzt werden, ihre Möglichkeiten zur Bedrohungserkennung und zum Patchen zu maximieren, unterstützt diese Lösung die Anforderungen des CRA an lange Supportzeiträume und adressiert zentrale Vorgaben wie sichere Update-Mechanismen, kontinuierliches Schwachstellenmanagement und Systemintegrität.
Die Existenz von COTS-Lösungen wie SECOs Clea OS zeigt, dass CRA-Compliance nicht so herausfordernd sein muss, wie sie zunächst erscheint. Indem Entwicklungsteams dazu ermutigt werden, auf fertige Software-Frameworks zu setzen, die ein hohes Maß an Anpassbarkeit ermöglichen, können Hersteller den Übergang in eine neue Cybersicherheitslandschaft erleichtern und gleichzeitig differenzierte Produkte auf den Markt bringen.