CRA-Meldepflichten ab dem 11. September 2026: Auslöser, Fristen, Meldewege

Was gilt seit dem 11. September 2026?

Die Meldepflicht nach dem Cyber Resilience Act gilt seit dem 11. September 2026. Artikel 14 verpflichtet Hersteller von Produkten mit digitalen Elementen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die Behörden zu melden. Die übrigen Produkt-, Dokumentations- und Konformitätspflichten greifen erst am 11. Dezember 2027.

Der Cyber Resilience Act ist Produktrecht. NIS2 und DORA nehmen das Unternehmen als Ganzes in die Pflicht, der CRA das einzelne Produkt, und zwar über dessen gesamten Lebenszyklus von der Entwicklung bis zum Ende des Supportzeitraums.

Die Verordnung staffelt ihre Pflichten über fünf Stichtage:

• 10.12.2024: Die Verordnung tritt in Kraft, die Umsetzungsphase läuft.
• 11.06.2026: Kapitel IV wird anwendbar, notifizierte Stellen können Konformitätsbewertungen durchführen.
• 11.09.2026: Die Meldepflichten der Hersteller nach Art. 14 greifen.
• 11.12.2027: Vollanwendung mit Produkt-, Prozess-, Dokumentations- und Konformitätspflichten.
• 11.06.2028: Zertifikatsübergang.

Wichtig für die Praxis ist die Behandlung von Altprodukten. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen grundsätzlich erst bei einer wesentlichen Änderung unter die vollen Anforderungen. Artikel 14 gilt für relevante Altprodukte im Anwendungsbereich jedoch bereits jetzt. Wer nur seine Neuentwicklungen betrachtet, unterschätzt den eigenen Meldeumfang.

Die Meldepflicht ist damit die erste CRA-Anforderung, die im Tagesgeschäft ankommt, und sie betrifft ein deutlich größeres Produktportfolio, als viele Hersteller erwarten.

Welche Ereignisse lösen die CRA-Meldepflicht aus?

Die CRA-Meldepflicht kennt genau zwei Auslöser: eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen und einen schwerwiegenden Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit. Liegt keiner der beiden vor, entsteht keine Pflicht nach Artikel 14.

Eine hohe CVSS-Bewertung, ein veröffentlichter Proof-of-Concept oder eine bekannte, aber nicht aktiv ausgenutzte CVE reichen allein nicht aus. An dieser Abgrenzung scheitern die meisten Prozesse. Ohne vorab definierte Kriterien entscheidet im Ereignisfall das Bauchgefühl darüber, ob eine Meldung herausgeht.

Auch ohne Meldepflicht bleiben Behebung und Dokumentation Pflicht. Ein Fund, der Artikel 14 nicht auslöst, verschwindet also nicht aus dem Schwachstellenmanagement.

Wann gilt eine Schwachstelle als aktiv ausgenutzt?

Eine Schwachstelle gilt als aktiv ausgenutzt, wenn verlässliche Anhaltspunkte dafür vorliegen, dass Angreifer eine konkrete Produktschwachstelle in der Praxis nutzen. Den Nachweis liefert in aller Regel erst ein Zusammenspiel mehrerer Signale.

Diese vier Quellen liefern die belastbaren Anhaltspunkte:

• Threat Intelligence: Hinweise darauf, dass die Schwachstelle im Feld ausgenutzt wird.
• Telemetrie: eigene Produktdaten, die ein auffälliges Verhalten im Einsatz zeigen.
• Kundenmeldungen: Berichte über Fehlfunktionen, unerklärliche Zugriffe oder Manipulationen.
• Support- und Lieferantenhinweise: Meldungen aus dem eigenen Servicekanal und von Komponentenherstellern.

Ohne diese Signale bleibt eine Schwachstelle ein Fall für das Schwachstellenmanagement, aber kein Fall für die Single Reporting Platform.

Was ist ein schwerwiegender Sicherheitsvorfall?

Ein schwerwiegender Sicherheitsvorfall ist ein Ereignis, das die Sicherheit eines Produkts mit digitalen Elementen erheblich beeinträchtigt, auch ohne dass eine Produktschwachstelle ausgenutzt wurde. Der klassische Fall ist ein kompromittierter Updatekanal, bei dem Integrität und Verfügbarkeit der Auslieferung betroffen sind.

Ob ein Ereignis diese Schwelle erreicht, entscheidet sich erst im Kontext. Diese fünf Achsen tragen die Bewertung:

• Technische Schwere: Wie tief greift der Vorfall in die Sicherheitseigenschaften des Produkts ein?
• Erreichbarkeit: Ist das betroffene Produkt aus dem Netz erreichbar oder nur lokal?
• Installierte Basis: Wie viele Systeme, Versionen und Nutzer sind erfasst?
• Privilegien: Welche Rechte erlangt ein Angreifer über den Vorfall?
• Daten- und Safety-Auswirkungen: Sind Daten oder die Betriebssicherheit betroffen?

Diese Bewertung gehört in eine vorab definierte Klassifizierung, denn im Ereignisfall fehlt die Zeit, die Kriterien erst zu entwickeln.

Ab wann läuft die 24-Stunden-Frist?

Die drei Fristen nach Artikel 14 starten nicht mit dem ersten Hinweis. Maßgeblich ist der Zeitpunkt, zu dem nach einer ersten Prüfung angemessene Gewissheit über das Ereignis besteht. Meldet ein Kunde eine Auffälligkeit, prüfen Sie Produktbezug und Ausnutzung, und erst das bestätigte Ergebnis setzt die Uhr in Gang.

Alle drei Fristen des Artikels 14 laufen ab diesem Zeitpunkt der bestätigten Kenntnis. Sie addieren sich nicht. Nach der Frühwarnung binnen 24 Stunden bleiben also nicht weitere 72 Stunden, sondern noch 48 Stunden bis zur zweiten Meldung.

Dokumentieren Sie den Zeitpunkt der Kenntniserlangung mit unveränderbarem Zeitstempel. Die Marktaufsicht fragt im Zweifel auch, warum Sie nicht früher gehandelt haben.

Welche Informationen verlangt die CRA-Meldung nach 24 und 72 Stunden?

Artikel 14 verlangt drei Meldungen in drei Zeitfenstern, alle über dieselbe Plattform. Die erste Meldefrist endet nach 24 Stunden mit der Frühwarnung, die zweite nach 72 Stunden mit der eigentlichen Meldung. Der Abschlussbericht dokumentiert anschließend Ursache und Behebung.

Unvollständigkeit ist kein Grund, die Frühwarnung zu verzögern. Nach 24 Stunden liegt in den seltensten Fällen ein vollständiges Lagebild vor, oft steht die Forensik noch am Anfang. Geben Sie an, was gesichert ist, kennzeichnen Sie Vermutungen als solche und lassen Sie den Rest offen.

Parallel zur Behördenmeldung verlangt der CRA, betroffene Nutzer risikoabhängig zu informieren. Diese Nutzerinformation läuft nicht über die Behördenplattform und braucht deshalb einen eigenen Prozess mit Advisory und Kundenbestandsabgleich.

Wie läuft die Meldung über die Single Reporting Platform?

Die CRA-Meldung läuft elektronisch über die Single Reporting Platform, die von der ENISA betrieben wird. Eine Meldung erreicht gleichzeitig das koordinierende CSIRT, in Deutschland das BSI, und die ENISA. Die Weiterverteilung an andere Stellen übernimmt anschließend das CSIRT.

Ein Meldekanal bedeutet aber nicht einen einzigen Adressaten. Der CRA kennt keinen One-Stop-Shop. Weder ENISA noch BSI informieren die Datenschutzaufsicht, die BaFin oder Ihre Kunden, und keine dieser Parallelmeldungen hält die CRA-Frist an.

Diese Meldewege bleiben nach einem Sicherheitsvorfall Ihre eigene Aufgabe:

• NIS2 und DORA: eigene Fristen, eigene Taxonomien, eigene Adressaten.
• DSGVO: Meldung an die Aufsichtsbehörde und gegebenenfalls Benachrichtigung der Betroffenen.
• Kundenverträge: vertraglich zugesagte Informationspflichten gegenüber Ihren Kunden.
• Produktsicherheit: Warnung des Marktes vor der weiteren Nutzung betroffener Produkte.

Über die Einhaltung der Frist entscheidet oft eine banale Vorarbeit. Der Zugang zur Plattform muss vorher stehen. Richten Sie die Zugänge ein, benennen Sie zu jedem Entscheider eine Stellvertretung und gehen Sie den Weg einmal durch. Im Ernstfall bleibt keine Zeit, das nachzuholen.

Wer entscheidet innerhalb von 24 Stunden?

Die 24-Stunden-Frist ist keine juristische, sondern eine organisatorische Hürde. Sie wird gerissen, wenn im Ereignisfall unklar ist, wer die Kenntnis feststellt, wer freigibt und wer die Meldung tatsächlich absetzt. Ein tragfähiges Mindestmodell verteilt diese Aufgaben auf fünf Rollen. Im Zentrum steht das Product Security Incident Response Team, kurz PSIRT.

• PSIRT-Lead: stellt den Auslöser fest, führt die Uhr und koordiniert den Fall.
• Engineering: bestätigt Produktbezug, betroffene Versionen und Ausnutzbarkeit.
• Legal und Compliance: prüft die Meldepflicht, klärt die Zuständigkeit und gibt die Meldung frei.
• Produkt und Support: ermittelt den betroffenen Kundenbestand und entwickelt den Workaround.
• Kommunikation und Management: bewertet die Reputationslage und stimmt die Botschaften ab.

Jede dieser Rollen braucht eine benannte Stellvertretung. Der Cyber Resilience Act kennt keine Bürozeiten. Die Frist läuft auch nachts und am Wochenende weiter.

Ebenso wichtig ist ein einziger Eingangskanal für alle Verdachtsmomente. Verlangen Sie von Kunden oder Mitarbeitenden nicht, vorab zu entscheiden, ob ein Hinweis in den CRA-, NIS2- oder Datenschutzkanal gehört, denn diese Sortierung kostet genau die Stunden, die später fehlen.

Melden oder nicht? Drei Fälle aus der Praxis

Ob ein Ereignis die CRA-Meldepflicht auslöst, entscheidet sich an wenigen Prüffragen: Gibt es einen Produktbezug, gibt es eine aktive Ausnutzung, und wenn nicht, liegt ein schwerwiegender Sicherheitsvorfall vor? Drei typische Konstellationen zeigen, wie unterschiedlich die Antworten ausfallen.

Aktiv ausgenutzte IoT-Kamera: Meldepflicht ausgelöst

Threat Intelligence und Kundenlogs zeigen eine Command Injection gegen Firmware 4.2 einer vernetzten Kamera. Das PSIRT bestätigt den Produktbezug und die aktive Ausnutzung. Mit dieser Bestätigung beginnt die Frist.

Innerhalb von 24 Stunden geht die Frühwarnung über die Single Reporting Platform heraus, mit eingegrenzten Versionen. Bis zur 72-Stunden-Meldung stehen Workaround oder Hotfix sowie eine Impact-Bewertung. Zum Abschluss veröffentlichen Sie einen signierten Patch, informieren die Nutzer, überwachen die Adoption und reichen den Abschlussbericht ein.

Ergebnis: Produktbezug und aktive Ausnutzung sind bestätigt, damit greift Artikel 14.

Open-Source-Komponente ohne Exploit: keine Meldung nach Artikel 14

In einer integrierten Bibliothek wird eine neue CVE bekannt. Proof-of-Concept-Code ist öffentlich, aber es gibt keine verlässlichen Hinweise auf eine aktive böswillige Ausnutzung im Produktkontext. Die Bibliothek ist im Produkt aktiv eingebunden.

Sie patchen, testen, verteilen sicher, bereiten ein Advisory vor und melden den Fund an den Maintainer. Die Exploit-Lage beobachten Sie weiter, denn eine gering bewertete Schwachstelle kann relativ schnell zu einem schwerwiegenden Fall werden.

Ergebnis: Proof-of-Concept-Code allein genügt nicht, Behebung und Dokumentation bleiben Pflicht.

Kompromittiertes Cloud-Backend: Meldung über den schwerwiegenden Vorfall

Angreifer kompromittieren den Update-Orchestrator einer B2B-Appliance. Eine ausgenutzte Produktschwachstelle ist nicht bestätigt, Integrität und Verfügbarkeit der Updates sind jedoch schwer betroffen. Damit greift Artikel 14 über den zweiten Auslöser.

Sie isolieren den Updatekanal, rotieren Schlüssel, warnen Kunden, sichern Evidenz und setzen die Meldungen ab. Root Cause und Kontrollen stellen Sie im Abschlussbericht dar. Parallel prüfen Sie NIS2, DORA, DSGVO und vertragliche Informationspflichten gesondert.

Ergebnis: Artikel 14 greift über den Vorfall, Parallelmeldungen halten die CRA-Frist nicht an.

Wie werden Sie in 90 Tagen meldefähig?

Meldefähigkeit lässt sich in drei Etappen herstellen, auch wenn die volle CRA-Compliance bis zum 11. Dezember 2027 deutlich mehr verlangt. Der Fokus liegt zuerst auf Entscheidungsfähigkeit und Meldeweg. Die vollständige Dokumentation folgt danach.

1. Tage 0 bis 30: Zuständigkeit klären. Produkt-Scope und Produktinventar erfassen, PSIRT- und Legal-Owner benennen, Entscheidungsbaum für 24 und 72 Stunden festlegen, Zuständigkeit für Plattform und CSIRT klären, Meldetemplates und Stellvertretung aufsetzen.
2. Tage 31 bis 60: Prozesse aufsetzen. Kanal für Coordinated Vulnerability Disclosure einrichten, SBOM-Pilot starten, Triage-Modell einführen, Hotfix-Release-Pfad definieren, Nutzer- und Advisory-Prozess aufbauen, Incident-Matrix für CRA, NIS2, DORA und DSGVO erstellen.
3. Tage 61 bis 90: Wirksamkeit prüfen. Tabletop-Übung durchführen, erkannte Lücken schließen, KPIs und Gap-Analyse zu Anhang I und II aufsetzen, technische Dokumentation prüfen, priorisierte Roadmap freigeben.

Ob der Prozess trägt, zeigen Kennzahlen. Aussagekräftig sind eine SBOM-Abdeckung von mindestens 95 Prozent, eine Zeit bis zur Triage von unter vier Stunden bei kritischen Fällen und eine Patch-SLA-Erfüllung von mindestens 90 Prozent. Zwei Tabletop-Übungen pro Jahr liefern die Evidenz dafür.

Wer diese Etappen jetzt geht, gewinnt zugleich die Grundlage für die Vollanwendung, denn Produktinventar, SBOM und Governance tragen auch die Pflichten ab Dezember 2027.

Fazit: Die CRA-Meldepflicht entscheidet sich in der Vorarbeit

Die CRA-Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026 und verlangt drei Meldungen ab bestätigter Kenntnis. Die Meldefristen betragen 24 Stunden für die Frühwarnung und 72 Stunden für die Meldung, dazu kommt der Abschlussbericht. Ausgelöst wird sie nur durch eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall, nicht durch jede CVE.

Am Rechtstext scheitert selten jemand. Gerissen wird die Frist an der Entscheidungsfähigkeit im Ereignisfall. Wer erst dann klärt, welche Versionen betroffen sind, wer freigeben darf und wie der Plattformzugang funktioniert, hat die 24 Stunden bereits verbraucht.

Fünf Bausteine tragen den Prozess: Sichtbarkeit und Intake, kontextuelle Triage, Remediation und Test, sichere Auslieferung und Kommunikation sowie Governance und Evidenz. Sie sind zugleich das Fundament für die Vollanwendung des Cyber Resilience Act am 11. Dezember 2027.

Das größere wirtschaftliche Risiko liegt im Marktzugang. Produkte ohne saubere Prozesse und Dokumentation verschwinden früher oder später aus den Portfolios von Händlern und Plattformen.

Häufig gestellte Fragen

Gilt die CRA-Meldepflicht auch für Produkte, die vor dem 11. September 2026 auf den Markt kamen?

Ja, Artikel 14 gilt auch für relevante Altprodukte im Anwendungsbereich des Cyber Resilience Act. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den vollen Produkt- und Konformitätspflichten zwar grundsätzlich erst bei einer wesentlichen Änderung. Von der Meldepflicht sind sie davon unabhängig erfasst.

Muss jede CVE nach dem Cyber Resilience Act gemeldet werden?

Nein, eine bekannte CVE löst für sich genommen keine CRA-Meldepflicht aus. Erforderlich sind verlässliche Anhaltspunkte für eine aktive Ausnutzung der konkreten Produktschwachstelle oder ein schwerwiegender Sicherheitsvorfall. Eine hohe CVSS-Bewertung und veröffentlichter Proof-of-Concept-Code genügen nicht, ändern aber nichts an der Pflicht zur Behebung.

Ersetzt eine Meldung nach NIS2 die CRA-Meldung?

Nein, eine NIS2-Meldung ersetzt die Meldung nach Artikel 14 des Cyber Resilience Act nicht. Beide Regelwerke haben eigene Adressaten und eigene Fristen. Ein einzelnes Ereignis kann parallel Meldepflichten nach CRA, NIS2, DORA, DSGVO und aus Kundenverträgen auslösen, und keine dieser Meldungen hält die CRA-Frist an.

Wen trifft die Meldepflicht nach Artikel 14?

Die Meldepflicht nach Artikel 14 des Cyber Resilience Act trifft die Hersteller von Produkten mit digitalen Elementen. Einführer und Händler tragen andere Pflichten: Sie prüfen Kennzeichnung und Dokumentation und dürfen ein Produkt ohne diese nicht bereitstellen. Klären Sie deshalb vor jeder Zuständigkeitsdiskussion, welche Akteursrolle Sie für das jeweilige Produkt haben.

Was tun, wenn nach 24 Stunden noch Informationen fehlen?

Die Frühwarnung geht trotzdem raus, denn Unvollständigkeit rechtfertigt keine Verzögerung. Offene Felder bleiben offen, Unsicheres kennzeichnen Sie als Vermutung. Die fehlenden Angaben liefern Sie mit der Meldung nach 72 Stunden nach.