CRA und Lieferkette: Was Hersteller von ihren Lieferanten fordern müssen

Der Cyber Resilience Act (CRA) endet nicht an der eigenen Fabrikhalle. Wer als Maschinenbauer Software, Kommunikationsmodule oder andere digitale Baugruppen zukauft, muss von seinen Lieferanten belastbare Nachweise fordern. Sonst kann schon eine einzige unsichere Drittkomponente die CRA-Konformität des Gesamtprodukts gefährden. Typische Fälle aus der Praxis sind ein Kommunikationsmodul mit ungepatchter Schwachstelle, eine Open-Source-Library mit bekannten Schwachstellenmeldungen (CVEs), oder ein proprietärer Binary Blob ohne Software Bill of Materials (SBOM).

Dieser Artikel richtet sich an Maschinenbauer und Hersteller technischer Produkte, die stark auf Zulieferer und OEM-Komponenten, also eingekaufte Module anderer Hersteller, setzen. Er setzt Grundkenntnisse des CRA voraus; einen kompakten Einstieg bietet unser Artikel: Was kommt auf Maschinenbauer zu?. Im Folgenden geht es um die Haftungslogik, den Umgang mit Drittkomponenten, die SBOM-Pflicht, Lieferanten-Assessments, Vertragsklauseln und die Schnittstellen zu NIS2, ISO 27001 und IEC 62443.

Was der CRA zur Lieferkette konkret fordert

Artikel 13 Absatz 5 CRA verpflichtet Hersteller, bei der Integration von Komponenten Dritter angemessene Sorgfalt walten zu lassen. Das klingt abstrakt, ist aber operativ konkret: Hersteller müssen Maßnahmen dokumentieren, die sicherstellen, dass integrierte Drittkomponenten die Sicherheit des Gesamtprodukts nicht beeinträchtigen. Der CRA verlangt nicht, dass jeder Zulieferer schon heute einen perfekten Reifegrad nachweist. Er verlangt aber, dass fehlende Nachweise erkannt, Risiken bewertet und Gegenmaßnahmen dokumentiert werden.

Artikel 6 Buchstabe a CRA erlaubt das Inverkehrbringen nur für Produkte, die die Anforderungen aus Annex I, Teil I erfüllen. Erwägungsgrund 54 konkretisiert das Ziel dahinter: Hersteller sollen Produkte ohne bekannte ausnutzbare Schwachstellen bereitstellen. Diese Anforderung gilt für das Gesamtprodukt, also auch für alle integrierten Drittkomponenten. Wer sich darauf beruft, dass der Lieferant die Komponente so verbaut hat, schützt sich damit regulatorisch nicht.

Annex I, Teil II, Nr. 1 schreibt die SBOM-Pflicht fest: Hersteller müssen Schwachstellen und Komponenten ihres Produkts identifizieren und dokumentieren, einschließlich einer SBOM in einem gebräuchlichen maschinenlesbaren Format, die mindestens die Abhängigkeiten auf oberster Ebene abdeckt. In der Praxis kommen dafür etwa SPDX oder CycloneDX in Frage. Auf begründete Anforderung der Marktüberwachung muss die SBOM verfügbar sein. Erwägungsgrund 34 konkretisiert die Sorgfalt bei Drittkomponenten: Je nach Risiko nennt der CRA etwa die Prüfung von CE-Kennzeichnung, Update-Historie, Schwachstellendatenbanken oder zusätzliche Sicherheitstests. Lieferkettensicherheit ist damit keine optionale Erweiterung, sondern struktureller Bestandteil der CRA-Konformität.

Wer haftet und wofür?

Der Hersteller im Sinne des CRA trägt die volle Konformitätsverantwortung für das Produkt mit digitalen Elementen. Er muss CE-Kennzeichnung und Konformitätserklärung ausstellen, und er haftet auch für Drittkomponenten, die ins Produkt integriert wurden. Auch ein Maschinenbauer, der fremde Steuerungsmodule verbaut, ist Hersteller des Gesamtprodukts. Wichtig: Vertragliche Regelungen mit Lieferanten können zivilrechtliche Rückgriffsansprüche schaffen, aber die regulatorische Haftung gegenüber Behörden verbleibt beim Hersteller.

Artikel 19 CRA regelt die Pflichten der Importeure. Importeur ist nach Artikel 3 Nummer 16 CRA eine in der Union ansässige natürliche oder juristische Person, die ein Produkt mit digitalen Elementen in Verkehr bringt, das den Namen oder die Marke einer außerhalb der Union ansässigen Person trägt. Vor dem Inverkehrbringen muss sie unter anderem prüfen, ob die Konformitätsbewertung durchgeführt wurde, die technische Dokumentation erstellt wurde und das Produkt die CE-Kennzeichnung trägt. Diese Konstellation ist im Maschinenbau häufig, etwa wenn ein Unternehmen ein fertiges digitales OEM-Modul eines außereuropäischen Herstellers erstmals auf dem Unionsmarkt bereitstellt.

In der Praxis werden diese Rollen leicht vermischt. Ein Unternehmen kann etwa Hersteller des Gesamtprodukts sein und gleichzeitig für eine eingekaufte Baugruppe Importeurspflichten auslösen. Für die Lieferkettenperspektive ist deshalb vor allem diese Abgrenzung wichtig:

Meldepflichten und Incident-Abläufe hängen vom konkreten Vorfall und von der betroffenen Rolle ab. Für die Lieferkette ist die Kernbotschaft einfacher: Wer das Endprodukt unter eigenem Namen verkauft, kann die regulatorische Verantwortung nicht an den Zulieferer delegieren.

Der Open-Source-Steward ist eine neue CRA-Kategorie, definiert in Artikel 3 Nummer 14 und mit eigenen Pflichten in Artikel 24 CRA: Gemeint ist eine juristische Person, die die Entwicklung bestimmter Open-Source-Produkte für kommerzielle Nutzung dauerhaft und systematisch unterstützt. Das ist ein erleichtertes Regime, aber kein Freifahrtschein. Die entscheidende Abgrenzung: Wer ein Produkt mit OSS-Anteil kommerziell in Verkehr bringt, ist Hersteller und kein Steward. Welche Konsequenzen bei Nicht-Konformität drohen, beschreibt unser Artikel: CRA Strafen und Sanktionen.

Open Source und Drittkomponenten: Die Haftungsfalle

Nicht alle Drittkomponenten sind gleich riskant. Kommerzielle OEM-Komponenten wie Kommunikationsmodule oder HMI-Panels haben häufig definierte Supportprozesse, Sicherheitsmeldungen und feste Ansprechpartner. Bei Open-Source-Libraries, Binary Blobs und Vendor-SDKs ohne Quellcode fehlen diese Nachweise oder Eskalationswege häufiger. Das macht sie nicht automatisch unsicherer, aber für Hersteller deutlich schwerer steuerbar.

Das Log4Shell-Szenario illustriert die eigentliche Friktion: Nicht nur die Schwachstelle war das Problem, sondern die fehlende Transparenz über transitive Abhängigkeiten. Ohne aktuelle SBOM oder ein anderes belastbares Komponenteninventar konnten viele Hersteller nicht kurzfristig sagen, welche Produkte überhaupt betroffen waren. Genau diese Lücke wird unter dem CRA kritisch. Eine Early Warning wird erst dann relevant, wenn dein Produkt tatsächlich betroffen ist und eine Schwachstelle aktiv ausgenutzt wird. Dafür brauchst du intern schnelle Auskunftsfähigkeit, klare Ansprechpartner und ein aktuelles Inventar.

Binary Blobs sind eine besondere Herausforderung: keine Quellcodeeinsicht, oft keine öffentlichen CVE-Einträge und nur begrenzte Prüfbarkeit. Gerade hier musst du den Lieferanten vertraglich auf SBOM, Sicherheitsmeldungen und Schwachstelleninformationen festnageln oder die Komponente technisch stärker kapseln und überwachen. Fehlende SBOM-Daten vom Lieferanten erhöhen das Restrisiko und hinterlassen eine Dokumentationslücke, die Marktüberwachungsbehörden als mangelnde Sorgfalt werten können.

Wie ein belastbares Komponenteninventar für Embedded-Systeme und PLC-Umgebungen entsteht, beschreibt unser Artikel: SBOM für Embedded-Systeme.

SBOM als Rückgrat der Lieferkettenverantwortung

Ohne SBOM des eigenen Produkts ist keine systematische Risikoanalyse möglich. Ohne SBOM des Lieferanten wird die Sicht auf Drittkomponenten deutlich schlechter, aber nicht unmöglich. Beides gehört zusammen: Im Zielbild liefert jeder kritische Lieferant eine SBOM, der Hersteller aggregiert diese zur Produkt-SBOM und speist das Ergebnis ins Vulnerability Monitoring ein.

Die Realität sieht oft anders aus: Viele Lieferanten können noch keine maschinenlesbare SBOM liefern. Dann brauchst du eine gestufte Übergangsstrategie statt einer pauschalen Entweder-oder-Entscheidung. Für netzwerknahe oder sicherheitskritische Komponenten solltest du maschinenlesbare SBOMs priorisieren. Für weniger kritische Zukaufteile kann vorübergehend eine gepflegte Komponentenliste in PDF oder Excel genügen, wenn Verantwortliche, Versionen und Updatepfade sauber dokumentiert sind. Verbleibende Lücken müssen intern dokumentiert und durch eigene Maßnahmen kompensiert werden, zum Beispiel durch eigenes Inventarisieren, zusätzliche Tests, Binäranalyse oder enges Monitoring von Herstellerhinweisen.

Was die eigene Produkt-SBOM mindestens leisten muss, legt Annex I, Teil II, Nr. 1 fest: Sie muss Komponenten und Schwachstellen dokumentieren und mindestens die Abhängigkeiten auf oberster Ebene in einem gebräuchlichen maschinenlesbaren Format abdecken. Welche Felder und Elemente im Detail verlangt werden, kann die Kommission nach Artikel 13 Absatz 24 CRA noch spezifizieren.

Das folgende Beispiel in CycloneDX JSON zeigt deshalb eine praktikable Struktur und keine im CRA abschließend festgelegte Feldliste.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "supplier": { "name": "OpenSSL Software Foundation" },
      "name": "openssl",
      "version": "3.1.4",
      "purl": "pkg:generic/openssl@3.1.4",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "vulnerabilities": []
    }
  ]
}

Die purl dient hier als eindeutige Kennung der Komponente. Das Feld vulnerabilities ist nur dann sinnvoll, wenn du auch belastbar pflegst, welche bekannten Schwachstellen für dein Produkt tatsächlich relevant sind.

SBOM kombiniert mit dem CISA Known Exploited Vulnerabilities Catalog und der ENISA EUVD ergibt ein automatisierbares CVE-Matching. OWASP Dependency-Track ist ein bewährtes Open-Source-Tool, das genau diesen Prozess abbildet. Ohne SBOM des Lieferanten steigt der manuelle Aufwand deutlich. Dann musst du stärker mit eigener Inventarisierung, Tooling und Herstellerkommunikation arbeiten.

Lieferanten-Assessments: Was muss geprüft werden?

Eine einmalige Prüfung reicht nicht aus. Die CRA-Pflicht gilt für den gesamten Support-Zeitraum eines Produkts, typischerweise fünf Jahre oder mehr. Lieferanten können sich verändern: End-of-Life-Ankündigungen, Übernahmen, Insolvenzen. Deshalb brauchst du kein starres Jahresritual, sondern ein risikobasiertes Modell: ein initiales Assessment vor Freigabe, engere Prüfzyklen für kritische Lieferanten und Anlassprüfungen bei sicherheitsrelevanten Änderungen. Für wenig kritische Standardkomponenten kann eine vereinfachte Bestätigung ausreichen. Für schwer ersetzbare Kernkomponenten brauchst du deutlich mehr Tiefe.

Warnsignale bei der Lieferantenbewertung sind: kein dokumentierter Patchprozess, keine nachvollziehbare Schwachstellenhistorie für das Produkt, keine klare End-of-Life-Policy, ausdrückliche Ablehnung der SBOM-Anforderung und reine Binärlieferung ohne Herkunftsinformationen.

Die Ergebnisse solcher Assessments sollten in die technische Dokumentation nach Artikel 31 und Annex VII einfließen. So kann der Hersteller Risikobewertung, Prüfungen und die Ausübung der Sorgfalt aus Artikel 13 Absatz 5 nachvollziehbar belegen. Die ENISA Good Practices for Supply Chain Cybersecurity bieten einen strukturierten Leitfaden für solche Assessments. Wie der eigene Entwicklungsprozess dabei steht, zeigt unser Lunaris SDL-Assessment, das sich analog auf Lieferanten anwenden lässt.

Was in eine Lieferantenvereinbarung gehört

Vertragliche Regelungen mit Lieferanten verschieben keine regulatorische CRA-Haftung gegenüber Behörden. Sie schaffen aber zivilrechtliche Rückgriffsansprüche und definieren operative Pflichten des Lieferanten. Ohne Vertragsklauseln hat der Hersteller keine gesicherte Grundlage, Lieferantenpflichten im Streitfall durchzusetzen.

Es gibt aber nicht die eine CRA-Standardklausel, die in jeder Lieferbeziehung gleich gut funktioniert. Was du durchsetzen kannst, hängt von Kritikalität, Marktmacht, Austauschbarkeit des Lieferanten und Lebensdauer der Komponente ab. Für kritische Komponenten sollte eine Lieferantenvereinbarung diese Punkte möglichst ausdrücklich regeln:

• SBOM-Lieferpflicht: Format, Aktualisierungsrhythmus und Mindesttiefe der gelieferten Komponentenliste, idealerweise maschinenlesbar pro Release
• Meldung sicherheitsrelevanter Vorfälle: Ansprechpartner, Fristen, Inhalt der Meldung und Eskalationsweg bei aktiv ausgenutzten oder produktrelevanten Schwachstellen
• Update- und End-of-Life-Regelung: Welche Versionen wie lange unterstützt werden, welche Reaktionszeiten für Sicherheitsupdates gelten und wie früh ein Support-Ende angekündigt werden muss
• Nachweise und Einsicht: Welche Dokumente, Testnachweise oder Prozessbeschreibungen der Lieferant auf Anfrage bereitstellt
• Audit- oder Review-Recht: Ob und in welchem Umfang du Sicherheitsprozesse prüfen oder durch Dritte prüfen lassen darfst
• Haftung und Eskalation: Welche Folgen eine Pflichtverletzung hat, zum Beispiel Sonderkündigungsrecht, Rückgriff oder definierte Eskalationsstufen

Wichtig ist die Trennung zwischen CRA-Pflicht und Verhandlungsposition: Feste Werte wie 48 Stunden, CVSS-Schwellen oder 12 Monate Vorlauf vor dem Support-Ende können sinnvoll sein, sind aber keine automatischen CRA-Grenzwerte. Sie müssen zur Komponente und zur Lieferbeziehung passen.

Bei der Priorisierung gilt: Für Kommunikationsstacks, Kryptobibliotheken, Fernwartungszugänge und andere schwer ersetzbare Kernkomponenten solltest du auf verbindliche Zusagen bestehen. Bei weniger kritischen Standardteilen kann ein Minimalset aus Ansprechpartner, Versionsübersicht, Meldung von Sicherheitsvorfällen und Updatepfad ausreichen. Für Open-Source-Komponenten ohne direkten Vertragsgegenpart entfallen vertragliche Hebel weitgehend. Dann brauchst du intern eine belastbare Freigabe, eigene Inventarisierung und im Zweifel kommerziellen Support oder eine technische Alternative.

Die BSI TR-03183 enthält Anforderungen an Software-Lieferketten und ist eine gute Orientierung für Lieferantenvereinbarungen im deutschen Markt. Für die konkrete Vertragsgestaltung ist juristische Prüfung notwendig; Musterklauseln sollten nicht ungeprüft verwendet werden.

Schnittstellen zu NIS2, ISO 27001 und IEC 62443

Wer bereits NIS2-Anforderungen, ISO 27001 oder IEC 62443 implementiert hat, hat für die CRA-Lieferkettenpflichten oft eine gute Ausgangsbasis. Aber es gibt wichtige Unterschiede, und wer diese übersieht, bekommt eine Lücke, die Marktüberwachungsbehörden sehen.

NIS2 Artikel 21 verlangt Supply-Chain-Security als Mindest-Sicherheitsmaßnahme für wesentliche und wichtige Einrichtungen. Der strukturelle Unterschied: NIS2 ist eine Betreiberpflicht und fragt, was mit dem eigenen Dienst passiert ist. CRA ist eine Herstellerpflicht und fragt, was mit dem Produkt passiert ist. Ein Maschinenbauer, der NIS2-regulierte Betreiber beliefert, bekommt CRA-Konformitätsnachweise zunehmend auch als Kundenanforderung zurück.

ISO 27001:2022 bietet mit den Controls 5.19 bis 5.21 einen strukturierten Rahmen für Lieferantenbeziehungen. Eine ISO-27001-Zertifizierung des Lieferanten ist ein belastbares Indiz für vorhandene Prozesse, deckt aber nicht alle CRA-Anforderungen ab: Die SBOM-Pflicht und die produktspezifischen Meldepflichten sind CRA-spezifisch und müssen explizit ergänzt werden.

IEC 62443-4-1 ist die Norm mit der stärksten Überschneidung zur CRA-Herstellerpflicht im industriellen Umfeld. Sie enthält Anforderungen zu Security Requirements Engineering, Secure Design, Patch Management und End-of-Life, also genau dem, was Artikel 13 CRA vom Hersteller verlangt. Eine Zertifizierung des Lieferanten nach IEC 62443-4-1 kann als Nachweis für die CRA-Due-Diligence dokumentiert werden. Aber auch hier gilt: SBOM-Format, ENISA-Meldepflichten und öffentliche CVD-Policy sind CRA-spezifisch und nicht vollständig durch IEC 62443 abgedeckt.

Einen vollständigen Überblick über die Regulierungsschnittstellen bietet unser Artikel: CRA und angrenzende EU-Vorschriften.

Lieferkette ist Produktverantwortung

Der CRA macht den Hersteller zum vollverantwortlichen Eigentümer des Gesamtprodukts, auch dort, wo Drittkomponenten verbaut sind. Die SBOM ist dabei nicht nur eine regulatorische Pflicht, sondern das operative Instrument, das Schwachstellenmanagement in der Lieferkette überhaupt erst ermöglicht. Lieferantenvereinbarungen sind der vertragliche Hebel; das Assessment ist der Nachweis der ausgeübten Sorgfalt.

Für Maschinenbauer wird das Thema erst dann praktisch, wenn daraus ein belastbarer Ablauf wird:

1. Erstelle zuerst ein Komponenteninventar. Du musst wissen, welche Drittkomponenten in welchen Produkten und Produktversionen stecken.
2. Teile diese Komponenten nach Risiko ein. Kommunikationsmodule, Fernwartungszugänge, Kryptobibliotheken und nicht austauschbare OEM-Bausteine gehören nach oben auf die Liste.
3. Fordere von diesen Lieferanten zuerst die Mindestnachweise an: Ansprechpartner, unterstützte Versionen, Updatepfad, Meldung von Sicherheitsvorfällen und wenn möglich eine maschinenlesbare SBOM.
4. Dokumentiere jede Lücke mit Frist und Verantwortlichen. Eine fehlende SBOM ohne Termin, Owner und Kompensationsmaßnahme ist kein Plan, sondern nur ein offener Punkt.

Wenn ein Lieferant bei einer kritischen Komponente nicht mitzieht, brauchst du einen klaren Eskalationspfad:

1. Technisch eskalieren: Prüfe, ob du die Komponente isolieren, enger überwachen oder durch zusätzliche Tests absichern kannst.
2. Kaufmännisch eskalieren: Gehe in Einkauf und Vertragsmanagement, wenn Nachweise, Updatezusagen oder Meldungen von Sicherheitsvorfällen fehlen.
3. Produktseitig eskalieren: Entscheide mit Produktverantwortung und Management, ob die Komponente ersetzbar ist, befristet mit Restrisiko weiterlaufen darf oder die Freigabe blockiert werden muss.
4. Regulatorisch dokumentieren: Halte fest, warum du welche Restlücke vorübergehend akzeptierst und welche Abstellmaßnahme bis wann umgesetzt sein muss.

Der entscheidende Punkt ist unbequem, aber wichtig: Wenn ein nicht ersetzbarer Lieferant für eine kritische Komponente weder Transparenz noch Updatefähigkeit liefern kann, hast du kein reines Beschaffungsproblem. Du hast ein Produktrisiko, das aktiv entschieden und dokumentiert werden muss.

Wer mit dem SBOM-Thema noch am Anfang steht, findet den praktischen Einstieg in unserem Artikel: SBOM für Embedded-Systeme. Was bei einer aktiv ausgenutzten Schwachstelle aus der Lieferkette konkret zu tun ist, erklärt unser Artikel: CRA Meldepflichten. Den Gesamtüberblick über alle zehn Schritte zur Konformität bietet unser Artikel: In 10 Schritten zur CRA-Konformität.

Welche Lieferantenkonstellation ist in deinem Unternehmen die größte Herausforderung? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.