Wissens-Hub: Cyber Resilience Act

CRA: Was seit September gilt. Und was bis Dezember 2027 kommt.

Zuletzt aktualisiert: 09. November 2026
Lesedauer: 10 Minuten

Quick Win

Der Cyber Resilience Act kommt in zwei Stufen. Seit dem 11. September 2026 gilt die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Ab dem 11. Dezember 2027 gilt der volle Anforderungskatalog. Wer den Meldeprozess aufgesetzt hat, hat jetzt gut 13 Monate für den Rest. Das reicht, wenn ihr jetzt startet. Es reicht nicht, wenn ihr bis Herbst 2027 wartet.

💡 Key Takeaways

Seit 11. September 2026:
Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Frühwarnung innerhalb von 24 Stunden.
Ab 11. Dezember 2027:
Voller Katalog mit Security by Design, SBOM und Update-Pflichten.
Noch kein Meldeprozess?
Dann ist das jetzt Priorität Nummer eins, denn die Pflicht gilt bereits.
Der CRA betrifft auch Open Source.
Kommerziell genutzte Open-Source-Komponenten fallen unter den CRA, nicht-kommerzielle OSS-Projekte nicht.
Ein Thema für die Entwicklung.
Der CRA ist eine Aufgabe für euren Entwicklungsprozess, nicht nur für die Rechtsabteilung.

Zwei Fristen, eine Verwechslungsgefahr

Der Cyber Resilience Act, kurz CRA, ist seit Dezember 2024 als EU-Verordnung 2024/2847 in Kraft [1]. Seitdem kursiert viel zum Thema. Meistens vermischt als ein großer Block: „CRA kommt, alles muss sicher sein, sonst Bußgeld.“ Das stimmt technisch, hilft aber niemandem bei der Priorisierung.

Tatsächlich hat der CRA einen gestaffelten Zeitplan. Der erste Meilenstein: Seit dem 11. September 2026 sind Melde- und Schwachstellenmanagement-Pflichten verbindlich. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb festgelegter Fristen an die zuständige Behörde melden. Der zweite, deutlich größere Meilenstein: Ab dem 11. Dezember 2027 gilt der vollständige Anforderungskatalog für alle betroffenen Produkte.

Das ist der Kern, den viele Artikel zum Thema unterschlagen. Die erste Frist gilt seit dem 11. September 2026. Bis zur zweiten bleiben ab heute gut 13 Monate.

Was seit September 2026 gilt

Seit dem 11. September 2026 müsst ihr aktiv ausgenutzte Schwachstellen in euren Produkten und schwerwiegende Sicherheitsvorfälle melden [2]. Die Pflicht gilt für alle Produkte mit digitalen Elementen, die auf dem EU-Markt sind, also auch für bereits veröffentlichte Apps und Software.

Gemeldet wird über die zentrale Meldeplattform der ENISA an das zuständige nationale CSIRT. Die Fristen laufen ab dem Moment, in dem ihr von der Ausnutzung Kenntnis habt:

Schritt	Frist
Frühwarnung	innerhalb von 24 Stunden
Meldung mit ersten Details	innerhalb von 72 Stunden
Abschlussbericht Schwachstelle	spätestens 14 Tage, nachdem eine Korrektur verfügbar ist
Abschlussbericht Sicherheitsvorfall	innerhalb eines Monats nach der Meldung

Entscheidend ist die Kenntnis, nicht ein lückenloses Monitoring. Die Pflichten zur laufenden Produktbeobachtung kommen erst 2027. Kenntnis entsteht nach einer ersten Einschätzung, und die muss zügig erfolgen.

Was ihr dafür braucht, falls es noch nicht steht: eine feste Anlaufstelle für Schwachstellenmeldungen, eine klare Zuständigkeit für die Entscheidung „melden oder nicht“ und einen dokumentierten Meldeweg.

Was bis Dezember 2027 noch dazukommt

Der breite Katalog, der 2027 vollständig greift, verlangt strukturell mehr. Vier Bausteine bilden den Kern.

1) Security by Design und by Default. Cybersicherheit gehört in die Produktentwicklung, nicht als nachträglicher Patch. Praktisch heißt das: Standardkonfigurationen ohne Default-Passwörter, Zugriffskontrollen von Anfang an mitgedacht, Kryptographie nicht als Feature, sondern als Grundzustand.
2) Software Bill of Materials (SBOM). Jedes Produkt braucht eine aktuell gehaltene Stückliste seiner Software-Komponenten und Bibliotheken. Das betrifft ausdrücklich auch Fremdkomponenten und Open-Source-Abhängigkeiten. Ohne SBOM lässt sich im Ernstfall nicht sagen, welche eigenen Produkte von einer Schwachstelle in einer bestimmten Library betroffen sind.
3) Vulnerability- und Incident-Management. Über den gesamten Support-Zeitraum hinweg, nicht nur beim Launch. Das Risiko-Assessment eines Produkts muss laufend aktualisiert werden, nicht einmalig vor der Markteinführung erstellt.
4) Update-Pflichten. Hersteller müssen für den gesamten Supportzeitraum kostenlose Sicherheitsupdates bereitstellen. Der Zeitraum richtet sich nach der erwarteten Nutzungsdauer und beträgt mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist. Jedes Update muss mindestens zehn Jahre oder bis zum Ende des Supportzeitraums verfügbar bleiben, je nachdem, was länger ist. Bei maßgeschneiderten Produkten für Unternehmen kann vertraglich etwas anderes vereinbart werden. Das reicht über den typischen Projektabschluss hinaus und gehört in jeden Wartungsvertrag.

Wie tief diese vier Bausteine im Einzelfall greifen, hängt von der Risikoklasse des Produkts ab. Dazu gleich mehr.

Was sich im Entwicklungsalltag konkret ändert

Für Entwicklungsteams landet der CRA am Ende in der CI/CD-Pipeline, nicht in einem Compliance-Dokument.

Dependency-Scanning wird zur Pflichtübung statt zur Kür. Wer heute schon Tools wie Dependabot, Snyk oder OWASP Dependency-Check im Einsatz hat, ist strukturell näher an der SBOM-Pflicht als Teams, die Abhängigkeiten manuell im Blick behalten.

Die SBOM selbst lässt sich am saubersten automatisiert aus dem Build-Prozess generieren, nicht nachträglich von Hand pflegen. Formate wie CycloneDX oder SPDX haben sich dafür etabliert.

Das Vulnerability-Management braucht einen klaren Eskalationsweg. Nicht nur „wer testet“, sondern „wer entscheidet, ob eine gefundene Schwachstelle aktiv ausgenutzt wird, und wer meldet fristgerecht“. Das ist eher eine Prozessfrage als eine Tool-Frage.

Und: Dokumentation wird zum Nebenprodukt der Entwicklung, nicht zur separaten Fleißarbeit danach. Risikobewertungen, Architekturentscheidungen und Update-Historie gehören dort hin, wo ohnehin schon dokumentiert wird, etwa ins Repository selbst.

Erfahre mehr zum operativen Monitoring

Betrifft uns das? Einordnung nach Risikoklasse

Welche Pflichten auf euch zukommen, hängt davon ab, in welche Kategorie euer Produkt fällt. Die meisten Business-Apps, internen Tools und Web-Anwendungen sind Standardprodukte.

Kategorie	Typische Beispiele	Konformitätsbewertung
Standardprodukte	Die meisten B2B-Apps, interne Tools, Web- und App-Projekte	Selbstbewertung durch den Hersteller plus EU-Konformitätserklärung
Wichtige Produkte, Klasse I	z. B. Identitäts- und Zugangsverwaltung, Passwortmanager, VPN-Software, Betriebssysteme	Selbstbewertung nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema (mindestens Stufe „mittel“) vollständig angewendet werden. Sonst über eine notifizierte Stelle. Stand November 2026 ist noch keine harmonisierte Norm im Amtsblatt veröffentlicht, in der Praxis heißt das: externe Prüfung.
Wichtige Produkte, Klasse II	z. B. Firewalls, Systeme zur Angriffserkennung, Hypervisoren und Container-Laufzeitumgebungen	Immer über eine externe Konformitätsbewertungsstelle
Kritische Produkte	z. B. Hardware mit Sicherheitsboxen, Smart-Meter-Gateways, Smartcards	EU-Cybersicherheitszertifizierung, wo vorgeschrieben. Sonst wie Klasse II.

Die vollständigen Listen stehen in den Anhängen III und IV der Verordnung [3].

Erfahre mehr zum Tech Audit

Was jetzt Priorität hat und was noch Zeit hat

Jetzt:

Meldeprozess prüfen oder aufsetzen: Anlaufstelle, Zuständigkeit, dokumentierter Meldeweg. Die Pflicht gilt bereits.
Produkte einordnen: Standardprodukt, wichtiges Produkt der Klasse I oder II, kritisches Produkt.
Überblick über eure Abhängigkeiten, auch ohne fertige SBOM.
Supportzeitraum je Produkt festlegen: mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist.

Bis Dezember 2027:

Automatisierte SBOM pro Produkt
Security by Design im Entwicklungsprozess verankern
Update- und Supportverträge anpassen

Fazit

Der CRA ist kein Stichtag, sondern ein Prozess in zwei Stufen. Die erste Stufe gilt seit September: Wer aktiv ausgenutzte Schwachstellen nicht zuverlässig melden kann, hat jetzt Handlungsbedarf. Die zweite Stufe ist der größere Umbau. Bis Dezember 2027 klingt nach viel Zeit, ist es für SBOM, Security by Design und neue Supportverträge aber nicht. Wer jetzt einordnet und priorisiert, setzt das in Ruhe um statt im Endspurt.