CRA-Meldepflichten: 24 Stunden, 72 Stunden und Abschlussbericht richtig vorbereiten

Seit 11. September 2026 müssen Hersteller nach Artikel 14 des Cyber Resilience Act aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit melden. Die Meldung erfolgt über die ENISA Single Reporting Platform. Frühwarnung und weitergehende Meldung sind ohne unangemessene Verzögerung, spätestens innerhalb von 24 beziehungsweise 72 Stunden nach Kenntniserlangung erforderlich. Die Abschlussfrist unterscheidet sich nach Ereignisart.

Für die Einordnung in das gesamte Regelwerk führt der zentrale Überblick zum Cyber Resilience Act Pflichten, Fristen und Konformität zusammen. Den zeitlichen Kontext finden Sie zusätzlich in der Übersicht zu den CRA-Fristen 2026–2027; die organisatorische Verantwortung ist im Beitrag zu den CRA-Herstellerpflichten vertieft.

Praxisvorlage: Mit dem CRA Incident & Reporting Paket erhalten Sie editierbare Vorlagen für 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Abschlussbericht, Triage und interne Eskalation.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Schwachstellen & Meldeprozesse. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Die Produktbetroffenheit und interne Eskalation sollten durch eine PSIRT-Funktion mit klarer Vertretung koordiniert werden. Externe Finder melden über den CVD-Kontakt; dieser Eingang muss mit dem gesetzlichen Meldeprozess verbunden sein.

ENISA-Plattform: Zugang und Fristenkontrolle im Oktober 2026

Die CRA Single Reporting Platform der ENISA ist seit dem 11. September 2026 in Betrieb. Hersteller melden über die Plattform an das nach Artikel 14 Absatz 7 zuständige koordinierende CSIRT. Zugang, EU Login, verantwortliche Personen und Vertretung sollten vor dem ersten meldepflichtigen Ereignis vorbereitet sein.

Wichtig für die Fristenkontrolle: Die 24- und 72-Stunden-Fristen knüpfen an die Kenntniserlangung an. Die ENISA-FAQ, Stand 3. Oktober 2026, weist darauf hin, dass der 72-Stunden-Zähler der aktuellen Plattformversion noch von der Einreichung der Frühwarnung ausgeht. Dokumentieren Sie deshalb selbst den Kenntniszeitpunkt und kontrollieren Sie die gesetzliche Frist unabhängig vom Plattformzähler.

Die besonderen Meldepflichten für Open-Source-Software-Stewards nach Artikel 24 Absatz 3 beginnen am 11. Dezember 2027. Eine Organisation, die zugleich Hersteller ist, muss ihre Herstellerpflichten gesondert berücksichtigen. Freiwillige Meldungen nach Artikel 15 sind in der aktuellen Plattformversion laut ENISA noch nicht implementiert.

Seit wann gelten die CRA-Meldepflichten?

Artikel 14 gilt ab dem 11. September 2026. Dieser Termin ist ausdrücklich in Artikel 71 Absatz 2 festgelegt. Die Meldepflichten beginnen damit mehr als ein Jahr vor der vollständigen Anwendung des CRA am 11. Dezember 2027.

Das ist für Bestandsprodukte wichtig. Unternehmen dürfen nicht davon ausgehen, dass 2026 nur zukünftige Produktgenerationen relevant sind. Die Europäische Kommission weist darauf hin, dass die Meldepflichten auch Produkte mit digitalen Elementen betreffen können, die bereits vor dem 11. Dezember 2027 im EU-Markt bereitgestellt wurden.

Was muss bei einer aktiv ausgenutzten Schwachstelle gemeldet werden?

Ein Hersteller muss jede aktiv ausgenutzte Schwachstelle in einem Produkt mit digitalen Elementen melden, von der er Kenntnis erlangt. Die Meldung erfolgt über die einheitliche Meldeplattform gleichzeitig an das zuständige CSIRT und die ENISA.

Was bedeutet „aktiv ausgenutzt“?

Entscheidend ist nicht allein, dass eine technische Schwachstelle existiert. „Aktiv ausgenutzt“ beschreibt einen Fall, in dem verlässliche Anhaltspunkte dafür bestehen, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Erlaubnis des Systeminhabers ausgenutzt hat. Für die interne Triage braucht es deshalb eine klare Trennung zwischen einer theoretischen Schwachstelle, einem öffentlich bekannten Exploit und einer tatsächlich aktiv ausgenutzten Schwachstelle im Sinne der Meldepflicht.

Unternehmen sollten diese Einstufung nicht erst in einem Krisenfall definieren. Security-Team, Product Security, Entwicklung und Management benötigen ein gemeinsames Entscheidungsschema.

Welche Frist gilt für die 24-Stunden-Frühwarnung?

Die Frühwarnung muss unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntnis des Herstellers erfolgen. Bei aktiv ausgenutzten Schwachstellen sollen dabei unter anderem die Mitgliedstaaten angegeben werden, in deren Hoheitsgebiet das betroffene Produkt nach Kenntnis des Herstellers bereitgestellt wurde.

Die 24-Stunden-Meldung ist ausdrücklich als Frühwarnung angelegt. Das Unternehmen muss zu diesem Zeitpunkt noch nicht jede technische Ursache abschließend analysiert haben. Es muss aber genügend Informationen und Zuständigkeiten haben, um den Fall einzuordnen und die erste Meldung fristgerecht abzugeben.

Wann beginnt die 24-Stunden-Frist?

Der CRA knüpft an die Kenntnis des Herstellers an. Unternehmen sollten deshalb intern festlegen, welche Funktion oder Stelle Meldungen entgegennimmt und wann ein Sachverhalt als hinreichend bekannt gilt. Wenn ein Security-Mitarbeiter eine belastbare Information erhält, ist es riskant, den Fristbeginn künstlich bis zur nächsten Managementsitzung zu verschieben.

Ein guter Prozess protokolliert Zeitpunkte: Eingang der Information, erste Validierung, Eskalation, Entscheidung über Meldepflicht und Abgabe der Meldung.

Was muss innerhalb von 72 Stunden erfolgen?

Bei aktiv ausgenutzten Schwachstellen folgt grundsätzlich innerhalb von 72 Stunden nach Kenntnis eine ausführlichere Meldung, sofern die Informationen nicht bereits übermittelt wurden. Diese Meldung enthält soweit verfügbar allgemeine Informationen zum betroffenen Produkt, zur Art der Ausnutzung und Schwachstelle sowie zu ergriffenen Korrektur- oder Risikominderungsmaßnahmen.

Außerdem können Maßnahmen beschrieben werden, die Nutzer ergreifen sollen. Das zeigt, warum technische Analyse und Kundenkommunikation eng mit dem Meldeprozess verbunden sein müssen. Ein Incident-Team braucht schnell belastbare Aussagen zu betroffenen Versionen, Mitigations, Workarounds und Updateplänen.

Wann ist der Abschlussbericht bei Schwachstellen fällig?

Der Abschlussbericht ist grundsätzlich spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme vorzulegen, soweit die relevanten Informationen nicht bereits gemeldet wurden.

Der Bericht umfasst mindestens eine Beschreibung der Schwachstelle einschließlich Schweregrad und Auswirkungen, soweit verfügbar Informationen zu böswilligen Akteuren sowie Informationen über Sicherheitsupdate oder andere Korrekturmaßnahmen.

Welche Meldepflicht gilt bei schweren Sicherheitsvorfällen?

Neben aktiv ausgenutzten Schwachstellen müssen Hersteller schwere Sicherheitsvorfälle melden, die sich auf die Sicherheit eines Produkts mit digitalen Elementen auswirken. Auch hier ist innerhalb von 24 Stunden eine Frühwarnung vorgesehen.

Die Frühwarnung soll unter anderem angeben, ob der Verdacht besteht, dass der Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist. Danach folgt grundsätzlich innerhalb von 72 Stunden eine weitergehende Meldung. Für den Abschlussbericht gilt bei schweren Vorfällen eine Frist von grundsätzlich einem Monat nach der 72-Stunden-Meldung.

Was ist ein „schwerer Sicherheitsvorfall“?

Ein Sicherheitsvorfall ist nicht automatisch schwer. Für die Einordnung müssen Auswirkungen auf die Sicherheit des Produkts betrachtet werden. Relevant sind insbesondere Vorfälle, die die Fähigkeit eines Produkts beeinträchtigen, Daten, Funktionen oder Dienste gegen unbefugte Zugriffe, Manipulation oder Störungen zu schützen.

Unternehmen sollten Schwellenwerte und Kriterien festlegen. Dazu können Reichweite, Anzahl betroffener Nutzer oder Produkte, mögliche Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit, Dauer, Ausnutzbarkeit und mögliche physische Folgen gehören. Die Kriterien müssen zum Produktportfolio passen.

Wohin wird gemeldet?

Die Meldung erfolgt über die einheitliche Meldeplattform nach Artikel 16. Sie richtet sich gleichzeitig an das zuständige CSIRT des Mitgliedstaats und die ENISA. Welches CSIRT als Koordinator zuständig ist, hängt von den Regeln des CRA und der Hauptniederlassung des Herstellers ab.

Für Unternehmen ist vor allem wichtig, dass der technische Meldeweg nicht erst im Vorfall gesucht wird. Verantwortliche sollten Zugang, Vertretung und benötigte Kontoinformationen vorbereiten und den internen Ablauf testen.

Welche Informationen muss ein Unternehmen vorhalten?

Die kurzen Fristen zwingen Hersteller zu guter Produkttransparenz. Ohne aktuelle Produkt- und Komponenteninformationen wird aus einer Schwachstellenmeldung schnell eine Suchaktion.

Mindestens schnell verfügbar sollten sein:

• betroffene Produkte und Produktversionen,
• Verbreitung im EU-Markt und relevante Mitgliedstaaten,
• betroffene Software- oder Hardwarekomponenten,
• Schweregrad und Auswirkungen,
• Hinweise zur aktiven Ausnutzung,
• bekannte Angriffswege,
• verfügbare Mitigations und Workarounds,
• Status eines Sicherheitsupdates,
• zuständige interne Ansprechpartner,
• Zeitleiste der Kenntnis und Reaktion.

Eine versionierte SBOM hilft besonders bei der schnellen Zuordnung einer Schwachstelle zu Produkten. Sie ersetzt aber nicht die technische Bewertung der Ausnutzbarkeit.

Wie sollte ein interner 24/72-Stunden-Prozess aussehen?

Der Prozess muss einfach genug sein, um unter Zeitdruck zu funktionieren. Ein großes Handbuch ohne klare Entscheidungspunkte ist weniger wert als ein kurzer, getesteter Ablauf.

Schritt 1: Eingang zentralisieren

Sicherheitsmeldungen sollten über eine zentrale Kontaktstelle eingehen. Zusätzlich müssen interne Quellen wie Monitoring, Support, Lieferantenmeldungen, Bugtracker und Security Advisories berücksichtigt werden.

Schritt 2: Sofortige Triage

Eine verantwortliche Person prüft, ob das betroffene Produkt in den CRA fällt, ob der Hersteller verantwortlich ist und ob Anzeichen für aktive Ausnutzung oder einen schweren Sicherheitsvorfall vorliegen. Der Zeitpunkt des Eingangs wird dokumentiert.

Schritt 3: Produktumfang bestimmen

Über Produktinventar und SBOM werden betroffene Versionen, Komponenten und Märkte ermittelt. Parallel wird geprüft, ob weitere Produktlinien denselben verwundbaren Baustein verwenden.

Schritt 4: Meldeentscheidung eskalieren

Die Entscheidung darf nicht von einer einzigen Person abhängen, die gerade nicht erreichbar ist. Eine Vertretungsregel und klar definierte Entscheidungsbefugnis sind Pflicht für einen belastbaren Prozess.

Schritt 5: 24-Stunden-Frühwarnung

Die verfügbaren Informationen werden fristgerecht übermittelt. Offene technische Fragen werden klar als noch in Analyse befindlich gekennzeichnet.

Schritt 6: 72-Stunden-Meldung vorbereiten

Entwicklung, Security und Produktmanagement liefern technische Details, Mitigations, betroffene Versionen und Kundenmaßnahmen. Die Meldung wird aktualisiert.

Schritt 7: Korrektur und Abschlussbericht

Nach Bereitstellung einer Korrektur werden Ursachen, Auswirkungen, Sicherheitsupdate und weitere Maßnahmen dokumentiert und fristgerecht im Abschlussbericht zusammengeführt.

Wie hängt die Meldepflicht mit Kundenkommunikation zusammen?

Die CRA-Meldung an Behörden ersetzt nicht die Pflicht, Nutzer angemessen zu informieren. Hersteller müssen bei Sicherheitsproblemen verständliche Informationen und Korrekturmaßnahmen bereitstellen. Ein Patch ohne klare Information zu betroffenen Versionen und Installationsschritten kann die Risikominderung verzögern.

Unternehmen sollten deshalb eine Kommunikationsmatrix vorbereiten: Behördenmeldung, direkte Kundeninformation, Security Advisory, Release Notes, Supportanweisung und gegebenenfalls öffentliche Schwachstelleninformation.

Welche Rolle spielen Lieferanten?

Eine Schwachstelle kann in einer Drittkomponente liegen. Der Hersteller des Endprodukts braucht dann schnell Informationen vom Zulieferer: betroffene Versionen, Exploitstatus, Fix, Workaround und technische Auswirkungen. Wenn Verträge keine Security-Reaktionszeiten vorsehen, kann die CRA-Frist zum Problem werden.

Lieferantenvereinbarungen sollten deshalb definieren, wie sicherheitsrelevante Informationen weitergegeben werden, welche Ansprechpartner 24/7 erreichbar sind und welche SBOM- oder Versionsdaten geliefert werden.

Was sollte ein KMU anders machen?

Ein kleines Unternehmen braucht keinen überdimensionierten SOC-Prozess. Es braucht einen funktionierenden Prozess. Eine einfache Lösung kann aus einer zentralen Security-Mailadresse, einem dokumentierten Triage-Schema, zwei verantwortlichen Personen, einer Produktliste, einem SBOM-Ablageort und vorbereiteten Meldevorlagen bestehen.

Wichtig ist die Vertretung. Wenn nur ein Entwickler weiß, wie das Produkt aufgebaut ist, und diese Person nicht erreichbar ist, kann die 24-Stunden-Frist nicht zuverlässig eingehalten werden.

Welche Fehler sind besonders riskant?

Nur CVSS betrachten

Ein hoher CVSS-Wert allein entscheidet nicht, ob aktive Ausnutzung vorliegt. Umgekehrt kann eine Schwachstelle mit moderater Bewertung im konkreten Produkt sehr relevant sein.

Fristbeginn an Managementfreigabe koppeln

Die gesetzliche Frist hängt an Kenntnis des Herstellers, nicht an internen Sitzungsrhythmen. Freigabeprozesse müssen deshalb zur Frist passen.

Keine EU-Marktübersicht pflegen

Wenn nicht bekannt ist, in welchen Mitgliedstaaten ein Produkt bereitgestellt wurde, fehlen bereits für die Frühwarnung wichtige Informationen.

Produktversionen nicht sauber trennen

Ohne Versions- und Build-Zuordnung ist unklar, welche Kunden betroffen sind und welcher Patch hilft.

Meldeprozess nie testen

Ein Prozess, der nur auf Papier existiert, scheitert oft an Zugängen, Kontaktlisten oder fehlenden Daten. Mindestens ein Tabletop-Test vor dem ersten realen Vorfall ist sinnvoll.

Welche Daten sollten für eine CRA-Meldung sofort verfügbar sein?

Die kurzen Fristen lassen wenig Raum für langwierige Recherche. Hersteller sollten deshalb schon vor einem Vorfall festlegen, welche Informationen aus welchen Systemen gezogen werden. Eine vorbereitete Datenbasis beschleunigt nicht nur die Meldung, sondern auch technische Bewertung und Kundenkommunikation.

Typischerweise sollten schnell verfügbar sein:

• eindeutige Produkt- und Versionsbezeichnung,
• Beschreibung der betroffenen Funktion oder Komponente,
• Zeitpunkt und Quelle der ersten Kenntnis,
• Hinweise auf aktive Ausnutzung oder Auswirkungen,
• betroffene Produktversionen und Märkte,
• erste Bewertung des Risikos und der Schwere,
• bereits eingeleitete Gegenmaßnahmen,
• verfügbare Patches oder Workarounds,
• zuständige interne Ansprechpartner,
• relevante Lieferanten oder Open-Source-Komponenten.

Warum sollte der Zeitpunkt der Kenntnis dokumentiert werden?

Die Meldefristen knüpfen an die Kenntnis des Herstellers an. Deshalb sollte nachvollziehbar sein, wann ein Hinweis erstmals einging, wann er als belastbar bewertet wurde und wann die interne Eskalation begann. Ein zentrales Security-Ticket oder Incident-Protokoll kann diese Zeitpunkte sauber festhalten.

Was passiert, wenn noch nicht alle Fakten feststehen?

Gerade die Frühwarnung ist dafür vorgesehen, dass zu Beginn noch Informationen fehlen können. Der Prozess sollte deshalb nicht auf vollständige technische Gewissheit warten. Wichtig ist, bekannte Fakten von Annahmen zu trennen und offene Punkte strukturiert nachzuliefern.

Wie lässt sich der Prozess testen?

Ein einfaches Szenario reicht: Eine häufig eingesetzte Bibliothek im Produkt wird aktiv ausgenutzt. Das Team erhält um 10:00 Uhr eine belastbare Meldung. Nun wird geprüft, wie schnell Produktversionen, Märkte, Ausnutzbarkeit, zuständige Personen und Mitigations ermittelt werden.

Der Test sollte messen, ob eine plausible Frühwarnung innerhalb von Stunden erstellt werden kann, ob die 72-Stunden-Informationen aus den vorhandenen Systemen zusammengeführt werden können und ob Kundenkommunikation und Patchprozess parallel funktionieren.

Wie hängen Meldepflichten und Herstellerpflichten zusammen?

Die Meldepflicht ist kein isolierter Compliance-Prozess. Sie funktioniert nur, wenn die grundlegenden CRA-Herstellerpflichten bereits organisatorisch verankert sind. Risikobewertung hilft bei der Auswirkungsanalyse, SBOM hilft bei der Produktzuordnung, Supportprozesse liefern Patchfähigkeit und technische Dokumentation schafft Produkttransparenz.

Deshalb sollte die CRA-Umsetzung nicht in „Meldung“ und „Produktkonformität“ getrennt werden. Beide Bereiche nutzen dieselben Daten und Verantwortlichkeiten.

Wer sollte intern über eine CRA-Meldung entscheiden?

Die Entscheidung sollte nicht an einer einzelnen Person hängen. Sinnvoll ist ein kleiner, vorab benannter Kreis aus Security, Produktverantwortung und Compliance beziehungsweise Recht. Für Abwesenheiten braucht es eine Vertretung, weil die 24-Stunden-Frist auch außerhalb normaler Bürozeiten laufen kann.

Wichtig ist außerdem eine klare Eskalationsschwelle: Technische Teams müssen wissen, ab wann ein Fund nicht mehr nur als normales Security-Ticket behandelt wird, sondern sofort in den CRA-Meldeprozess geht. So verliert das Unternehmen keine Stunden durch Zuständigkeitsfragen.

Die Entscheidung und ihre Grundlage sollten im Incident-Protokoll dokumentiert werden. Das gilt auch dann, wenn nach Prüfung keine Meldepflicht angenommen wird.

Wo stehen die Meldefristen im Original?

Die verbindlichen Meldepflichten stehen in Artikel 14 der Verordnung (EU) 2024/2847 bei EUR-Lex. Unternehmen sollten zusätzlich die aktuelle Ausgestaltung der einheitlichen Meldeplattform und neue Leitlinien der Europäischen Kommission beobachten.