CRA SBOM Compliance Checkliste 2026

Der CRA (Verordnung (EU) 2024/2847) trifft nach Schätzungen der Europäischen Kommission rund 11.000 Hersteller in Deutschland, die Produkte mit digitalen Elementen auf dem EU-Markt anbieten. Für die meisten davon ist die Software Bill of Materials ein neues regulatorisches Artefakt, das sich weder mit einer Excel-Tabelle noch mit einem einmaligen Audit abbilden lässt. Die folgende Checkliste strukturiert den Weg zur CRA-konformen SBOM-Praxis in fünf Phasen — jede mit konkreten Arbeitspaketen, die ein Projektteam direkt in Tickets übersetzen kann.

Kerndaten zur CRA-SBOM-Compliance

Betroffene Hersteller in der EU: geschätzt 16.000+ (Kommissions-Impact-Assessment)

Bußgeldrahmen: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes

Meldepflicht an CSIRT (DE: BSI): ab 11. September 2026

Volle Anwendung inkl. SBOM-Pflicht: ab 11. Dezember 2027

Aufbewahrungspflicht: mindestens 5 Jahre oder erwartete Nutzungsdauer

Reaktionszeit bei aktiv ausgenutzter Schwachstelle: 24 Stunden (Erstmeldung an CSIRT)

Phase 1

Bestandsaufnahme — Produktlandschaft erfassen (Q2 2026)

Bevor eine SBOM erzeugt werden kann, muss klar sein, welche Produkte überhaupt unter den CRA fallen. Das klingt trivial, ist es aber nicht: Viele Unternehmen haben keine vollständige Liste ihrer Produkte mit digitalen Elementen, insbesondere wenn Firmware, Embedded-Komponenten oder OEM-Software im Spiel sind.

Alle Produkte mit digitalen Elementen identifizieren (Hardware mit Software, Standalone-Software, Firmware)
Jedes Produkt nach CRA-Kategorie klassifizieren: Standard, wichtig Klasse I, wichtig Klasse II, kritisch (Anhang III und IV)
Prüfen, ob sektorale Ausnahmen greifen (Medizinprodukte, Fahrzeuge, Luftfahrt, Verteidigung)
Für jedes Produkt den verantwortlichen Hersteller im Sinne des CRA bestimmen (Art. 3 Nr. 16)
Unterstützungszeitraum pro Produkt festlegen (Art. 13 Abs. 8: erwartete Nutzungsdauer, mindestens 5 Jahre)
Bestehendes Abhängigkeitsmanagement bewerten: Wird bereits mit Lock-Files, Manifest-Dateien oder Dependency-Scans gearbeitet?

Das Ergebnis dieser Phase ist ein Produktregister mit CRA-Klassifizierung. Ohne dieses Register fehlt die Grundlage für die Konformitätsbewertung nach Art. 32 — und damit für die CE-Kennzeichnung.

Phase 2

Toolchain aufsetzen — Format, Generator, Signierung (Q2–Q3 2026)

Die SBOM-Toolchain besteht aus drei Elementen: einem Formatstandard, einem Generator und einem Signierungsmechanismus. Alle drei müssen aufeinander abgestimmt sein, bevor die erste produktive SBOM erzeugt wird.

SBOM-Format wählen: CycloneDX (OWASP, VEX-Integration) oder SPDX (ISO/IEC 5962:2021, stärkere Lizenz-Metadaten)
SBOM-Generator in CI/CD integrieren: Syft (Container), cdxgen (Node.js, Java, polyglott), Trivy (Container + Filesystem), CycloneDX-Plugins (Maven, Gradle, pip)
Namespace- und Versionierungsschema definieren (Package-URL/purl als Identifier, Produkt-Version als SBOM-Referenz)
Signierung mit cosign einrichten — SBOM wird zusammen mit dem Release-Artefakt signiert
Artefakt-Repository für SBOM-Ablage auswählen (OCI Registry, Nexus, Artifactory)
Testlauf: Für ein Pilotprodukt SBOM erzeugen, signieren, im Repository ablegen und mit Grype/Trivy gegen NVD scannen

Empfehlung für Greenfield-Projekte: CycloneDX, weil die integrierte VEX-Unterstützung den Schwachstellen-Meldeprozess in Phase 4 erheblich vereinfacht. Wer bereits SPDX im Einsatz hat (z. B. Yocto-basierte Embedded-Systeme), bleibt bei SPDX — ein Formatwechsel bringt mehr Friction als Nutzen.

Phase 3

SBOM-Prozess etablieren — Automatisierung und Aufbewahrung (Q3 2026)

Eine manuell gepflegte SBOM ist regulatorisch wertlos. Der CRA verlangt Nachvollziehbarkeit: Welche Komponenten waren in welchem Build, wann wurde die SBOM erzeugt, wer hat sie signiert. Das geht nur mit einem vollständig automatisierten Prozess.

SBOM-Erzeugung bei jedem Build automatisieren (CI-Pipeline-Step, kein manueller Eingriff)
SBOM an Release-Artefakt koppeln: gleiche Versionsnummer, gleicher Signaturzyklus
Versionierung im Artefakt-Repository sicherstellen (jede SBOM eindeutig einem Produkt-Release zugeordnet)
Aufbewahrungspflicht implementieren: SBOMs mindestens 5 Jahre oder über die Unterstützungszeit archivieren
Internen vollständigen Abhängigkeitsgraph pflegen (transitive Abhängigkeiten), auch wenn die ausgelieferte SBOM nur Top-Level abdeckt
Vulnerability-Monitoring anbinden: SBOM-Daten fließen automatisch in Schwachstellen-Scanner (Dependency-Track, Grype, Trivy)

Typischer Fehler in dieser Phase: Die SBOM wird im CI erzeugt, aber nirgendwo langfristig archiviert. CI-Artefakte haben oft nur 30 Tage Retention — das reicht für die 5-Jahres-Pflicht nicht annähernd aus. Die Archivierung gehört ins Release-Management, nicht ins CI-System.

Phase 4

Schwachstellen-Meldeprozess produktiv schalten (bis 11. September 2026)

Die Meldepflichten nach Art. 14 CRA greifen bereits ab dem 11. September 2026 — 15 Monate vor der vollen CRA-Anwendung. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an das zuständige CSIRT melden. In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) als nationale Koordinierungsstelle benannt.

SBOM als Input für CSIRT-Meldung nutzbar machen: Bei einer Schwachstelle in Komponente X sofort ermitteln, welche Produkte und Versionen betroffen sind
24-Stunden-Reaktionskette definieren: Schwachstelle erkannt → betroffene Produkte identifiziert (via SBOM) → Erstmeldung an BSI
Meldewege zum BSI einrichten (ENISA-Meldeplattform, voraussichtlich über das Single Reporting Platform ab September 2026)
VEX-Dokumente (Vulnerability Exploitability eXchange) für jede gemeldete Schwachstelle erstellen: Produkt betroffen / nicht betroffen / in Prüfung
Eskalationsprozess intern dokumentieren: Wer entscheidet über die Ausnutzbarkeit? Wer meldet? Wer informiert Kunden?
Übungsmeldung durchspielen: Simulierte Schwachstelle in einer Komponente, volle Prozesskette bis zur BSI-Meldung testen

CRA-Fristen auf einen Blick

11. September 2026: Schwachstellen-Meldepflichten werden wirksam (Art. 14 CRA)

11. September 2026: Marktüberwachungsbehörden nehmen Tätigkeit auf (Art. 52 CRA)

11. Dezember 2027: Volle CRA-Anwendung — SBOM-Pflicht, technische Dokumentation, CE-Konformität

Aufbewahrung: Technische Dokumentation (inkl. SBOM) mindestens 10 Jahre nach Inverkehrbringen (Art. 13 Abs. 12)

Reaktionszeit: 24 Stunden Erstmeldung bei aktiv ausgenutzter Schwachstelle, 72 Stunden detaillierte Folgemeldung

Phase 5

Vollständige Dokumentation und CE-Konformität (bis 11. Dezember 2027)

Ab dem 11. Dezember 2027 dürfen nur noch CRA-konforme Produkte in der EU in Verkehr gebracht werden. Die SBOM ist dabei ein Element der technischen Dokumentation nach Anhang II. Ohne vollständige technische Dokumentation gibt es keine Konformitätserklärung — und ohne Konformitätserklärung keine CE-Kennzeichnung.

SBOM in technische Dokumentation nach Anhang II integrieren
Konformitätsbewertung nach Art. 32 durchführen: Standardprodukte per Selbstbewertung (Modul A), Klasse I über harmonisierte Normen oder Drittprüfung, Klasse II und kritisch zwingend durch notifizierte Stelle
EU-Konformitätserklärung nach Anhang V erstellen
CE-Kennzeichnung anbringen (Art. 28)
Koordinierte Schwachstellenoffenlegung (Coordinated Vulnerability Disclosure, CVD) nach Art. 15 einrichten
Kontaktdaten für Schwachstellenmeldungen durch Dritte veröffentlichen (Art. 13 Abs. 6)

Für Unternehmen, deren Produkte in die Klassen „wichtig Klasse II" oder „kritisch" fallen, ist die Vorlaufzeit entscheidend: Notifizierte Stellen haben begrenzte Kapazitäten, und die ersten Audits nach harmonisierten Normen werden voraussichtlich erst Mitte 2027 möglich sein. Wer spät dran ist, riskiert Marktzugangsverzögerungen.

Häufig gestellte Fragen

Welche Produkte fallen unter die SBOM-Pflicht des CRA?

Unter die SBOM-Pflicht fallen alle „Produkte mit digitalen Elementen", die in der EU in Verkehr gebracht werden. Das umfasst Hardware mit eingebetteter Software, eigenständige Software, Firmware und SaaS-Komponenten, die Teil eines lokal installierten Produkts sind. Der CRA unterscheidet drei Kategorien: Standardprodukte (Selbstbewertung möglich), wichtige Produkte Klasse I und II (Konformitätsbewertung durch harmonisierte Normen bzw. Dritte) und kritische Produkte (zwingend Drittprüfung). Ausgenommen sind rein cloudbasierte SaaS-Dienste und Produkte, die bereits unter sektorale Regulierung fallen, etwa Medizinprodukte oder Fahrzeuge.

Reicht eine einmalige SBOM-Erstellung für die CRA-Compliance?

Nein. Eine SBOM ist an einen konkreten Build gebunden und muss bei jedem Release neu erzeugt werden. Der CRA verlangt zusätzlich, dass SBOMs über die gesamte Unterstützungszeit des Produkts aufbewahrt werden — mindestens fünf Jahre oder die erwartete Nutzungsdauer, je nachdem was länger ist. Darüber hinaus muss die SBOM als Input für den Schwachstellen-Meldeprozess nutzbar sein: Wird in einer enthaltenen Komponente eine Schwachstelle bekannt, muss der Hersteller innerhalb von 24 Stunden an das zuständige CSIRT (in Deutschland: BSI) melden können, welche Produkte betroffen sind.

Was passiert, wenn ein Unternehmen die SBOM-Pflicht nicht einhält?

Der CRA sieht Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem welcher Betrag höher ist. Die Marktüberwachungsbehörden der Mitgliedstaaten — in Deutschland voraussichtlich das BSI zusammen mit der Bundesnetzagentur — können darüber hinaus Produkte vom Markt nehmen lassen oder Vertriebsverbote aussprechen. Für Hersteller bedeutet eine fehlende SBOM nicht nur ein Bußgeldrisiko, sondern potenziell auch einen Marktzugangsverlust für den gesamten EU-Binnenmarkt.