Seit dem 11. September 2026 gelten die Meldepflichten nach Artikel 14 des Cyber Resilience Act (CRA). Für Hersteller liegt die operative Herausforderung jedoch nicht allein in den Fristen. Eine belastbare Meldung setzt voraus, dass zeitkritische Informationen zu Produkt, Version, Verfügbarkeit, Sicherheitslage und Gegenmaßnahmen konsistent, nachvollziehbar und freigabefähig vorliegen.
Das am 1. Oktober 2026 aktualisierte CRA-SRP-Glossar von ENISA macht diese Anforderung konkret. Es ist kein eigenständiger Rechtsakt und ersetzt nicht die Vorgaben der Verordnung. Als operative Hilfestellung zeigt es aber, welche Daten in den Feldern der Single Reporting Platform (SRP) erwartet werden. Hersteller sollten diese Feldlogik daher in eine eigene Daten- und Nachweisarchitektur übersetzen, statt sie erst im Vorfall in der Plattform abzubilden.
Nicht die Frist allein, sondern die Meldungsgrundlage ist kritisch
Artikel 14 der Verordnung (EU) 2024/2847 erfasst aktiv ausgenutzte Schwachstellen sowie schwerwiegende Sicherheitsvorfälle, welche die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen. Eine aktiv ausgenutzte Schwachstelle setzt belastbare Belege voraus, dass ein böswilliger Akteur sie ohne Erlaubnis des Systeminhabers ausnutzt. Ein Sicherheitsvorfall ist unter anderem dann schwerwiegend, wenn er die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit wichtiger oder sensibler Daten oder Funktionen beeinträchtigt oder beeinträchtigen kann oder Schadcode im Produkt beziehungsweise in Systemen eines Nutzers eingeführt oder ausgeführt wurde oder werden kann.
Für beide Fallgruppen ist eine Frühwarnung unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung, und eine weitere Meldung binnen 72 Stunden erforderlich. Für aktiv ausgenutzte Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Minderungsmaßnahme vorzulegen. Bei schwerwiegenden Sicherheitsvorfällen beträgt die Frist für den Abschlussbericht einen Monat ab der 72-Stunden-Meldung. Die rechtlichen Anforderungen ergeben sich aus dem CRA; die Kommission erläutert die Meldearchitektur zusätzlich auf ihrer Informationsseite zu den CRA-Reporting-Pflichten.
Die erste operative Leitfrage lautet deshalb nicht nur: „Ist die 24-Stunden-Frist gestartet?“ Sie lautet auch: „Welche Fakten sind zum maßgeblichen Zeitpunkt belegt, welche sind geschätzt und welche werden noch untersucht?“ Ein Runbook muss diese Unterscheidung erzwingen und dokumentierbar machen.
Awareness, Ereigniszeitpunkt und Maßnahmenverfügbarkeit trennen
Für aktiv ausgenutzte Schwachstellen sieht das SRP-Glossar ein Pflichtfeld für Datum und Uhrzeit der Kenntniserlangung vor. Gemeint ist der Zeitpunkt, zu dem der Hersteller oder eine andere relevante Partei die Schwachstelle erstmals erkannt hat. Ist dieser Zeitpunkt nicht exakt rekonstruierbar, soll die bestgestützte Schätzung als solche in der Beschreibung kenntlich gemacht werden. Der Zeitpunkt des tatsächlichen Auftretens oder der Ausnutzung ist davon zu trennen und wird für die 72-Stunden-Meldung relevant.
Bei schwerwiegenden Sicherheitsvorfällen fordert das Glossar ebenfalls einen Awareness-Zeitpunkt für Frühwarnung und 72-Stunden-Meldung. Hinzu kommt in der zweiten Stufe der bekannte oder geschätzte Ereigniszeitpunkt. Für die Friststeuerung, die spätere Nachvollziehbarkeit und mögliche Eskalationen dürfen diese Zeitpunkte nicht in einer unstrukturierten Incident-Chronik verschwimmen.
Praktisch empfiehlt sich eine beweissichere Zeitlinie in UTC. Sie sollte mindestens Quelle und Eingang der Erstinformation, die erste fachliche Bewertung, verantwortliche Bearbeiter, gesicherte Belege, Entscheidungen zur Meldefähigkeit und den Status offener Fragen enthalten. Ebenso separat zu dokumentieren ist, wann ein Patch, ein Workaround oder eine andere Minderungsmaßnahme tatsächlich verfügbar wurde. Gerade dieser Zeitpunkt trägt bei aktiv ausgenutzten Schwachstellen die Frist für den Abschlussbericht.
SRP-Felder als internes Datenmodell nutzen
Bereits die Frühwarnung verlangt laut Glossar unter anderem Meldungstyp, Titel, Zusammenfassung, betroffene Mitgliedstaaten, Produktname und genaue Produktversion. Zusätzlich sind Felder für Produktkategorie, Komponenten, End-of-Support-Status, erwartete Abhilfe, verfügbare Nutzermaßnahmen, Informationssensitivität und bereits ergriffene Maßnahmen vorgesehen.
Diese Angaben sollten nicht als Formulararbeit des PSIRT verstanden werden. Sie bilden Anforderungen an mehrere Datenquellen ab. Ein belastbares Runbook verknüpft daher ein Fallmanagement mit vorgehaltenen Produktstammdaten. Mindestens verfügbar sein sollten:
- offizieller Produktname sowie betroffene Versionen, Builds und Komponenten,
- zuständiges Produktteam, Release- und Updatekanäle,
- Support- und End-of-Support-Status,
- Mitgliedstaaten, in denen das Produkt verfügbar ist,
- Kontakt- und Kommunikationswege für Nutzer,
- Status, Umfang und Verfügbarkeit von Patch, Workaround oder sonstigen Maßnahmen.
Besondere Aufmerksamkeit verdient die Verfügbarkeit nach Mitgliedstaaten. Die gesetzliche Meldung wird über den Endpunkt des koordinierenden CSIRT des Mitgliedstaats der Hauptniederlassung des Herstellers in der Union eingereicht und ist grundsätzlich gleichzeitig für ENISA zugänglich. Der empfangende CSIRT leitet sie an weitere relevante koordinierende CSIRTs in Mitgliedstaaten weiter, in denen das Produkt verfügbar ist. Vertriebs- und Bereitstellungsdaten sind damit kein nachgelagerter Vertriebsaspekt, sondern Teil der Meldungsgrundlage.
Zwei Fallpfade mit unterschiedlichen Faktenlagen
Für eine aktiv ausgenutzte Schwachstelle führt PSIRT oder Vulnerability Management die Beleglage zur Ausnutzung. Produktentwicklung und Release Management müssen zeitnah bestätigen, welche Versionen betroffen sind, welche Komponenten den Sachverhalt verursachen und ob Maßnahmen tatsächlich verfügbar und nutzbar sind. Unbestätigte Annahmen dürfen nicht als gesicherte Exploit-Fakten ausgegeben werden. Sie sollten als laufende Untersuchung oder Schätzung kenntlich bleiben.
Beim schwerwiegenden Sicherheitsvorfall beginnt der Fall häufig im Incident Response. Die Übergabe an Produktsecurity und Regulatory Reporting muss deshalb ausdrücklich definiert sein. Bis zur 72-Stunden-Meldung verlangt das Glossar unter anderem eine erste Bewertung, Informationen zu Vorfallsart, laufenden Maßnahmen, Schwere, Auswirkungen und wahrscheinlicher Ursache. Das Runbook sollte bestätigte forensische Befunde, Hypothesen, Reichweite und offene Untersuchungsfragen getrennt führen. Vorläufige Bewertungen müssen als vorläufig erkennbar sein.
In beiden Pfaden ist die Nutzerinformation kein bloßes Kommunikationsanhängsel. Nach Artikel 14 Absatz 8 sind betroffene Nutzer und gegebenenfalls alle Nutzer über Risiko sowie erforderliche Minderungs- und Abhilfemaßnahmen zu informieren. Dass das Glossar bereits umgesetzte Maßnahmen und konkret durch Nutzer ausführbare Maßnahmen als eigene Felder vorsieht, unterstreicht diese Verbindung.
Rollen und Freigaben vor dem Ereignis festlegen
Ein funktionsübergreifendes Reporting-Runbook braucht Verantwortungsobjekte statt einer abstrakten Sammelzuständigkeit. PSIRT und Vulnerability Management verantworten die technische Faktenlage bei Schwachstellen. Produktsecurity, Engineering und Release Management bestätigen Produkt- und Versionsscope sowie die Wirksamkeit und Verfügbarkeit von Maßnahmen. Incident Response liefert bei Sicherheitsvorfällen Lagebild und Ermittlungsstatus. Legal und Compliance sollten Meldefähigkeit, Sensitivität, Eskalationen und mögliche parallele Anforderungen prüfen, jedoch nicht zum alleinigen Datenlieferanten werden.
Die Kommunikationsverantwortung benötigt einen festen Übergabepunkt. Sicherheitswarnungen, Workarounds, Patch-Hinweise und Einschränkungen sollten inhaltlich mit den Angaben in der SRP abgestimmt werden. Vorab freigegebene Formate verkürzen dabei nicht die notwendige Sachprüfung, reduzieren aber vermeidbare Reibung unter Zeitdruck.
SRP-Betriebsfähigkeit und erste 24 Stunden prüfen
Die SRP setzt persönliche EU-Login-Konten mit Multi-Faktor-Authentifizierung voraus. Pro Hersteller kann es einen Primary Assigned Representative und bis zu 20 Secondary Assigned Representatives geben; beide Rollen können Meldungen einreichen und aktualisieren. Weil Entwürfe nur im individuellen Konto sichtbar sind, darf die interne Fallführung nicht auf SRP-Entwürfen beruhen. Erforderlich sind mehrere getestete Berechtigungen, Vertretungsregeln und ein unabhängiger interner Arbeitsbereich.
Die SRP-FAQ von ENISA weist zudem darauf hin, dass Plattformzähler nur Hilfsmittel sind und die gesetzliche Verantwortung nicht ersetzen. Der gegenwärtige 72-Stunden-Zähler orientiert sich an der Einreichung der Frühwarnung und soll künftig auf dem Awareness-Feld beruhen. Fristen sind daher intern anhand der gesetzlichen Vorgaben und des dokumentierten Awareness-Zeitpunkts zu steuern.
Für die ersten 24 Stunden sollte ein Runbook mindestens die Triage des Ereignistyps, den gesicherten Awareness-Zeitstempel, Produkt- und Versionsscope, Mitgliedstaaten der Verfügbarkeit, Nutzermaßnahmen, Evidenzstatus, Rollenaktivierung und die fristgerechte Einreichung abprüfen. Glossar, Feldpflichten und Plattformkonfiguration sind veränderliche operative Abhängigkeiten. Vorlagen und Kontrollen sollten daher regelmäßig gegen die jeweils aktuelle ENISA-Guidance geprüft werden.
Ein wirksames CRA-Reporting entsteht damit nicht in der SRP selbst. Es beruht auf einer vorab gepflegten Datenbasis, einer nachvollziehbaren Zeitlinie und klaren Entscheidungsrechten. Die Plattform ist der Übermittlungsweg; die belastbare Meldungsgrundlage muss im Herstellerunternehmen bereits bestehen.