ENISA veröffentlicht Advisory zur SBOM: Empfehlungen über den CRA hinaus

Am 22. Oktober 2026 hat die ENISA das „Technical Advisory for Software Bill of Materials“ veröffentlicht, ihre Empfehlung zur SBOM in Version 1.10. Das Dokument richtet sich an kleine und mittlere Unternehmen, die mit der SBOM beginnen. Für diese Unternehmen beschreibt es eine automatisierte Pipeline, in der jede SBOM nach der Validierung signiert wird. Damit geht das Advisory deutlich über die Pflicht aus Anhang I Teil II Nummer 1 CRA hinaus. Maschinenbauern empfehlen wir diese Pipeline nicht als nächsten Schritt, weil vielen von ihnen noch die Firmware-Stände der zugekauften Komponenten fehlen.

Das Advisory ist eine technische Empfehlung zum Aufbau von SBOM-Prozessen. Es bindet niemanden und legt den CRA ausdrücklich nicht aus. Inhaltlich bietet es eine Architektur mit Datenflüssen entlang eines SBOM-Lebenszyklus, ein Bedrohungsmodell nach STRIDE und Gegenmaßnahmen. HBOM, CBOM und AI-BOM schließt es aus, es geht nur um die Software-Stückliste. Was eine SBOM ist und wie sie entsteht, erklären wir im Beitrag SBOM nach CRA erstellen.

Inhalt

1. Das Advisory ist branchenneutral und nennt den Maschinenbau nicht
2. Die ENISA geht bei der SBOM über CRA und BSI-Richtlinie hinaus
3. Für zugelieferte Firmware und kleine Hersteller bleibt das Advisory vage
4. Im Maschinenbau fehlt der SBOM oft schon der Firmware-Stand
5. Erst Inventar und Risikobeurteilung, die Signatur zuletzt

Das Advisory ist branchenneutral und nennt den Maschinenbau nicht

Die ENISA hat den Text aus einem Entwurf von Ende 2025 entwickelt und mit der CRA Expert Group abgestimmt. Weitere Überarbeitungen sind angekündigt. Inhaltlich folgt das Advisory den Prinzipien aus dem Secure by Design and Default Playbook der ENISA.

Laut ENISA ist das Dokument branchenneutral, den Maschinenbau erwähnt es nicht. Neben Architektur und Bedrohungsmodell listet es Open-Source-Werkzeuge je Lebenszyklusphase auf. Wo solche Werkzeuge an Grenzen stoßen, beschreiben wir unter SBOM-Tools und ihre Grenzen.

Die ENISA geht bei der SBOM über CRA und BSI-Richtlinie hinaus

Das Advisory beschreibt nach eigener Aussage Empfehlungen, die über die Anforderungen des CRA hinausgehen können. Wie weit, zeigt der Vergleich mit dem Text der Verordnung (EU) 2024/2847 und der BSI TR-03183-2, die das Advisory bei den Datenfeldern selbst als Grundlage nennt:

	CRA	BSI TR-03183-2 (Version 2.1.0)	ENISA-Advisory
Tiefe	mindestens Abhängigkeiten der obersten Ebene (Anh. I Teil II Nr. 1)	Liefergegenstands-SBOM als MUSS	keine eigene Mindesttiefe
SBOM-Typ	nicht festgelegt	Build-SBOM, ohne Build gleichwertige Angaben	Einstieg beim Build
Format	gängig und maschinenlesbar (Anh. I Teil II Nr. 1)	CycloneDX ab 1.6 oder SPDX ab 3.0.1, JSON oder XML	gängig und maschinenlesbar
Signatur	nicht verlangt	Empfehlung („should“) im erläuternden Anhang	fester Schritt nach der Validierung
Weitergabe	Ablage in der technischen Dokumentation, an die Marktüberwachung auf begründetes Verlangen (Anh. VII Nr. 8), an Nutzer freiwillig (Anh. II Nr. 9)	Anbieter verantwortet die Verfügbarkeit referenzierter SBOMs	kontrollierte Weitergabe mit Zugriffskontrolle
Verbindlichkeit	Verordnung	technische Richtlinie, keine Rechtsnorm	ausdrücklich unverbindlich

Die Tiefe in der CRA-Spalte ist unsere Lesart. Wir setzen die Abhängigkeiten der obersten Ebene mit der Top-Level-SBOM der TR gleich, also der Primärkomponente samt allem, wovon sie direkt abhängt. So steht das in keiner der drei Quellen. Daraus folgt eine klare Staffelung. Die TR verlangt mehr Tiefe als der CRA, die ENISA mehr Infrastruktur als beide.

Bei der Weitergabe treffen wir in Projekten immer wieder auf denselben Konflikt. Kunden möchten die SBOM der Maschine sehen, die Hersteller geben sie nicht heraus. Einen Anspruch darauf haben Kunden nach dem CRA nicht. Das Advisory stützt diese Zurückhaltung: Als Gegenmaßnahme gegen den Abfluss von Angaben zu Versionen und Lieferantenbeziehungen nennt es selbst die kontrollierte Weitergabe. Wie der CRA die Pflichten rund um SBOM und Schwachstellen verteilt, erklären wir unter Wer für Schwachstellen und SBOM verantwortlich ist.

Für zugelieferte Firmware und kleine Hersteller bleibt das Advisory vage

Für binär zugelieferte Komponenten verweist das Advisory auf die Analysed SBOM. Lassen sich solche Komponenten nicht vollständig analysieren, sollen Hersteller die „known unknowns“ dokumentieren. Die TR stuft Firmware-Images als Archive ein, die sich nicht in ihre Ursprungskomponenten zerlegen lassen. Wie ein Hersteller bei einem solchen Image die Abhängigkeiten der obersten Ebene abgrenzt, sagt keine der beiden Quellen. Bei einer zugekauften Steuerung mit Laufzeitsystem und Feldbus-Stack hängt aber davon ab, was in der SBOM steht.

Der zweite offene Punkt betrifft die Zielgruppe. Das Advisory wendet sich an KMU, die mit der SBOM beginnen. Für die Integration setzt es dann „mature continuous integration infrastructure and standardised build processes“ voraus und formuliert dort mit „must be established“, obwohl es sich für unverbindlich erklärt. Laut dem SBOM Adoption State of Play 2026 der ENISA, auf den sich das Advisory stützt, wollen 41 Prozent der Befragten die Generierung je Release oder Build voll automatisieren. Eine vollautomatische Pflege über den Supportzeitraum erwarten 26 Prozent. Die ENISA selbst nennt die Automatisierung nach dem Build „work in progress“.

Im Maschinenbau fehlt der SBOM oft schon der Firmware-Stand

Eine Verpackungsmaschine mit zugekaufter SPS, HMI-Panel und Fernwartungsrouter hat keinen eigenen Build, an den sich die Pipeline der ENISA anhängen ließe. Die Software steckt in den Komponenten der Zulieferer und kommt als Binär-Image ins Haus. Gerätebauer mit eigener Firmware haben es leichter. Yocto, Zephyr und Linux erzeugen SPDX bereits, der Build muss die Funktion nur einschalten. Wer seine Firmware selbst baut und eine CI betreibt, sollte das nutzen. Für diese Hersteller passt der Ansatz der ENISA.

Beim Maschinenbauer liegt das Problem eine Stufe früher. Bei vielen sehen wir, dass Komponenten auf Lager liegen und bei Bedarf nachbestellt werden. Zwischen zwei Einkäufen ändert sich die Firmware-Version, und in der Produktion schreibt sie niemand auf. Zwei baugleiche Verpackungsmaschinen können deshalb mit unterschiedlichen Ständen das Werk verlassen.

Für die SBOM zählt der Stand, der ausgeliefert wird. Das ist fast immer die Firmware, die beim Einbau, beim Factory Acceptance Test oder bei der Inbetriebnahme auf SPS, Panel und Router eingespielt ist. Diese Version muss die Fertigung je Maschine festhalten. Viele Hersteller müssen dafür ihre Abläufe in der Fertigung ändern, bevor eine SBOM für die Maschine möglich wird.

Erst Inventar und Risikobeurteilung, die Signatur zuletzt

Wir empfehlen Maschinenbauern die SBOM in der Tiefe, die der CRA verlangt, und nicht mehr. Die größeren Lücken liegen bei der Cybersecurity-Risikobeurteilung, und dorthin gehört der Aufwand zuerst. Sie erkennen diese Lücke, wenn im Projekt Fragen wie „Brauchen wir Secure Boot?“ aufkommen, aber niemand weiß, welche verbaute Komponente überhaupt riskant ist. Ein anderes Anzeichen ist der Einwand, die Firmware-Version der Safety-SPS sei unwichtig, weil diese nicht am Internet hängt. Solange unklar ist, wo die Risiken im Produkt liegen, kommen Fragen zur SBOM zu früh. Wie sich die Risikobewertung zwischen Hersteller und Betreiber aufteilt, zeigt der Beitrag Risikobewertung nach CRA, MVO und NIS-2.

Signatur und Artefaktbindung halten wir für den letzten Schritt. Solange die Firmware-Version der Automatisierungskomponenten nicht ermittelbar ist, sichert eine Signatur eine Liste ab, deren Inhalt nicht stimmt.

Beim Einstieg stimmen wir der ENISA zu. Sie empfiehlt, beim Build anzusetzen und zuerst die Integrationspunkte zu bestimmen. Eine Signatur sieht dieser Einstieg noch nicht vor. Welche Pflichten neben der SBOM in die technische Dokumentation gehören, fasst der Überblick CRA-Pflichten für Hersteller zusammen.

Für Software- und Gerätehersteller mit eigener CI ist das Advisory eine brauchbare Arbeitsgrundlage. Am Bedarf des Maschinenbaus geht es vorbei.