Am 10. Dezember 2024 trat der Cyber Resilience Act ( CRA ) der Europäischen Union als Verordnung (EU) 2024/2847 in Kraft. Erstmals in der Geschichte wurden Cybersicherheitsanforderungen für Produkte mit digitalen Elementen im gesamten EU-Binnenmarkt rechtsverbindlich – kein freiwilliger Rahmen, sondern eine Marktzugangsvoraussetzung, die mit Geldbußen von bis zu 15 Millionen Euro oder 2.5 % des weltweiten Jahresumsatzes , je nachdem, welcher Betrag höher ist, untermauert wird.
Ab dem 11. September 2026 müssen Hersteller, Importeure und Händler ausgenutzte Sicherheitslücken und schwerwiegende Sicherheitsvorfälle aktiv an ENISA und die nationalen CSIRTs melden. Für Organisationen, die vernetzte Geräte entwickeln, herstellen oder vertreiben, definiert der CRA neu, was die Auslieferung eines Produkts bedeutet.
Dieser Blog erläutert detailliert, was die CRA konkret von einer Codesignaturarchitektur verlangt , ordnet diese Anforderungen den technischen Kontrollen zu, die zu ihrer Erfüllung erforderlich sind, und erklärt, warum Organisationen, die ihre Signaturinfrastruktur noch nicht angepasst haben, die Zeit davonläuft, dies vor Ablauf der jeweiligen Compliance-Frist zu tun.
Was der Cyber Resilience Act tatsächlich erfordert
Die Verordnung gilt für alle „Produkte mit digitalen Elementen“, die auf dem EU-Markt in Verkehr gebracht werden. Diese Kategorie ist so weit gefasst, dass sie praktisch jedes vernetzte Hardwaregerät und die darauf laufende Software umfasst. Router, Smart-Home-Geräte, medizinische Geräte, industrielle Steuerungen, Laptops, Server, IoT-Sensoren und die dazugehörige Firmware fallen darunter.
Die Verordnung basiert auf dem Grundprinzip der Sicherheit durch Design. Produkte müssen so konzipiert, entwickelt und gewartet werden, dass ihre Cybersicherheit über ihre gesamte erwartete Lebensdauer gewährleistet ist. Es handelt sich nicht um eine einmalige Zertifizierung, sondern um eine kontinuierliche Verpflichtung, die gemäß Artikel 13 Absatz 8 für einen Mindestunterstützungszeitraum von fünf Jahren oder, falls kürzer, für die erwartete Produktlebensdauer gilt.
Speziell für die Codesignierung legt das CRA mehrere Verpflichtungen fest, die sich direkt aus seinen Kernanforderungen ergeben:
Die Integrität von Software und Firmware muss entlang der gesamten Lieferkette und während des gesamten Produktlebenszyklus gewährleistet sein. Jedes mit einem Produkt ausgelieferte Firmware-Image und jedes Update muss auf Authentizität und Unveränderlichkeit verifizierbar sein. Dies erfordert eine kryptografische Signaturinfrastruktur mit nachweisbaren Kontrollen darüber, wer signieren darf, was signiert werden darf und welche Prüfprotokolle existieren.
Sichere Update-Mechanismen sind ausdrücklich vorgeschrieben. Gemäß Artikel 13 sind Hersteller verpflichtet, die automatische Installation von Sicherheitsupdates zu gewährleisten und Mechanismen zur Überprüfung der Update-Authentizität zu implementieren. Ein Update-System ohne kryptografische Signaturprüfung erfüllt diese Anforderung nicht.
Die koordinierte Offenlegung von Sicherheitslücken gemäß Artikel 14 bedeutet, dass die Hersteller über die operative Infrastruktur verfügen müssen, um festzustellen, welche Produktlinien von einer bestimmten Sicherheitslücke betroffen sind, ENISA innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Sicherheitslücke zu benachrichtigen und innerhalb von 72 Stunden einen vollständigen Triagebericht vorzulegen.
Es wird ein maschinenlesbares SBOM benötigt, das alle im Produkt enthaltenen Softwarekomponenten dokumentiert. Für die Signatur bedeutet dies, dass die Herkunft jeder Firmware-Komponente nachvollziehbar und dokumentierbar sein muss.
Zuordnung von CRA-Anhang I zu technischen Signaturkontrollen
Anhang I der CRA legt die spezifischen Sicherheitsanforderungen fest, die Produkte mit digitalen Elementen erfüllen müssen. Für Firmware und eingebettete Software lassen sich diese Anforderungen direkt in konkrete technische Kontrollen umsetzen.
| CRA-Anhang I-Anforderung | Artikelreferenz | Erforderliche technische Kontrolle |
|---|---|---|
| Sicherheit durch Design: Risiken angemessen für den beabsichtigten Verwendungszweck behandeln | Art. 1 | Sichere Bootkette: unveränderliche BootROM/OTP-Anker mit gerätespezifischen Schlüsseln; jede Bootphase wird vor der Ausführung kryptografisch verifiziert |
| Daten- und Codeintegrität: Schutz der Integrität gespeicherter Daten, übertragener Daten und ausführbarer Programme | Art. 2(f) | Firmware-Signierung: HSM-gebundene Schlüssel signieren jedes Firmware-Artefakt; SUIT/FIT/UEFI-Manifeste liefern Herkunftsnachweis und Manipulationssicherheit. |
| Zugangskontrolle: Schutz vor unbefugtem Zugriff | Art. 2(d) | M-of-N-Signaturquorum: Produktionsfirmware darf nicht von einer einzelnen Person signiert werden; dies wird durch rollenbasierte Zugriffskontrolle (RBAC) der Signaturplattform sichergestellt. |
| Vorfallminderung: die Auswirkungen von Sicherheitsvorfällen reduzieren | Art. 2(k) | Produktspezifische Schlüsselisolierung: Eine Sicherheitslücke betrifft ein einzelnes Produkt, nicht das gesamte Portfolio. |
| Keine bekannten Schwachstellen: Produkte müssen ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden. | Art. 2(a) | Vorabprüfung auf Schwachstellen: Firmware-Artefakte werden vor der Signierungsfreigabe anhand bekannter CVE-Datenbanken geprüft. |
| Minimierte Angriffsfläche: Alle externen Schnittstellen einschränken | Art. 2(j) | Geräteattestierung: DICE/TPM/PSA/TEE liefern einen Laufzeitnachweis dafür, dass nur verifizierter, unveränderter Code ausgeführt wird. |
Schlüsselisolationsarchitektur
Die operativ bedeutendste architektonische Änderung, die die CRA von den meisten Organisationen fordert, ist der Übergang von einer gemeinsam genutzten Signaturschlüsselinfrastruktur zur produktspezifischen Schlüsselisolation.
Das Modell mit gemeinsamem Schlüssel ist der Standard für Organisationen, die Codesignierung ohne formale Governance eingeführt haben. Ein einziger Signaturschlüssel, beispielsweise auf einem USB-Token oder einem Build-Server gespeichert, wird verwendet, um die Firmware für jedes Produkt zu signieren. Es ist einfach zu verwalten und funktioniert technisch. Gemäß dem Code-Records Act (CRA) stellt es jedoch einen Verstoß gegen die strukturelle Compliance dar.
Darum ist diese Unterscheidung wichtig:
Architektur mit gemeinsamem Schlüssel
Alle Produktlinien verwenden denselben Signaturschlüssel. Wenn dieser Schlüssel kompromittiert wird:
- Alle damit gekennzeichneten Produkte sind gleichzeitig betroffen.
- Der Wirkungsbereich umfasst das gesamte Portfolio.
- Die in Artikel 14 vorgesehene 24-Stunden-Meldepflicht gegenüber der ENISA muss alle betroffenen Produkte gleichzeitig erfassen, ohne dass die Möglichkeit besteht, den Umfang der Auswirkungen abzuschätzen.
- Antwort zur Einhaltung der Vorschriften: Ohne produktbezogene Aufzeichnungen ist dies innerhalb von 24 Stunden nicht möglich.
Schlüsselarchitektur pro Produkt
Jede Produktlinie verfügt über einen eigenen Schlüssel, der intern generiert und in einer separaten HSM- Partition gespeichert wird. Wenn ein Schlüssel kompromittiert wird:
- Nur das Produkt, das mit diesem Schlüssel verknüpft ist, ist betroffen.
- Der Explosionsradius beschränkt sich auf eine einzelne Produktlinie.
- Die Mitteilung nach Artikel 14 deckt einen definierten Bereich ab, der präzise und schnell beantwortet werden kann.
- Antwort zur Einhaltung der Vorschriften: Der Prüfpfad identifiziert sofort betroffene Produkte, Signaturvorgänge und Firmware-Versionen.
Für einen Hersteller mit vier Produktlinien bedeutet das Modell mit gemeinsamem Schlüssel ein potenzielles Marktrücknahmeverfahren und gleichzeitige Abhilfemaßnahmen für alle Produkte. Die produktspezifische Trennung hingegen bedeutet, dass nur ein Produkt betroffen ist, drei weiterhin normal funktionieren und die Meldung präzise und nicht panisch erfolgt.
Die Umstellung auf die produktspezifische Schlüsselisolation erfüllt auch die Anforderungen der CRA an die Lieferkettenverantwortlichkeit gemäß Artikel 13 §5. Die Konformitätsbewertungsdokumentation für die CE-Kennzeichnung muss nachweisen, dass der Signaturschlüssel jedes Produkts über eine eigene Verwaltung, Zugriffskontrollen und einen eigenen Prüfpfad verfügt.
Anbieterneutrale Unterzeichnung
Eine der praktischen Herausforderungen für Hersteller, die die CRA-Vorgaben erfüllen wollen, ist die Vielfalt der Siliziumarchitekturen in ihren Produktportfolios. Ein Unternehmen, das sowohl einen Consumer-Router (ARM TrustZone), ein Smart Appliance (MCU/IoT), einen Industriecontroller (RISC-V) als auch ein Serverprodukt (x86/UEFI) herstellt, sieht sich vier unterschiedlichen Plattform-Ökosystemen gegenüber, die jeweils über verschiedene Signatur-Toolchains, unterschiedliche Firmware-Formate (SUIT, FIT, UEFI-Manifeste) und unterschiedliche Hardware-Root-of-Trust-Mechanismen (DICE, TPM, PSA, TEE) verfügen.
Die CRA legt keinen Wert auf diese Komplexität und fordert einheitliche, nachvollziehbare Kontrollen für alle Produkte im Geltungsbereich. Eine herstellerneutrale Signaturarchitektur löst dieses Problem, indem sie die plattformspezifische Signatur-Toolchain von der zugehörigen Richtlinien-Engine entkoppelt. Anstatt vier separate Signatur-Workflows mit vier separaten Schlüsselverwaltungsverfahren und vier separaten Prüfprotokollen zu erstellen, sorgt eine zentrale Richtlinien-Engine für eine einheitliche Governance auf allen Plattformtypen, während plattformspezifische Integrationen die Format- und Protokolldetails für jede Plattform übernehmen.
Die Architekturschichten funktionieren wie folgt:
Hardwarebasierte Vertrauensbasis: FIPS 140-2-zertifizierte HSMs stellen die Schlüsselspeicherung und Signiervorgänge für alle Plattformen bereit. Die Unterstützung von ML-DSA und SLH-DSA gewährleistet quantenresistente Signierung über dieselbe Infrastruktur wie für klassische Algorithmen.
Zentrale Richtlinien-Engine: Die HSM-gestützte Signaturverwaltung wendet einheitliche rollenbasierte Zugriffskontrolle (RBAC), Quorumsanforderungen (M-of-N) und Genehmigungsworkflows über alle Produktlinien und Plattformen hinweg an. Änderungen an den Signaturrichtlinien werden überall gleichzeitig wirksam.
CI/CD und Audit-Schicht: Signierung, Attestierung und unveränderliche Protokollgenerierung erfolgen während der Build-Phase und erzeugen den Artefakt-Hash, die Schlüssel-ID, die Genehmigeridentität, die Pipeline-Phase und den Zeitstempel, die die Audit-Anforderungen der CRA erfordern.
Konforme Ausgaben: Jede Plattform erhält die signierte Firmware im nativen Format mit dem entsprechenden Manifesttyp: SUIT für IoT/MCU, FIT für ARM/Embedded Linux, UEFI-Manifest für x86-Serverplattformen und RISC-V-spezifische Attestierung. Der ENISA-Berichtsworkflow liefert strukturierte, SRP-fähige Ausgaben, die die 24-Stunden-Benachrichtigungspflicht direkt erfüllen.
Diese Architektur erfüllt die CRA-Anforderung an einheitliche Kontrollen über alle Produktlinien hinweg, ohne dass ein separates Compliance-Programm für jede Siliziumplattform erforderlich ist.
Wie CodeSign Secure von Encryption Consulting hilft
CodeSign Secure ist die Enterprise-Plattform für das Code-Signatur-Management von Encryption Consulting. Sie wurde entwickelt, um die Infrastrukturkontrollen bereitzustellen, die für die Einhaltung der CRA-Vorschriften in allen in diesem Blog behandelten Bereichen erforderlich sind.
HSM-gestütztes Schlüsselmanagement: CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) und ist mit Thales Luna, Entrust nCipher, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Die produktspezifische Schlüsselisolation wird auf HSM-Partitionsebene gewährleistet: Jede Produktlinie erhält einen eigenen, dedizierten Schlüssel, der in der Hardware generiert und niemals exportiert wird. Dies erfüllt direkt die Anforderungen der CRA an einen Hardware-Root of Trust gemäß Artikel 13(1)(c) sowie die Anforderung an die produktspezifische Isolation gemäß Artikel 13 §5.
M-of-N-Signaturquorum und RBAC: Das rollenbasierte Zugriffskontrollmodell der Plattform erzwingt die M-of-N-Genehmigungsanforderungen für die Signierung von Produktions-Firmware. Keine einzelne Person kann einen Signiervorgang initiieren und genehmigen. Signieranfragen, Genehmigungen und Ablehnungen werden protokolliert. Die RBAC-Konfiguration selbst ist auditierbar und versionskontrolliert und stellt die dokumentierte Signaturrichtlinie bereit, die für CRA-Konformitätsbewertungen erforderlich ist.
Unveränderliche Protokollierung: Jedes Signaturereignis in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Protokolle werden zentral und getrennt von der Signaturinfrastruktur gespeichert.
Plattformübergreifende Firmware-Formatunterstützung: CodeSign Secure unterstützt die Signierung von Firmware-Artefakten in allen Formaten, die ein vielfältiges Produktportfolio erfordert: .bin, .img, .hex, .fw, .dfu und .efi. Damit wird die Anforderung der CRA nach einheitlichen Kontrollen über alle Produktlinien hinweg erfüllt, ohne dass die Signaturinfrastruktur für jede Plattform neu aufgebaut werden muss.
Unterstützung für Post-Quanten-Kryptographie: CodeSign Secure v3.02 unterstützt produktionsreife ML-DSA (FIPS 204, Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und SLH-DSA (FIPS 205) als abtrennbare Signaturen neben klassischen Algorithmen. Für Hersteller von Produkten mit mehr als fünfjährigen CRA-Supportverpflichtungen bietet die PQC-Signatur bereits heute Schutz vor der HNDL-Bedrohung, noch bevor CRQC verfügbar ist.
CI/CD-Pipeline-Integration: CodeSign Secure lässt sich über API- und Befehlszeilenschnittstellen in Azure DevOps, Jenkins, GitLab CI und andere gängige Pipeline- Plattformen integrieren. Die Signierung der Firmware ist ein kontrollierter, richtlinienbasierter Schritt in der Build-Pipeline und kein manueller Vorgang.
Fazit
Der Cyber Resilience Act hat die Firmware-Signierung von einer bewährten Sicherheitsmaßnahme zu einer verbindlichen Rechtspflicht erhoben. Die erste Umsetzungsmaßnahme, die Meldepflichten für Vorfälle und Schwachstellen gemäß Artikel 14, tritt am 11. September 2026 in Kraft. Die vollständige Einhaltung der Vorschriften, einschließlich der CE-Kennzeichnung, ist bis zum 11. Dezember 2027 erforderlich. Die Infrastruktur, die zur Einhaltung dieser beiden Fristen benötigt wird – produktspezifische Schlüsselisolierung, HSM-gestützte Signierung, M-von-N-Quoren, 10-jährige Audit-Trails und auf Schwachstellenprüfungen basierende Signierungs-Workflows – benötigt 12 bis 18 Monate für die Konzeption und Implementierung.
Die Organisationen, die am besten für die Einhaltung der CRA-Vorschriften aufgestellt sind, sind nicht diejenigen, die erst im Dezember 2027 mit dem Aufbau ihrer Signaturarchitektur beginnen. Sie sind diejenigen, die sie jetzt aufbauen, bevor die Meldepflichten ab September 2026 die Lücken in ihrer aktuellen Infrastruktur aufdecken.
Bei Encryption Consulting bietet CodeSign Secure die von der CRA geforderte Signaturinfrastruktur – von der HSM-gestützten Schlüsselisolation über unveränderliche Prüfprotokolle bis hin zur Post-Quantum-Signatur, die die HNDL-Bedrohung innerhalb des von der CRA vorgegebenen Unterstützungszeitraums adressiert.
