124% mehr gemeldete CVEs pro Tag in 2026 als im Vorjahr.

Leitfaden zum Cyber Resilience Act

CRA-Anforderungen Schritt für Schritt

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

Der aktuelle Stand

  • Die Meldepflichten gelten bereits. Seit dem 11. September 2026 melden Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, auch für bereits auf dem Markt befindliche Produkte.
  • Alles andere gilt ab dem 11. Dezember 2027. Produkte, die vorher in Verkehr gebracht werden, fallen nur unter den Rest des CRA, wenn sie wesentlich verändert werden.
  • Die Leitlinien liegen vor. Die unverbindlichen Leitlinien C(2026) 5252 der Kommission vom 27. Juli 2026 erläutern Anwendungsbereich, wesentliche Veränderung, Unterstützungszeiträume und Meldungen, und die Durchführungsverordnung (EU) 2025/2392 beschreibt die Kategorien wichtiger und kritischer Produkte.
CRA timeline The CRA was adopted in 2024 as Regulation (EU) 2024/2847. Its reporting obligations apply from 11 September 2026, including for products already on the market, and the regulation applies in full from 11 December 2027. 2024 Adopted as Regulation (EU) 2024/2847 11 September 2026 Reporting obligations apply, also for products already on the market 11 December 2027 The regulation applies in full Now Reporting clock is running Plan the SBOM and vulnerability handling before full application

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 Roadmap: zehn Schritte

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.

  1. 1

    Anwendungsbereich und Ihre Rolle bestätigen

    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.

    Zuständig
    Produktmanagement mit Rechtsabteilung
    Aufzubewahrende Nachweise
    Ein Produktinventar mit Entscheidungen zum Anwendungsbereich und Ihrer jeweiligen Rolle
    Produkt mit dem CRA Checker prüfen →
    Who the CRA applies to The CRA places obligations on manufacturers, importers and distributors of products with digital elements made available on the EU market, including software and hardware with embedded software. Economic operators Manufacturers Importers Distributors Most obligations fall on the manufacturer Products with digital elements Software products IoT devices Hardware with embedded software The test Is the product made available on the EU market? If so, its manufacturer carries the CRA obligations
  2. 2

    Jedes Produkt einstufen

    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.

    Zuständig
    Produktmanagement mit Compliance
    Aufzubewahrende Nachweise
    Die Kategorie jedes Produkts und die Begründung dafür
  3. 3

    Cybersicherheitsrisiko bewerten

    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.

    Zuständig
    Sicherheit mit Entwicklung
    Aufzubewahrende Nachweise
    Eine dokumentierte Risikobewertung pro Produkt
  4. 4

    Den Unterstützungszeitraum festlegen

    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.

    Zuständig
    Produktmanagement
    Aufzubewahrende Nachweise
    Der Unterstützungszeitraum, veröffentlicht, wo Nutzer ihn sehen
  5. 5

    Aus jedem Release-Build eine SBOM erzeugen

    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.

    Zuständig
    Entwicklung
    Aufzubewahrende Nachweise
    Eine SBOM pro Release als CycloneDX oder SPDX

    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.

    An SBOM recorded during the build Packages from npm, PyPI, Cargo, Go, OCI registries and the CI cache pass through a package-aware proxy on the CRACI runner. The job's SBOM lists what was fetched, states its completeness and exports as CycloneDX or SPDX. Package sources npm PyPI Cargo · Go OCI registries CI cache restore Package- aware proxy on the runner Job SBOM express 5.2.1 requests 2.32.3 serde 1.0.219 + transitive deps Declared license on every component Complete Completeness states per job and cache: Complete, Complete with connections, Incomplete, Unavailable, Not recorded CycloneDX · SPDX
  6. 6

    Das Ausgelieferte überwachen und unverzüglich beheben

    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.

    Zuständig
    Sicherheit mit den Teams, die für das jeweilige Produkt zuständig sind
    Aufzubewahrende Nachweise
    Befunde, Triage-Entscheidungen, Fixes und die Updates, mit denen sie ausgeliefert wurden

    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.

  7. 7

    Eine Richtlinie zur Offenlegung von Schwachstellen veröffentlichen

    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.

    Zuständig
    Sicherheit
    Aufzubewahrende Nachweise
    Die veröffentlichte Richtlinie, die Kontaktadresse und Ihre Security Advisories
  8. 8

    Die 24-Stunden-Meldefrist proben

    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.

    Zuständig
    Sicherheit oder Incident Response
    Aufzubewahrende Nachweise
    Ein Runbook für Meldungen mit benannten Zuständigen und die eingereichten Meldungen

    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.

    CRA notifications, submitted for you When a vulnerability is actively exploited, the CRA sets deadlines: an early warning within 24 hours, a notification within 72 hours and a final report 14 days after a fix is available. CRACI submits them through the CRA Single Reporting Platform to the CSIRT and ENISA on the manufacturer's behalf. Actively exploited vulnerability found Aware 24 hours Early warning 72 hours Notification Fix + 14 days Final report CRACI submits on your behalf Through the CRA Single Reporting Platform to the CSIRT and ENISA and shows which products and releases are affected What stays with you The reporting obligation itself Informing affected users Severe incidents: final report within one month
  9. 9

    Die grundlegenden Anforderungen in die Entwicklung einbauen

    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.

    Zuständig
    Entwicklung
    Aufzubewahrende Nachweise
    Ergebnisse von Sicherheitstests und Release-Prüfungen

    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.

  10. 10

    Die Dokumentation zusammenstellen und die Konformitätsbewertung bestehen

    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.

    Zuständig
    Compliance mit Entwicklung
    Aufzubewahrende Nachweise
    Technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung

    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.

    Evidence for the conformity assessment CRACI supplies technical evidence: build-time SBOMs, vulnerability and remediation records, provenance and network traces, with SBOMs exported as CycloneDX or SPDX and the rest returned by the API. The manufacturer uses it in the technical documentation, runs the conformity assessment, by self-assessment or with a notified body, draws up the EU declaration of conformity and applies the CE marking. CRACI supplies the evidence Build-time SBOMs Vulnerability records Provenance Network traces The manufacturer's process Technical documentation Conformity assessment: self-assessment or notified body EU declaration of conformity CE marking CRACI does not assess, certify or manage the assessment

Anforderungen und die Nachweise dahinter

Marktüberwachungsbehörden können Ihre technische Dokumentation anfordern. Das hinterlässt jede Anforderung, und das zeichnet CRACI davon aus Ihren Builds auf.

AnforderungFundstelleAufzubewahrende NachweiseVon 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