CRA-Meldepflichten: Jetzt zählt das Playbook

CRA-Meldepflichten: Jetzt zählt das Playbook.

Seit dem 11.09.2026 ist Art. 14 Cyber Resilience Act „scharf“ gestellt. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die Single Reporting Platform melden. Wer erst nach einem Vorfall reagiert und Zuständigkeiten, Meldewege sowie Mitwirkungspflichten klärt, verliert nicht nur wertvolle Zeit.

Zusammenfassung (TL; DR):

• Seit dem 11. September 2026 verpflichtet Artikel 14 des Cyber Resilience Act (CRA) Hersteller zur Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle über eine zentrale Plattform.
• Die Fristen verlangen eine Frühwarnung binnen 24 Stunden sowie eine Folgemeldung innerhalb von 72 Stunden nach Kenntnisnahme.
• Unternehmen müssen zur Vermeidung von Zeitverlusten und Risiken in der Lieferkette ein praxistaugliches Playbook mit klaren Eskalationswegen etablieren.

Der Cyber Resilience Act (CRA) erreicht seine letzten Meilensteine

Seit dem 11.09.2026 ist mit Art. 14 CRA der nächste Meilenstein der Verordnung wirksam. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf ihre Produkte über die CRA Single Reporting Platform (CRA SRP) melden.

Die vollständigen Produktanforderungen des CRA greifen grundsätzlich erst ab dem 11.12.2027. Wer daraus ableitet, für die Compliance Vorbereitung bleibe noch ausreichend Zeit, unterschätzt den Handlungsdruck. Im Sicherheitsvorfall zählen nicht nur Technik und Forensik, sondern auch Kenntniszeitpunkt, Zuständigkeiten, Meldewege und Dokumentation. Dass gerade diese organisatorischen Fragen Schwierigkeiten bereiten, zeigt bereits Art. 33 DS-GVO. Genau deshalb braucht es jetzt ein praxistaugliches Playbook.

Was jetzt schon gilt (in a nutshell)

Art. 14 CRA erfasst zwei Fallgruppen. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Sicherheit eines Produkts mit digitalen Elementen. Gemeldet wird über die von ENISA betriebene CRA SRP.

Nicht jede bekannte oder veröffentlichte Schwachstelle und nicht jeder technische Fehler ist meldepflichtig. Entscheidend ist bei Schwachstellen insbesondere, dass sie aktiv ausgenutzt werden. Daneben besteht die Meldepflicht für schwerwiegende Sicherheitsvorfälle mit Produktbezug.

Für beide Fallgruppen gilt ein gestuftes Meldeverfahren

Danach ist unverzüglich, jedenfalls aber innerhalb von 24 Stunden nach Kenntnisnahme eine Frühwarnung abzugeben. Auch die anschließende Meldung hat unverzüglich, spätestens jedoch innerhalb von 72 Stunden nach Kenntnisnahme zu erfolgen. „Unverzüglich“ heißt gerade nicht innerhalb von 24 bzw. 72 Stunden. Gefordert ist ein Handeln ohne schuldhaftes Zögern. Die Stundenfristen markieren dabei lediglich die äußerste zeitliche Grenze.

Für den Abschlussbericht gelten unterschiedliche Fristen: Bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, bei schwerwiegenden Sicherheitsvorfällen innerhalb eines Monats nach der 72-Stunden-Meldung.

Unternehmen müssen also prüfen und entscheiden können, obwohl die technische Aufklärung regelmäßig noch nicht abgeschlossen ist.

Warum die „Stunden“-Frist organisatorisch gefährlich ist

24 Stunden sind kein Tag im organisatorischen Sinne. Ebenso wenig sind 72 Stunden drei Arbeitstage. Die Fristen laufen in Stunden und nehmen auf Bürozeiten, Wochenenden oder Feiertage keine Rücksicht.

Erhält ein Hersteller am Freitagnachmittag Kenntnis von einem potenziell meldepflichtigen Sachverhalt, kann die interne Prüfung nicht bis Montag warten. Genau hier entscheidet sich, ob ein Incident-Response-Prozess regulatorisch tatsächlich funktioniert.

Auch die 72-Stunden-Frist beginnt bereits mit der Kenntnisnahme. Nach Ablauf der ersten 24 Stunden verbleiben also nicht nochmals 72 Stunden, sondern grundsätzlich nur noch 48 Stunden bis zur nächsten Höchstgrenze.

Typische Verzögerungen

Typische Verzögerungen entstehen dabei insbesondere durch die Organisation: Wer darf den Vorfall rechtlich einordnen? Wer ist auf Herstellerseite entscheidungsbefugt? Wer hat Zugriff auf Logs? Wer bewertet, ob Kundensysteme betroffen sind? Wer stimmt die Meldung ab? Wer informiert Nutzer? Und wer spricht mit Dienstleistern, Integratoren, Behörden oder Versicherern? Wer gibt wie die Meldung ab?

Gerade bei Software-Lieferketten wird dieses Problem konkret sichtbar. Ein kompromittiertes Paket, manipulierte Abhängigkeiten, ein kompromittierter Update-Server, abgeflossener Quellcode oder gestohlene Schlüssel können schnell zahlreiche nachgelagerte Systeme betreffen. Technisch geht es dann – so habe ich mir sagen lassen – um Detection, Containment und Remediation. Rechtlich zugleich um Kenntnisnahme, Meldepflicht, Nachweisbarkeit und im Zweifel auch um Exkulpation.

Hersteller müssen melden – Dienstleister müssen vorbereitet sein

Adressat der Meldepflicht nach Art. 14 CRA ist grundsätzlich der Hersteller. IT- und Cloud-Dienstleister oder externe Incident-Response-Teams werden nicht allein durch ihre Beteiligung am Vorfall selbst meldepflichtig. Etwas anderes kann gelten, wenn sie aufgrund ihrer konkreten Rolle nach dem CRA selbst als Hersteller anzusehen sind.

Praktisch verfügen Dienstleister aber häufig zuerst über entscheidende Informationen, etwa aus Monitoring, Logs oder Forensik. Ohne sie kann der Hersteller seine Meldepflicht unter Umständen nicht rechtzeitig erfüllen.

Genau daraus entsteht für Dienstleister ein nicht unerhebliches Risiko. Wer in Kundenprojekten Produkte mit digitalen Elementen entwickelt, integriert, wartet, absichert oder betreibt, sollte seine Rolle im CRA-Kontext wissen und klären. Es reicht nicht aus, allgemein „Support bei Sicherheitsvorfällen“ zuzusagen. Entscheidend ist, welche Informationen innerhalb welcher Frist an wen geliefert werden müssen und wer welche Entscheidung trifft.

Die typische Lücke liegt im Vertrag

Viele IT-Verträge enthalten SLA und allgemeine Mitwirkungspflichten, sind aber nicht auf Art. 14 CRA abgestimmt. Häufig fehlen konkrete Handlungsinstruktionen: Wer prüft die regulatorische Relevanz? Wer darf mit Behörden kommunizieren? Welche technischen Mindestinformationen sind zu liefern? Wer dokumentiert die Kenntnisnahme und sichert Beweise? Wer trägt das Risiko verspäteter Freigaben oder unvollständiger Informationen?

Solche Fragen lassen sich im laufenden Sicherheitsvorfall nicht verhandeln. Sie gehören vorab in Verträge und Playbooks.

Was in das CRA-Playbook gehört

Die folgenden Punkte sind kein abschließender Anforderungskatalog, sondern zentrale Regelungsfelder eines CRA-Playbooks.

• Klare Rollen und Zuständigkeiten: Hersteller, Kunde, Dienstleister und Incident-Response-Team müssen wissen, wer welche Aufgabe übernimmt. Dabei sollte ausdrücklich zwischen technischer Analyse, rechtlicher Bewertung, Meldeentscheidung, Nutzerinformation und Behördenkommunikation unterschieden werden.
• Definierte Eskalationsschwellen: Nicht erst bestätigte Sicherheitsvorfälle sollten eine Eskalation auslösen. Auch plausible Hinweise auf aktiv ausgenutzte Schwachstellen, kompromittierte Entwicklungsumgebungen, manipulierte Update-Kanäle, abgeflossenen Quellcode oder sonstige produktbezogene Sicherheitsereignisse müssen frühzeitig in den vorgesehenen Prüfprozess gelangen.
• Feste Kommunikations- und Meldewege: Dazu gehören erreichbare Ansprechpartner, Vertretungsregelungen, interne Fristen und Freigabeprozesse sowie Verfahren für Wochenenden, Feiertage und Urlaubszeiten. Ein Playbook, das nur während normaler Bürozeiten funktioniert, wird der Dynamik eines Cybervorfalls und den Stundenfristen des Art. 14 CRA nicht gerecht.
• Festgelegte technische Mindestinformationen: Frühzeitig verfügbar sein sollten insbesondere der Zeitpunkt der ersten Kenntnisnahme, betroffene Produkte und Versionen, Art des Ereignisses, Hinweise auf eine aktive Ausnutzung, betroffene Komponenten, Logdaten, Indikatoren einer Kompromittierung, bereits getroffene Sofortmaßnahmen und bekannte verbleibende Risiken.
• Belastbare Dokumentation: Wer später nachvollziehbar darlegen muss, warum eine Meldung erfolgt oder unterblieben ist, benötigt mehr als Chatverläufe und verstreute Tickets. Erforderlich sind insbesondere nachvollziehbare Entscheidungsvermerke, Zeitstempel, technische Befunde, Zuständigkeitsnachweise und Freigaben.
• Vertragliche Risiko- und Verantwortungsverteilung: Klassische SLA-Regelungen erfassen häufig vor allem technische Reaktionszeiten. Regulatorische Fristversäumnisse, verspätete oder unvollständige Informationen, fehlende Mitwirkung oder unkoordinierte Kommunikation sind damit nicht automatisch sachgerecht abgebildet und sollten einer rechtlichen Revision unterzogen werden. Gerade im Verhältnis zwischen Hersteller und IT-Dienstleister sollte deshalb geprüft werden, welche Informations-, Eskalations- und Mitwirkungspflichten vertraglich festgelegt werden müssen.

CRA, NIS2 und DS-GVO nicht getrennt denken

Ein weiterer Praxisfehler besteht darin, Meldepflichten isoliert zu betrachten und Synergien nicht mitzunehmen. Ein Sicherheitsvorfall kann mehrere Prüfpfade gleichzeitig auslösen. Der CRA fragt nach aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen mit Produktbezug. Das NIS2-/BSIG-Regime fragt nach erheblichen Sicherheitsvorfällen bei regulierten Einrichtungen. Die DS-GVO fragt nach Verletzungen des Schutzes personenbezogener Daten.

Diese Pflichten haben unterschiedliche Voraussetzungen, Fristen, Adressaten und Dokumentationsanforderungen. In der Praxis beruhen sie aber häufig auf denselben technischen Informationen und demselben Lebenssachverhalt. Deshalb sollten technische Incident Response und rechtliche Meldeprüfung nicht getrennt nebeneinanderlaufen. Sie müssen als gemeinsamer Prozess organisiert werden.

Fazit

Art. 14 CRA ist kein Thema für 2027. Die Meldepflichten gelten jetzt und mit ihnen sehr kurze Reaktionszeiten. Wer im Ernstfall erst Zuständigkeiten, Informationswege oder vertragliche Pflichten klären muss, hat schon verloren. Entscheidend ist deshalb, die Meldekette jetzt organisatorisch und vertraglich belastbar aufzustellen. Der nächste Sicherheitsvorfall ist nur ein Mausklick entfernt.

Häufige Fragen (FAQ)