Cyber Resilience Act: Die Meldekette seit dem 11. September 2026

Artikel 14 des Cyber Resilience Act ist seit dem 11. September 2026 anwendbar. Hersteller erfasster Produkte mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts gestuft melden. Die Frühwarnung ist ohne unangemessene Verzögerung und spätestens 24 Stunden nach Kenntnis abzugeben; die ausführlichere Meldung ist spätestens binnen 72 Stunden nach Kenntnis fällig. Ursachenanalyse und Abhilfe müssen bei der ersten Nachricht noch nicht abgeschlossen sein.

Für eine aktiv ausgenutzte Schwachstelle verlangt der CRA verlässliche Nachweise, dass ein böswilliger Akteur sie ohne Erlaubnis eines Systemeigentümers ausgenutzt hat. Eine allgemeine Meldung zu einer Fremdkomponente belegt noch nicht, dass der Meldegrund im eigenen Produkt vorliegt. Nach der nicht bindenden Kommissionsleitlinie ist unter anderem zu prüfen, ob der verwundbare Code im ausgelieferten Produkt erreichbar ist und ob die Schwachstelle dort ausgenutzt wird oder wurde.

Der zweite Meldeweg betrifft einen schwerwiegenden Vorfall mit Auswirkungen auf die Sicherheit des Produkts. Artikel 14 nennt eine tatsächliche oder mögliche Beeinträchtigung des Schutzes von Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten beziehungsweise Funktionen. Auch die Einführung oder Ausführung von Schadcode im Produkt oder im System eines Nutzers kann erfasst sein. Ein böswilliger Ursprung muss bei diesem Vorfallstyp noch nicht abschließend bewiesen sein.

Ein CVE-Eintrag, ein Lieferantenhinweis oder auffällige Logdaten starten die Frist daher nicht in jedem Fall automatisch. Sie müssen jedoch prompt bewertet werden.

Die Kommissionsleitlinie nimmt Kenntnis an, sobald die unverzügliche Erstbewertung einen angemessenen Grad an Sicherheit erreicht, dass der gesetzliche Meldefall vorliegt. Diese Leitlinie ist nicht bindend, beschreibt aber den aktuellen Stand der Behördenauslegung. Ein später angesetzter interner Freigabetermin verschiebt den so bestimmten Kenntniszeitpunkt nicht.

Fristen und Berichte

Die Frühwarnung enthält nur die zu diesem Zeitpunkt verlangten begrenzten Angaben. Spätestens binnen 72 Stunden nach Kenntnis sind allgemeine Informationen, eine erste Bewertung und die bereits ergriffenen Korrektur- oder Minderungsmaßnahmen zu ergänzen.

Für aktiv ausgenutzte Schwachstellen wird der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme fällig. Bei einem schwerwiegenden Vorfall gilt ein Monat ab der 72-Stunden-Meldung. Die 14-Tage-Frist läuft somit nicht pauschal ab dem ersten Hinweis; eine gemeinsame interne Frist ohne Zuordnung zum Meldegrund könnte für einen der beiden Wege falsch sein. Das koordinierende CSIRT kann außerdem einen Zwischenbericht verlangen. Die 24 und 72 Stunden sind Höchstgrenzen. Artikel 14 verlangt für diese Meldungen zugleich ein Handeln ohne unangemessene Verzögerung. Eine vorbereitete frühe Meldung darf daher nicht allein deshalb zurückgehalten werden, weil ein interner Kalender noch Restzeit anzeigt.

Für die Bearbeitung empfiehlt sich, offene technische Fragen von den bereits verfügbaren Angaben zu trennen und spätere Erkenntnisse dem bestehenden Fall zuzuordnen. Das ist eine organisatorische Folgerung aus der gestuften Meldepflicht, keine zusätzlich festgelegte Berichtsform. Weil sich die Beweislage während der Untersuchung ändert, empfiehlt sich eine chronologische Fallakte. Sie kann Eingang des Signals, geprüfte Evidenz, den angenommenen Kenntniszeitpunkt, betroffene Produktstände und spätere Korrekturen festhalten. Vermutungen bleiben dabei als solche gekennzeichnet. Diese Dokumentationsform ist eine redaktionelle Compliance-Empfehlung; der CRA schreibt nicht genau dieses Aktenmuster vor.

Auch die zuständige Stelle folgt einem gesetzlichen Zuordnungssystem. Für Hersteller mit einer Hauptniederlassung in der EU richtet Artikel 14 Absatz 7 die Meldung an das koordinierende CSIRT dieses Mitgliedstaats; relevant ist, wo die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Für andere Niederlassungskonstellationen enthält die Vorschrift weitere Kriterien. Die Auswahl sollte im konkreten Fall vorab geklärt werden, ohne aus dem Standort eines einzelnen Servers auf die zuständige Meldestelle zu schließen.

Produktstände und technische Evidenz

Der CRA trat am 10. Dezember 2024 in Kraft, seine Pflichten beginnen aber zu unterschiedlichen Zeiten. Artikel 14 gilt schon im September 2026; der Großteil der Anforderungen an Entwicklung, Produktdokumentation und Konformität folgt im Dezember 2027. Nach der nicht bindenden Kommissionsleitlinie erfasst die Meldepflicht auch Produkte, die vor dem allgemeinen Anwendungsdatum in Verkehr gebracht wurden, und kann über das Ende des Supportzeitraums hinausreichen. Daraus folgt keine pauschale Rückwirkung aller übrigen CRA-Pflichten.

Für einen neuen Meldefall muss der Hersteller dennoch feststellen können, welche ausgelieferte Version welche Komponente enthält. Eine versionsgebundene Software Bill of Materials kann die Suche verkürzen. Sie beweist weder, dass der verwundbare Code erreichbar ist, noch dass er aktiv ausgenutzt wurde. VEX kann den technischen Bewertungsstand mit Status wie betroffen, nicht betroffen, in Untersuchung oder behoben abbilden. Die regulatorische Entscheidung nimmt es dem Hersteller nicht ab.

Single Reporting Platform

ENISAs Single Reporting Platform ist nach Mitteilung der Kommission seit dem 11. September 2026 in Betrieb. Nach dem am 3. August aktualisierten FAQ erfolgt der Zugang über EU Login; eine API für automatisierte Einreichungen ist in diesem Stadium nicht vorgesehen. Ein EU-Login-Konto kann vorab angelegt werden. ENISA empfiehlt jedoch, Registrierung und Validierung in der Plattform erst bei einem konkreten Meldebedarf zu beginnen, um die zuständigen CSIRTs nicht unnötig zu belasten. Die Betriebshinweise können sich auch nach dem Start ändern. Für Prozesshandbücher ist deshalb ein Verweis auf die aktuelle Plattformdokumentation belastbarer als ein dauerhaft eingebauter Screenshot. Die Plattform ersetzt weder die technische Reaktion noch andere Meldewege, die je nach Unternehmen und Vorfall zusätzlich einschlägig sein können.

Der Plattformzugang ist personenbezogen: ENISA beschreibt EU Login mit Mehrfaktor-Authentisierung und primäre beziehungsweise weitere bevollmächtigte Vertreter des Herstellers. Ein gespeicherter Entwurf ist für andere Vertreter nicht sichtbar.

Daraus ergibt sich für die interne Vertretung eine praktische Aufgabe. Ein Wechsel der bearbeitenden Person darf nicht voraussetzen, dass die Ersatzperson denselben privaten Entwurf öffnen kann. Benötigte Fallinformationen und Zuständigkeiten müssen über einen dafür vorgesehenen internen Übergabeweg verfügbar sein. Die Zusammenstellung von Produktständen oder Fallinformationen kann intern automatisiert werden; die eigentliche Abgabe erfolgt über die Plattformoberfläche. Plattformzähler und Erinnerungen nehmen dem Hersteller die Verantwortung für die gesetzlichen Fristen nicht ab.

Für einen Plattformausfall nennt ENISA die Nachreichung über die SRP nach Wiederverfügbarkeit. Bei dringendem Kommunikationsbedarf soll das zuständige CSIRT direkt kontaktiert werden. Dieser Kontakt ersetzt die spätere SRP-Einreichung nicht. Eine betriebliche Vorbereitung sollte deshalb auch festhalten, wie ein gescheiterter Einreichungsversuch dokumentiert und der noch offene Meldevorgang weiterverfolgt wird. Das ist eine abgeleitete Betriebsempfehlung, keine zusätzliche gesetzliche Ausnahme von der Meldepflicht.

Nach Kenntniserlangung informiert der Hersteller nach Artikel 14 Absatz 8 betroffene Nutzer und, soweit angemessen, alle Nutzer über die Schwachstelle oder den Vorfall sowie erforderlichenfalls über Maßnahmen. Anders als bei der 24- und 72-Stunden-Meldung nennt der Absatz keine konkrete Frist „unverzüglich“. Die Kommissionsleitlinie spricht von einer zeitnahen, risikobasierten und verhältnismäßigen Information. Adressatenkreis und Detailgrad richten sich daher nach dem Fall.

Ein Probelauf kann prüfen, ob Vertretung, Produktarchiv, technische Erstbewertung und Plattformzugang zusammen funktionieren. Dabei wird kein erfundener Meldefall als Tatsache behandelt; getestet werden die Übergaben und Entscheidungen des eigenen Prozesses. Der Probelauf zeigt auch, ob ein älterer Build unter Zeitdruck einer tatsächlich ausgelieferten Produktversion zugeordnet werden kann.

Hinweis: Diese Einordnung ersetzt keine Prüfung des Einzelfalls.