Cyber Resilience Act
Checkliste zur Bereitschaft für Hersteller
Nutzen Sie diese Checkliste, um Zuständigkeiten zu verteilen und Nachweise zu sammeln, während Sie Produkte mit digitalen Elementen auf den CRA vorbereiten.
Leitfaden zum Cyber Resilience Act
Eine praktische Roadmap für die Teams, die Produkte mit digitalen Elementen entwickeln: was zu tun ist, wer zuständig ist und welche Nachweise aufzubewahren sind. Was das Gesetz sagt, lesen Sie unter Was ist der Cyber Resilience Act.
Zuletzt aktualisiert am 15. Oktober 2026
What the Cyber Resilience Act asks manufacturers to do
Der Geltungsbereich der Verordnung (EU) 2024/2847, die Termine, ab denen sie gilt, die Meldefristen und wo die Pflichten zu SBOM und Schwachstellenbehandlung stehen.
Petteri Pulkkinen und Erika Marttinen bei Kubernetes Community Days Helsinki 2026, 8:03 bis 15:20 aus SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Die Schritte verlaufen ungefähr in dieser Reihenfolge, aber für bereits auf dem Markt befindliche Produkte sind die Schritte 5 bis 8 zuerst wichtig, denn die Meldepflichten gelten für sie bereits.
Listen Sie jedes Produkt mit digitalen Elementen auf, das Sie in der EU bereitstellen, einschließlich eigenständig verkaufter Software und der Cloud-Backends, die Produkte zum Funktionieren brauchen. Bestätigen Sie für jedes, dass es nicht ausgenommen ist (Medizinprodukte, Fahrzeuge, Luftfahrt, Schiffsausrüstung, Verteidigung) und ob Sie sein Hersteller, Einführer oder Händler sind.
Produkt mit dem CRA Checker prüfen →Die meisten Produkte gehören zur Standardkategorie. Vergleichen Sie Ihre Produkte mit den Listen wichtiger (Anhang III) und kritischer (Anhang IV) Produkte; die Durchführungsverordnung (EU) 2025/2392 enthält deren technische Beschreibungen. Die Kategorie entscheidet, ob Sie eine Selbstbewertung durchführen dürfen oder eine benannte Stelle oder Zertifizierung brauchen.
Erstellen Sie für jedes Produkt eine Cybersicherheits-Risikobewertung. Sie entscheidet, wie die grundlegenden Anforderungen aus Anhang I gelten, und gehört in die technische Dokumentation. Aktualisieren Sie sie, wenn sich das Produkt oder die Bedrohungen ändern.
Legen Sie fest, wie lange Sie Schwachstellen für jedes Produkt behandeln: mindestens fünf Jahre, sofern das Produkt nicht voraussichtlich kürzer genutzt wird. Informieren Sie Nutzer, wann die Unterstützung endet, und halten Sie jedes Sicherheitsupdate mindestens 10 Jahre verfügbar.
Der CRA verlangt eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten erfasst. Wenn Sie sie in dem Build erzeugen, der das Release herstellt, statt einmalig von Hand, bleibt sie dem Ausgelieferten treu.
Wo CRACI hilft: CRACI zeichnet die SBOM auf, während jeder Build läuft, einschließlich transitiver Abhängigkeiten und aus Caches wiederhergestellter Pakete, und exportiert sie als CycloneDX oder SPDX.
Beobachten Sie während des gesamten Unterstützungszeitraums veröffentlichte Versionen, nicht nur den Main-Branch, auf neue Schwachstellen. Beheben Sie sie unverzüglich, liefern Sie Sicherheitsupdates kostenlos und, wo machbar, getrennt von Funktionsupdates aus.
Wo CRACI hilft: CRACI prüft überwachte SBOMs nach der Auslieferung erneut auf neue Schwachstellen, und Sicherheitsteams sichten Befunde und leiten sie an die Teams weiter, die für den Fix zuständig sind. Policy-Gates können einen Build aufgrund von Befunden blockieren.
Geben Sie Forschenden und Kunden eine Kontaktstelle für die Meldung von Schwachstellen und eine Richtlinie zur koordinierten Offenlegung von Schwachstellen. Sobald ein Update verfügbar ist, veröffentlichen Sie Informationen zu den Schwachstellen, die es behebt.
Seit dem 11. September 2026 erfordert eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht über die Single Reporting Platform. Benennen Sie, wer die aktive Ausnutzung bestätigt, wer meldet und wer die Nutzer informiert. Das Schwierige ist, innerhalb von Stunden zu wissen, welche Produkte und Releases die verwundbare Komponente enthalten.
Wo CRACI hilft: Die Build-Historie von CRACI zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, die Inventaransicht zeigt, welche Versionen auf welchen Produkten im Einsatz sind, und CRACI übermittelt die CRA-Meldungen in Ihrem Namen.
Liefern Sie ohne bekannte ausnutzbare Schwachstellen und mit sicherer Standardkonfiguration aus, schützen Sie Daten und Zugriffe, begrenzen Sie die Angriffsfläche und ermöglichen Sie Sicherheitsupdates, standardmäßig automatisch, wo anwendbar. Testen und prüfen Sie die Sicherheit regelmäßig.
Wo CRACI hilft: CRACI setzt eine Egress-Richtlinie dafür durch, was Builds herunterladen dürfen, und Policy-Gates können einen Build aufgrund von Befunden blockieren.
Stellen Sie die in Anhang VII beschriebene technische Dokumentation zusammen, führen Sie die Konformitätsbewertung für Ihre Kategorie durch, erstellen Sie die EU-Konformitätserklärung und bringen Sie die CE-Kennzeichnung an. Bewahren Sie Dokumentation und Erklärung mindestens 10 Jahre oder für den Unterstützungszeitraum auf, je nachdem, was länger ist.
Wo CRACI hilft: CRACI exportiert SBOMs als CycloneDX oder SPDX, einschließlich der in ihren Komponenten gefundenen Schwachstellen, und seine API liefert SBOMs, Netzwerk-Traces und Provenienzdaten für Ihre technische Dokumentation. Bewertung und Erklärung bleiben Ihr Prozess.
Marktüberwachungsbehörden können Ihre technische Dokumentation anfordern. Das hinterlässt jede Anforderung, und das zeichnet CRACI davon aus Ihren Builds auf.
| Anforderung | Fundstelle | Aufzubewahrende Nachweise | Von CRACI |
|---|---|---|---|
| Cybersicherheits-Risikobewertung | Artikel 13, Anhang I | Dokumentierte Bewertung pro Produkt | Ihr Prozess |
| Keine bekannten ausnutzbaren Schwachstellen beim Release | Anhang I Teil I | Schwachstellenstatus des Release-Builds | SBOM des Release-Builds gegen Advisories geprüft; Policy-Gates |
| Software-Stückliste | Anhang I Teil II | Maschinenlesbare SBOM pro Release | Aus jedem Build aufgezeichnet, CycloneDX oder SPDX |
| Umgang mit Schwachstellen während des Unterstützungszeitraums | Artikel 13, Anhang I Teil II | Befunde, Triage-Entscheidungen, Fixes, Advisories | Laufende Neubewertung, Triage, VEX |
| Sorgfaltspflicht bei Komponenten von Dritten | Artikel 13 | Komponentenaufzeichnungen, auch zu zugekaufter Software | Hersteller-SBOMs zusammen mit Ihren eigenen überwacht; deklarierte Lizenzen |
| Meldung ausgenutzter Schwachstellen und schwerwiegender Vorfälle | Artikel 14 | Frühwarnungen, Meldungen, Abschlussberichte | Übermittelt die Meldungen in Ihrem Namen |
| Unterstützungszeitraum | Artikel 13 | Veröffentlichtes Enddatum der Unterstützung | Ihr Prozess |
| Technische Dokumentation und Erklärung | Artikel 13, Anhang VII | 10 Jahre oder für den Unterstützungszeitraum aufbewahrt | SBOM-Export und API-Daten für die Dokumentation |
Cyber Resilience Act
Nutzen Sie diese Checkliste, um Zuständigkeiten zu verteilen und Nachweise zu sammeln, während Sie Produkte mit digitalen Elementen auf den CRA vorbereiten.
Praktische Fragen von Teams, die mit dem CRA beginnen
Die grundlegenden Anforderungen aus Anhang I auf Basis einer Cybersicherheits-Risikobewertung erfüllen, eine SBOM führen, Schwachstellen während eines Unterstützungszeitraums von mindestens fünf Jahren behandeln, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, die technische Dokumentation führen, eine Konformitätsbewertung bestehen und die CE-Kennzeichnung anbringen.
Beim Anwendungsbereich und den Meldungen. Finden Sie heraus, welche Produkte der CRA erfasst, und stellen Sie dann sicher, dass Sie die 24-Stunden-Frühwarnung für eine aktiv ausgenutzte Schwachstelle einhalten könnten, denn die Meldepflichten gelten seit dem 11. September 2026, auch für bereits auf dem Markt befindliche Produkte. Der Rest gilt ab dem 11. Dezember 2027.
Anhang VII führt es auf. Dazu gehören die Cybersicherheits-Risikobewertung des Produkts, die SBOM und Informationen dazu, wie der Hersteller mit Schwachstellen umgeht. Sie wird mindestens 10 Jahre oder für den Unterstützungszeitraum aufbewahrt, je nachdem, was länger ist, und Marktüberwachungsbehörden auf Anfrage vorgelegt.
Nein. Die SBOM ist Teil der technischen Dokumentation und geht auf Anfrage an eine Marktüberwachungsbehörde. Die Verordnung verlangt nicht, sie zu veröffentlichen.
Ja. Am 27. Juli 2026 veröffentlichte die Europäische Kommission unverbindliche Leitlinien, C(2026) 5252, mit 67 praktischen Beispielen. Sie behandeln Datenfernverarbeitung, freie und quelloffene Software, wesentliche Veränderungen, Unterstützungszeiträume, Meldungen und Risikobewertung. Die Durchführungsverordnung (EU) 2025/2392 beschreibt die Kategorien wichtiger und kritischer Produkte.
Die Pflichten sind dieselben, aber gegen Kleinst- und Kleinunternehmen werden keine Geldbußen wegen versäumter 24-Stunden-Frühwarnung verhängt, und die Leitlinien der Kommission sind mit Blick auf Kleinstunternehmen und KMU verfasst.
Nein. Die Einhaltung des CRA ist der Prozess des Herstellers, einschließlich Risikobewertung, Konformitätsbewertung und Erklärung. CRACI automatisiert einen wesentlichen Teil der Transparenz über die Lieferkette und der Nachweise, die dieser Prozess braucht: SBOMs aus jedem Build, Schwachstellenverfolgung nach dem Release und die CRA-Meldungen.
Sehen Sie, wie CRACI aus jedem Build eine SBOM aufzeichnet, das Ausgelieferte überwacht und CRA-Meldungen in Ihrem Namen übermittelt