Für Hersteller von Produkten mit digitalen Elementen sind die Meldepflichten nach Artikel 14 des Cyber Resilience Act (CRA) seit dem 11. September 2026 praktisch wirksam. Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, welche die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen. Die Meldung erfolgt über die CRA Single Reporting Platform (SRP) an das zuständige koordinierende CSIRT und grundsätzlich gleichzeitig an ENISA.
Die zentrale operative Herausforderung liegt nicht in einer vollständigen technischen Aufklärung innerhalb weniger Stunden. Entscheidend ist vielmehr, dass ein Hersteller den Zeitpunkt der Kenntniserlangung belastbar festhält, den Sachverhalt zügig einordnet und auf Basis der verfügbaren Fakten handlungsfähig bleibt. Product Security, PSIRT, Incident Response, Entwicklung, Legal, Compliance und Management benötigen dafür einen abgestimmten Ablauf.
Meldeauslöser präzise einordnen
Eine entdeckte Schwachstelle ist nicht allein deshalb meldepflichtig. Nach den ENISA-Erläuterungen liegt eine aktiv ausgenutzte Schwachstelle vor, wenn belastbare Hinweise bestehen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systeminhabers ausgenutzt hat. Theoretische Ausnutzbarkeit oder ein noch unbestätigter Verdacht reichen für sich genommen nicht aus.
Ein schwerer Sicherheitsvorfall ist nach Artikel 14 Absatz 5 CRA gegeben, wenn er die Fähigkeit des Produkts zum Schutz von Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen negativ beeinträchtigt oder beeinträchtigen kann. Das gilt auch, wenn der Vorfall zur Einführung oder Ausführung von Schadcode im Produkt oder in den Netz- und Informationssystemen eines Produktnutzers geführt hat oder führen kann.
Diese Einordnung ist eine frühe Steuerungsentscheidung. Ein internes Verfahren sollte deshalb zwischen bestätigten Tatsachen, fachlichen Bewertungen, offenen Punkten und unbestätigten Annahmen unterscheiden. Dies gilt besonders für die Angreiferzuordnung: Soweit keine verlässliche Attribution vorliegt, sollen beobachtete Indikatoren beschrieben und die Attribution als unbekannt ausgewiesen werden. Das SRP-Glossar von ENISA verdeutlicht, dass Angaben etwa zu Angriffsvektor, CVE oder Attribution nur soweit erwartet werden, wie belastbare Informationen vorhanden sind.
Fristen ab Kenntniserlangung steuern
Für beide Meldegegenstände gilt eine Frühwarnung ohne ungerechtfertigte Verzögerung und spätestens 24 Stunden nach Kenntniserlangung. Spätestens innerhalb von 72 Stunden ist eine Folgemeldung mit allgemeinen Informationen und einer Erstbewertung einzureichen. Für den Abschlussbericht gelten unterschiedliche Zeitpunkte:
- Bei einer aktiv ausgenutzten Schwachstelle ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Minderungsmaßnahme fällig.
- Bei einem schweren Sicherheitsvorfall ist er innerhalb eines Monats nach der 72-Stunden-Meldung einzureichen.
Die Fristen sollten aus einem intern dokumentierten Awareness-Zeitpunkt berechnet werden. Zu diesem Protokoll gehören mindestens Informationsquelle, Zeitpunkt, bewertende Funktion, Produktbezug sowie die Begründung der ersten Einordnung. SRP-Reminder oder Plattformzähler sind hierfür keine hinreichende Steuerungsgrundlage. ENISA weist darauf hin, dass die aktuelle Plattformanzeige die Fälligkeit der Folgemeldung 48 Stunden nach Abgabe der Frühwarnung berechnet. Dadurch kann eine Meldung als überfällig erscheinen, obwohl seit Kenntniserlangung noch keine 72 Stunden vergangen sind. Die Verantwortung für die gesetzlichen Fristen bleibt beim Hersteller.
Die ersten 24 Stunden: minimal belastbare Frühwarnung
Die Frühwarnung dient nicht der abschließenden Ursachenanalyse. Sie verlangt jedoch strukturierte Mindestinformationen. Nach dem SRP-Glossar gehören hierzu unter anderem ein Titel, eine faktenbasierte Zusammenfassung, Produktname und Produktversion, bekannte Mitgliedstaaten der Bereitstellung sowie der Zeitpunkt der Kenntniserlangung. Bei schweren Sicherheitsvorfällen ist außerdem anzugeben, ob der Vorfall mutmaßlich auf rechtswidrige oder böswillige Handlungen zurückgeht.
Damit diese Angaben zeitgerecht vorliegen, benötigen Hersteller ein mit PSIRT-, Release- und Vertriebsprozessen verbundenes Produkt-, Versions- und Vertriebslandregister. Besonders bei Produkten mit mehreren Komponenten oder Lieferantenanteilen darf die Ermittlung betroffener Versionen nicht erst mit dem Meldefall beginnen. Auch Lieferanten- und Komponentenprozesse sollten zeitkritische Eskalationswege vorsehen: Informationen über die aktive Ausnutzung einer Drittkomponente können für die Bewertung eigener Produkte und erforderlicher Maßnahmen maßgeblich sein.
Praktisch bewährt sich eine entscheidungsfähige 24-Stunden-Triage. Sie bewertet auf Basis der vorliegenden Informationen, ob ein meldepflichtiger Sachverhalt wahrscheinlich vorliegt, welche Produkte betroffen sein können und ob eine Frühwarnung freizugeben ist. Die weitere technische Untersuchung läuft anschließend fort; sie darf eine erforderliche Frühwarnung nicht unnötig verzögern.
Bis 72 Stunden: Faktenbild und Maßnahmen konkretisieren
Die Folgemeldung erfordert eine fachliche Anreicherung. Bei aktiv ausgenutzten Schwachstellen betrifft dies insbesondere das Produkt, die allgemeine Art von Exploit und Schwachstelle sowie bereits ergriffene und für Nutzer verfügbare Maßnahmen. Bei schweren Sicherheitsvorfällen sind insbesondere Art des Vorfalls, Erstbewertung sowie ergriffene und verfügbare Maßnahmen zu übermitteln.
Ein internes Meldepaket sollte daher bestätigte Fakten und offene Punkte getrennt dokumentieren. Sinnvoll sind zudem die betroffenen Produkte, Versionen und Komponenten, die Wirkungsanalyse, Eindämmungs- und Abhilfemaßnahmen, mögliche Nutzermaßnahmen sowie Quellen und Zeitstempel. Die Bewertung einer Information als sensitiv sollte ebenfalls nachvollziehbar festgehalten werden. So bleibt erkennbar, welche Aussage auf gesicherten Erkenntnissen beruht und welche später aktualisiert werden muss.
Abschlussbericht mit Remediation verbinden
Der Abschlussbericht darf nicht als isolierte Compliance-Aufgabe behandelt werden. Bei aktiv ausgenutzten Schwachstellen knüpft seine Frist an die Verfügbarkeit einer Abhilfe- oder Minderungsmaßnahme an. Damit besteht eine unmittelbare Verbindung zu Patch-, Workaround-, Release- und Kundenkommunikationsprozessen. Bei schweren Sicherheitsvorfällen läuft die Frist dagegen ab der 72-Stunden-Meldung.
PSIRT und Produktverantwortliche sollten deshalb frühzeitig klären, welche Maßnahme verfügbar ist, für welche Versionen sie gilt, welche Restrisiken verbleiben und welche Schritte Nutzer selbst durchführen müssen. Legal und Compliance können die Konsistenz mit der eingereichten Meldung und die Dokumentation der Freigaben unterstützen. Das Management benötigt ein transparentes Lagebild, ohne die operative Meldung durch unnötig lange Eskalationsstufen zu verzögern.
Rollen, Freigaben und SRP-Betriebsbereitschaft
Die gesetzliche Verantwortung des Herstellers und die technischen Plattformrollen sind auseinanderzuhalten. Intern sollte eindeutig geregelt sein, wer Fakten bereitstellt, wer die Meldepflicht bewertet, wer Freigaben verantwortet und wer die Meldung tatsächlich einreicht. Ein mögliches Rollenmodell weist Product Security oder PSIRT die technische Triage und Schwachstellenbewertung zu; Incident Response liefert Erkenntnisse zum Ereignisverlauf und zur Wirkung. Produktentwicklung verantwortet technische Abhilfen, während Legal und Compliance die regulatorische Einordnung und Nachweisführung unterstützen. Die Geschäftsleitung sollte für definierte Eskalationsfälle eingebunden sein.
In der SRP gibt es pro Hersteller genau einen Primary Assigned Representative sowie bis zu 20 Secondary Assigned Representatives. Beide Rollen können Meldungen einreichen und aktualisieren. Entwürfe sind jedoch nur im jeweiligen Konto des Assigned Representative sichtbar. Daher sollte die interne Falldokumentation nicht ausschließlich in einem noch nicht eingereichten SRP-Entwurf liegen. Mindestens zwei handlungsfähige Secondary Assigned Representatives zu benennen und in Übungen zu testen, reduziert das Ausfallrisiko einzelner Personen.
Der Hersteller wählt das koordinierende CSIRT. Grundsätzlich ist dies das CSIRT des Mitgliedstaats, in dem sich die Hauptniederlassung in der EU befindet, also dort, wo Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Die ENISA-FAQ zur SRP erläutert auch Ersatzanknüpfungen für nicht eindeutig bestimmbare oder außerhalb der EU ansässige Hersteller.
Manuelle Übermittlung und Ausfallszenarien einplanen
Die erste SRP-Version stellt keine API bereit. Interne Datenbestände, Triage-Workflows und Freigaben können zwar automatisiert vorbereitet werden; die Übermittlung erfolgt jedoch zunächst über die Plattformoberfläche. Der Prozess muss deshalb auch unter Zeitdruck manuell ausführbar sein.
Für eine vorübergehend nicht verfügbare SRP sollte ein abgestimmter Kommunikationsplan mit Kontaktwegen zum koordinierenden CSIRT bestehen. Hält der Hersteller eine sofortige Kommunikation für erforderlich, kann er das koordinierende CSIRT direkt kontaktieren. Die verpflichtende Meldung ist nach Wiederverfügbarkeit jedoch über die SRP nachzureichen. Ein regelmäßig getesteter Notfallablauf verhindert, dass technische Plattformprobleme zu ungeklärten Verantwortlichkeiten führen.
Ein belastbarer CRA-Meldeprozess verbindet damit regulatorische Fristensteuerung, technische Untersuchung, Produktdaten, Remediation und nachweisbare Entscheidungen. Er ist nicht erst im akuten Vorfall aufzubauen: Rollen, Informationsquellen, Vertretungen, Freigaben und Ausfallwege müssen vorher definiert und praktisch erprobt sein.