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

Eine einzige unsichere Drittkomponente kann die gesamte CRA-Konformität eines Produkts gefährden. Ein zugekauftes Kommunikationsmodul mit einer ungepatchten Schwachstelle, eine Open-Source-Library mit aktiv ausgenutzen CVEs, ein Binary Blob ohne SBOM: All das ist kein hypothetisches Szenario, sondern Alltag im Maschinenbau. Der Cyber Resilience Act (CRA) macht den Hersteller für das Gesamtprodukt verantwortlich, unabhängig davon, wie viele Teile zugekauft wurden.

Dieser Artikel richtet sich an Maschinenbauer und Hersteller technischer Produkte, die stark auf Zulieferer und OEM-Komponenten 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. Es gibt kein explizites Verbot, nicht-CRA-konforme Zulieferer zu nutzen, aber eine nachweisliche Risikobewertung und -minderung ist Pflicht.

Annex I, Teil I des CRA verbietet, ein Produkt mit bekannten ausnutzbaren Schwachstellen in Verkehr zu bringen. 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, Anforderung 1 schreibt die SBOM-Pflicht fest: Hersteller müssen Schwachstellen und Komponenten ihres Produkts einschließlich der mindestens übergeordneten Abhängigkeiten ermitteln und dokumentieren. Die SBOM muss in einem maschinenlesbaren Standardformat vorliegen (SPDX oder CycloneDX) und Behörden auf Anforderung zur Verfügung gestellt werden. Erwägungsgrund 19 des CRA macht die Logik dahinter explizit: Wer Drittkomponenten integriert, trägt die volle Produktverantwortung. 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 23 CRA regelt die Importeurspflichten: Wer Produkte mit digitalen Elementen aus Drittländern bezieht und in der EU in Verkehr bringt, ist Importeur und muss vor der Markteinführung prüfen, ob eine Konformitätsbewertung durchgeführt wurde, ob das CE-Zeichen vorhanden ist und ob die technische Dokumentation verfügbar ist. Diese Konstellation ist im Maschinenbau häufig: OEM-Komponenten aus Asien oder den USA, die in eigene Produkte integriert und dann in der EU verkauft werden.

Der Open-Source-Steward nach Artikel 22 ist eine neue CRA-Kategorie: Wer OSS systematisch pflegt und auf dem Markt bereitstellt, hat erleichterte Pflichten, 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 oft eine bekannte CVE-Historie und einen definierten Support-Zeitraum. Open-Source-Libraries, Binary Blobs und Vendor-SDKs ohne Quellcode sind schwieriger zu bewerten, aber mindestens genauso haftungsrelevant.

Das Log4Shell-Szenario illustriert das Problem: Ein einziger CVE in einer transitiven Abhängigkeit betraf Produkte über alle Branchen hinweg. Ohne SBOM war für viele Hersteller nicht einmal klar, welche Produkte überhaupt die betroffene Library enthielten. Unter dem CRA wäre das ein Problem: Der Hersteller muss innerhalb von 24 Stunden eine Early Warning einreichen, wenn eine Schwachstelle aktiv ausgenutzt wird, und das setzt ein aktuelles Komponenteninventar voraus.

Binary Blobs sind eine besondere Herausforderung: keine Quellcodeeinsicht, oft keine öffentlichen CVE-Einträge, und der Lieferant muss für SBOM und Schwachstelleninformationen vertraglich verpflichtet werden. Fehlende SBOM-Daten vom Lieferanten erhöhen das Restrisiko und hinterlassen eine Dokumentationslücke, die Marktüberwachungsbehörden als mangelnde Due Diligence 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 Supplier-SBOM gibt es keine Sichtbarkeit auf Drittkomponenten und deren Schwachstellen. Beides gehört zusammen: Der Idealzustand ist, dass jeder Lieferant eine SBOM liefert, der Hersteller diese zur Produkt-SBOM aggregiert und das Ergebnis ins Vulnerability Monitoring einspeist.

Die Realität sieht oft anders aus: Viele Lieferanten können noch keine maschinenlesbare SBOM liefern. Eine Übergangsstrategie ist pragmatischer als Blockade: Eine PDF-Komponentenliste als initialer Schritt akzeptieren, aber vertraglich das Zielbild einer maschinenlesbaren SBOM innerhalb von 12 bis 18 Monaten vereinbaren. Verbleibende Lücken müssen intern dokumentiert und durch eigene Risikomaßnahmen kompensiert werden.

Was die eigene Produkt-SBOM mindestens enthalten muss, legt Annex I, Teil II, Anforderung 1 fest: Produktname, Versionsnummer der eingebetteten Komponente, Lieferant der eingebetteten Komponente, eindeutige Kennung der Komponente, maschinenlesbares Format (SPDX oder CycloneDX), pro Release versioniert und archiviert.

Ein Minimalbeispiel in CycloneDX JSON zeigt, wie eine SBOM-Komponente strukturiert sein sollte:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "supplier": { "name": "OpenSSL Software Foundation" },
      "name": "openssl",
      "version": "3.1.4",
      // PURL als eindeutige Kennung der Komponente
      "purl": "pkg:generic/openssl@3.1.4",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      // Optionales VEX: bekannte CVEs und ihre Relevanz für dieses Produkt
      "vulnerabilities": []
    }
  ]
}

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 Supplier-SBOM wird daraus manuelle Recherche bei jedem neuen CVE.

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: EOL-Ankündigungen, Übernahmen, Insolvenzen. Die Empfehlung ist ein initiales Assessment, eine jährliche Wiederholung und eine Anlassprüfung bei sicherheitsrelevanten Änderungen.

Red Flags bei der Lieferantenbewertung sind: kein dokumentierter Patchprozess, keine CVE-Historik für das Produkt (fehlende Transparenz ist nicht gleichbedeutend mit sicher), keine klare EOL-Policy, ausdrückliche Ablehnung der SBOM-Anforderung und Binary-only-Lieferung ohne Herkunftsinformationen.

Das Ergebnis des Assessments gehört zur technischen Dokumentation nach Annex VII des CRA. Es zeigt Behörden, dass der Hersteller die Due-Diligence-Pflicht aus Artikel 13 Absatz 5 nachweislich ausgeübt hat. 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.

Eine CRA-konforme Lieferantenvereinbarung sollte mindestens folgende Elemente enthalten:

• SBOM-Lieferpflicht: Format (SPDX oder CycloneDX JSON/XML), mindestens Top-Level-Dependencies, Lieferung mit jedem Release-Artefakt, Aktualisierungspflicht bei sicherheitsrelevanten Komponentenänderungen
• Vulnerability Disclosure Obligation: Meldung aktiv ausgenutzter Schwachstellen in gelieferten Komponenten binnen 48 Stunden nach eigener Kenntniserlangung, mit CVE-Referenz, betroffenen Versionen und geplantem Fix
• Security-Update-Verpflichtung: Sicherheitsupdates für die vereinbarte Support-Laufzeit (mindestens 5 Jahre), kostenloser Patch für Hochrisiko-Schwachstellen (CVSS ≥ 7.0) innerhalb definierter SLA, EOL-Ankündigung mindestens 12 Monate vor Support-Ende
• Nachweispflichten: Technische Dokumentation, Testergebnisse und Konformitätsnachweise auf Anforderung, Nachweis eines funktionierenden Vulnerability-Management-Prozesses
• Audit- und Einsichtsrecht: Recht des Herstellers oder beauftragter Dritter, Sicherheitsprozesse des Lieferanten zu prüfen, mit definierter Ankündigungsfrist
• Haftungsklausel: Schadensersatzpflicht bei nachweisbar durch Lieferantenpflichtverletzung verursachter CRA-Sanktion

Bei der Priorisierung gilt: Hochkritische Komponenten wie Kommunikationsstacks, Kryptobibliotheken oder Netzwerkschnittstellen brauchen alle Klauseln verbindlich. Für Standardkomponenten ohne Netzwerkfunktion reicht ein Minimalset. Für Open-Source-Komponenten ohne kommerzielle Nutzungslizenz sind vertragliche Klauseln nicht möglich; hier sind interne SBOM und Risikoanalyse der einzige Weg.

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 Due Diligence.

Für Maschinenbauer ergibt sich daraus eine klare Reihenfolge: Zuerst ein Komponenteninventar erstellen, also klären, welche Drittkomponenten in welchen Produkten stecken. Dann Lieferanten nach Risikoklasse der gelieferten Komponente priorisieren und einen strukturierten Assessment-Fragebogen versenden. Parallel dazu Lieferantenvereinbarungen um CRA-spezifische Klauseln ergänzen. Schließlich einen SBOM-Prozess aufbauen, der Supplier-SBOMs aggregiert und in ein automatisiertes Vulnerability Monitoring einspeist.

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.