Die Lieferkettenpflichten des Cyber Resilience Acts (CRA) gehen über die reine Komponentenauswahl hinaus: Sie umfassen eine strukturierte Risikobeurteilung, eine eigenständige Due-Diligence-Pflicht und ein aktives Schwachstellenmanagement über den gesamten Unterstützungszeitraum. Wir erklären die CRA-Pflichten für Hersteller und wo ihre Verantwortung endet.
In aller Kürze
- Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller, die Cybersicherheit ihrer Produkte über den gesamten Lebenszyklus zu gewährleisten.
- Unter diese Pflicht fallen auch alle integrierten Drittkomponenten, proprietäre Software, Hardware-Bausteine und Open-Source-Pakete gleichermaßen.
- Dafür fordert der CRA vor allem Risikobeurteilung, Due Diligence und aktives Schwachstellenmanagement.
Warum ist Komponentenauswahl die Grundlage der Lieferkettensicherheit unter dem CRA?
Moderne Softwareprodukte setzen sich aus eigenen Codebestandteilen, Bibliotheken von Drittanbietern, Hardware-Bausteinen und Cloud-Diensten zusammen. Der CRA trägt dieser Realität Rechnung: Wer ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt, haftet für die CRA-Konformität dieses Produkts in seiner Gesamtheit – einschließlich aller integrierten Bestandteile, unabhängig von deren Herkunft.
Der vorliegende Artikel konzentriert sich auf die strukturellen Lieferkettenpflichten, die für alle Arten von Drittkomponenten gelten – proprietäre Software, Hardware-Bausteine und Open-Source-Pakete gleichermaßen.
Tipp: Wann ein Unternehmen durch die Integration von Open-Source-Software zum Hersteller wird bis hin zur Rolle von Open-Source-Stewards finden Sie in unserem Artikel zum Open-Source-Management unter dem CRA.
Was versteht der CRA unter integrierten Komponenten?
Ein Produkt mit digitalen Elementen ist gemäß Art. 3 Nr. 1 CRA definiert als
„ein Software- oder Hardwareprodukt und seine Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die gesondert in Verkehr gebracht werden”.
Integrierte Komponenten sind Software- oder Hardware-Bausteine, die physisch oder logisch in das Endprodukt eingebettet werden und dessen Funktion mitbestimmen.
Externe Software, welche notwendig ist für eine Funktion eines Produkts mit digitalen Elementen, gilt als Komponente. Externe Software wird nie als Datenfernverarbeitungslösung im Sinne von Art. 3 Nr. 2 CRA angesehen, da sie nicht vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wurde. Es ist nicht notwendig das diese externe Software Kernfunktionen übernimmt.
Tipp: In unserem Whitepaper zu Produkten unter dem CRA finden Sie Erläuterungen zu Datenfernverarbeitungslösungen. Weitere Informationen auch im speziellen Ratgeber zur Bedeutung des CRA für SaaS-Anbieter in der Lieferkette.
Was sind die wichtigsten CRA-Pflichten bei der Komponentenauswahl?
Der CRA unterscheidet zwischen zwei komplementären, aber rechtlich eigenständigen Pflichten für Hersteller in Bezug auf die Lieferkette und externen Komponenten: Risikobeurteilung und Due Diligence.
Pflicht 1: Cybersicherheits-Risikobeurteilung (Art. 13 Abs. 1 CRA)
Die Risikobeurteilung bezieht sich auf das Produkt als Ganzes. Sie erfasst alle relevanten Risiken, die das Produkt betreffen können – einschließlich solcher, die von außen einwirken, etwa aus unsicheren Netzwerkumgebungen, externen Diensten oder dem Betriebskontext.
Der Hersteller muss diese Risiken identifizieren und durch das Produktdesign mitigieren. Dabei muss er die externe Umgebung nicht kontrollieren oder steuern – wohl aber sicherstellen, dass sein Produkt gegenüber den identifizierten externen Risiken widerstandsfähig ist.
Auch integrierte Drittkomponenten fließen in die Risikobeurteilung ein: Ihre sicherheitsrelevanten Eigenschaften müssen bewertet und die identifizierten Risiken durch Maßnahmen auf Produktebene adressiert werden.
Pflicht 2: Sorgfaltspflicht (Due Diligence) bei Drittkomponenten (Art. 13 Abs. 5 CRA)
Die Due-Diligence-Pflicht betrifft ausschließlich Komponenten, die physisch oder logisch in das Produkt integriert sind und von einem Dritten bezogen werden. Der Hersteller muss sicherstellen, dass diese Komponenten die Konformität des Endprodukts mit den wesentlichen Cybersicherheitsanforderungen nicht gefährden.
Während die Risikobeurteilung also das Produkt als Ganzes im Blick hat, richtet sich die Due Diligence konkret auf die Eigenschaften der einzelnen Drittkomponente. Der Hersteller muss risikobasiert prüfen, ob die Komponente die Sicherheitsanforderungen des Endprodukts erfüllt – und diesen Nachweis dokumentieren.
Die EU-Kommission betont in ihren Leitlinien zur Umsetzung des CRA, dass die Due Diligence ist keine Formalität ist, sondern eine inhaltliche Auseinandersetzung mit den Sicherheitseigenschaften der Komponente erfordert.
Wie sieht angemessene Due Diligence unter dem CRA in der Praxis aus?
Das angemessene Maß an Due Diligence hängt von der Art und dem Ausmaß des Cybersecurity-Risikos einer bestimmten Komponente ab und soll sicherstellen, dass die integrierten Komponenten die Cybersecurity des Produkts mit digitalen Elementen eines Herstellers nicht gefährden. Die Risikobewertung des Produkts mit digitalen Elementen liefert ebenfalls Informationen über das angemessene Maß an Due Diligence. Wenn eine Komponente oder ein Produkt mit mehr Risiken verbunden ist, sollten die Maßnahmen, die ein Hersteller im Rahmen der Due Diligence ergreifen sollte, umfangreicher sein als bei einer Komponente oder einem Produkt, das mit weniger Risiken verbunden ist.
In Einklang mit der Erwägungsgrundlage 34 CRA können die Hersteller unter anderem folgende Maßnahmen ergreifen:
- prüfen, ob die Komponente bereits die CE-Kennzeichnung trägt;
- prüfen, ob die Komponente regelmäßig Sicherheitsupdates erhält, z. B. durch Prüfung des Sicherheitsupdateverlaufs;
- in der eingerichteten europäischen Datenbank für Schwachstellen oder in anderen öffentlich zugänglichenDatenbanken für Schwachstellen nachprüfen, welche Schwachstellen für die Komponente gelten, und das Produkt mit digitalen Elementen so konzipieren, entwickeln und herstellen, dass die Komponente in die digitalen Elemente integriert ist und diese Schwachstellen die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen;
- zusätzliche Sicherheitstests durchführen, z. B. Fuzzing-Tests, Penetrationstests, Firmware-Analysen, Side-Channel-Analysen, Red-Team-Übungen, Analyse des Netzwerktraffics, Spoofing von Sensoren;
- Durchführung einer Softwarekompositionsanalyse der Komponente;
- Sandboxing oder Isolierung von besonders kritischen Komponenten;
- sofern verfügbar, Überprüfung der SBOM der Komponente;
- Überprüfung des Supportzeitraums der Komponente;
- Überprüfung, ob der Verwendungszweck der Komponente mit der Verwendung durch den integrierenden Hersteller übereinstimmt;
- Bewertung der Sicherheitslage des Herstellers der Komponente.
Muss eine Komponente ein CE-Kennzeichen tragen?
Nein – die CE-Kennzeichnung ist kein zwingendes Auswahlkriterium. Der CRA verlangt keine ausschließliche Integration von CE-gekennzeichneten Komponenten. Entscheidend ist, ob die Komponente die sicherheitsbezogenen Anforderungen des Produkts erfüllt. Eine CE-Kennzeichnung erleichtert den Nachweis erheblich, ist aber nicht der einzige zulässige Weg.
Die Integration von Komponenten, die die CE-Kennzeichnung tragen, kann jedoch bestimmte Verpflichtungen vereinfachen, z.B. die Behandlung von Schwachstellen in integrierten Komponenten.
Hinweis: Für Open-Source-Komponenten sieht der CRA in Art. 25 außerdem die Möglichkeit freiwilliger Sicherheitsbescheinigungen vor. Mehr dazu im Ratgeber zum Open-Source-Management unter dem CRA.
Wer ist für Schwachstellen in integrierten Komponenten verantwortlich?
Die Schwachstellen-Behandlungspflichten des CRA (Anhang I, Teil II) gelten für das Produkt in seiner Gesamtheit – also auch für Schwachstellen, die in integrierten Fremdbausteinen entdeckt werden. Dabei gilt ein differenziertes System:
Komponente unterliegt selbst dem CRA
Wenn die integrierte Komponente selbst dem CRA unterliegt, kann der integrierende Hersteller auf die Schwachstellen-Behandlungspflichten des Komponentenherstellers zurückgreifen. Er bleibt jedoch selbst verpflichtet, seine Nutzer zu informieren, Mitigationsmaßnahmen bereitzustellen und seine Dokumentation zu aktualisieren.
Komponente unterliegt nicht dem CRA
Wenn die Komponente nicht dem CRA unterliegt – etwa weil sie vor Anwendung des CRA auf den Markt gebracht wurde oder nicht als Produkt mit digitalen Elementen zählt –, muss der integrierende Hersteller die Schwachstelle eigenständig adressieren: durch Deaktivierung betroffener Funktionen, Austausch der Komponente oder Entwicklung eines eigenen Patches. Gemäß Art. 13 Abs. 6 CRA ist ein selbst entwickelter Patch an den Entwickler oder Maintainer der Komponente weiterzugeben.
Auslaufen des Komponentensupports
Besondere Aufmerksamkeit verdient das Auslaufen des Unterstützungszeitraums einer integrierten Komponente: Wenn ein zentraler Baustein nicht mehr mit Sicherheitsupdates versorgt wird, während das Endprodukt noch im Unterstützungszeitraum ist, muss der Hersteller eigenständig für eine Lösung sorgen – sei es durch Komponentenaustausch, eigene Patches oder, als letztes Mittel, durch Rückruf des Produkts nach Art. 13 Abs. 21 CRA. Hersteller sollten daher beim Festlegen des eigenen Unterstützungszeitraums die Support-Horizonte ihrer zentralen Drittkomponenten von Anfang an einplanen.
Warum ist eine SBOM die praktische Grundlage jeder Lieferkettenkontrolle?
Eine zentrale praktische Konsequenz der Lieferkettenpflichten ist die Anforderung, eine Software Bill of Materials (SBOM) zu erstellen und zu pflegen. Die technische Dokumentation nach Anhang VII CRA muss eine Aufstellung der Software-Komponenten des Produkts enthalten – vergleichbar einem Zutatenverzeichnis. Nur wer seine Komponentenbasis kennt, kann Schwachstellen in integrierten Bausteinen überhaupt identifizieren, bewerten und an Nutzer kommunizieren.
In der Praxis sollte die SBOM nicht als punktuelle Momentaufnahme verstanden werden, sondern als lebendes Dokument, das mit jeder Produktversion aktualisiert wird.
Besondere Herausforderung stellen transitive Abhängigkeiten dar – Komponenten, die ihrerseits auf weitere Open-Source-Bausteine zurückgreifen. Ohne automatisierte Software-Composition-Analysis-Tools lässt sich diese Tiefe kaum manuell überblicken.
Fazit: Lieferkettensicherheit ist eine strukturelle Daueraufgabe
Der CRA macht deutlich: Cybersicherheit endet nicht an der eigenen Codezeile. Wer fremde Komponenten integriert – ob proprietär, als Hardware-Baustein oder als Open-Source-Paket –, übernimmt Verantwortung für deren Sicherheitseigenschaften über den gesamten Produktlebenszyklus.
Die Lieferkettenpflichten des CRA sind dabei keine einmalige Prüfaufgabe, sondern eine strukturelle Daueraufgabe: Sie beginnen bei der Komponentenauswahl, setzen sich in der laufenden Schwachstellenbeobachtung fort und enden erst mit dem Ablauf des Unterstützungszeitraums.
Hersteller sollten daher frühzeitig Prozesse etablieren, die eine vollständige Erfassung aller Drittkomponenten (SBOM), eine risikobasierte Bewertung ihrer Sicherheitseigenschaften und ein strukturiertes Monitoring von Schwachstellen gewährleisten. Nur wer seine Lieferkette kennt und dokumentiert, kann für sein Produkt einstehen – und das ist unter dem CRA ab dem 11. Dezember 2027 rechtlich verpflichtend.