Warum SBOM entscheidend für die Compliance unter dem EU Cyber Resilience Act (CRA) ist

Die wichtigsten Punkte

• SBOM erhöht die Transparenz, indem sie ein strukturiertes Inventar der Softwarekomponenten bereitstellt und damit Security by Design unterstützt. 
• Der EU Cyber Resilience Act (CRA) schreibt SBOM als Teil der Sicherheits- und Compliance-Pflichten für Produkte mit digitalen Elementen vor. 
• Die BSI-Umsetzungsrichtlinie TR-03183-2 v1.0 verlangt maschinenlesbare SBOMs in CycloneDX 1.4+ oder SPDX 2.3+ und unterstützt damit ein automatisiertes Vulnerability Handling. Der CRA selbst überlässt Format und Elemente der SBOM den Durchführungsrechtsakten der Kommission und den harmonisierten Normen. 
• SBOMs enthalten keine Vulnerability-Informationen, erleichtern aber externe Vulnerability Assessments (z. B. VEX, CSAF) als Teil der Risikobewertung. 
• Bei Verstößen können die Sanktionen bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes erreichen, wobei die Marktüberwachungsbehörden befugt sind, Produkte vom Markt zu nehmen. 
• CLOUDYRION unterstützt Organisationen bei der Implementierung von SBOMs, kryptografischer Signierung und Compliance-Maßnahmen, um die Anforderungen des EU CRA zu erfüllen. 

Die Herausforderung: Mangelnde Transparenz über Drittanbieter-Abhängigkeiten 

Eine der größten Herausforderungen in der Softwaresicherheit ist die mangelnde Transparenz über Drittanbieter-Abhängigkeiten. Viele Organisationen setzen auf Softwarekomponenten von Drittanbietern, haben dabei jedoch keinen vollständigen Überblick darüber, was in ihren Anwendungen steckt. Das erschwert es, Vulnerabilities zu erkennen und darauf zu reagieren, und erhöht das Risiko von Cyberangriffen. 

Der EU CRA adressiert diese Risiken, indem er eine transparente Dokumentation der Softwaresicherheit vorschreibt, zu der verpflichtende SBOMs als Eckpfeiler der Supply-Chain-Sicherheit gehören. Ohne eine strukturierte SBOM tun sich Organisationen schwer damit, 

• Vulnerabilities wirksam zu erkennen und darauf zu reagieren, einschließlich aktiv ausgenutzter Vulnerabilities, 
• die Compliance mit regulatorischen Anforderungen aufrechtzuerhalten, etwa mit denen der NIS2-Richtlinie, 
• die Integrität und Sicherheit der Software sicherzustellen, die zentrale Aspekte der Secure-by-Default-Prinzipien sind. 

Um diesen Herausforderungen zu begegnen, empfiehlt die TR-03183 des BSI (Umsetzungsleitfaden) ein maschinenverarbeitbares SBOM-Format, das kryptografische Integrität, Metadaten-Tracking und strukturierte Abhängigkeiten umfasst. Dieser Ansatz steht im Einklang mit dem europäischen Cybersecurity-Zertifizierungsschema und unterstützt das vom CRA geforderte Konformitätsbewertungsverfahren. 

Die BSI TR-03183 ist eine deutsche Umsetzungsrichtlinie, die CRA-konforme SBOM-Praktiken unterstützt. Sie ist selbst kein verbindliches EU-Recht: Die verbindlichen Anforderungen des CRA ergeben sich aus der Verordnung, aus den im Amtsblatt der EU (OJEU) zitierten harmonisierten Normen und aus den Durchführungsrechtsakten der Kommission. Die TR-03183 ist ein belastbares Referenzprofil, insbesondere für Anbieter, die in den deutschen Markt und den deutschen öffentlichen Sektor verkaufen. 

CRA-Compliance-Zeitplan 

Das Verständnis der wichtigsten Termine ist für die Planung Ihres Compliance-Wegs entscheidend: 

Meilenstein	Datum
CRA tritt in Kraft	10. Dezember 2024
Kapitel IV (Notifizierung der Konformitätsbewertungsstellen) gilt	11. Juni 2026
Berichtspflichten nach Artikel 14 beginnen	11. September 2026
Ausreichende notifizierte Stellen voraussichtlich einsatzbereit	11. Dezember 2026
Vollständige Anwendung des CRA	11. Dezember 2027

 Wichtig: Die Delegierte Verordnung (EU) 2026/339 der Kommission vom 16. Februar 2026 hat die RED-Delegierte Verordnung (EU) 2022/30 mit Wirkung zum 11. Dezember 2027 förmlich aufgehoben — dem Datum, an dem der CRA vollständig anwendbar wird. Bis dahin gelten die RED-Cybersecurity-Anforderungen weiterhin für in den Anwendungsbereich fallende Funkanlagen, die ab dem 1. August 2025 auf dem EU-Markt bereitgestellt werden. Die Marktüberwachung im Rahmen der RED bleibt für Anlagen durchsetzbar, die zwischen dem 1. August 2025 und dem 10. Dezember 2027 in Verkehr gebracht werden, und zwar auch nach Inkrafttreten der Aufhebung. 

Durchsetzung und Sanktionen nach Artikel 64 

Die CRA-Sanktionen sind dreistufig: 

• Stufe 1 — bis zu 15 Mio. EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes (je nachdem, welcher Betrag höher ist) bei Nichteinhaltung der grundlegenden Cybersecurity-Anforderungen in Anhang I oder der Herstellerpflichten in den Artikeln 13 und 14. 
• Stufe 2 — bis zu 10 Mio. EUR oder 2 % bei sonstigen Verstößen von Wirtschaftsakteuren und in der Konformitätsbewertung (Importeur, Händler, EU-Konformitätserklärung, technische Dokumentation, CE-Kennzeichnung, Konformitätsbewertungsverfahren, Zusammenarbeit mit der Marktüberwachung). 
• Stufe 3 — bis zu 5 Mio. EUR oder 1 % für die Bereitstellung unrichtiger, unvollständiger oder irreführender Informationen gegenüber notifizierten Stellen oder Marktüberwachungsbehörden. 

In der Praxis können Marktüberwachungsmaßnahmen wirtschaftlich schmerzhafter sein als das Bußgeld selbst. Nationale Behörden können Korrekturmaßnahmen verlangen, die Bereitstellung einschränken oder die Rücknahme, den Rückruf oder das Verbot des Inverkehrbringens eines Produkts auf dem EU-Markt anordnen. 

Zwei wichtige Ausnahmeregelungen nach Artikel 64 Absatz 10: 

• Kleinstunternehmen und kleine Unternehmen sind von Geldbußen ausgenommen, wenn sie die 24-Stunden-Frist für die Frühwarnung nach Artikel 14 Absatz 2 Buchstabe a (und die entsprechende Frist für schwerwiegende Vorfälle nach Artikel 14 Absatz 4 Buchstabe a) nicht einhalten. Andere Pflichten und andere Fristen gelten weiterhin. 

• Open-Source-Software-Stewards sind von CRA-Geldbußen für jeglichen Verstoß ausgenommen. Ihre zugrunde liegenden Pflichten (Cybersecurity-Richtlinie, Vulnerability Handling, Zusammenarbeit mit der Marktüberwachung, Berichterstattung) gelten weiterhin, aber bei Nichteinhaltung kann keine Geldstrafe verhängt werden. 

Welche Produkte sind betroffen? Die CRA-Klassifizierung verstehen 

Der CRA gilt für praktisch alle Produkte mit digitalen Elementen, die auf dem EU-Markt verkauft werden. Allerdings unterliegen nicht alle Produkte denselben Compliance-Anforderungen. Die Verordnung führt ein risikobasiertes Klassifizierungssystem ein, das den Prüfungsumfang und die Art der erforderlichen Konformitätsbewertung bestimmt. 

Standardprodukte (Standardkategorie) 

Die Mehrheit der digitalen Produkte fällt in diese Kategorie. Hersteller können ein Self-Assessment durchführen, um die Konformität nachzuweisen — eine Beteiligung Dritter ist nicht erforderlich. Dazu gehören Verbraucheranwendungen, einfache IoT-Geräte, Standard-Business-Software und die meisten vernetzten Produkte ohne kritische Sicherheitsfunktionen. 

Klasse I — Wichtige Produkte 

Produkte in dieser Kategorie haben eine erhöhte Sicherheitsrelevanz und erfordern entweder interne Kontrollverfahren auf Basis harmonisierter Normen oder eine Bewertung durch Dritte, falls keine Normen angewendet werden. Zu den Klasse-I-Produkten gehören: 

• Passwortmanager und Authentifizierungssoftware 
• VPN-Clients und Remote-Access-Tools 
• Netzwerkmanagement- und Konfigurationstools 
• Browser und Browser-Erweiterungen 
• Boot-Manager und BIOS/UEFI-Software 
• Betriebssysteme (Desktop, Mobil, Server) 
• Software für Public-Key-Infrastruktur (PKI) und die Ausstellung digitaler Zertifikate 

Klasse II — Wichtige Produkte (höheres Risiko) 

Die in Anhang III aufgeführten Klasse-II-Produkte haben eine höhere Cybersecurity-Relevanz und unterliegen strengeren Konformitätsbewertungsverfahren nach Artikel 32 Absatz 3. Die wichtigen Produkte der Klasse II bilden eine abschließende Liste von vier Kategorien: 

• Hypervisoren und Container-Runtime-Systeme, die die virtualisierte Ausführung von Betriebssystemen und ähnlichen Umgebungen unterstützen 
• Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme 
• Manipulationssichere Mikroprozessoren 
• Manipulationssichere Mikrocontroller 

Für Klasse-II-Produkte müssen Hersteller die Konformität mit einem der folgenden Verfahren nach Artikel 32 Absatz 3 nachweisen (der einfachere interne Kontrollweg, der für Standardprodukte und bestimmte Klasse-I-Produkte verfügbar ist, ist für Klasse II nicht zulässig): 

• EU-Baumusterprüfung (Modul B) gefolgt von Konformität mit der Bauart auf Grundlage einer internen Fertigungskontrolle (Modul C) 
• Konformitätsbewertung auf Grundlage einer umfassenden Qualitätssicherung (Modul H) 
• Sofern verfügbar und anwendbar, ein europäisches Cybersecurity-Zertifizierungsschema mit einem Vertrauensniveau von mindestens „substanziell“ 

Kritische Produkte (Anhang IV) 

Eine eigene, enger gefasste Kategorie. Nach Artikel 8 Absatz 1 kann für kritische Produkte die Erlangung eines europäischen Cybersecurity-Zertifikats mit einem Vertrauensniveau von mindestens „substanziell“ erforderlich sein. Wo kein solches Schema verfügbar oder vorgeschrieben ist, folgen Hersteller denselben Verfahren nach Artikel 32 Absatz 3 wie bei den wichtigen Produkten der Klasse II. Zu den in Anhang IV aufgeführten kritischen Produkten gehören: 

• Hardware-Geräte mit Security Boxes (z. B. manipulationssichere Sicherheitsmodule für kritische Anwendungen) 
• Smart-Meter-Gateways innerhalb von Smart-Metering-Systemen 
• Smartcards und ähnliche Geräte, einschließlich Secure Elements 

Die meisten Produkte in dieser Kategorie sind sektorkritische Infrastrukturkomponenten, nicht allgemeine Unternehmens-IT. 

Klasse-II- und kritische Produkte: Die Konformitätsplanung ist ein Arbeitspaket für 2026 

Wenn Ihr Produkt unter Klasse II oder Kritisch fällt, behandeln Sie die Auswahl des Konformitätswegs und die Planung notifizierter Stellen / Modul H als Arbeitspaket für 2026, nicht als nachträgliche Aufgabe für 2027. 

Drei CRA-Termine machen das konkret: 

• 11. Juni 2026 — Kapitel IV (Notifizierung der Konformitätsbewertungsstellen) wird anwendbar. Die Mitgliedstaaten benennen Notifizierungsbehörden; die Konformitätsbewertungsstellen beginnen mit den formellen Notifizierungsverfahren. 
• 11. Dezember 2026 — es sollten ausreichend notifizierte Stellen benannt sein, um Kapazitäten sicherzustellen und Engpässe zu vermeiden. 
• 11. Dezember 2027 — vollständige Anwendung des CRA; Produkte, die eine Konformitätsbewertung durch Dritte erfordern, dürfen ohne diese nicht auf dem EU-Markt in Verkehr gebracht werden. 

Das Zeitfenster zwischen Juni 2026 und Dezember 2027 ist der Zeitraum, in dem die Einbindung notifizierter Stellen, Modul-H-Audits des Qualitätssystems (falls gewählt) oder die Teilnahme an einem europäischen Cybersecurity-Zertifizierungsschema erfolgen muss. Eine späte Einbindung bedeutet, im Jahr 2027 mit allen anderen Klasse-II-/kritischen Herstellern um begrenzte Kapazitäten notifizierter Stellen zu konkurrieren. 

Vom CRA ausgenommene Produkte 

Bestimmte Produktkategorien sind ausdrücklich ausgenommen, weil sie bereits durch sektorspezifische Gesetzgebung reguliert sind: 

Ausnahme	Anwendbare Verordnung
Automotive-Produkte	UN R155/R156
Medizinprodukte	MDR/IVDR
Luftfahrtsysteme	EU-Luftsicherheitsverordnungen
Verteidigung und nationale Sicherheit	Regelungen der Mitgliedstaaten
Open-Source-Software*	Unter bestimmten Bedingungen ausgenommen

*Die Open-Source-Ausnahme gilt nur für nicht-kommerzielle, community-getriebene Entwicklung ohne Supportpflichten oder direkte finanzielle Vergütung durch Nutzer. Sobald sie in ein kommerzielles Produkt integriert werden, fallen Open-Source-Komponenten in die Verantwortung des Herstellers. 

Was ist mit SaaS und Cloud-Diensten? 

SaaS ist keine klare Ausnahme. Der CRA unterscheidet zwischen eigenständigen Diensten und Lösungen zur Fernverarbeitung von Daten: 

• Eigenständige SaaS — Software, die als Dienst bereitgestellt wird und für das Funktionieren keines Produkts mit digitalen Elementen erforderlich ist — fällt im Allgemeinen außerhalb des CRA-Produktrahmens. 
• Lösungen zur Fernverarbeitung von Daten, die für ein Produkt mit digitalen Elementen erforderlich sind, um eine oder mehrere seiner Funktionen auszuführen, fallen ausdrücklich in den Anwendungsbereich des CRA, und der Hersteller des vernetzten Produkts bleibt für sie verantwortlich. 

Auch NIS2 ist kein kategorischer Ersatz für den CRA. NIS2 gilt für bestimmte Arten von Einrichtungen (Cloud-Computing-Anbieter, Rechenzentren, Managed Service Provider, MSSPs, Online-Marktplätze, Suchmaschinen, soziale Plattformen und andere) auf Basis von Sektor, Größe und Rolle — es „ersetzt“ den CRA nicht allgemein für SaaS. 

Praktisches Fazit: Wenn Ihre SaaS ein vernetztes Produkt unterstützt, fallen Teile Ihres Stacks wahrscheinlich in den CRA-Anwendungsbereich. Wenn Sie eine qualifizierte SaaS-Einrichtung betreiben, gelten NIS2-Pflichten möglicherweise parallel — nicht ersatzweise. 

Warum die Klassifizierung wichtig ist 

Die korrekte Klassifizierung Ihrer Produkte ist der entscheidende erste Schritt auf Ihrem Compliance-Weg. Eine Fehlklassifizierung kann zu einer unzureichenden Konformitätsbewertung führen (mit dem Risiko von Sanktionen wegen Nichteinhaltung) oder zu unnötigen Kosten für Drittprüfungen. Wenn Sie sich bei der Klassifizierung Ihres Produkts unsicher sind, holen Sie frühzeitig Expertenrat ein. 

SBOM verstehen und ihre Rolle in der Compliance 

Eine Software Bill of Materials ist im Kern ein detailliertes Inventar der Softwarekomponenten, vergleichbar mit einer Zutatenliste für Software. Die TR-03183 definiert SBOM als ein maschinenlesbares Dokument, das eine automatisierte Sicherheitsverarbeitung unterstützt, was für das Management der Angriffsfläche von Produkten mit digitalen Elementen entscheidend ist. 

Gesetzliche Mindestanforderung vs. Implementierungs-Benchmark 

Zwei Ebenen, die häufig vermischt werden: 

• Die gesetzliche Mindestanforderung des CRA — die Verordnung verpflichtet Hersteller, die Komponenten und Vulnerabilities ihrer Produkte mit digitalen Elementen zu identifizieren und zu dokumentieren, unter anderem durch die Erstellung einer SBOM in einem gängigen, maschinenlesbaren Format, das mindestens die Top-Level-Abhängigkeiten abdeckt. Das ist das verbindliche Minimum. Das genaue Format und die Elemente werden im Laufe der Zeit durch Durchführungsrechtsakte der Kommission und harmonisierte Normen festgelegt. 
• Der Implementierungs-Benchmark BSI TR-03183 — die TR-03183 ist eine nicht verbindliche BSI-Umsetzungsrichtlinie, die deutlich weiter geht: Sie legt SBOM-Felder, Formate, Hash-Algorithmen und eine Trennung zwischen SBOM- und Vulnerability-Daten über VEX/CSAF fest. Sie ist in drei Teile gegliedert: Teil 1 (allgemeine Anforderungen), Teil 2 (SBOM) und Teil 3 (Vulnerability-Berichte und -Benachrichtigungen) und wird laufend aktualisiert. 

Für deutsche und EU-Hersteller ist die sicherste Planungsannahme, den CRA als gesetzliche Mindestanforderung und die TR-03183 als praktischen Qualitäts-Benchmark zu behandeln — und dabei die harmonisierten Normen und die Durchführungsrechtsakte der Kommission im Blick zu behalten, sobald sie ausreifen. Das Befolgen der TR-03183 begründet keine Konformitätsvermutung; das Befolgen einer im OJEU zitierten harmonisierten Norm hingegen schon. 

Verfügbarkeit ≠ öffentliche Veröffentlichung 

Der CRA verlangt von Herstellern generell nicht, SBOMs öffentlich zu veröffentlichen. Die technische Dokumentation nach Anhang VII — einschließlich SBOM-bezogener Elemente — muss erstellt, gepflegt und den Marktüberwachungsbehörden und Konformitätsbewertungsstellen auf Anfrage zur Verfügung gestellt werden. Hersteller können SBOMs außerdem (in der Regel unter NDA) mit Unternehmenskunden im Rahmen von Vendor-Risk-Prozessen teilen. 

Es gibt eine bemerkenswerte Ausnahme: Die FAQ der Kommission benennt eine spezifische Situation, in der bei bestimmter freier und Open-Source-Software eine Veröffentlichung des Self-Assessments gelten kann. Für den typischen Hersteller kommerzieller Produkte planen Sie mit der SBOM-Verfügbarkeit gegenüber Regulierungsbehörden und vertraglich gebundenen Kunden — nicht mit einer öffentlichen Freigabe. 

Erforderliche SBOM-Elemente nach dem BSI-Profil TR-03183-2 

Nach BSI TR-03183-2 v1.0 (12. Juli 2023) muss eine SBOM, die diese Umsetzungsrichtlinie erfüllen soll, die folgenden Elemente enthalten. (CRA-verbindliche Anforderungen können abweichen, sobald die relevanten Durchführungsrechtsakte und harmonisierten Normen finalisiert sind — die TR-03183-2 selbst ist BSI-Umsetzungsleitfaden, kein verbindliches EU-Recht.) 

• Komponentenname & Version — zur Sicherstellung der Nachverfolgbarkeit von Abhängigkeiten 
• Komponenten-Ersteller (Hersteller-/Lieferanten-URL oder E-Mail) — Identifizierung der Softwarequellen 
• Lizenzinformationen — sowohl deklarierte als auch festgestellte Lizenzen 
• Kryptografischer Hash der ausführbaren Komponente (SHA-256) — eine kryptografisch sichere Prüfsumme der Komponente in ihrer ausführbaren Form, die sicherstellt, dass Sie überprüfen können, ob die einsetzbare Komponente mit der in der SBOM dokumentierten übereinstimmt (gemäß TR-03183-2 v1.0 Abschnitt 5.2.2) 
• Dateieigenschaften — ob die Komponente ausführbar, ein Archiv oder strukturiert ist 
• Zeitstempel — Datum und Uhrzeit der SBOM-Erstellung 
• Dependency Tracking — mindestens bis zur ersten externen Komponente 

Ohne diese Elemente erfüllt eine SBOM nicht das Implementierungsprofil der TR-03183-2 v1.0. Beachten Sie, dass die TR-03183-2 eine BSI-Umsetzungsrichtlinie ist; die rechtliche CRA-Compliance ergibt sich letztlich aus der Verordnung selbst, aus den harmonisierten Normen, sobald sie im OJEU zitiert sind, und aus den Durchführungsrechtsakten der Kommission. 

Wie tief sollte die SBOM gehen? 

Die gesetzliche Mindestanforderung des CRA (Anhang I, Teil I) verlangt eine SBOM, die mindestens die Top-Level-Abhängigkeiten des Produkts abdeckt. Das Implementierungsprofil BSI TR-03183-2 v1.0 geht weiter: Es verlangt eine Liefergegenstands-SBOM, die als Teil des Build-Prozesses erzeugt wird und Abhängigkeiten auf jedem Pfad rekursiv auflöst, mindestens bis einschließlich der ersten Komponente, die nicht mehr Teil des Liefergegenstands ist (Abschnitt 5.1). 

Praktisch bedeutet das: Top-Level-Abhängigkeiten erfüllen die Verordnung in ihrer aktuellen Fassung; das Befolgen der TR-03183-2 bedeutet, tiefer aufzulösen, wobei jede im Liefergegenstand enthaltene Komponente vollständig beschrieben wird, bevor die SBOM an der ersten externen Grenze endet. Dies ist eines der deutlichsten Beispiele dafür, warum CRA-konform ≠ TR-03183-konform ist und warum insbesondere deutsche Hersteller planen, dem BSI-Profil zu folgen statt nur dem reinen CRA-Wortlaut. 

Wie sich das BSI-Profil TR-03183-2 von den US-Mindestelementen (NTIA) unterscheidet 

Organisationen, die mit den US-NTIA-Mindestelementen (National Telecommunications and Information Administration) für SBOMs vertraut sind, fragen sich vielleicht, wie die europäischen Anforderungen im Vergleich abschneiden. Beide Frameworks haben Gemeinsamkeiten, doch das BSI-Profil TR-03183-2 empfiehlt zusätzliche Elemente, die über die US-Basislinie hinausgehen. 

SBOM-Element	NTIA (USA)	TR-03183-2 (BSI-Profil)
Lieferanten-/Erstellername	✓	✓
Komponentenname	✓	✓
Komponentenversion	✓	✓
Abhängigkeitsbeziehungen	✓	✓
Zeitstempel	✓	✓
Eindeutiger Identifikator	✓	✓
Kryptografischer Hash (SHA-256)	–	✓ (BSI-Profil)
Lizenzinformationen	–	✓ (BSI-Profil)
SBOM-URI/Dokument-Namespace	–	✓ (BSI-Profil)
Dateieigenschaften (ausführbar/Archiv)	–	✓ (BSI-Profil)

Hinweis: Die TR-03183-2 ist ein BSI-Implementierungsprofil. Der CRA selbst überlässt die SBOM-Elemente den Durchführungsrechtsakten der Kommission und den harmonisierten Normen. 

Die wichtigsten Unterschiede erklärt

Kryptografischer Hash: Die TR-03183-2 v1.0 verlangt SHA-256-Hashes für alle einsetzbaren Komponenten. Das gewährleistet eine Integritätsprüfung — Sie können nachweisen, dass die Komponente in der Produktion exakt der in der SBOM dokumentierten entspricht. 

Lizenzinformationen: Die europäischen Anforderungen umfassen ausdrücklich sowohl deklarierte als auch festgestellte Lizenzen. Das unterstützt die rechtliche Compliance und das Management geistigen Eigentums über die gesamte Lieferkette hinweg. 

SBOM-URI: Jede SBOM muss einen eindeutigen Dokument-Namespace (URI) haben, der eine eindeutige Identifizierung und Querverweise über Systeme und Organisationen hinweg ermöglicht. 

Dateieigenschaften: Komponenten müssen nach Typ klassifiziert werden (ausführbar, Archiv, Quellcode oder strukturierte Daten), was eine granularere Sicherheitsanalyse unterstützt. 

Was das für Ihre Compliance-Strategie bedeutet

Wenn Ihre Organisation bereits SBOMs nach den NTIA-Richtlinien erstellt, haben Sie eine solide Grundlage — sind aber noch nicht CRA-konform. Das Upgrade auf die TR-03183 erfordert, kryptografische Hashes zu allen Komponenteneinträgen hinzuzufügen, umfassende Lizenzdaten einzubeziehen, eindeutige Dokument-Identifikatoren zu implementieren und die Dateieigenschaften jeder Komponente zu klassifizieren. 

Die meisten modernen SBOM-Tools (Syft, Trivy, CycloneDX CLI) können bei richtiger Konfiguration TR-03183-konforme Ausgaben erzeugen. Entscheidend ist, Ihre Pipeline-Einstellungen und Validierungsprüfungen vor der Frist 2027 anzupassen. 

Gängige SBOM-Formate 

BSI TR-03183-2 v1.0 (Abschnitt 4) verlangt SBOMs in einem der folgenden Formate: 

1. CycloneDX, Version 1.4 oder höher — sicherheitsorientiertes Format, gut geeignet für CRA-konforme Workflows 
2. SPDX (Software Package Data eXchange), Version 2.3 oder höher — weit verbreitet für die Beschreibung von Softwarepaketen und Lizenzierung 

Hinweis zu SWID: SWID-Tags kommen in der TR-03183-2 v1.0 nicht vor und sind nicht Teil des BSI-Implementierungsprofils. SWID kann in Enterprise-Asset-Management-Kontexten, die es bereits nutzen, weiterhin nützlich sein, sollte aber nicht als CRA-/TR-03183-Compliance-Weg herangezogen werden. CycloneDX und SPDX sind die Formate, auf denen die BSI-Richtlinie aufbaut. 

SBOM und VEX (TR-03183-Compliance) 

Eine häufige Frage ist, ob SBOMs selbst Vulnerability-Daten tragen sollten oder ob Vulnerability-Informationen separat übermittelt werden sollten. 

Die BSI TR-03183-2 v1.0 (Abschnitt 3.1) ist hier eindeutig: Eine SBOM enthält keine Vulnerability-Informationen. Der Standard weist ausdrücklich darauf hin, dass die SBOM-Formate selbst die Möglichkeit bieten, Vulnerability-Daten aufzunehmen — erklärt dies jedoch für nicht empfehlenswert. Um festzustellen, ob ein Produkt von einer Vulnerability betroffen ist, empfiehlt das BSI, die Komponentenliste der SBOM mit Vulnerability-Informationsquellen (CVE, Security Advisories) abzugleichen und VEX (Vulnerability Exploitability eXchange) oder Security Advisories zu nutzen, um die Ausnutzbarkeit zu kommunizieren. 

Praktisches Fazit: Nach dem Profil TR-03183-2 halten Sie das Komponenteninventar in der SBOM und liefern Vulnerability-/Ausnutzbarkeitsinformationen separat über VEX oder CSAF (Common Security Advisory Framework) aus. Dies ist die Design-Empfehlung des BSI, kein pauschales Verbot durch die SBOM-Formate selbst — CycloneDX unterstützt mehrere BOM-Typen und SPDX 3.0 verfügt über ein Security-Profil. 

Entwicklungen 2025/26: Standardisierung und Infrastruktur 

Seit dem Inkrafttreten des CRA im Dezember 2024 wurden bei der Implementierungsinfrastruktur erhebliche Fortschritte erzielt: 

Warten Sie nicht auf harmonisierte Normen — verfolgen Sie sie aber genau 

Die harmonisierten Normen des CRA werden im Rahmen des Normungsauftrags M/606 der Kommission entwickelt, der 41 horizontale und produktspezifische Normen umfasst. Der Auftrag wurde am 3. April 2025 von CEN, CENELEC und ETSI offiziell angenommen. Sobald einzelne Normen im Amtsblatt der EU (OJEU) zitiert werden, können sie eine Konformitätsvermutung in Bezug auf die grundlegenden Cybersecurity-Anforderungen des CRA begründen. 

Bis dahin sollten Hersteller mit dem CRA-Text selbst, dem CRA-Leitfaden und der FAQ der Europäischen Kommission, der BSI TR-03183 und den entstehenden CEN-/CENELEC-/ETSI-Entwürfen als praktischem Implementierungs-Stack planen. Mit der CRA-Arbeit zu warten, bis harmonisierte Normen vorliegen, ist keine tragfähige Strategie — die meisten Zeitpläne deuten darauf hin, dass nur ein Teil der M/606-Normen vor Dezember 2027 im OJEU zitiert sein wird. 

Im September 2025 veröffentlichte ETSI die ersten Entwürfe europäischer Normen (EN) zur öffentlichen Konsultation, die technische Normen für Produktkategorien wie Passwortmanager, Netzwerkschnittstellen und Betriebssysteme abdecken. 

ENISA-Infrastruktur 

• European Vulnerability Database (EUVD) — am 13. Mai 2025 gestartet, dient als zentrale Plattform für handlungsrelevante Vulnerability-Informationen in der gesamten EU 
• Single Reporting Platform (SRP) — derzeit in Entwicklung für die Vulnerability- und Incident-Meldung nach Artikel 14 
• EUCC-CRA-Angleichung — ENISA hat Studien veröffentlicht, die analysieren, wie eine Zertifizierung über EUCC die CRA-Compliance nachweisen könnte, mit laufenden Pilotprojekten 

EUVD und SRP sind unterschiedliche Systeme 

Die European Vulnerability Database (EUVD) und die CRA Single Reporting Platform (SRP) werden oft verwechselt. Sie dienen unterschiedlichen Zwecken: 

• EUVD — Infrastruktur für Vulnerability-Transparenz und -Intelligence. ENISA-betrieben, öffentlich zugänglich und funktional vergleichbar mit NVD oder CVE Details. Behandeln Sie sie als eingehende Intelligence-Quelle. 
• SRP — der regulatorische Meldekanal, den Hersteller für ihre Pflichten nach Artikel 14 nutzen müssen. Über die SRP eingereichte Meldungen werden an den benannten CSIRT-Koordinator und an ENISA weitergeleitet. Behandeln Sie sie als ausgehenden regulatorischen Meldekanal. 

In einem CRA-Programm speist die EUVD Ihr Monitoring und Ihr Triage. Die SRP empfängt Ihre Meldungen, wenn eine aktiv ausgenutzte Vulnerability oder ein schwerwiegender Vorfall bestätigt wird. 

Meldung nach Artikel 14: die 24h-/72h-/Abschlussbericht-Uhr 

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Vulnerabilities und schwerwiegende Vorfälle über die ENISA Single Reporting Platform (SRP) melden. Die Taktung ist festgelegt: 

• Frühwarnung — innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat. 
• Vulnerability-/Incident-Meldung — innerhalb von 72 Stunden. 
• Abschlussbericht — für aktiv ausgenutzte Vulnerabilities spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar wird; für schwerwiegende Vorfälle innerhalb eines Monats nach der 72-Stunden-Meldung. 

Entscheidend ist, dass die Meldepflicht nach Artikel 14 auch für Bestandsprodukte gilt. Artikel 69 Absatz 3 enthält eine Ausnahmeregelung: Obwohl die materiellen CRA-Pflichten für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, nur dann greifen, wenn diese Produkte eine wesentliche Änderung erfahren, gelten die Meldepflichten nach Artikel 14 für alle in den Anwendungsbereich fallenden Produkte auf dem Markt — einschließlich solcher, die vor Jahren ausgeliefert wurden. Praktisch bedeutet das, dass Hersteller bis September 2026 — nicht erst bis Dezember 2027 — über SBOM- und Vulnerability-Handling-Fähigkeiten für das bestehende Produktportfolio verfügen müssen. 

Aktualisierungen der BSI-Technischen Richtlinie 

Das BSI entwickelt eine umfassende Technische Richtlinie in drei Teilen: 

• Teil 1: Allgemeine Anforderungen — Leitlinien für Hersteller und Produkte, abgestimmt auf die CRA-Artikel und -Anhänge 
• Teil 2: Software Bill of Materials (SBOM) — formale und inhaltliche Anforderungen an SBOMs 
• Teil 3: Vulnerability-Berichte und -Benachrichtigungen — Verfahren für den Umgang mit eingehenden Vulnerability-Meldungen 

Wie sich SBOM in den breiteren CRA-Pflichtenkanon einfügt 

SBOM ist ein Baustein der CRA-Compliance — sichtbar, weil greifbar und tool-gestützt, aber bei Weitem nicht das Gesamtbild. Ein vollständiges CRA-Programm deckt außerdem ab: 

• CE-Kennzeichnung — Produkte mit digitalen Elementen müssen die CE-Kennzeichnung tragen, gestützt durch eine EU-Konformitätserklärung (Anhang V). 
• Technische Dokumentation (Anhang VII) — ein strukturiertes Dokumentenset, das Risikobewertung, Design- und Entwicklungsinformationen, Vulnerability-Handling-Verfahren und Komponenteninventar umfasst (wo die SBOM angesiedelt ist). 
• Vulnerability Handling (Artikel 13) — Hersteller müssen einen Vulnerability-Handling-Prozess einrichten und betreiben, ähnlich einer PSIRT-Funktion: Intake, Triage, Fix, Disclosure, Kundenbenachrichtigung. 
• Meldepflichten (Artikel 14) — wird eine aktiv ausgenutzte Vulnerability entdeckt, müssen Hersteller über die ENISA Single Reporting Platform innerhalb von 24 Stunden eine Frühwarnung, innerhalb von 72 Stunden eine Vulnerability-Meldung und innerhalb von 14 Tagen einen Abschlussbericht einreichen. Für schwerwiegende Vorfälle gilt eine ähnliche Taktung. 
• Supportzeitraum — Hersteller müssen einen Supportzeitraum festlegen, der die erwartete Nutzungsdauer des Produkts widerspiegelt. Der Supportzeitraum beträgt mindestens fünf Jahre, es sei denn, das Produkt wird voraussichtlich kürzer als fünf Jahre genutzt; in diesem Fall kann er der erwarteten Nutzungsdauer entsprechen. SBOM bildet hierfür die unmittelbare Grundlage: Man kann nicht patchen, was man nicht inventarisieren kann. 
• Rollenaufteilung — unterschiedliche Pflichten gelten für Hersteller, Importeure, Händler und Bevollmächtigte. Die eigene Rolle falsch zu bestimmen, ist ein häufiger Compliance-Fehler im EU-Produktrecht. 
• Open Source Steward — eine neue CRA-Kategorie. Stewards (Organisationen, die die Entwicklung von in kommerziellen Produkten genutzter OSS systematisch unterstützen) tragen ein leichteres, aber reales Pflichtenset, das sich von dem der Hersteller unterscheidet. 
• SBOM ist das Fundament, das Vulnerability Handling, Meldung und Supportzeitraum betreibbar macht. Sie ist notwendig, aber nicht hinreichend für die CRA-Compliance. 

SBOMs in CI/CD-Pipelines integrieren 

SBOMs sollten in den Software-Lebenszyklus integriert werden, sodass sie bei jeder Build-Stufe automatisch erzeugt und aktualisiert werden. Durch kontinuierliches Monitoring der Abhängigkeiten und die Validierung von SBOMs mit Tools wie Syft und Trivy können Organisationen Sicherheitsrisiken vor dem Deployment verhindern. Sichere Build-Pipelines spielen eine entscheidende Rolle bei der Abwehr von Software-Supply-Chain-Bedrohungen und unterstützen den Produktlebenszyklus. 

Die BSI TR-03183 (Umsetzungsleitfaden) empfiehlt, SBOMs in sichere Softwareentwicklungs-Pipelines zu integrieren, um eine durchgängige Nachverfolgbarkeit zu gewährleisten. 

Best Practices für die SBOM-Integration 

Eine effektive SBOM-Implementierung beginnt mit Automatisierung. Organisationen sollten SBOMs bei jeder Build-Stufe automatisch erzeugen, sodass jedes Release eine genaue Momentaufnahme aller Komponenten festhält. Dependency-Tracking-Tools wie Syft, Grype und OWASP Dependency-Check helfen dabei, Vulnerabilities zu erkennen, bevor das Deployment die Produktion erreicht. Um die Integrität Ihrer Software-Supply-Chain weiter zu stärken, setzen Sie das Framework Supply Chain Levels for Software Artifacts (SLSA) für sichere Builds ein und signieren Sie alle SBOMs kryptografisch mit Tools wie Sigstores Cosign. 

Vom Commit zum Deployment: ein Beispiel-Workflow 

Eine gut konzipierte Pipeline verzahnt die SBOM-Generierung nahtlos mit dem Entwicklungslebenszyklus. Wenn Entwickler Code committen, löst die CI/CD-Pipeline automatisch die SBOM-Generierung aus. Während des Build-Prozesses wird diese SBOM integriert und validiert, was vollständige Transparenz über alle Abhängigkeiten sicherstellt. Anschließend analysieren Security-Tools die SBOM, um potenzielle Risiken zu identifizieren, bevor der Build weiterläuft. Nach der Freigabe werden sowohl die finalen Build-Artefakte als auch die begleitende SBOM kryptografisch signiert. Beim Deployment reist die signierte SBOM mit dem Release mit und ermöglicht so regulatorische Audits sowie einen überprüfbaren Nachweis darüber, was genau ausgeliefert wurde. 

Dieser Ansatz stellt Compliance sicher, minimiert zugleich Sicherheitsrisiken und unterstützt die langfristige Software-Resilienz. 

Kryptografisches Hashing und Signieren für SBOM-Integrität 

Die Integrität einer SBOM sicherzustellen, ist ebenso wichtig wie sie überhaupt zu haben. Ohne geeignete Schutzmaßnahmen könnte eine SBOM manipuliert werden, was das Vertrauen untergräbt, das sie eigentlich schaffen soll. Code Signing ermöglicht es Entwicklern, mithilfe kryptografischer Signaturen die Authentizität von Software zu verifizieren, während die Checksum-Validierung mithilfe von Hash-Funktionen wie SHA-256 sicherstellt, dass Dateien unverändert bleiben. Für die SBOM selbst ermöglichen Tools wie Sigstores Cosign Organisationen, digitale Signaturen anzubringen, die belegen, dass das Dokument seit der Erstellung nicht verändert wurde. Zusammen stehen diese Techniken im Einklang mit den im CRA verankerten Secure-by-Default-Prinzipien. 

Sichere Software-Build-Pipelines und SBOM-Integration 

Damit eine SBOM wirklich wirksam ist, muss sie in sichere Entwicklungs-Pipelines eingebettet sein, statt als nachträgliche Ergänzung aufgesetzt zu werden. Reproducible Builds stellen sicher, dass derselbe Quellcode stets identische Ausgaben erzeugt, was es ermöglicht, zu verifizieren, dass ausgelieferte Binärdateien mit ihrer angegebenen Herkunft übereinstimmen. Das Tracking der Build Provenance, gestützt durch Frameworks wie SLSA, liefert einen auditierbaren Nachweis darüber, wo und wie Software gebaut wurde. Schließlich verhindern Ephemeral Build Environments — temporäre, saubere Umgebungen, die für jeden Build hochgefahren und danach zerstört werden —, dass persistente Bedrohungen die Pipeline mit der Zeit kompromittieren. 

Warum SBOM für kritische Branchen wichtig ist 

Mit dem CRA sind SBOMs nicht länger optional — Branchen wie Energie, Gesundheitswesen, Finanzen und Verkehr verlassen sich auf digitale Produkte, die strenge regulatorische Standards erfüllen müssen. Ohne SBOM-Compliance riskieren Organisationen Sanktionen wegen Nichteinhaltung. SBOM stärkt die Resilienz, indem sie: 

• Transparenz über Drittanbieter-Komponenten schafft, um Supply-Chain-Risiken zu reduzieren 
• ein proaktives Vulnerability Management durch automatisierte Security Scans unterstützt 
• die Incident Response erleichtert, indem betroffene Komponenten schnell identifiziert werden 
• die Herkunft und Authentizität von Software durch kryptografisches Signieren sicherstellt 

Diese Praktiken sind besonders entscheidend für alle Unternehmen, die Produkte mit digitalen Elementen auf dem EU-Markt anbieten, unabhängig von ihrem Standort. 

Für wen gilt der CRA? 

Der CRA hat einen breiten Anwendungsbereich und deckt nahezu alle Hardware- und Softwareprodukte ab, die mit einem anderen Gerät oder Netzwerk verbunden werden können: 

• Alle Hardware- und Softwareprodukte mit digitalen Elementen, die in der EU verkauft werden 
• Einschließlich Lösungen zur Fernverarbeitung von Daten 
• Gilt unabhängig davon, wo das Produkt hergestellt wird 
• Deckt sowohl B2C- als auch B2B-Produkte ab 
• Produkte, die gegen Entgelt oder kostenlos bereitgestellt werden 

Open-Source-Software und der CRA 

Die Verwendung von Open-Source-Software befreit ein kommerzielles Produkt nicht von den CRA-Anforderungen. Wenn Sie Open-Source-Komponenten in ein Produkt mit digitalen Elementen integrieren, das Sie auf dem EU-Markt in Verkehr bringen, sind Sie weiterhin für die Sicherstellung der Compliance verantwortlich, einschließlich Vulnerability Management und SBOM. 

Einige rein community-getriebene Open-Source-Projekte ohne kommerzielle Aktivität fallen außerhalb der direkten CRA-Pflichten. Sobald sie jedoch in ein kommerzielles Produkt mit digitalen Elementen integriert werden, werden sie Teil der Verantwortung des Herstellers. 

Nennenswerte Ausnahmen 

Der CRA nimmt Sektoren aus, die bereits durch eigene cybersecurity-relevante Regelungen geregelt sind — insbesondere Automotive (UN R155/R156), Medizinprodukte (MDR/IVDR), Luftfahrt und Verteidigung. SaaS ist differenzierter zu betrachten: Eigenständige SaaS fällt im Allgemeinen außerhalb des CRA-Produktrahmens, doch Lösungen zur Fernverarbeitung von Daten, die integraler Bestandteil eines Produkts mit digitalen Elementen sind, bleiben im Anwendungsbereich. NIS2 kann parallel für qualifizierte SaaS-Anbieter gelten, abhängig von Art der Einrichtung, Sektor und Größe — es ist kein pauschaler Ersatz für den CRA. 

Warum das über die CRA-Bußgelder hinaus wichtig ist 

CRA-Compliance ist nicht nur ein regulatorisches Häkchen. Die überarbeitete Produkthaftungsrichtlinie — Richtlinie (EU) 2024/2853, angenommen am 23. Oktober 2024 — muss bis zum 9. Dezember 2026 in nationales Recht umgesetzt werden und gilt für Produkte, die nach diesem Datum in Verkehr gebracht oder in Betrieb genommen werden. Die Richtlinie schließt Software ausdrücklich in die Definition von „Produkt“ ein, und ihre Erwägungsgründe machen deutlich, dass Cybersecurity-Vulnerabilities und das Versäumnis, notwendige Sicherheitsupdates bereitzustellen, ein Produkt im Sinne der Haftung fehlerhaft machen können. 

Praktische Konsequenz: Schlechte SBOM-Qualität, schwaches Vulnerability Handling und versäumte Sicherheitsupdates können gleichzeitig an zwei Fronten zu einer Haftung führen — CRA-Geldbußen und Marktüberwachungsmaßnahmen nach öffentlichem Recht sowie zivilrechtliche Haftungsansprüche nach nationalem Produkthaftungsrecht, wie es aus der PLD 2024/2853 umgesetzt wird. SBOM und Vulnerability Handling sind nicht nur regulatorische Hygiene; sie sind Beweismittel in einem Anspruch wegen eines fehlerhaften Produkts. 

Was der CRA speziell für den deutschen Markt bedeutet 

Für Produkte, die auf dem deutschen Markt in Verkehr gebracht werden, sind neben dem CRA selbst drei zusätzliche Ebenen relevant: 

• BSI-Marktaufsicht — das BSI positioniert sich als Marktüberwachungsbehörde für Teile des CRA. Seine bisherige Arbeit an der TR-03183 zeigt, worauf sich seine Durchsetzungsaufmerksamkeit voraussichtlich konzentrieren wird. 
• Rolle der BNetzA — die Bundesnetzagentur behält die Marktüberwachung für Funkanlagen im Rahmen der RED, und diese Zuständigkeit überträgt sich auf Produkte im Übergangsfenster von der RED zum CRA (1. August 2025 bis 10. Dezember 2027). 
• Wechselwirkung mit IT-SiG 2.0 / KRITIS — Betreiber kritischer Infrastrukturen in Deutschland tragen bereits Pflichten nach dem IT-Sicherheitsgesetz 2.0 und dem BSIG. CRA-regulierte Produkte, die in KRITIS-Umgebungen geliefert werden, sehen sich mit einem gestapelten Pflichtenset konfrontiert: CRA-Konformität auf Produktebene beim Hersteller plus KRITIS-Pflichten auf Betreiberebene weiter unten in der Kette. Lieferantenauswahl und vertragliche Weitergabe (Flow-down) werden damit entscheidend. 

CLOUDYRION berät deutsche Hersteller zur praktischen Wechselwirkung dieser Regime — insbesondere dort, wo Produkte mit digitalen Elementen in KRITIS-Sektoren verkauft werden. 

Beschaffungs-Checkliste: Was Sie von Lieferanten für CRA-fähige SBOMs verlangen sollten 

Wenn Sie Lieferanten von Produkten mit digitalen Elementen bewerten oder onboarden, verlangen Sie als Teil der vertraglichen Liefergegenstände Folgendes: 

• Maschinenlesbare SBOM pro Release (CycloneDX oder SPDX) 
• Klare Komponentenidentifikation: Name, Version, Lieferant, Abhängigkeitsbeziehung 
• Angegebene Abhängigkeitstiefe (nur Top-Level vs. vollständiger transitiver Graph) 
• Kryptografische Hashes für einsetzbare Komponenten 
• Lizenz-Metadaten für jede Komponente 
• Vulnerability-Handling-SLAs (Zeitrahmen für Triage, Fix, Disclosure) 
• VEX- oder CSAF-Status-Feeds für fortlaufende Aussagen zur Ausnutzbarkeit 
• Benachrichtigungszusagen, die es Ihnen ermöglichen, die 24-Stunden-Meldefrist des CRA für nachgelagert entdeckte, aktiv ausgenutzte Vulnerabilities einzuhalten 
• Für kritische Lieferanten: ein vertragliches Recht, die SBOM-Qualität gegen das Profil TR-03183-2 oder, sobald verfügbar, gegen die anwendbare harmonisierte Norm zu validieren 

Diese Klauseln übersetzen die Herstellerpflichten des CRA in Lieferantenpflichten — genau das, was Enterprise-Beschaffung und CISOs vor September 2026 operationalisieren müssen. 

Nützliche externe Ressourcen 

• EU Commission CRA Implementation Page 
• BSI Cyber Resilience Act Overview 
• OpenSSF Free CRA Course (LFEL1001) 
• European Vulnerability Database (EUVD)