← Blog

    Lieferanten ohne CSAF: wie Anlagenbauer deren Schwachstellen trotzdem überwachen

    Kurz gefasst · Stand: September 2026

    Kein Lieferant ist verpflichtet, Ihnen maschinenlesbare Sicherheitsmeldungen zu liefern. Der Cyber Resilience Act schreibt ein Format nur für die SBOM vor (Anhang I Teil II Nr. 1), nicht für Advisories; der Entwurf der harmonisierten Norm prEN 40000-1-3 führt eine menschenlesbare Veröffentlichung als Grundanforderung und CSAF nur als risikobasierte Zusatzanforderung. Die Pflicht, Schwachstellen in zugekauften Komponenten zu erkennen, zu bewerten und seit dem 11. September 2026 binnen 24 Stunden zu melden, liegt trotzdem beim Anlagenbauer (Art. 13, Art. 14). Praktisch heißt das: nicht auf CSAF warten, sondern je Lieferant den tatsächlichen Kanal festhalten und jede Meldung auf ein einheitliches Raster normalisieren.

    Fast jedes Gespräch über Lieferanten-Monitoring kommt an derselben Stelle an: Die großen Lieferanten hätten CSAF, der Rest ziehe schon nach. Der erste Teil stimmt. Der zweite ist eine Hoffnung – und sie hat weder im Verordnungstext noch im aktuellen Normentwurf eine Grundlage.

    Die öffentliche CSAF-Liste des BSI führt 15 Einträge, acht davon aus der Industrie

    Es gibt dafür eine öffentliche Referenz. Das BSI betreibt unter wid.cert-bund.de eine CSAF-Liste, in der sich Hersteller als Provider eintragen lassen. Ein Abruf am 10. September 2026 ergibt: 15 Einträge. Davon sind zwei Koordinatoren – das BSI selbst und die US-Behörde CISA. Bleiben 13 Hersteller, und von diesen sind für den Maschinen- und Anlagenbau überhaupt einschlägig: Siemens, Schneider Electric, ABB, SICK, Hitachi Energy, KUNBUS, Nozomi Networks und IDS Innomic. Acht.

    Diese Liste ist nicht die ganze Welt: Ein Hersteller kann CSAF veröffentlichen, ohne dort eingetragen zu sein, und Verbands-CERTs bündeln Advisories weiterer Hersteller. Die Größenordnung ändert das nicht. Dem steht eine typische Anlagen-Stückliste gegenüber – Steuerungen, Antriebe, Sensorik, Industrie-PCs, Netzwerktechnik, Sicherheitstechnik – mit Komponenten von Dutzenden Lieferanten je Anlage. Der maschinenlesbar publizierende Lieferant ist nicht die Regel mit ein paar Nachzüglern. Er ist die Ausnahme.

    Der CRA schreibt für Advisories kein Format vor

    Das ist kein Versäumnis der Hersteller, sondern die Rechtslage. Anhang I Teil II Nr. 4 CRA verpflichtet Hersteller, nach Bereitstellung einer Sicherheitsaktualisierung Informationen über behobene Schwachstellen zu teilen und zu veröffentlichen, einschließlich einer Beschreibung, der Angaben zur Identifikation des betroffenen Produkts, der Auswirkungen und der Schwere. Über die Form steht dort nichts.

    Ein Formatzwang taucht im CRA an genau zwei Stellen auf, und beide zielen nicht auf das Advisory Ihres Lieferanten:

    • Anhang I Teil II Nr. 1 verlangt die Software-Stückliste „in einem gängigen maschinenlesbaren Format" – das betrifft die SBOM, nicht die Sicherheitsmeldung.
    • Art. 13 Abs. 6 verlangt, dass ein Hersteller eine selbst entwickelte Korrektur für eine fremde Komponente dem Komponentenhersteller „gegebenenfalls in einem maschinenlesbaren Format" mitteilt. Diese Pflicht läuft von Ihnen zum Lieferanten hin, nicht umgekehrt.

    Auch der Normentwurf macht CSAF nicht zur Pflicht

    Der übliche Einwand lautet: Was der CRA offenlässt, regelt die harmonisierte Norm. Der Entwurf, um den es geht, ist prEN 40000-1-3 (CEN/CENELEC JTC 13) zur Schwachstellenbehandlung nach Anhang I Teil II. Er trennt zwei Ebenen:

    • Grundanforderung: Informationen zu behobenen Schwachstellen sind in einem menschenlesbaren Format bereitzustellen.
    • Zusatzanforderung („requirement enhancement"): Bereitstellung in einem verbreiteten maschinenlesbaren Format – mit ausdrücklichem Verweis auf CSAF 2.0 (ISO/IEC 20153:2025).

    Diese Zusatzanforderungen sind im Entwurf ausdrücklich risikobasiert angelegt: Ob sie gelten, bestimmt sich nach den Risiken des jeweiligen Produkts. Für einen Näherungsschalter gilt damit ein anderer Maßstab als für eine Firewall. Der Entwurf ist zudem noch nicht final – aber seine Richtung ist eindeutig, und sie geht nicht dahin, CSAF flächendeckend verbindlich zu machen. Wer seine Prozessplanung darauf stützt, dass in zwei Jahren alle Lieferanten CSAF liefern, plant gegen den Normtext.

    Die Pflicht bleibt trotzdem vollständig bei Ihnen

    Aus dem fehlenden Formatzwang folgt keine Entlastung, sondern das Gegenteil. Wer eine Anlage unter eigenem Namen in Verkehr bringt und damit Hersteller wird, trägt die Verantwortung für das Gesamtprodukt. Vier Bestimmungen greifen ineinander:

    • Art. 13 Abs. 5 – bei der Integration von Komponenten Dritter ist die gebotene Sorgfalt walten zu lassen.
    • Art. 13 Abs. 6 – eine in einer integrierten Komponente festgestellte Schwachstelle ist deren Hersteller zu melden und nach Anhang I Teil II zu behandeln.
    • Art. 13 Abs. 7 – alle relevanten Cybersicherheitsaspekte sind systematisch zu dokumentieren, „einschließlich der Schwachstellen, von denen er Kenntnis erlangt, und aller von Dritten bereitgestellten einschlägigen Informationen".
    • Anhang I Teil II Nr. 2 – Schwachstellen sind unverzüglich zu behandeln und zu beheben.

    Vor allem Art. 13 Abs. 7 wird unterschätzt. „Alle von Dritten bereitgestellten einschlägigen Informationen" sind genau die Lieferantenmeldungen – auch die als PDF angehängte. Eine solche PDF im persönlichen Postfach eines Servicetechnikers ist keine systematische Dokumentation. Der Kanal ist damit nicht nur ein technisches, sondern ein Nachweisproblem.

    Dazu kommt die Uhr. Ab dem 11. September 2026 (Art. 71 Abs. 2) gilt Art. 14: 24 Stunden für die Frühwarnung an den koordinierenden CSIRT und die ENISA, 72 Stunden für die eigentliche Schwachstellenmeldung, und spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme der Abschlussbericht. Die Frist läuft ab eigener Kenntnisnahme. Ein Lieferant, der spät informiert, verkürzt damit nicht Ihre Frist – aber er verkürzt die Zeit, die Sie zum Bewerten haben.

    Der Kanal entscheidet über die Automatisierung, nicht das Format

    Statt Lieferanten in „hat CSAF" und „hat kein CSAF" zu sortieren, ist die brauchbare Einteilung die nach dem Kanal – denn er entscheidet, wie viel Automatisierung möglich ist:

    • CSAF über einen abrufbaren Feed – per ROLIE oder über eine Verzeichnisstruktur: maschinenlesbar, vollständig abrufbar, Änderungen erkennbar. Der Idealfall – und der seltene.
    • RSS/Atom oder eine Advisory-Übersichtsseite mit stabiler Struktur: der Abruf lässt sich automatisieren, der Inhalt bleibt Fließtext. Die Produktzuordnung entsteht erst bei der Verarbeitung.
    • Mailingliste oder Security-Newsletter: technisch einfach, aber nur wirksam, wenn er abonniert ist – und wenn das Abo nicht auf einer Person liegt, die das Unternehmen verlassen kann.
    • PDF an eine Einzeladresse oder Kundenportal mit Login: kein Abruf von außen möglich. Hier entscheidet die Organisation: Wer bekommt es, wer trägt es ein, was passiert im Urlaub.

    Der teuerste Kanal ist keiner der vier – es ist der fünfte: der Lieferant, dessen Kanal niemand kennt. Solange nicht je Lieferant dokumentiert ist, wo seine Advisories erscheinen, ist die Aussage „wir haben keine offenen Schwachstellen" kein Prüfergebnis, sondern eine Vermutung.

    Der Normentwurf liefert das Raster, auf das jede Meldung normalisiert wird

    Der Normentwurf liefert nebenbei die Lösung für das Formatproblem. prEN 40000-1-3 verlangt von jeder Veröffentlichung – menschenlesbar oder maschinenlesbar – mindestens diese Angaben:

    • Beschreibung der Schwachstelle
    • Schwachstellen-Identifikator (in der Regel eine CVE-Nummer)
    • Angaben zur Identifikation des betroffenen Produkts
    • mögliche Auswirkung
    • Schweregrad
    • Angaben zur Behebung
    • Veröffentlichungs- und Aktualisierungsdatum

    Diese sieben Felder sind der kleinste gemeinsame Nenner aller Advisories, unabhängig vom Transportweg. Wer sein Schwachstellenmanagement auf genau dieses Raster baut, kann eine CSAF-Datei und eine abgetippte PDF im selben Vorgang führen und im selben Bericht ausweisen. Die eigene Betroffenheitsaussage gehört daneben – dafür ist VEX das passende Format, und diese Aussage treffen ohnehin Sie, nicht der Lieferant.

    Der eigentliche Engpass ist der Identifikator, nicht das Format

    Eine Warnung an dieser Stelle, weil sie in Tool-Demos regelmäßig untergeht: Selbst ein perfekt maschinenlesbares Advisory nützt nichts, wenn sich das betroffene Produkt nicht auf Ihre verbaute Komponente abbilden lässt. Industrieadvisories identifizieren Produkte über Artikelnummern und herstellereigene Versionsnotation, nicht über CPE oder PURL. Der Abgleich läuft deshalb über Hersteller, Bestellnummer und Firmware-Stand – ausführlich mit Zahlen im Beitrag zur Tool-Auswahl. Wer beim Lieferanten etwas erreichen will, sollte deshalb nicht zuerst nach CSAF fragen, sondern nach eindeutigen Bestellnummern und Versionsbereichen im Advisory.

    Beim Lieferanten lohnen vier Nachfragen, ein Formatwechsel gehört nicht dazu

    Vier Dinge lohnen die Nachfrage, in dieser Reihenfolge:

    • Die Feed- oder Übersichtsseiten-URL – einmal erfragt, dauerhaft nutzbar. Der billigste Gewinn überhaupt.
    • Verteiler auf ein Funktionspostfach statt auf eine Person.
    • Bestellnummer und betroffene Versionsbereiche im Advisory, ausgeschrieben.
    • Die sieben Pflichtangaben oben als Mindestinhalt, im Rahmenvertrag verankert.

    Bei einem Lieferanten, der einen niedrigen einstelligen Prozentsatz Ihres Einkaufsvolumens ausmacht, hat eine Vertragsklausel allerdings wenig Hebel. Deshalb gilt: Der Kanal, den Sie selbst kontrollieren, ist mehr wert als die Zusage, die Sie nicht durchsetzen können.

    Drei Schritte machen das Monitoring belastbar

    • Lieferantenliste aus der SBOM ableiten, nicht aus dem Einkauf. Der Einkauf kennt Vertragspartner, die Stückliste kennt verbaute Komponenten – inklusive der Hersteller hinter einem Handelspartner.
    • Je Lieferant den Kanal einmal feststellen und dokumentieren. Feed-URL, Mailingliste, Portal oder „nichts gefunden" – auch das ist ein Ergebnis und gehört in die Akte.
    • Eingang normalisieren, auf Anlagen mappen, Bewertung dokumentieren. Erst dieser Schritt macht aus eingegangenen Meldungen die systematische Dokumentation, die Art. 13 Abs. 7 verlangt.

    Auf CSAF zu warten ist damit keine Strategie, weil weder die Verordnung noch der Normentwurf es flächendeckend verlangen. Belastbar wird das Monitoring durch etwas Langweiligeres – eine vollständige Lieferantenliste, einen dokumentierten Kanal je Lieferant und ein einheitliches Raster, in dem PDF und CSAF nebeneinander bestehen können.

    Lieferanten-Monitoring in der Demo ansehen →

    Werkspilot erfasst Lieferantenmeldungen von CSAF bis E-Mail, gleicht sie mit den Anlagen im Feld ab und dokumentiert die Bewertung nachweisfähig. Dieser Beitrag gibt den Stand der Regulierung zum Zeitpunkt der Veröffentlichung wieder und ist keine Rechtsberatung. Maßgeblich sind die Verordnungstexte selbst; prEN 40000-1-3 ist ein Normentwurf und noch nicht in Kraft.

    Häufige Fragen

    Nein. Der Cyber Resilience Act schreibt ein maschinenlesbares Format nur für die Software-Stückliste vor (Anhang I Teil II Nr. 1). Für die Veröffentlichung von Informationen über behobene Schwachstellen (Anhang I Teil II Nr. 4) nennt die Verordnung kein Format. Auch der Entwurf der harmonisierten Norm prEN 40000-1-3 verlangt als Grundanforderung nur eine menschenlesbare Veröffentlichung; ein maschinenlesbares Format wie CSAF 2.0 ist dort als risikobasierte Zusatzanforderung geführt, nicht als Pflicht für alle Produkte. Ein Lieferant, der Advisories als PDF verschickt, verletzt damit keine Formatvorgabe des CRA – für Advisories gibt es keine. Über den geforderten Inhalt sagt das nichts.

    Indem der Kanal je Lieferant einmal festgestellt und dokumentiert wird und alle eingehenden Meldungen auf dasselbe Raster normalisiert werden: Beschreibung, Schwachstellen-Identifikator, Angaben zur Identifikation des betroffenen Produkts, mögliche Auswirkung, Schweregrad, Behebung sowie Veröffentlichungs- und Aktualisierungsdatum. Diese Felder verlangt der Normentwurf prEN 40000-1-3 von jeder Veröffentlichung, unabhängig vom Format. Wer sein Monitoring auf dieses Raster baut, kann eine CSAF-Datei und eine PDF im selben Vorgang führen. Wichtig ist außerdem, dass Lieferantenmeldungen an ein Funktionspostfach gehen und nicht an eine einzelne Person.

    Beide, aber für unterschiedliche Produkte. Der Komponentenhersteller meldet für seine Komponente, der Anlagenbauer für die Anlage, die er unter eigenem Namen in Verkehr gebracht hat. Zusätzlich verpflichtet Art. 13 Abs. 6 CRA den Anlagenbauer, eine in einer integrierten Komponente festgestellte Schwachstelle demjenigen zu melden, der diese Komponente herstellt oder wartet. Die 24-Stunden-Frist für die Frühwarnung an ENISA und CSIRT läuft ab eigener Kenntnisnahme – nicht ab dem Zeitpunkt, zu dem der Lieferant informiert hat.

    Die Meldepflichten nach Art. 14 CRA gelten seit dem 11. September 2026 (Art. 71 Abs. 2). Wer seit diesem Stichtag innerhalb von 24 Stunden eine Frühwarnung abgeben soll, muss vorher wissen, welche Komponenten in welchen Anlagen stecken und über welchen Kanal deren Hersteller Schwachstellen bekannt geben. Die übrigen CRA-Pflichten einschließlich CE-Kennzeichnung und technischer Dokumentation gelten ab dem 11. Dezember 2027.