UTOVER
Alle News

Cyber Resilience Act: Die 24-Stunden-Meldekette ab September 2026

Am 11. September 2026 wird Artikel 14 des CRA anwendbar. Ein Warnsignal startet die Frist nicht automatisch, darf aber auch nicht liegen bleiben: Nach einer prompten Erstbewertung zählt der Zeitpunkt, an dem der Hersteller mit angemessener Sicherheit von einem Meldefall im eigenen Produkt weiß.

Veröffentlicht 24.08.2026Von UTOVER4 Min. LesezeitRSS-Feed
  • Cyber Resilience Act
  • Produktsicherheit
  • Incident Response
  • Software-Lieferkette

Artikel 14 des Cyber Resilience Act wird am 11. September 2026 anwendbar. Hersteller erfasster Produkte mit digitalen Elementen müssen dann 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. Das koordinierende CSIRT kann außerdem einen Zwischenbericht verlangen.

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.

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 soll am 11. September 2026 betriebsbereit sein. 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 bis zum 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.

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. Spätestens hier zeigt sich, ob ein älterer Build unter Zeitdruck tatsächlich zu einer ausgelieferten Produktversion zurückverfolgt werden kann.

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

Lesen Sie mehr von UTOVER