Cyber Resilience Act Reporting: Playbook für die 24-Stunden-Frist ab September 2026
Ab 11. September 2026 müssen Hersteller eine aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen stufenweise über ENISAs Single Reporting Platform melden. Der Ablauf beginnt mit einer Frühwarnung binnen 24 Stunden, gefolgt von der Schwachstellenmeldung binnen 72 Stunden und einem Abschlussbericht nach Bereitstellung der Abhilfemaßnahme.
Dieser technische Leitfaden ist keine Rechtsberatung. Er übersetzt die Meldepflicht in einen ausführbaren Ablauf für Produkt-, Security-, Support- und Führungsteams.
Was ändert sich am 11. September 2026?
| Zeitpunkt | Auslöser | Technische Aktion |
|---|---|---|
| 24 Stunden | Frühwarnung nach Kenntnis aktiver Ausnutzung | Meldung öffnen und Zeitpunkt, Märkte sowie erste Schwere dokumentieren |
| 72 Stunden | Schwachstellenmeldung | Analyse, Exploit-Indikatoren, Maßnahmen und Versionen ergänzen |
| Abschluss | Spätestens 14 Tage nach verfügbarer Abhilfe | Ursache, Fix, Rollout und Nutzerkommunikation belegen |
Wer verantwortet die Meldeuhr?
Ein Incident Commander besitzt die Uhr, doch Product, Security, Support, Legal und Communications liefern die Belege. Kenntnis ist ein Geschäftsereignis, nicht erst die Vergabe einer CVE. Legt fest, wer Kenntnis erklären darf, und schreibt die Entscheidung in eine unveränderbare Incident-Zeitachse.
- Meldungen von Forschern, Kunden, CSIRTs, Bug Bounties, Monitoring und Lieferanten in einer Queue bündeln.
- Produkt, Version, Länder, Exploit-Indikatoren und ersten Beobachtungszeitpunkt strukturiert speichern.
- Dieselbe interne Incident-ID für alle drei Meldestufen verwenden.
Welche Architektur braucht der Meldeprozess?
Baut eine Evidenz-Pipeline statt eines Formularrituals. Der Plattform-Adapter liest aus einem dauerhaften Incident-Datensatz. Trennt bestätigte Fakten von Hypothesen, weist jeder offenen Frage eine verantwortliche Person zu und bewahrt Einreichungsbelege auf.
- Manipulationsgeschützte UTC-Zeitachse mit Akteur.
- Produkt- und Versionsinventar mit SBOM, Releases und Supportzeitraum.
- Disclosure-Entscheidungslog, Kundenentwurf und redigiertes Beweispaket.
- Regelmäßige Übung mit synthetischer aktiver Ausnutzung.
Wie vermeidet ihr Fehl- und Nichtmeldungen?
Nutzt zwei Gates: Betrifft der Fall ein erfasstes Produkt mit digitalen Elementen, und gibt es belastbare Hinweise auf aktive Ausnutzung oder einen schweren Vorfall? Unsicherheit stoppt die Uhr nicht. Eskaliert sie und dokumentiert die Entscheidungsbasis.
- Nicht auf perfekte Attribution, öffentliche CVE oder fertige Ursachenanalyse warten.
- Keine unnötigen Schwachstellendetails in breit sichtbaren Kanälen verteilen.
- Wochenenden, Urlaub, Lieferantenmeldungen und ausgefallenes Monitoring testen.
Sechs Wochen bis zum belastbaren CRA-Ablauf
- Woche 1: Produkte, Rollen, Märkte, Supportzeiträume und Verantwortliche erfassen.
- Woche 2: Kenntnis, Schwere, aktive Ausnutzung und Entscheidungsrechte definieren.
- Woche 3: Incident-Schema, Evidenzspeicher, Rechte und Audit Trail bauen.
- Woche 4: Intake, Inventar, Releases und Kundenkommunikation verbinden.
- Woche 5: 24- und 72-Stunden-Handover als Tabletop üben.
- Woche 6: Lücken schließen und quartalsweise Übungen terminieren.
Produkt bauen, nicht nur Backlog
Wenn dieser Artikel auf eine echte Produktentscheidung einzahlt, hilft Wavect dir beim Scoping, Bauen, Härten oder Führen der Softwarearbeit mit Senior-Founder-Urteil.
Sinnvolle Service-Wege:
FAQ zum CRA Reporting
Wann beginnen die CRA-Meldepflichten?
Braucht die 24-Stunden-Meldung eine fertige Ursachenanalyse?
Wo wird gemeldet?
Reicht ein Schwachstellenscanner?
Fazit
Behandelt die 24-Stunden-Frist als Architekturvorgabe. Eine geübte Evidenz-Pipeline und klare Entscheidungsrechte sind wertvoller als ein Meldetemplate in letzter Minute.
Primärquellen
- EU-Kommission zum CRA Reporting. Offizielle Fristen und Stufen
- ENISA Single Reporting Platform. Offizielle Plattforminformationen
- EU-Kommission zur finalen CRA-Leitlinie. Aktuelle Umsetzungshilfe