CRA-Compliance für Elektronikhersteller: Wie SBOM, Secure Boot und Root of Trust den EU-Marktzugang sichern
Vernetzte Elektronikprodukte müssen über ihren gesamten Lebenszyklus hinweg sicher und updatefähig bleiben. Der Cyber Resilience Act der EU verpflichtet Hersteller, Cybersicherheit in Entwicklung, Produktion und Wartung zu verankern. Automatisierte SBOMs, Secure Boot und Hardware-Root-of-Trust schaffen dafür Transparenz, schützen die Firmware-Integrität und sichern Updates. Entscheidend ist jedoch nicht nur, einzelne Anforderungen formal zu erfüllen, sondern von Beginn an eine robuste, automatisierbare und prüfbare Security-Architektur aufzubauen.
Warum CRA und digitaler Produktpass zusammen gedacht werden sollten
Vernetzte Produkte müssen künftig nicht nur sicher, auch die zugehörige Dokumentation muss technisch nachvollziehbar sein. So verpflichtet der Cyber Resilience Act (CRA) Hersteller dazu, Cybersicherheit über alle Stufen der Wertschöpfungskette hinweg zu integrieren: vom Planen und Entwickeln, über das Produzieren bis hin zum Warten von Produkten. Das gilt für alle sogenannten „Produkte mit digitalen Elementen“ (PDE). Hierzu zählen vernetzte Hardwareprodukte ebenso wie reine Softwareprodukte.
Um der entsprechenden Dokumentationspflicht nachzukommen, können Unternehmen auf den digitalen Produktpass (DPP) zurückgreifen. Er bietet eine strukturierte Datengrundlage für produktbezogene Informationen entlang der gesamten Wertschöpfungskette und bündelt etwa Informationen zu Materialien, Reparierbarkeit und Recyclingfähigkeit, um Produkte transparent und rückverfolgbar zu gestalten.
Die eigentliche Aufgabe für Unternehmen besteht künftig darin, CRA-Compliance in robuste technische Formate zu übersetzen. So entsteht aus der reinen Nachweispflicht ein belastbares Fundament für sichere, updatefähige und vertrauenswürdige Produkte.
Was bedeutet der CRA für Hersteller von Elektronikprodukten?
Der CRA verlangt von Herstellern, Cybersicherheit als technische Produkteigenschaft über den gesamten Lebenszyklus zu verankern. Produkte mit digitalen Elementen sind so zu entwickeln und zu produzieren, dass sie Risiken systematisch reduzieren. Zur Nachweispflicht zählen zum Beispiel:
- eine dokumentierte Risikoanalyse
- sichere Default-Konfigurationen
- Schutz vor unbefugtem Zugriff
- Integrität von Software und Daten
- Mechanismen für Sicherheitsupdates und Schwachstellenbehandlung
Die CRA-Konformität wird für betroffene Produkte zudem Teil des CE-relevanten Nachweises. Somit müssen Unternehmen zum Beispiel Security-Anforderungen prüfbar dokumentieren, in Entwicklungsprozesse integrieren und über die erwartete Nutzungsdauer des Produkts pflegen. Der Anwendungsbereich des CRA ist dabei recht breit gefächert.
Laut BSI umfasst der CRA Produkte, die direkt oder indirekt mit Geräten oder Netzwerken verbunden werden können. Somit gilt der CRA sowohl für vernetzte Hardwareprodukte wie Smartphones und Laptops, Mikroprozessoren, Firewalls und Smart-Meter-Gateways als auch für reine Softwareprodukte wie Buchhaltungssoftware oder Computerspiele.
Warum sollten Unternehmen eine SBOM pflegen?
Die Transparenz über die eingesetzte Software ist eine der Voraussetzungen für die CRA-Compliance. Hersteller müssen wissen, welche Komponenten, Bibliotheken und Abhängigkeiten in welchem Produkt stecken. Genau dafür ist eine Software Bill of Materials vorgesehen. Eine SBOM ist laut ZVEI ein formaler, idealerweise maschinenlesbarer Datensatz, der die in einem Produkt enthaltenen Software-Komponenten inventarisiert. Sie enthält unter anderem Angaben zu:
- Komponentenname
- Version
- Ersteller
- Abhängigkeiten
Die SBOM schafft Transparenz in der Software-Lieferkette und hilft Herstellern, bei Schwachstellenmeldungen schneller zu prüfen, ob ein Produkt betroffen ist. Entwickler sollten daher Änderungen an der realen Software zeitnah in der SBOM abbilden.
Bei Aufbau und Bewertung einer SBOM hilft unter anderem die Richtlinie BSI TR-03183-2. Sie beschreibt, wie diese als verwertbarer Nachweis für Software-Transparenz aufgebaut sein sollte und macht Vorgaben zu formalen und fachlichen Mindestinformationen, etwa zu Komponenten, Versionen und maschinenlesbaren Formaten.
Diese Transparenz ist jedoch nur ein Teil der CRA-Compliance. Zusätzlich müssen Hersteller sicherstellen, dass im Produkt nur autorisierte und unveränderte Software ausgeführt wird. Dafür kommen Secure Boot und Hardware-Root-of-Trust ins Spiel.
Was versteht man unter Secure Boot und Hardware-Root-of-Trust?
Secure Boot sorgt dafür, dass ein Gerät beim Start nur geprüfte und unveränderte Software ausführt. Dafür wird der Code kryptografisch validiert, bevor er geladen wird. Die Hardware-Root-of-Trust bildet den geschützten Ausgangspunkt dieser Vertrauenskette: Sie ist das erste Element im System, dem vertraut wird, und auf dem alle weiteren Prüfungen aufbauen.
Für die CRA-Konformität ist das relevant, weil Hersteller nachweisen müssen, dass Firmware-Integrität, Geräteidentität und sichere Updates technisch abgesichert sind. Je nach Plattform können dafür unterschiedliche Funktionen genutzt werden, z.B.:
- Trusted Platform Module (TPM)
- Secure Element
- TrustZone
- Physical Unclonable Function (PUF)
- MCU-integrierte Sicherheitsfunktionen
Wichtig sind außerdem signierte Firmware-Images, belastbares Schlüsselmanagement, Rollback-Schutz, gehärtete Debug-Schnittstellen und validierte OTA-Updates.
Warum Architekturentscheidung statt Compliance-Checkliste?
SBOM, Secure Boot und Hardware-Root-of-Trust erfüllen unterschiedliche Aufgaben innerhalb der CRA-Compliance. Die SBOM schafft Transparenz über Software-Komponenten, Versionen und Abhängigkeiten. Secure Boot und Hardware-Root-of-Trust setzen an einer anderen Stelle an: Sie schützen das Produkt selbst und sichern sie Geräteidentität, Firmware-Integrität und updatefähige Produktarchitekturen technisch ab. Erst wenn Unternehmen beide Ebenen zusammen berücksichtigen, transparente Software-Lieferkette und abgesicherte Gerätearchitektur, ist die CRA-Compliance über den gesamten Produktlebenszyklus belastbar.
Damit diese beiden Ebenen zusammenwirken, sollten Entwicklung, Systemarchitektur, Einkauf, Qualitätssicherung und technische Projektleitung frühzeitig gemeinsame Standards festlegen: welche Komponenten zum Einsatz kommen, wie man Schlüssel verwaltet, welche Informationen Lieferanten bereitstellen müssen und wie man Releases dokumentiert. So wird CRA-Compliance nicht erst am Ende des Projekts geprüft, sondern von Beginn an in Produktdesign, Entwicklungsprozess und Lieferkette verankert.
Was bedeutet der CRA für die Elektronikbranche?
Eine sorgfältige CRA-Readiness entwickelt sich für die Elektronikbranche mehr und mehr zu einem Differenzierungsmerkmal. Unternehmen, die Firmware, Schwachstelleninformationen und Nachweise automatisiert beherrschen, reduzieren den Audit-Aufwand und stärken das Vertrauen in ihre vernetzten Produkte. Der CRA adressiert diese Produktverantwortung über den gesamten Lebenszyklus und macht Cybersicherheit zu einem prüfbaren Bestandteil der Marktfähigkeit.
Für Hersteller, Entwickler und Systemarchitekten bietet die electronica den passenden Branchenkontext. Als Weltleitmesse der Elektronik deckt sie das Spektrum moderner Elektronik ab und verbindet Komponenten, Systeme, Software und Anwendungsmärkte miteinander.
Wer tiefer in Themen rund um CRA, Cybersicherheit, Embedded und IoT Security einsteigen möchte, kann sich auf der electronica bei Fachvorträgen, Panel-Diskussionen und Experten-Foren – etwa dem Cyber Security Forum oder dem Embedded Systems Forum – umfassend informieren und sich mit den führenden Experten der Branche austauschen.