CRA-Lieferanten-Sorgfaltspflicht: Fragebogen und Warnsignale

Die Bauteil-Sorgfaltspflicht ist eine Herstellerpflicht nach Artikel 13 Absatz 5 der Cyberresilienz-Verordnung. Der vollständige Wortlaut:

„Für die Zwecke der Erfüllung der in Absatz 1 festgelegten Pflicht lassen die Hersteller die gebotene Sorgfalt walten, wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen, auch nicht bei der Integration von freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurde."

Diese Seite ist die operative Ergänzung zu den Herstellerpflichten. Den regulatorischen Rahmen, die Rollenabgrenzung und die einführerseitigen Prüfungen finden Sie in den Cluster-Leitfäden: Hersteller, Einführer, Händler und Wer fällt unter den CRA. Was hier folgt, ist der Fragebogen, sind die Playbooks für die Lieferantentypen, die in den Cluster-Seiten nicht abgedeckt sind (FOSS, Cloud, reine Hardware, OSS-Treuhänder, modifizierte COTS-Firmware), und sind die operativen Szenarien, die Teams in der realen Beschaffung treffen (nicht antwortende Lieferanten, gemeinsam genutzte vorgelagerte Komponenten, M&A-Altlasten, N-Tier-Sichtbarkeit).

Warum Lieferanten-Sorgfaltspflicht zählt

Auch als Hersteller des eigenen Produkts enthält Ihre Lieferung Komponenten von Zulieferern: Drittanbieter-Softwarebibliotheken, Hardwarekomponenten, Firmware-Module, Cloud-Dienste. Schwachstellen in diesen Komponenten werden zu Ihren Schwachstellen, und Ihre Konformitätsbewertung muss Lieferkettenrisiken berücksichtigen.

Artikel 13 Absatz 5 macht diese Bewertung explizit. Der CRA schreibt kein Fragebogenformat vor, ein schriftlicher Fragebogen ist aber der praktische Weg, um zu dokumentieren, dass Sie vor der Integration Komponentensicherheit, Schwachstellenbehandlung, SBOM-Verfügbarkeit, Supportzusagen und Reaktionspfade des Lieferanten geprüft haben. Ohne datierte Aufzeichnungen haben Sie gegenüber einer Marktüberwachungsbehörde keine Geschichte zu erzählen, wie das Risiko auf Komponentenebene behandelt wurde.

Wenn Ihre Rolle bei einem Produkt zugleich die des Einführers ist (Sie bringen das Produkt eines Nicht-EU-Herstellers in die EU), sind die vier Einführer-Vor-Markt-Prüfungen eine eigene Verifizierungspflicht. Dieser Leitfaden bleibt auf die herstellerseitige Komponentensorgfalt fokussiert.

Rahmen der Sorgfaltspflicht

Gestufter Ansatz

Nicht alle Lieferanten brauchen das gleiche Prüfniveau:

LIEFERANTEN-STUFEN-BEWERTUNG

STUFE 1 (Kritisch):
- Komponenten mit Sicherheitsfunktionen (Krypto, Auth, Firewalls)
- Kern-Softwareabhängigkeiten
- Hardware mit Firmware
Bewertung: Vollständiger Fragebogen + Dokumentationsprüfung + laufende Überwachung

STUFE 2 (Bedeutend):
- Hauptfunktionalitäts-Komponenten
- Netzwerkverbundene Elemente
- Datenverarbeitungskomponenten
Bewertung: Standardfragebogen + Dokumentationsprüfung

STUFE 3 (Standard):
- Nicht-Sicherheitskomponenten
- Hilfsbibliotheken
- Peripheriehardware
Bewertung: Basisfragebogen + Stichproben

STUFE 4 (Minimal):
- Commodity-Komponenten
- Etablierte OSS
- Nicht-vernetzte Hardware
Bewertung: Basisverifizierung + SBOM-Aufnahme

Bewertungsbereiche

Ihre Sorgfaltsprüfung sollte abdecken:

Der Rahmen ist allgemein, die Nachweise, die jeder Lieferantentyp tatsächlich liefern kann, variieren jedoch. Die nächsten fünf Abschnitte arbeiten die häufigsten Lieferantenformen ab und den Sorgfaltspfad, der jeweils passt.

FOSS-spezifische Lieferanten-Sorgfaltspflicht

Artikel 13 Absatz 5 nennt FOSS-Komponenten ausdrücklich: Komponenten aus freier und quelloffener Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurden. Die Rechtspflicht greift unabhängig davon, ob Geld fließt. Ein mit Blut unterzeichneter Fragebogen eines kommerziellen Anbieters ist nicht das Modell, wenn die Quelle ein GitHub-Projekt mit drei Maintainern ist.

Bei nicht-kommerziellen FOSS-Komponenten verschiebt sich der Nachweissatz von lieferantenbestätigten Dokumenten hin zu projektbeobachtbaren Signalen, die Sie selbst erheben können.

FOSS-KOMPONENTEN-SORGFALTSCHECKLISTE

PROJEKT-GESUNDHEIT:
[ ] Aktive Commits in den letzten 90 Tagen
[ ] Anzahl unterschiedlicher Beitragender (>1 = Bus-Faktor-Entlastung)
[ ] Release-Kadenz angegeben oder beobachtbar
[ ] Issue-Tracker reagiert (mediane Zeit bis zum ersten Kommentar)

SICHERHEITSLAGE:
[ ] SECURITY.md vorhanden mit Offenlegungsadresse
[ ] CVD-Richtlinie (privater Sicherheitskanal, nicht nur ein Issue)
[ ] CVE-Historie geprüft (NVD, GitHub Security Advisories, OSV)
[ ] SBOM-Bestandteile sind selbst wiedererkennbar, keine tiefen Forks

LIZENZ UND HERKUNFT:
[ ] SPDX-Identifier passt zur Aussage der Paket-Metadaten
[ ] Keine lizenzinkompatible transitive Abhängigkeit
[ ] Veröffentlichte Artefakte haben verifizierbare Herkunft (z. B. SLSA, sigstore)

IHR NOTFALLPLAN:
[ ] Fork-Ziel benannt, falls die Quelle verstummt
[ ] Interne Patch-Kapazität benannt (welcher Entwickler, welcher Code)
[ ] Ersatzkandidaten gelistet, Umstellungsaufwand geschätzt

Zwei operative Regeln. Erstens verlangt Artikel 13 Absatz 6, dass Schwachstellen, die Sie in einer FOSS-Komponente finden, an das Upstream-Projekt gemeldet werden und dass jede von Ihnen entwickelte Behebung zurückgegeben wird, gegebenenfalls in maschinenlesbarer Form. Der Fragebogen-Punkt, den Sie hier prüfen, ist nicht die Verpflichtung der Quelle Ihnen gegenüber, sondern Ihre eigene Verpflichtung, Schwachstellen und Patches zurückzuspielen. Zweitens hebt eine stille Quelle Ihre Pflicht nicht auf. Wird das Projekt inaktiv, ist Ihr Notfallplan (Fork, interne Pflege, Ersatz) Teil der Sorgfaltsakte, kein Zukunftsproblem.

Bei Projekten, die durch eine Stiftung oder eine juristische Person als Open-Source-Treuhänder getragen werden, ändert sich das Sorgfaltsmuster nochmals. Dieser Fall folgt im nächsten Abschnitt.

OSS-Treuhänder vs. kommerzieller Lieferant

Eine kleine, aber wichtige Klasse vorgelagerter Projekte wird von einem Open-Source-Treuhänder getragen: einer juristischen Person, typischerweise einer Stiftung, deren Kernzweck der Erhalt bestimmter Open-Source-Projekte für die kommerzielle Nutzung ist. Linux Foundation, Eclipse Foundation und Apache Software Foundation sind typische Beispiele. Treuhänder fallen unter Artikel 24, nicht unter Artikel 13. Der Pflichtensatz ist enger (eine dokumentierte Cybersicherheitsrichtlinie, eine Kooperationspflicht gegenüber der Marktüberwachung, eine teilweise Anwendung der Meldepflicht nach Artikel 14), und der Treuhänder ist nicht der Hersteller eines kommerziellen Produkts weiter unten in der Kette.

Zur Hersteller-vs.-Treuhänder-Abgrenzung siehe Open-Source-Treuhänder.

Die Sorgfaltsfolge für Sie als nachgelagerten Integrator: Der Fragebogen sieht anders aus.

Was Sie weiter tun: Projekt-Gesundheits-Checks, SBOM-Aufnahme, CVE-Monitoring, eigener Fork-und-Patch-Notfall. Was Sie nicht mehr erwarten: vertragliche SLAs für Schwachstellenmeldungen, kostenpflichtige Support-Stufen, Audit-Klauseln. Die Sorgfaltsakte für eine treuhänderisch getragene Komponente ist dünner auf der Lieferantenseite und stärker bei Ihren eigenen Kontrollen als bei einem kommerziellen Anbieter, und das ist die rechtlich korrekte Form.

Sorgfalt für Cloud-Service-Komponenten

Wenn die „Komponente" in Ihrem Produkt eine API oder ein verwalteter Dienst ist (eine Authentifizierungs-SaaS, ein verwalteter Message-Broker, eine Serverless-Funktion, eine Cloud-Datenbank), sieht das Nachweismuster wieder anders aus. Es gibt keine EU-Konformitätserklärung, kein SBOM, keinen Quellcode, den Sie ausliefern. Es gibt einen Vertrag, ein Portfolio an Sicherheitsattestierungen und ein Modell geteilter Verantwortung.

SORGFALT FÜR CLOUD-SERVICE-KOMPONENTEN

SICHERHEITSATTESTIERUNGEN:
[ ] SOC 2 Type II Bericht (aktuell)
[ ] ISO/IEC 27001 Zertifikat (aktuell, Geltungsbereich prüfen)
[ ] ISO/IEC 27017 (cloudspezifische Kontrollen), sofern relevant
[ ] ISO/IEC 27018 (PII in der Public Cloud), sofern personenbezogene Daten betroffen

OPERATIVE NACHWEISE:
[ ] Statusseite mit Vorfallshistorie und Nachberichten
[ ] Veröffentlichte RTO/RPO und Datum des letzten DR-Tests
[ ] Subdienstleister-Liste und Benachrichtigungsverfahren bei Änderungen
[ ] Auftragsverarbeitungsvertrag mit EU-Datenresidenz, sofern zutreffend

GETEILTE VERANTWORTUNG:
[ ] Verantwortungsbereich des Anbieters dokumentiert
[ ] Eigener Verantwortungsbereich anerkannt (Konfiguration, Identität, Secrets, Netzwerk)
[ ] Logging- und Audit-Trail-Zugriff im eigenen Verantwortungsbereich

CRA-NAHE:
[ ] Offenlegungsweg für Schwachstellen der API selbst
[ ] Frist für Vorfallsmeldung im Vertrag (Stunden, nicht „unverzüglich")
[ ] Vorlaufzeit für Dienst-Einstellung (typisch 12 Monate)

Der CRA regelt den Cloud-Anbieter nicht direkt, solange der Anbieter kein Produkt mit digitalen Elementen auf den Markt bringt. Ihre Pflicht nach Artikel 13 Absatz 5 ist es, nachzuweisen, dass die Cloud-Abhängigkeit die Cybersicherheit Ihres Produkts nicht beeinträchtigt. Die Lieferung ist das Attestierungsportfolio plus eine schriftliche Erklärung zur geteilten Verantwortung, kein CRA-förmiger Fragebogen.

Sorgfalt für reine Hardware- und ODM-Lieferanten

Wenn Ihr Auftragsfertiger (ODM, EMS, OEM-Bestücker) physische Boards liefert und die Firmware Ihnen gehört, stellt der Lieferant das Hardware-Substrat bereit, nicht die Sicherheitshülle. Der CRA legt die Sicherheitshülle bei Ihnen ab, beim Unternehmen, das die Firmware flasht und signiert, die auf das Board kommt.

Der Fragebogen ist hier dünner bei Software-Fragen und stärker bei Hardware-Vertrauen und Lieferkettenintegrität.

SORGFALT FÜR REINE HARDWARE / ODM

HARDWARE-VERTRAUEN:
[ ] BOM mit kryptographisch belastbarer Komponenten-Identifikation
[ ] Kontrollen gegen Fälschungen (Audit der Bauteilbeschaffung)
[ ] Quelle des Secure Element und Methode der Vorbereitstellung
[ ] Verfahren zur Schlüsseleinbringung im Werk und Audit-Spur

MONTAGE-INTEGRITÄT:
[ ] ISO 9001 Qualitätssystem etabliert
[ ] Manipulationsnachweise bei Montage und Versand
[ ] Los- und Seriennummern-Rückverfolgbarkeit vom Werk bis zur Wareneingangsrampe

FIRMWARE-ÜBERGABE:
[ ] Wer signiert die Firmware: Sie, der ODM oder beide
[ ] Zustand bei Erstinbetriebnahme (Werkseinstellungen, Eigentumsübergang)
[ ] Bootloader und Secure-Boot-Kette, wem gehört jedes Glied

NACH AUSLIEFERUNG:
[ ] EOL-Ankündigungsvorlauf für die Hardwareplattform
[ ] Last-Time-Buy-Zusage und Laufzeit
[ ] Verfügbarkeit von Ersatzteilen für den zugesagten Supportzeitraum

Ein häufiger operativer Fehler: ein mehrjähriger Supportzeitraum mit einem ODM, dessen Hardware-EOL-Fenster nur 18 Monate beträgt. Der CRA-Supportzeitraum beginnt mit dem Inverkehrbringen des Produkts auf dem EU-Markt, geht das zugrundeliegende Silizium innerhalb dieses Fensters in EOL, wandert die Supportpflicht nicht in die Toleranz Ihres Kunden ab.

COTS-Firmware, die Sie verändern

Wenn Sie ein kommerzielles Standardprodukt nehmen, die Firmware verändern und das Ergebnis auf dem EU-Markt bereitstellen, behandelt Artikel 22 Sie als Hersteller des veränderten Produkts für den Teil, der von der wesentlichen Änderung betroffen ist, oder für das gesamte Produkt, wenn die Änderung die Cybersicherheitshülle berührt.

„Eine natürliche oder juristische Person, bei der es sich nicht um den Hersteller, Einführer oder Händler handelt und die eine wesentliche Änderung an dem Produkt mit digitalen Elementen vornimmt und dieses Produkt auf dem Markt bereitstellt, gilt für die Zwecke dieser Verordnung als Hersteller."

Die Sorgfaltsfolge ist groß: Die EU-Konformitätserklärung und die Konformitätsbewertung des ursprünglichen Herstellers decken das Produkt, so wie Sie es in Verkehr bringen, nicht mehr ab. Sie übernehmen den Pflichtensatz des Herstellers für den betroffenen Teil oder das gesamte Produkt. Der ursprüngliche Lieferant wird für die CRA-Akte irrelevant, Ihr eigenes Engineering-Team wird zur verantwortlichen Stelle.

Der Sorgfaltsschritt ist hier daher kein Fragebogen an den ursprünglichen Anbieter. Es ist eine interne Bewertung der Änderungsauswirkung. Dokumentieren Sie den Änderungsumfang, entscheiden Sie, ob er wesentlich ist, und behandeln Sie das Ganze als Hersteller-Pflicht, wenn die Änderung Authentifizierung, Verschlüsselung, Netzwerkfläche oder den Update-Mechanismus berührt. Eine saubere Aufzeichnung, welche Änderung auf welche Stückzahl-Charge angewendet wurde, ist das Artefakt, nach dem eine Marktüberwachungsbehörde zuerst fragen wird.

Der Fragebogen

Verwenden Sie diesen Fragebogen als Ausgangspunkt für kommerzielle Software- und Hardware-Anbieter. Die vorhergehenden Abschnitte decken die Varianten für FOSS, OSS-Treuhänder, Cloud-APIs, reine Hardware-ODMs und modifizierte COTS-Firmware ab.

Abschnitt 1: Unternehmensinformationen

LIEFERANTEN-SORGFALTS-FRAGEBOGEN
Abschnitt 1: Unternehmensinformationen

1.1 Unternehmensdetails
    Firmenname: _________________________________
    Geschäftsadresse: ____________________________
    Gründungsland: _______________________________
    Hauptansprechpartner: ________________________
    Sicherheitskontakt: __________________________

1.2 Geschäftsinformationen
    Jahre im Geschäft: ___________________________
    Mitarbeiterzahl: _____________________________
    Jahresumsatz (Bereich): ______________________

1.3 EU-Vertretung (falls Nicht-EU)
    Name + Adresse des bevollmächtigten EU-Vertreters: ___
    (Volle Details zur AR-Kaskade und zur Einführer-
    Weiterleitung ohne EU-Niederlassung im Einführer-
    Cluster-Leitfaden:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Zertifizierungen (Kopien beifügen)
    [ ] ISO 9001 (Qualitätsmanagement)
    [ ] ISO 27001 (Informationssicherheit)
    [ ] ISO 27701 (Datenschutz)
    [ ] SOC 2
    [ ] Sonstige: _________________________________

Abschnitt 2: Produkt-Compliance

Abschnitt 2: Produkt-Compliance

2.1 Produktidentifikation
    Produktname/Modell: __________________________
    Version/Revision: ____________________________
    Produktkategorie: ____________________________

2.2 CRA-Klassifizierung
    [ ] Standard
    [ ] Wichtige Klasse I (Anhang III, Teil I)
    [ ] Wichtige Klasse II (Anhang III, Teil II)
    [ ] Kritisch (Anhang IV)
    [ ] Noch nicht klassifiziert

2.3 Konformitätsbewertung
    [ ] Modul A (Selbstbewertung)
    [ ] Modul B+C (EU-Baumusterprüfung)
    [ ] Modul H (Vollständige Qualitätssicherung)
    [ ] Noch nicht abgeschlossen

    Falls Modul B, C oder H:
    Name der notifizierten Stelle: _______________
    Zertifikatsnummer: ___________________________
    Zertifikatsdatum: ____________________________

2.4 EU-Konformitätserklärung
    [ ] Konformitätserklärung verfügbar (Kopie beifügen)
    [ ] Konformitätserklärung noch nicht ausgestellt
    Datum der Konformitätserklärung: _____________

2.5 CE-Kennzeichnung
    [ ] CE-Kennzeichnung angebracht
    [ ] CE-Kennzeichnung noch nicht angebracht
    Falls angebracht, wo am Produkt: _____________

2.6 Technische Dokumentation
    [ ] Technische Dokumentation auf Anfrage verfügbar
    [ ] SBOM verfügbar (Format: __________________)
    [ ] Risikobewertungsdokumentation verfügbar
    [ ] Benutzer-/Sicherheitsanleitung verfügbar

Abschnitt 3: Sicherheitspraktiken

Abschnitt 3: Sicherheitspraktiken

3.1 Sichere Entwicklung
    Befolgen Sie einen sicheren Entwicklungslebenszyklus?
    [ ] Ja, beschreiben: _________________________
    [ ] Nein

    Führen Sie Sicherheitstests durch?
    [ ] Statische Analyse (SAST)
    [ ] Dynamische Analyse (DAST)
    [ ] Penetrationstests
    [ ] Fuzz-Tests
    [ ] Sonstiges: _______________________________

    Haben Sie einen sicheren Coding-Standard?
    [ ] Ja, welchen: _____________________________
    [ ] Nein

3.2 Komponentenmanagement
    Wie verfolgen Sie Drittanbieter-Komponenten?
    [ ] SBOM gepflegt
    [ ] Abhängigkeits-Tracking-Tool (Name: _______)
    [ ] Manuelle Verfolgung
    [ ] Nicht systematisch verfolgt

    Wie überwachen Sie Schwachstellen in Abhängigkeiten?
    [ ] Automatisiertes Scanning (Tool: __________)
    [ ] Manuelle CVE-Überwachung
    [ ] Verlassen auf Anbieterbenachrichtigungen
    [ ] Keine systematische Überwachung

3.3 Sicherheitsarchitektur
    Beschreiben Sie wesentliche Sicherheitsfunktionen des Produkts:
    _____________________________________________

    Welche kryptographischen Standards werden verwendet?
    _____________________________________________

    Wie ist die Authentifizierung implementiert?
    _____________________________________________

    Wie werden Daten im Ruhezustand und bei der Übertragung geschützt?
    _____________________________________________

Abschnitt 4: Schwachstellenmanagement

Abschnitt 4: Schwachstellenmanagement

4.1 Schwachstellen-Offenlegung
    Haben Sie eine koordinierte Schwachstellen-Offenlegungsrichtlinie?
    [ ] Ja, URL: _________________________________
    [ ] Nein

    Haben Sie eine security.txt-Datei?
    [ ] Ja, URL: _________________________________
    [ ] Nein

    Was ist die Sicherheitskontaktmethode?
    [ ] E-Mail: __________________________________
    [ ] Webformular: _____________________________
    [ ] Bug-Bounty-Plattform: ____________________
    [ ] Sonstiges: _______________________________

4.2 Reaktionszusagen
    Was ist Ihre Bestätigungsfrist?
    [ ] Innerhalb von 24 Stunden
    [ ] Innerhalb von 72 Stunden
    [ ] Innerhalb von 7 Tagen
    [ ] Keine Zusage

    Was ist Ihre typische Patch-Frist für:
    Kritische Schwachstellen: ____________________
    Hohe Schwachstellen: _________________________
    Mittlere Schwachstellen: _____________________

4.3 ENISA-Meldung
    Sind Sie auf die ENISA-Meldung vorbereitet (Sept. 2026)?
    [ ] Ja, Prozess etabliert
    [ ] In Bearbeitung
    [ ] Nein
    [ ] Nicht zutreffend (nicht Hersteller)

4.4 Historische Schwachstellen
    Wie viele Sicherheitsschwachstellen wurden
    in diesem Produkt in den letzten 24 Monaten gemeldet? ______

    Wie wurden sie behoben?
    [ ] Alle innerhalb angegebener Fristen gepatcht
    [ ] Einige Verzögerungen (erklären): _________
    [ ] Einige bleiben ungepatcht (erklären): ____

Abschnitt 5: Update und Support

Abschnitt 5: Update und Support

5.1 Supportzeitraum
    Was ist der zugesagte Supportzeitraum ab
    Inverkehrbringen?
    [ ] 5 Jahre (CRA-Minimum)
    [ ] 7 Jahre
    [ ] 10 Jahre
    [ ] Sonstiges: _______________________________
    [ ] Nicht definiert

    Wann wurde dieses Produkt erstmals auf dem EU-Markt in Verkehr gebracht?
    Datum: _______________________________________

    Wann endet der Supportzeitraum?
    Datum: _______________________________________

5.2 Update-Mechanismus
    Wie werden Sicherheitsupdates bereitgestellt?
    [ ] Automatische Updates (OTA)
    [ ] Manueller Download vom Portal
    [ ] Physische Medien
    [ ] Sonstiges: _______________________________

    Sind Sicherheitsupdates getrennt von Feature-Updates?
    [ ] Ja
    [ ] Nein, gebündelt

    Können Benutzer Updates aufschieben oder überspringen?
    [ ] Ja
    [ ] Nein, verpflichtend
    [ ] Konfigurierbar

5.3 Update-Verifizierung
    Sind Updates signiert?
    [ ] Ja, Methode: _____________________________
    [ ] Nein

    Können Benutzer die Update-Authentizität verifizieren?
    [ ] Ja, wie: _________________________________
    [ ] Nein

5.4 End-of-Support-Planung
    Haben Sie einen dokumentierten EOL-Prozess?
    [ ] Ja
    [ ] Nein

    Wie werden Kunden über EOL informiert?
    _____________________________________________

    Was passiert nach Ablauf des Supportzeitraums?
    [ ] Produkt funktioniert weiter
    [ ] Produkt verliert Funktionalität
    [ ] Produkt erfordert Migration

Abschnitt 6: Dokumentationsanforderungen

Abschnitt 6: Dokumentationsanforderungen

6.1 Verfügbare Dokumentation
    Markieren Sie alle Dokumentation, die Sie bereitstellen können:

    [ ] EU-Konformitätserklärung
    [ ] Technische Dokumentation (oder relevante Auszüge)
    [ ] Software Bill of Materials (SBOM)
        Format: [ ] CycloneDX [ ] SPDX [ ] Sonstiges
    [ ] Risikobewertungs-Zusammenfassung
    [ ] Sicherheitsarchitektur-Dokument
    [ ] Benutzeranleitung (sicherheitsrelevant)
    [ ] Schwachstellen-Offenlegungsrichtlinie
    [ ] Support-/Wartungsbedingungen

6.2 Dokumentationsbereitstellung
    Wie wird die Dokumentation bereitgestellt?
    [ ] Auf Anfrage (Antwortzeit: ________________)
    [ ] Über sicheres Portal
    [ ] Mit Produkt gebündelt
    [ ] Sonstiges: _______________________________

6.3 SBOM-Details (falls verfügbar)
    SBOM deckt ab:
    [ ] Nur direkte Abhängigkeiten
    [ ] Transitive Abhängigkeiten eingeschlossen
    [ ] Hardwarekomponenten (falls zutreffend)

    SBOM-Aktualisierungshäufigkeit:
    [ ] Pro Release
    [ ] Auf Anfrage
    [ ] Nicht systematisch aktualisiert

Abschnitt 7: Vertragliche Zusagen

Abschnitt 7: Vertragliche Zusagen

7.1 Compliance-Garantie
    Werden Sie CRA-Compliance im Vertrag garantieren?
    [ ] Ja
    [ ] Nein
    [ ] Verhandelbar

7.2 Dokumentationsaufbewahrung
    Werden Sie technische Dokumentation 10 Jahre aufbewahren?
    [ ] Ja
    [ ] Nein
    [ ] Kürzerer Zeitraum: _______________________

7.3 Benachrichtigungspflichten
    Werden Sie uns benachrichtigen über:
    [ ] Sicherheitsschwachstellen im Produkt
    [ ] Änderungen des Konformitätsstatus
    [ ] End-of-Support-Entscheidungen
    [ ] Wesentliche Änderungen der Sicherheitsarchitektur

7.4 Auditrechte
    Werden Sie Compliance-Audits erlauben?
    [ ] Ja, uneingeschränkt
    [ ] Ja, mit Vorankündigung
    [ ] Nein

7.5 Freistellung
    Werden Sie für CRA-Nicht-Compliance freistellen?
    [ ] Ja
    [ ] Nein
    [ ] Verhandelbar

Abschnitt 8: Bestätigung

Abschnitt 8: Bestätigung

Ich bestätige, dass die in diesem Fragebogen bereitgestellten
Informationen nach bestem Wissen und Gewissen richtig und
vollständig sind.

Ich verstehe, dass [Ihr Unternehmen] sich für CRA-Compliance-
Zwecke auf diese Informationen verlässt und dass wesentliche
Falschangaben zur Vertragskündigung führen können.

Ausgefüllt von: _____________________________________
Titel: ______________________________________________
Datum: ______________________________________________
Unterschrift: _______________________________________

Warnsignale (Signale vor Vertragsschluss)

Diese Warnsignale sind Signale, die während der Fragebogenprüfung und der Vertragsverhandlung auffallen sollten, bevor eine Bestellung unterzeichnet wird. Für das einführerseitige Spiegelbild beim Inverkehrbringen des Produkts eines Nicht-EU-Herstellers auf dem EU-Markt siehe Was abzulehnen ist und warum auf der Einführer-Cluster-Seite.

Kritische Warnsignale (disqualifizieren die Beziehung)

Ernste Warnsignale (erfordern verhandelte Minderung)

Gelbe Warnsignale (während der Beziehung überwachen)

Verifizierungsprozess und Überwachung

Erstverifizierung

1. Dokumentensammlung

   • Kopie der EU-Konformitätserklärung anfordern
   • SBOM anfordern (oder Verfügbarkeitsbestätigung)
   • Sicherheitskontaktinformationen anfordern
   • Zusage zum Supportzeitraum anfordern

2. Dokumentenprüfung

   • EU-Konformitätserklärung auf Unterschrift und Vollständigkeit prüfen
   • Produktidentifikation auf Übereinstimmung prüfen
   • CE-Kennzeichnungsangaben verifizieren
   • SBOM-Format und Vollständigkeit prüfen

3. Compliance-Stichproben

   • security.txt verifizieren (falls webzugänglich)
   • CVD-Richtlinie auf Veröffentlichung prüfen
   • Sicherheitskontakt auf Antwort testen
   • Supportzeitraum-Angaben in der Dokumentation verifizieren

Laufende Überwachung

LIEFERANTEN-ÜBERWACHUNGSPLAN

Monatlich:
[ ] Auf veröffentlichte Sicherheitshinweise prüfen
[ ] Sicherheitskontakt auf Funktion verifizieren
[ ] Schwachstellen-Offenlegungen prüfen

Vierteljährlich:
[ ] Aktualisiertes SBOM anfordern (bei signifikanten Releases)
[ ] CVD-Richtlinie auf Zugänglichkeit verifizieren
[ ] Auf neue Zertifizierungen oder Verfälle prüfen

Jährlich:
[ ] Vollständige Fragebogen-Auffrischung
[ ] Supportzeitraum-Status prüfen
[ ] Dokumentation auf Verfügbarkeit verifizieren
[ ] Prüfung der geschäftlichen Stabilität

Trigger-basiert:
[ ] Größerer Sicherheitsvorfall → Sofortige Prüfung
[ ] Eigentümerwechsel → Vollständige Neubewertung
[ ] Produkteinstellung → EOL-Planung
[ ] Vertragsverlängerung → Compliance-Neuverifizierung

Wenn ein Lieferant nicht antwortet

Das mit Abstand häufigste operative Versagen in der Lieferantensorgfalt ist nicht eine missglückte Fragebogenantwort, sondern das Ausbleiben jeder Antwort. Der Lieferant ignoriert die Anfrage, verzögert über Monate oder schickt eine einzeilige Antwort „Wir halten alle geltenden Vorschriften ein". Es gibt keine gesetzliche Strafe gegen den Lieferanten (er hat keine CRA-Pflicht, Ihren Fragebogen zu beantworten), der Eskalationspfad muss daher kommerziell und prozessual sein.

ESKALATION BEI AUSBLEIBENDER LIEFERANTENANTWORT

WOCHE 1: Erster Fragebogen versendet
         Angemessenes Antwortfenster: 15 Werktage für Stufe 1,
         30 Werktage für Stufe 2, 45 für Stufe 3 bis 4.

WOCHE 3: Erste Nachfass an den benannten Sicherheitskontakt und
         den kommerziellen Hauptkontakt. CC an Beschaffungsleitung.

WOCHE 5: Eskalation an den Account Executive des Lieferanten und
         an Ihre eigene Beschaffungsdirektion. Hartes Datum setzen.

WOCHE 7: Falls weiterhin keine substanzielle Antwort:
         a) Nicht-Antwort in der Lieferantenakte dokumentieren
         b) Komponente als „compliance-unverified" kennzeichnen
         c) Bewertung eines Ersatzlieferanten anstoßen
         d) Produktverantwortliche informieren, die auf die
            Komponente angewiesen sind

WOCHE 9: Entscheidungspunkt.
         Substanzielle Antwort eingegangen → zur Prüfung übergehen.
         Keine Antwort → auf Ersatzlieferanten umstellen und
         die Umstellung als CRA-getriebene Entscheidung dokumentieren.

Nicht-Antwort ist selbst Sorgfaltsnachweis. Eine Marktüberwachungsbehörde, die fragt, warum Sie einen Lieferanten beendet haben, wird einen dokumentierten Eskalationsverlauf und eine Umstellungsentscheidung weit eher akzeptieren als ein vages „Sie waren schwierig in der Zusammenarbeit". Das Artefakt, das Sie aufbewahren, ist das datierte Eskalationsprotokoll plus die Entscheidungsnotiz.

Gemeinsam genutzte vorgelagerte Komponenten und koordinierte Prüfung

Wenn mehrere Hersteller dieselbe vorgelagerte Komponente integrieren (eine weitverbreitete Kryptographie-Bibliothek, ein gängiges Bildverarbeitungs-SDK, ein populäres eingebettetes OS), trägt jeder nachgelagerte Hersteller seine eigene Pflicht aus Artikel 13 Absatz 5. Die Pflicht wandert nicht auf den sorgfältigsten Peer, und „alle anderen nutzen es" ist keine Verteidigung.

Es gibt zwei Koordinationsmuster, die Doppelarbeit reduzieren, ohne die Pflicht abzugeben:

Die Sorgfaltsakte sollte die gemeinsam genutzte Prüfquelle ausdrücklich benennen: „Prüfbericht von [Arbeitsgruppe], datiert [X], geprüft und akzeptiert am [Y], Lücken nachverfolgt in [System]". Eine Kopie aus der Akte eines Peers ersetzt nicht Ihre eigene Entscheidungsdokumentation.

Nach M&A: geerbte Lieferantenbeziehungen

Wenn Ihr Unternehmen ein anderes übernimmt, erbt es auch dessen Lieferantenliste. Eine häufige Realität nach M&A sind dutzende oder hunderte Lieferantenbeziehungen ohne jegliche CRA-förmige Sorgfaltsakte. Die Arbeit lässt sich nicht über Nacht erledigen, eine Triage ist innerhalb eines Quartals jedoch machbar.

LIEFERANTEN-TRIAGE NACH M&A (90 TAGE)

TAG 1-15: Inventur
[ ] Lieferantenliste aus ERP/Beschaffungssystem der übernommenen
    Einheit ziehen
[ ] Querverweis zu aktuellen Produkt-BOMs
[ ] Identifizieren, welche Lieferanten in CRA-erfasste Produkte fließen
[ ] Außerhalb des Anwendungsbereichs liegende Lieferanten aus der
    aktiven Triage entfernen

TAG 15-30: Stufenbildung
[ ] Eigenes Stufenmodell auf die geerbte Liste anwenden
[ ] Lieferanten ohne bestehende Sorgfaltsakte markieren
[ ] Lieferanten markieren, deren Produkte in Wichtige Klasse II
    oder Kritisch fallen

TAG 30-60: Stufe-1-Fragebögen
[ ] Fragebogen an jeden Stufe-1-Lieferanten ohne Akte senden
[ ] Neuversand an jeden Stufe-1-Lieferanten, dessen Akte älter
    als 24 Monate ist
[ ] Antworten zentral erfassen

TAG 60-90: Entscheidungspunkt
[ ] Stufe-1-Lieferanten mit bestandenen Antworten → integriert
[ ] Stufe-1-Lieferanten mit Warnsignalen → Minderungsplan oder Ersatz
[ ] Stufe-2/3-Lieferanten → in den jährlichen Standardzyklus einplanen

LAUFEND:
[ ] Geerbte Lieferanten in den normalen Überwachungsplan überführen
[ ] M&A-Herkunft in der Lieferantenakte für das Audit markieren

Der CRA gewährt keine M&A-Schonfrist, die übernehmende Einheit erbt die Herstellerpflicht zum Datum des Abschlusses der Übernahme, für die Komponenten in den ausgelieferten Produkten. Die obige Triage ist der praktische Kompromiss: nachweisen, dass ein verteidigbares Sorgfaltsprogramm läuft, auch wenn die vollständige Akte erst noch aufgebaut wird.

N-Tier-Sichtbarkeit bei Unterbeauftragungen

Ihr Tier-1-Lieferant kann selbst an einen Tier-2-Lieferanten weitervergeben, der wiederum Komponenten aus einer Tier-3-Quelle integriert. Die CRA-Pflicht liegt bei Ihnen, unabhängig davon, wo in der Kette die Schwachstelle entsteht. Die praktische Sichtbarkeit endet jedoch schnell jenseits von Tier 1.

Drei konkrete Kontrollen, die echte N-Tier-Sichtbarkeit erkaufen:

• Transitive-SBOM-Klausel. Der Vertrag verlangt, dass das SBOM des Lieferanten transitive Abhängigkeiten enthält, nicht nur direkte. Ein SBOM nur mit direkten Abhängigkeiten verbirgt fast die gesamte tatsächliche Risikofläche.
• Subdienstleister-/Subunternehmer-Liste. Der Vertrag verlangt vom Lieferanten, die Liste benannter Subunternehmer offenzulegen und zu aktualisieren, die sicherheitsrelevante Teile der Komponente berühren. Die Klausel gibt kein Vetorecht, aber Sichtbarkeit.
• Schwachstellen-Durchreichung. Der Vertrag verlangt, dass der Lieferant Schwachstellen, die in transitiv integrierten Komponenten entdeckt werden, in derselben Frist an Sie weiterreicht wie Schwachstellen in direkt entwickeltem Code.

Ohne ein transitives SBOM können Sie keine Abhängigkeitsbaum-Scans gegen die Komponente fahren und einer Marktüberwachungsbehörde nicht zeigen, dass das N-Tier-Risiko bewertet wurde. Ohne eine Subdienstleister-Liste ist ein Subunternehmerwechsel der Quelle (mit eigener Herkunft, eigenen Kontrollen, eigenem Bus-Faktor) für Sie unsichtbar. Ohne Schwachstellen-Durchreichung wird das Schweigen des Tier-1-Lieferanten zu einem Tier-2-Problem zu Ihrem Schweigen bei einem Sicherheitsvorfall.

Klauseln für Lieferantenverträge

Nehmen Sie diese Bestimmungen in Lieferantenverträge auf. Jede Klausel ist der vertragliche Anker für eines der obigen Sorgfaltsergebnisse.

Compliance-Zusicherung:

Der Lieferant sichert zu und garantiert, dass das/die Produkt(e)
der Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung)
entsprechen und dass der Lieferant die erforderliche
Konformitätsbewertung durchgeführt hat.

Dokumentationsbereitstellung:

Der Lieferant stellt auf Anfrage bereit:
(a) Kopie der EU-Konformitätserklärung
(b) Software Bill of Materials im [CycloneDX/SPDX]-Format,
    einschließlich transitiver Abhängigkeiten
(c) Technische Dokumentation, die für die Compliance-
    Pflichten des Käufers relevant ist
Antwortzeit: [5 Werktage]

Schwachstellen-Benachrichtigung:

Der Lieferant benachrichtigt den Käufer innerhalb von [24/48]
Stunden nach Kenntniserlangung von jeder Sicherheitsschwachstelle
im/in den Produkt(en) oder in einer transitiv integrierten
Komponente, die:
(a) aktiv ausgenutzt wird, oder
(b) einen CVSS-Score von 7.0 oder höher hat, oder
(c) öffentlich offengelegt werden soll

Supportzeitraum-Verpflichtung:

Der Lieferant verpflichtet sich, Sicherheitsupdates für
das/die Produkt(e) für einen Mindestzeitraum von [5/7/10]
Jahren ab dem Datum der ersten Marktplatzierung in der EU
bereitzustellen.

SBOM-Aktualisierungen:

Der Lieferant stellt ein aktualisiertes SBOM innerhalb von
[10] Werktagen nach jedem Produkt-Release bereit, das
Änderungen an direkten oder transitiven Drittanbieter-
Komponenten enthält.

Auditrechte:

Der Käufer kann die Einhaltung dieser Vereinbarung und der
geltenden CRA-Anforderungen durch den Lieferanten nach
[30 Tagen] schriftlicher Vorankündigung prüfen, nicht öfter
als einmal pro Jahr, es sei denn, ein Compliance-Anlass löst
eine zusätzliche Prüfung aus.

Subunternehmer-Offenlegung:

Der Lieferant pflegt und stellt auf Anfrage eine Liste der
Subunternehmer bereit, die zu sicherheitsrelevanten
Komponenten des/der Produkt(e) beitragen oder Zugriff darauf
haben. Der Lieferant benachrichtigt den Käufer über jede
wesentliche Änderung dieser Liste innerhalb von [30] Tagen.

Häufige Fehler

Auf Selbstauskunft vertrauen

Problem: Mündliche Zusicherungen des Lieferanten ohne Dokumentation akzeptieren.

Lösung: Immer schriftliche Nachweise einholen. Keine Kopie der EU-Konformitätserklärung, kein Kauf. Ein unterzeichneter Fragebogen ist die Untergrenze, nicht die Obergrenze.

Einmalige Bewertung

Problem: Sorgfaltspflicht nur bei Vertragsabschluss.

Lösung: Den obigen Überwachungsplan einführen. Der Compliance-Zustand ändert sich, Fragebögen veralten.

Stufe-3- und Stufe-4-Lieferanten ignorieren

Problem: Nur „große" Lieferanten bewerten, kleinere ignorieren.

Lösung: Auch kleine Komponenten bringen Schwachstellen ein (die Log4j-Lehre). Bewertung skalieren, die Stufe nicht überspringen.

Keine vertragliche Absicherung

Problem: Auf das Wohlwollen des Lieferanten ohne Vertragsbedingungen vertrauen.

Lösung: Compliance-Pflichten schriftlich festhalten. Die obigen Klauseln sind die Untergrenze.

Bis Dezember 2027 warten

Problem: Lieferantenbewertungen erst kurz vor dem CRA-Anwendungsdatum starten.

Lösung: Jetzt starten. Anbieterantworten verzögern sich. Nicht-konforme Lieferanten brauchen Monate für Sanierung oder Ersatz.

Lieferanten-Sorgfaltspflicht-Checkliste

LIEFERANTEN-SORGFALTSPFLICHT-CHECKLISTE

VOR BEAUFTRAGUNG:
[ ] Lieferantenstufe bestimmt (1/2/3/4)
[ ] Lieferantentyp bestimmt (kommerziell, FOSS, OSS-Treuhänder,
    Cloud, reine Hardware, modifizierte COTS)
[ ] Passende Fragebogenvariante ausgewählt
[ ] Interner Prüfer zugewiesen

ERSTBEWERTUNG:
[ ] Fragebogen versendet
[ ] Fragebogen empfangen und geprüft
[ ] Warnsignale identifiziert und adressiert
[ ] Dokumentation gesammelt:
    [ ] EU-Konformitätserklärung (oder Begründung „nicht zutreffend")
    [ ] SBOM mit transitiven Abhängigkeiten (oder Verfügbarkeit bestätigt)
    [ ] CVD-Richtlinie
    [ ] Zusage zum Supportzeitraum
[ ] Stichproben abgeschlossen:
    [ ] security.txt verifiziert
    [ ] Sicherheitskontakt getestet
    [ ] CE-Kennzeichnung verifiziert

VERTRAGSVERHANDLUNG:
[ ] Compliance-Klauseln aufgenommen
[ ] Dokumentationsbestimmungen vereinbart
[ ] Schwachstellen-Benachrichtigungsbedingungen festgelegt (Stunden, nicht „unverzüglich")
[ ] Supportzeitraum-Zusage gesichert
[ ] Auditrechte aufgenommen
[ ] SBOM-Aktualisierungsplan vereinbart
[ ] Subunternehmer-Offenlegungsklausel aufgenommen

NACH VERTRAGSABSCHLUSS:
[ ] Überwachungsplan etabliert
[ ] Erste Dokumentationslieferung bestätigt
[ ] Kontakte im Lieferantenmanagement-System registriert
[ ] Prüfungstermine im Kalender

LAUFEND:
[ ] Monatliche Prüfungen abgeschlossen
[ ] Vierteljährliche Prüfungen abgeschlossen
[ ] Jährliche Neubewertung abgeschlossen
[ ] Trigger-Ereignisse behandelt (Vorfall, Eigentümerwechsel, EOL)

Verwandte Leitfäden

• Wie man ein CRA-konformes SBOM erstellt: Tools, Formate und CI/CD-Integration
• Der CRA-Hersteller-Leitfaden
• CRA-Händler-Checkliste

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Anleitung konsultieren Sie qualifizierten Rechtsberater.