SBOM-Pflicht nach CRA: Was ab 11. Dezember 2027 gilt — und warum NIS2 Artikel 21 sie nie erwähnt

Die Software-Stückliste steht im Cyber Resilience Act an genau einer bindenden Stelle: Anhang I Teil II Nummer 1. Sie steht nicht in Artikel 21 der NIS2-Richtlinie, nicht in § 30 BSIG und nicht in der Durchführungsverordnung (EU) 2024/2690. Wir haben die deutschen Amtsblattfassungen beider NIS2-Texte durchsucht: null Treffer für „Stückliste“, null für „SBOM“ [2][3]. Wer die SBOM als NIS2-Pflicht verkauft, verwechselt zwei Regelungsebenen — und wer sie deshalb als „für uns nicht relevant“ abhakt, übersieht, dass sie über den Einkaufsvertrag trotzdem bei ihm ankommt.

Die Trennlinie ist sauber zu ziehen, und sie entscheidet über Ihren Aufwand. Dieser Beitrag ergänzt den Hub NIS2 und der Cyber Resilience Act um die Ebene der Produktdokumentation.

Gilt die SBOM-Pflicht für Sie? Der Schnelltest

Die SBOM-Pflicht hängt nicht an Ihrer NIS2-Einstufung, sondern an einer einzigen Frage: Bringen Sie ein Produkt mit digitalen Elementen unter Ihrem Namen oder Ihrer Marke auf den Unionsmarkt? Artikel 3 Nummer 13 CRA erfasst das ausdrücklich, „sei es gegen Bezahlung, zur Monetarisierung oder unentgeltlich“ [1] — kostenlose Software im geschäftlichen Kontext eingeschlossen.

Ihre Rolle	SBOM-Pflicht?	Rechtsgrundlage	Ab wann
Hersteller eines Produkts mit digitalen Elementen	Ja, bindend	CRA Anhang I Teil II Nr. 1 [1]	11.12.2027
Betreiber, besonders wichtige oder wichtige Einrichtung (kein Hersteller)	Nein — keine eigene SBOM-Pflicht	§ 30 Abs. 2 BSIG nennt sie nicht [4]	—
Einrichtung der 11 CIR-Arten (Cloud, MSP, MSSP, DNS, Vertrauensdienste …)	Nein, aber: Komponentenbeschreibung im Einkaufsverfahren	CIR Anhang 6.1.2 Buchst. c [3]	läuft bereits
Hersteller von Medizinprodukten (MDR/IVDR)	Nein — CRA ausgeschlossen	CRA Art. 2 Abs. 2 [1]	—
Verwalter quelloffener Software (Open-Source-Stiftung o. Ä.)	Nein — eigenes, leichteres Regime	CRA Art. 3 Nr. 14 [1]	—

Die dritte Zeile ist die interessante. Ein Cloud-Anbieter schuldet keine eigene Stückliste — muss aber im Beschaffungsverfahren Informationen zu den verwendeten Komponenten seiner Zulieferer einholen. Dazu unten mehr.

Was der CRA wörtlich verlangt — und was Erwägungsgrund 77 daraus macht

Anhang I Teil II Nummer 1 der Verordnung (EU) 2024/2847 verpflichtet Hersteller, „Schwachstellen und Komponenten der Produkte mit digitalen Elementen zu ermitteln und zu dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“ [1]. Zwei Wörter tragen die eigentliche Pflicht: ermitteln und dokumentieren. Die SBOM ist der benannte Weg dorthin, nicht der Selbstzweck — eine Stückliste, die niemand gegen eine Schwachstellendatenbank hält, erfüllt den Zweck der Norm nicht.

Artikel 3 Nummer 39 definiert die Software-Stückliste als „formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“ [1]. Entscheidend ist der zweite Halbsatz: gefordert sind nicht nur Komponenten, sondern Beziehungen — ein Abhängigkeitsgraph, keine Liste.

Veröffentlichen müssen Sie sie nicht. Erwägungsgrund 77 stellt fest: „Die Hersteller sollten nicht verpflichtet sein, die Software-Stückliste zu veröffentlichen“ [1]; das BSI formuliert es auf seiner CRA-Themenseite als „Die SBOM muss nicht veröffentlicht werden“ [11]. Erwägungsgründe sind allerdings Auslegungshilfen ohne eigene Bindungswirkung — dasselbe gilt für die dort verwendete Formulierung „gegebenenfalls eine Software-Stückliste aufstellen“. Maßgeblich ist der Anhangtext, und der kennt kein „gegebenenfalls“.

Wo die Stückliste stattdessen landet, regelt Anhang VII gleich zweifach — ein Detail, das in den meisten Ratgebern fehlt. Nummer 2 Buchstabe b zählt sie zum Pflichtinhalt der technischen Dokumentation („einschließlich der Software-Stückliste“), Nummer 8 nennt sie zusätzlich als Unterlage, die „auf begründetes Verlangen der Marktüberwachungsbehörde“ vorzulegen ist [1]. Praktisch heißt das: Sie halten sie ohnehin vor, und die Behörde kann sie gezielt anfordern. Geben Sie die SBOM freiwillig an Kunden weiter, verlangt Anhang II Nummer 9, in den Nutzerinformationen anzugeben, wo sie abrufbar ist [1].

Die Sanktionsebene ist unmissverständlich: Verstöße gegen die grundlegenden Anforderungen in Anhang I fallen nach Artikel 64 Absatz 2 in die höchste Bußgeldkategorie — bis zu 15 000 000 EUR oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist [1].

Warum NIS2 Artikel 21 die Software-Stückliste nie erwähnt

Der Grund ist keine Lücke, sondern Systematik: NIS2 reguliert Organisationen, der CRA reguliert Produkte. Artikel 21 Absatz 2 Buchstabe d verlangt „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern“; Buchstabe e verlangt „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen“ [2]. Beides adressiert Beziehungen und Prozesse — nie den Inhalt eines Produkts. § 30 Absatz 2 Nummern 4 und 5 BSIG übernehmen diese Formulierungen fast wörtlich [4]. Die zehn Maßnahmenkategorien im Detail behandelt unser Leitfaden zu den NIS2-Anforderungen.

Zwei Stellen bringen die Komponentenebene trotzdem in die NIS2-Welt:

Erstens Artikel 21 Absatz 3. Einrichtungen müssen bei Lieferantenentscheidungen „die Gesamtqualität der Produkte und der Cybersicherheitspraxis ihrer Anbieter und Diensteanbieter, einschließlich der Sicherheit ihrer Entwicklungsprozesse“ berücksichtigen [2]. Eine belastbare, aktuelle SBOM ist dafür ein naheliegender Nachweis — die Richtlinie schreibt ihn aber nicht vor. Wie diese Bewertung praktisch aufgesetzt wird, zeigt der Leitfaden zur NIS2-Lieferkettensicherheit.

Zweitens die Durchführungsverordnung (EU) 2024/2690. Für die elf dort geregelten Einrichtungsarten — Cloud- und Rechenzentrumsanbieter, MSP, MSSP, DNS-Dienste, TLD-Registries, CDN, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste — schreibt Anhang 6.1.2 Buchstabe c vor, dass die Beschaffungsverfahren „Informationen zur Beschreibung der Hardware- und Softwarekomponenten, die in den IKT-Diensten oder -Produkten verwendet werden“ umfassen [3]. Das Wort SBOM fällt nicht, in der Sache ist es dieselbe Information. Zwei Einschränkungen gehören dazu: Die Regel greift nach Nummer 6.1.1 nur für Komponenten, „die für die Sicherheit der Netz- und Informationssysteme … unverzichtbar sind“, und sie beruht auf der eigenen Risikobewertung [3]. Nach § 30 Absatz 3 BSIG hat der CIR für diese elf Arten Vorrang [4] — Details in unserem Leitfaden zur NIS2-Durchführungsverordnung.

Für Betreiber heißt das: Die Stückliste kommt nicht aus dem Gesetz, sondern aus dem Vertrag. Welche Klauseln das tragen, behandeln die NIS2-Lieferantenverträge.

Die einzige institutionelle Verbindung zwischen beiden Regimen auf SBOM-Ebene steht in Artikel 13 Absatz 25 CRA: Marktüberwachungsbehörden können für bestimmte Produktkategorien Stücklisten anfordern, die Gruppe für administrative Zusammenarbeit (ADCO) wertet sie zu einer unionsweiten Abhängigkeitsbewertung aus — und legt „der gemäß Artikel 14 der Richtlinie (EU) 2022/2555 eingesetzten Kooperationsgruppe einen Bericht“ vor [1]. Erwägungsgrund 22 ergänzt, dass die Weitergabe „in anonymisierter und aggregierter Form“ erfolgen soll [1]. Ihre Stückliste kann also in einer NIS2-Lagebewertung landen — anonymisiert, aber sie kann.

Wie tief muss die Stückliste reichen? Zwei Untergrenzen, die nicht deckungsgleich sind

Der CRA nennt eine Untergrenze: „zumindest die obersten Abhängigkeiten“ [1]. Das ist wenig. Ein Dienst mit 40 direkt deklarierten Bibliotheken erfüllt sie mit 40 Einträgen — die transitiv nachgezogenen Artefakte, die den weitaus größeren Teil des Abhängigkeitsbaums ausmachen, tauchen darin nicht auf. Genau dort sitzen die Komponenten, die in einer Schwachstellenmeldung als Erstes auftauchen und in keiner Beschaffungsliste stehen.

Die BSI-Richtlinie TR-03183-2 zieht die Grenze anders. Sie verlangt rekursive Auflösung auf jedem Pfad mindestens bis einschließlich der ersten Komponente außerhalb des Lieferumfangs [5]. Alles, was Sie selbst ausliefern, ist damit vollständig beschrieben; erst an der Außengrenze darf abgebrochen werden — und auch dort muss die erste externe Komponente noch eindeutig identifiziert sein, damit sich zwei Stücklisten verketten lassen.

Detaillierungsgrad (TR-03183-2)	Was enthalten ist	Erfüllt CRA-Minimum?
Top-level SBOM	nur die direkten Abhängigkeiten des Produkts	Ja (genau die Untergrenze)
n-level SBOM	rekursiv bis zur Tiefe n	Ja
Transitive SBOM	vollständig bis zur ersten Fremdkomponente je Pfad	Ja
Delivery item SBOM	vollständig bis zur ersten Komponente außerhalb des Lieferumfangs	Ja — BSI-Untergrenze
Complete SBOM	vollständige rekursive Auflösung ohne Abbruch	Ja

Wichtig für die Einordnung: Die TR-03183-2 ist eine Technische Richtlinie, kein Gesetz. Bindend wird sie erst, wenn sie ein Vertrag, eine Ausschreibung oder eine Konformitätsbewertung in Bezug nimmt. Rechtlich reicht die Top-Level-Stückliste. Praktisch ist sie der schwächste Nachweis, den Sie einem Prüfer oder Großkunden vorlegen können — und die TR ist der einzige veröffentlichte deutsche Maßstab, an dem sich Beschaffungsstellen orientieren.

Ergänzend unterscheidet die Richtlinie sechs Erstellungszeitpunkte — Design-, Source-, Build-, Analysed-, Deployed- und Runtime-SBOM [5]. Der Unterschied ist nicht akademisch: Eine aus dem Quellcode erzeugte Stückliste kennt vorkompilierte Binärartefakte nicht, die im Build hinzukommen. Wer im sicheren Entwicklungszyklus nur den Source-Scan verankert, dokumentiert nicht, was er ausliefert.

Format und Pflichtfelder: Was die BSI TR-03183-2 konkret fordert

Der CRA sagt nur „gängiges maschinenlesbares Format“. Die Kommission kann nach Artikel 13 Absatz 24 Format und Elemente per Durchführungsrechtsakt festlegen [1]; ein solcher Rechtsakt war bis zum Redaktionsschluss dieses Beitrags nicht auffindbar. Bis dahin ist die TR-03183-2 in Version 2.1.0 (20.08.2025) der konkreteste deutsche Maßstab. Sie verlangt JSON oder XML und eine gültige Datei nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 — ausschließlich offiziell freigegebene Fassungen [5][9][10].

Die Pflichtfelder gehen deutlich über das hinaus, was gängige Scanner ohne Nachkonfiguration ausgeben:

Ebene	Pflichtfelder nach TR-03183-2 v2.1.0
SBOM selbst	Ersteller (E-Mail-Adresse, ersatzweise URL); Zeitstempel der Erstellung
je Komponente	Ersteller; Name; Version; tatsächlicher Dateiname; Abhängigkeiten zu anderen Komponenten mit ausdrücklicher Angabe, ob die Aufzählung vollständig ist; Vertriebslizenzen; SHA-512-Prüfsumme der auslieferbaren Komponente; ausführbar / nicht ausführbar; Archiv / kein Archiv; strukturiert / unstrukturiert

Zwei Felder sind die üblichen Stolpersteine. Die SHA-512-Prüfsumme ist auf die auslieferbare Form der Komponente bezogen, nicht auf das Quellarchiv — sie entsteht also im Build, nicht im Repository. Und die explizite Vollständigkeitsangabe zu den Abhängigkeiten zwingt zu einer Aussage, die Werkzeuge gern offenlassen: Ist diese Liste erschöpfend oder nur das, was der Scanner gefunden hat?

Für deutschsprachige Leser gibt es eine Falle, die kein Wettbewerbsbeitrag benennt: Die deutsche Fassung der TR-03183-2 ist auf Version 1.0 von 2023 stehengeblieben. Die BSI-Downloadseite trägt den Hinweis „Version 1.0 der BSI TR-03183-2 ist veraltet“ [6]; die aktuelle Fassung 2.1.0 existiert nur auf Englisch [5]. Wer intern mit dem deutschen PDF arbeitet, arbeitet mit den Formatanforderungen von vor drei Versionswechseln. Hinzu kommt die Übergangsregel der Richtlinie selbst: Konform ist nur die jeweils neueste Version; die unmittelbar vorhergehende darf längstens sechs Monate nach Erscheinen einer neuen weiterverwendet werden [5].

International bewegt sich der Maßstab ebenfalls. Am 29. Juli 2026 hat die US-Behörde CISA gemeinsam mit dem BSI und weiteren Partnern eine überarbeitete Fassung der „Minimum Elements for a Software Bill of Materials“ veröffentlicht, die die NTIA-Mindestangaben von 2021 ersetzt [7][8]. Wer sein SBOM-Zielbild jetzt festschreibt, sollte die Feldliste versionieren statt sie einzufrieren.

Fahrplan: Was bis wann zu tun ist

Der 11. Dezember 2027 ist die Frist für die Stückliste selbst — aber nicht die erste relevante Frist. Artikel 14 CRA gilt bereits ab dem 11. September 2026, und die dort geforderte Meldung aktiv ausgenutzter Schwachstellen setzt voraus, dass Sie wissen, welche Komponenten in Ihren ausgelieferten Produkten stecken [1]. Die Stückliste ist damit faktisch fünfzehn Monate früher fällig, als das Datum vermuten lässt.

Rolle	Schritt	Aufwand
Hersteller	SBOM-Erzeugung in die Build-Pipeline hängen, nicht in den Release-Prozess — Build-SBOM statt Source-Scan	Mittel
Hersteller	Zielformat und Detaillierungsgrad festlegen (CycloneDX 1.6+ oder SPDX 3.0.1+; mindestens Delivery item SBOM)	Gering
Hersteller	Abgleich der Stückliste gegen Schwachstellenquellen automatisieren — das ist der Teil, den Anhang I Teil II Nr. 1 eigentlich meint	Hoch
Hersteller	Upstream-Meldeweg definieren: Artikel 13 Absatz 6 verpflichtet, eine Schwachstelle in einer integrierten Komponente an deren Hersteller oder Wartenden zu melden und einen Fix mitzuteilen [1]	Mittel
Betreiber	Komponentenbeschreibung als Beschaffungsanforderung verankern (CIR Anhang 6.1.2 Buchst. c bzw. § 30 Abs. 2 Nr. 5 BSIG)	Gering
Betreiber	Format- und Tiefenanforderung in den Vertrag schreiben — ohne sie liefern Anbieter eine Top-Level-Liste	Gering
Betreiber	Prüfen, wer die gelieferten Stücklisten auswertet; eine unausgewertete SBOM ist kein Nachweis nach Artikel 21 Absatz 3	Mittel

Artikel 13 Absatz 6 geht dabei weiter als die reine Meldung: Der entwickelte Fix ist dem Komponentenhersteller „gegebenenfalls in einem maschinenlesbaren Format“ mitzuteilen [1] — eine Rückgabepflicht in Richtung Open-Source-Ökosystem, die ohne saubere Komponentenidentifikation nicht erfüllbar ist.

Häufige Fragen

Muss ich die SBOM meinen Kunden aushändigen?
Nein. Der CRA kennt keine Herausgabepflicht gegenüber Nutzern, und Erwägungsgrund 77 stellt ausdrücklich fest, dass keine Veröffentlichungspflicht besteht [1]. Händigen Sie sie freiwillig aus, müssen die Nutzerinformationen nach Anhang II Nummer 9 angeben, wo sie abrufbar ist [1]. Große Kunden fordern sie ohnehin vertraglich — das ist eine Marktrealität, keine Rechtspflicht.

Gilt die Pflicht auch für kostenlose Software?
Ja, wenn Sie sie unter eigenem Namen oder eigener Marke vermarkten. Artikel 3 Nummer 13 erfasst die Vermarktung „gegen Bezahlung, zur Monetarisierung oder unentgeltlich“ [1]. Reine Open-Source-Verwalter im Sinne von Artikel 3 Nummer 14 unterliegen einem gesonderten, leichteren Regime.

Reicht die Ausgabe unseres bestehenden Schwachstellenscanners?
Meist nicht ohne Anpassung. Typische Scanner-Exporte enthalten Name, Version und Lizenz, aber weder die SHA-512-Prüfsumme der auslieferbaren Komponente noch die ausdrückliche Vollständigkeitsangabe zu den Abhängigkeiten [5]. Beides muss aktiv konfiguriert werden.

Wir sind NIS2-pflichtig, aber kein Hersteller. Brauchen wir eine SBOM?
Für sich selbst nicht — weder NIS2 noch das BSIG verlangen eine [2][4]. Sie brauchen aber ein Beschaffungsverfahren, das Komponenteninformationen einholt, und für die elf CIR-Einrichtungsarten ist das nach Anhang 6.1.2 Buchstabe c bindend [3].

Ändert der angekündigte Durchführungsrechtsakt die Anforderungen?
Möglich. Artikel 13 Absatz 24 ermächtigt die Kommission, Format und Elemente festzulegen [1]; veröffentlicht ist ein solcher Rechtsakt bislang nicht. Ein CycloneDX- oder SPDX-Export in aktueller Version ist die risikoärmste Vorbereitung, weil beide Formate als Referenz in der Diskussion stehen.

Fazit

Die SBOM ist eine CRA-Pflicht mit einem NIS2-Schatten. Bindend ist sie für Hersteller ab dem 11. Dezember 2027 aus Anhang I Teil II Nummer 1 — praktisch früher, weil die Meldepflicht aus Artikel 14 ab dem 11. September 2026 dieselbe Komponentenkenntnis voraussetzt. Für NIS2-pflichtige Betreiber existiert keine eigene Pflicht; bei ihnen entsteht die Stückliste im Einkaufsvertrag, gestützt auf Artikel 21 Absatz 3 und — für die elf CIR-Arten — auf Anhang 6.1.2 Buchstabe c. Wer beide Seiten zusammen plant, baut einen Nachweis statt zweier Dokumentenstapel. Die Doppelrolle insgesamt behandelt der Hub NIS2 und der Cyber Resilience Act.

Dieser Artikel bietet allgemeine Informationen und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen können je nach Rechtsordnung und Unternehmensart abweichen. Für eine auf Ihre Situation zugeschnittene Bewertung wenden Sie sich an eine qualifizierte Rechtsanwältin, einen qualifizierten Rechtsanwalt oder eine Compliance-Fachkraft.

Quellen

1. Verordnung (EU) 2024/2847 (Cyber Resilience Act), deutsche Amtsblattfassung — EUR-Lex
2. Richtlinie (EU) 2022/2555 (NIS2), deutsche Amtsblattfassung — EUR-Lex
3. Durchführungsverordnung (EU) 2024/2690 — EUR-Lex
4. § 30 BSIG — Risikomanagementmaßnahmen — Gesetze im Internet, Bundesministerium der Justiz
5. BSI, Technical Guideline TR-03183-2: Cyber Resilience Requirements — Part 2: Software Bill of Materials (SBOM), Version 2.1.0 (20.08.2025): www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf
6. BSI, BSI TR-03183-2 Version 1.0 (veraltet), deutschsprachige Fassung, Stand 31.07.2023: www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03183/BSI-TR-03183-2.html
7. BSI-Meldung vom 29.07.2026, „Software-Bestandteillisten: Minimum Elements for SBOM aktualisiert“: www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Minimum_Elements_SBOM_aktualisiert_260729.html
8. CISA, „2026 Minimum Elements for a Software Bill of Materials (SBOM)“, veröffentlicht am 29.07.2026: www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
9. CycloneDX Specification Overview — OWASP / Ecma International (ECMA-424)
10. SPDX Specifications — Linux Foundation
11. BSI, Themenseite Cyber Resilience Act: www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/cyber_resilience_act_node.html