In diesem Beitrag
Cyber Resilience Act: Operativer Meldeleitfaden für 24 und 72 Stunden
Stand 5. Oktober 2026 gelten die CRA-Meldepflichten für Hersteller bereits. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle erfordern eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden ab Kenntniserlangung. Der Abschlussbericht folgt bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme, bei schwerwiegenden Vorfällen binnen eines Monats nach der 72-Stunden-Meldung.
Die Meldepflichten für Hersteller gelten seit 11. September 2026. Dieser technische Leitfaden macht daraus einen laufenden Prozess statt eines künftigen Vorbereitungsprojekts. Er ist keine Rechtsberatung: Produktumfang, Wirtschaftsakteursrolle und Meldetatbestand müssen fachkundig geprüft werden. Die nachfolgenden Umsetzungsempfehlungen sind keine zusätzlichen gesetzlichen Pflichten.
Welche Frist gehört zu welcher Meldung?
| Schritt | Auslöser und Frist | Operativer Nachweis |
|---|---|---|
| Frühwarnung: beide Kategorien | Binnen 24 Stunden ab Kenntniserlangung | Kenntniszeitpunkt, Kategorie, erste Fakten und Eingangsbestätigung sichern. |
| Meldung: beide Kategorien | Binnen 72 Stunden ab Kenntniserlangung, nicht 72 Stunden nach der Frühwarnung | Betroffene Produkte, Bewertung und verfügbare Maßnahmen ergänzen. |
| Abschluss: aktiv ausgenutzte Schwachstelle | Spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme | Verfügbarkeitszeitpunkt, Behebung und Abschlussübermittlung dokumentieren. |
| Abschluss: schwerwiegender Vorfall | Binnen eines Monats nach der 72-Stunden-Meldung | Meldezeitpunkt, Kalendermonatsfrist und abschließende Vorfallsbewertung sichern. |
Wer verantwortet Kenntniserlangung und Eskalation?
Benenne eine verantwortliche Incident-Leitung und eine erreichbare Vertretung. Die Kenntniserlangung darf nicht künstlich bis zur Freigabe eines Tickets oder zur Veröffentlichung einer CVE verschoben werden. Dokumentiere, wer wann was wusste, und eskaliere unklare Meldetatbestände ohne auf vollständige Zuordnung zu warten.
- Meldungen von Forschenden, Kunden, Lieferanten, CSIRTs und Monitoring in einen Aufnahmeprozess führen.
- Erstbeobachtung, Kenntniserlangung im Unternehmen, interne Eskalation und externe Übermittlungen unterscheiden. UTC-Zeitstempel mit Nachweisen speichern.
- Anwendungsbereich und Auslöser getrennt bewerten: Ein Scanner-Fund ist nicht automatisch eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Vorfall. Entscheidung und Verantwortung dokumentieren.
Was gehört in die Vorfallsakte?
Nutze eine dauerhafte Incident-ID über alle Meldestufen. Trenne bestätigte Fakten von Annahmen und weise wesentlichen offenen Punkten Verantwortliche zu. Das folgende Schema ist eine technische Empfehlung, keine Behauptung, dass jedes Feld im externen Formular verpflichtend ist.
- Produkt und betroffene Version, Herstellerrolle, Länder, Kategorie, Ausnutzungs- oder Schweregradnachweise, Kenntniszeitpunkt und die beiden ersten Fristen erfassen.
- Bei Schwachstellen die Verfügbarkeit der Korrekturmaßnahme speichern, bei schwerwiegenden Vorfällen den Zeitpunkt der 72-Stunden-Meldung. Daraus die jeweils eigene Abschlussfrist berechnen.
- Belege, Bewertungsänderungen, Verantwortliche, Maßnahmen- und Rolloutentscheidungen, Kommunikation, übermittelte Inhalte und Eingangsbestätigungen aufbewahren.
- Sensible Exploit-Details und personenbezogene Daten beschränken. Zugriffe, angemessene Aufbewahrung und eine bereinigte Ansicht für die Zusammenarbeit festlegen.
Wo wird gemeldet und wie wird geübt?
Die Single Reporting Platform von ENISA ist seit 11. September 2026 in Betrieb. Nutze die offiziellen Zugangs- und Nutzungshinweise statt eine öffentliche Melde-API vorauszusetzen. Richte autorisierte Zugänge und Vertretungen jetzt ein; halte die interne Vorfallsakte unabhängig vom externen Formular.
- Zugang, Zuständigkeiten und passenden CSIRT-Meldeweg anhand der offiziellen Plattformhinweise prüfen.
- Zwei interne Übungen durchführen: eine ausgenutzte Schwachstelle und einen schwerwiegenden Vorfall. Keine erfundenen Übungsvorfälle in den produktiven Meldekanal einsenden.
- Wochenenden, Abwesenheiten, verlorenen Plattformzugang, verzögerte Lieferantenmeldungen und Sicherung der Eingangsbestätigungen testen.
Operative Prüfungen, die jetzt erforderlich sind
- Betroffene Produkte, Herstellerverantwortung, Incident-Leitung und Vertretung festlegen.
- Offiziellen Plattformzugang prüfen und aktuelle Meldeanleitungen im Incident-Handbuch pflegen.
- Kenntniszeitpunkte sowie getrennte 24-Stunden-, 72-Stunden- und kategoriespezifische Abschlussfristen abbilden.
- Meldungseingang mit Produkt-, Release- und Behebungsdaten verbinden; Zugriffsschutz und Abruf der Nachweise testen.
- Beide Kategorien üben, erkannte Lücken schließen und regelmäßige Übungen festlegen. Ein Verbesserungsprojekt setzt keine Meldefrist aus.
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:
Häufige Fragen zur CRA-Meldung
Gelten die Meldepflichten für Hersteller schon?
Laufen die 24- und 72-Stunden-Fristen nacheinander?
Ist jeder Abschlussbericht binnen 14 Tagen fällig?
Gilt für Open-Source-Software-Stewards derselbe Starttermin?
Braucht die Frühwarnung eine abgeschlossene Ursachenanalyse?
Ist dieser Leitfaden eine rechtliche Compliance-Bestätigung?
Fazit
Jetzt zählt verlässliche Ausführung: eine Vorfallsakte, klare Verantwortung mit Vertretung und getrennte Abschlussfristen für die beiden Kategorien. Meldung, Behebung und Kundenkommunikation müssen verbunden bleiben, ohne auf eine perfekte Ursachenanalyse zu warten.
Primärquellen
- Europäische Kommission: CRA-Meldepflichten. Termine für Hersteller und Stewards sowie beide Meldekategorien und Fristen
- ENISA: Single Reporting Platform. Offizieller Zugang, Nutzungshinweise und Meldematerialien
- Europäische Kommission: CRA-Anwendungsleitlinien. Anwendungsbereich und Umsetzung; aktuellen Abschnitt zur Meldung beachten