CRA-Meldung an ENISA: Single Reporting Platform Schritt für Schritt nutzen

Eine CRA-Meldung an ENISA wird über die Single Reporting Platform, kurz SRP, eingereicht. Hersteller melden dort aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit. Entscheidend sind ein dokumentierter Kenntniszeitpunkt, die richtige Meldungsart und eine tatsächlich abgesendete Meldung. Ein gespeicherter Formularentwurf erfüllt die Meldepflicht nicht.

Seit dem 11. September 2026 gelten die Meldepflichten aus Artikel 14 des Cyber Resilience Act. Das Unternehmen sollte deshalb Personen, Informationen und Freigaben vorbereitet haben, bevor ein dringender Fall eintritt. Die Plattform bedient diesen Prozess; sie entscheidet weder über die rechtliche Betroffenheit noch übernimmt sie die technische Untersuchung.

Dieser Leitfaden erklärt den operativen Ablauf. Die rechtlichen Voraussetzungen und Fristen behandelt der Beitrag zu den CRA-Meldepflichten. Die Einordnung in das gesamte Regelwerk finden Sie im Überblick zum Cyber Resilience Act.

Welche Informationen braucht das Team vor der ersten Meldung?

Das Team braucht einen belastbaren Sachverhalt, den Zeitpunkt der Kenntnisnahme und eine eindeutige Zuordnung zum Hersteller und Produkt. Eine vollständige Ursachenanalyse muss für die frühe Warnung noch nicht vorliegen. Bekannte Fakten, Vermutungen und offene Fragen sollten jedoch klar getrennt werden.

Ein brauchbarer Meldefall beginnt nicht mit dem Formular, sondern mit einem internen Vorgang. Darin stehen Produktname, betroffene Versionen, Sicherheitswirkung, bisherige Belege und die Person, die die Bewertung verantwortet. Geben Sie den Belegen feste Kennungen. So lässt sich später nachvollziehen, welche Aussage auf welcher Untersuchung beruht.

Kenntniszeitpunkt und Beweislage festhalten

Ein eingehender Hinweis kann zunächst unbestätigt sein. Sobald verlässliche Nachweise einer aktiven Ausnutzung vorliegen, darf das Team den maßgeblichen Zeitpunkt nicht durch eine spätere Vorstandssitzung ersetzen. Dokumentieren Sie, wann welche Erkenntnis verfügbar war und wie sie bewertet wurde. Eine rückwirkend glattgezogene Zeitleiste ist weniger belastbar als ein ehrlicher Verlauf mit Ergänzungen.

Bei schwerwiegenden Vorfällen ist gesondert zu prüfen, ob die Kriterien für die Auswirkungen auf die Produktsicherheit erfüllt sind. Ein Ausfall des internen Ticketsystems ist nicht automatisch ein CRA-Produktvorfall. Ein kompromittierter Updatekanal kann dagegen unmittelbar die Integrität ausgelieferter Produkte betreffen.

Meldebereitschaft ohne unnötige Vorabregistrierung

ENISA empfiehlt nach dem derzeitigen Registrierungsleitfaden, die Registrierung und Validierung der Herstellerzuordnung bei einem konkreten Meldebedarf zu beginnen. Vorbereitung bedeutet deshalb zunächst: EU-Login-Konto mit Mehrfaktor-Authentifizierung, geklärte Befugnisse, Herstellerdaten und erreichbare Ansprechpartner. Das Unternehmen sollte keine fiktive Meldung erzeugen, um den Ablauf zu testen.

Üben lässt sich der Vorgang intern mit einem anonymisierten Szenario. Prüfen Sie dabei die Erreichbarkeit des vorgesehenen Meldenden, die Wiederherstellung des zweiten Faktors und die Verfügbarkeit der Informationen außerhalb der üblichen Arbeitszeit. Der Probeablauf endet vor einer echten Plattformübermittlung.

Wer darf die Single Reporting Platform bedienen?

Die SRP arbeitet mit Assigned Representatives, also zugeordneten Meldepersonen. Diese operative Plattformrolle ist nicht mit dem gesetzlichen CRA-Bevollmächtigten gleichzusetzen. Die Auswahl eines Mitarbeiters im Formular ersetzt weder eine interne Vollmacht noch eine rechtliche Rollenprüfung.

Ein Primary AR kann sich einem Hersteller zuordnen. Ein Secondary AR wird über eine Einladung eingebunden. Nach dem aktuellen ENISA-Leitfaden setzt die Einladung eines Secondary AR einen verifizierten Primary AR voraus. Diese Voraussetzung gehört in die Vertretungsplanung: Ein kurzfristig benannter Ersatz steht nicht allein durch seine Aufnahme in eine Telefonliste als Plattformnutzer bereit.

Die Organisation bleibt verantwortlich für richtige und fristgerechte Angaben. Interne Arbeitsteilung ist trotzdem sinnvoll. Die technische Untersuchung liefert Befunde, die juristische oder Compliance-Funktion prüft die Meldeeinordnung, und eine befugte Person sendet den abgestimmten Sachstand ab. Bei kleinen Teams können diese Aufgaben auf wenige Personen verteilt werden, solange Zuständigkeiten und Vertretung eindeutig bleiben.

Berechtigungen praktisch absichern

Verwenden Sie personenbezogene Zugänge. Gemeinsame Konten erschweren den Nachweis, wer eine Meldung eingereicht oder verändert hat. Bewahren Sie Wiederherstellungsinformationen sicher auf und testen Sie die interne Vertretung. Eine Meldebefugnis sollte nicht von einem einzigen privaten Smartphone oder einem nicht erreichbaren Dienstleister abhängen.

Beim Ausscheiden einer Meldeperson müssen EU-Login-Zugang, Plattformzuordnung und interne Freigaberechte getrennt betrachtet werden. Die Sperrung des Firmenkontos entfernt nicht zwingend jede externe Zuordnung. Hinterlegen Sie deshalb im Offboarding die Prüfung des SRP-Zugriffs.

Das Product Security Incident Response Team kann den Vorgang führen. Es braucht dafür keine große Abteilung, wohl aber eine verbindliche Schnittstelle zu Entwicklung, Support und Geschäftsleitung. Eine einzige erreichbare Fallleitung reduziert widersprüchliche Informationen.

Wie laufen Registrierung und frühe Warnung ab?

Die Meldeperson authentifiziert sich mit EU Login, wählt den zuständigen koordinierenden CSIRT und ordnet den Hersteller zu. Anschließend wird eine neue Meldung für eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall angelegt. Die Herstellerzuordnung kann nach dem aktuellen ENISA-Leitfaden noch in Prüfung sein, während bereits gemeldet wird.

Die Zuständigkeit des koordinierenden CSIRT richtet sich nach den gesetzlichen Kriterien. Die Auswahl darf nicht einfach nach Sprache, Wohnort des Mitarbeiters oder bequemstem Kontakt erfolgen. Halten Sie die Unternehmensstruktur und die Begründung für die Auswahl im internen Vorgang fest. Bei komplexen Konzernen muss klar sein, welche juristische Person das Produkt unter ihrem Namen vermarktet.

Formular und Sachverhalt zusammenführen

Die frühe Warnung enthält die erforderlichen Angaben zum bekannten Sachverhalt. Beschreiben Sie konkret, was beobachtet wurde, welche Produkte betroffen sein könnten und welche Wirkung die Ausnutzung oder der Vorfall hat. Kennzeichnen Sie eine Versionsspanne als vorläufig, wenn die Untersuchung noch läuft. Ein unbegründetes „alle Produkte betroffen“ ist ebenso problematisch wie ein zu eng angesetzter Umfang.

Ein Beispiel: Für ein Gateway liegen Logs vor, die eine unbefugte Änderung der Konfiguration über die Wartungsschnittstelle zeigen. Das Team kennt den betroffenen Softwarezweig, aber noch nicht jede ausgelieferte Hardwarevariante. Die Meldung sollte diese Trennung erklären. Der Hinweis auf laufende Variantenprüfungen ist aussagekräftiger als eine vermeintlich vollständige Liste ohne Belege.

Die gesetzliche frühe Warnung muss unverzüglich und spätestens innerhalb von 24 Stunden nach Kenntnis erfolgen. „Spätestens“ ist keine Empfehlung, grundsätzlich bis zum letzten Moment zu warten. Organisieren Sie die Freigabe so, dass unvollständige, aber zutreffend eingeordnete Informationen rechtzeitig übermittelt werden können.

Absenden und Eingangsbeleg prüfen

Die SRP unterscheidet das Speichern eines Entwurfs vom Einreichen. Kontrollieren Sie den Status nach der Übermittlung und sichern Sie die Bestätigung mit Fallreferenz und Zeitpunkt. Eine Bildschirmaufnahme des ausgefüllten Formulars allein beweist keine erfolgreiche Abgabe.

Bei einer Fehlermeldung wird nicht automatisch eine fristgerechte Meldung angenommen. Halten Sie technische Störungen, Wiederholungsversuche und Kontakte zum vorgesehenen Support beziehungsweise zuständigen CSIRT fest. Das Team braucht einen dokumentierten Ausweich- und Eskalationsablauf; ein selbst erfundener Ersatzkanal sollte nicht ungeprüft als gleichwertige Meldung behandelt werden.

Wie werden die 72-Stunden-Meldung und der Abschlussbericht bearbeitet?

Die weiteren Meldestufen gehören zum bestehenden Fall. Sie konkretisieren den Sachverhalt, die Auswirkungen und die Maßnahmen. Die gesetzliche 72-Stunden-Frist wird vom Kenntniszeitpunkt gerechnet und beginnt nicht erst mit der frühen Warnung.

Wer nach 20 Stunden früh warnt, hat deshalb nicht weitere 72 Stunden bis zur zweiten Meldung. Nutzen Sie einen eigenen Fristenkalender mit dokumentierter Zeitzone. Plattformanzeigen und Erinnerungen sind hilfreich, ersetzen aber nicht die gesetzliche Berechnung. Für Meldungen am Wochenende braucht die Vertretung denselben Informationszugang wie das reguläre Team.

Den Sachstand systematisch ergänzen

Ordnen Sie neue Erkenntnisse den bisherigen Angaben zu. Welche Versionsspanne wurde bestätigt? Welche Angriffsbedingungen sind erforderlich? Welche Gegenmaßnahme können Nutzer tatsächlich anwenden? Welche Risiken bleiben offen? Änderungen sollten begründet werden, besonders wenn sich der betroffene Umfang vergrößert oder verkleinert.

Ein guter Zwischenstand sagt beispielsweise: „Firmware 4.2 und 4.3 sind betroffen; 4.1 wurde mit dokumentiertem Test ausgeschlossen. Der externe Wartungszugang kann bis zur Installation des Updates deaktiviert werden.“ Das ist handlungsnäher als „Patch in Arbeit“. Die Angaben müssen zur verfügbaren Schwachstellenbewertung passen.

Für aktiv ausgenutzte Schwachstellen ist der Abschlussbericht grundsätzlich spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Risikominderungsmaßnahme fällig. Bei schwerwiegenden Sicherheitsvorfällen gilt grundsätzlich spätestens ein Monat nach Übermittlung der entsprechenden Vorfallmeldung; für fortdauernde Vorfälle sind die gesetzlichen Fortschritts- und Abschlussregeln gesondert zu beachten.

Abschluss nicht voreilig erklären

Vor der abschließenden Übermittlung sollten Ursachenbeschreibung, betroffene Produkte, Sicherheitswirkung und Maßnahmen zusammenpassen. Ein verfügbarer Patch ist nicht automatisch auf allen Geräten installiert. Beschreiben Sie deshalb getrennt die Bereitstellung, die Nutzerinformation und den bekannten Umsetzungsstand.

Nach dem derzeitigen Plattformleitfaden ist eine Meldung nach Übermittlung des Final Report nicht mehr auf dem üblichen Weg bearbeitbar. Planen Sie eine sorgfältige Endkontrolle ein und klären Sie bei späteren Korrekturen den vorgesehenen Weg mit der zuständigen Stelle. Wichtige neue Informationen dürfen nicht nur im internen Ticket verbleiben.

Welche Daten und Nachweise gehören in die interne Meldeakte?

Die Meldeakte muss den Entscheidungsweg und die tatsächlich übermittelten Informationen nachvollziehbar machen. Dazu gehören Belege, Versionen der Meldung, Freigaben, Eingangsbestätigungen und die Kommunikation mit zuständigen Stellen. Sie muss nicht jedes rohe Log dauerhaft und unbeschränkt enthalten.

Trennen Sie eine unveränderte Beweiskopie von Arbeitskopien und zusammenfassenden Darstellungen. Rohdaten können personenbezogene Angaben, Geheimnisse oder ausnutzbare Details enthalten. Das Meldeformular ist kein Ablageort für unbereinigte Kundendaten. Übermitteln Sie die erforderlichen Informationen über vorgesehene sichere Kanäle und beschränken Sie den internen Zugriff.

Eine einfache Aktenstruktur umfasst fünf Bereiche: Eingang und Kenntniszeitpunkt, technische Untersuchung, rechtliche Einordnung, übermittelte Meldungen und Maßnahmen mit Nutzerkommunikation. Jeder Bereich enthält eine verantwortliche Person und einen nachvollziehbaren Versionsstand. So muss eine Vertretung nicht zuerst einen langen Chatverlauf rekonstruieren.

Behördenmeldung und Nutzerinformation unterscheiden

Die SRP-Meldung erreicht die vorgesehenen Stellen. Sie ersetzt nicht die notwendigen Informationen an betroffene Nutzer. Für diese braucht es verständliche Produkt- und Versionsangaben, verfügbare Schutzmaßnahmen sowie einen sicheren Bezugspunkt für spätere Updates.

Die koordinierte Offenlegung von Schwachstellen hilft, technische Details und Schutzmaßnahmen zeitlich sinnvoll zusammenzuführen. Eine unkoordinierte Veröffentlichung vollständiger Angriffsschritte kann die Gefährdung erhöhen. Das bedeutet jedoch nicht, gesetzliche Meldungen oder erforderliche Nutzerwarnungen beliebig aufzuschieben.

Übergabe an die Vertretung

Ein Meldungsfall kann über mehrere Tage laufen. Die Übergabe sollte deshalb einen kurzen, aktuellen Lagebericht enthalten: bestätigter Umfang, offene Untersuchungen, nächste Frist, bereits übermittelte Angaben und verfügbare Nutzermaßnahmen. Die Vertretung muss erkennen können, welche Dokumente verbindlich und welche noch Arbeitsstände sind.

Ein Beispiel verdeutlicht den Bedarf: Am Freitagabend meldet ein Kunde eine zusätzliche betroffene Variante. Die reguläre Fallleitung ist ab Samstag nicht erreichbar. Die Vertretung muss die neue Information bewerten und gegebenenfalls ergänzen können, ohne eine neue unabhängige Meldung mit abweichendem Sachstand anzulegen. Die vorhandene Fallreferenz und der Bezug auf frühere Angaben gehören deshalb ausdrücklich in die Übergabe.

Eine gute Übergabe benennt auch die Grenzen der bisherigen Untersuchung. Wurde eine Variante nur anhand des Komponentenstands ausgeschlossen oder tatsächlich getestet? Liegt die Information direkt vom Kunden oder über einen Händler vor? Diese Unterschiede können für die nächste Entscheidung wesentlich sein.

Meldungsdaten unabhängig vom Portal sichern

Die interne Akte sollte die übermittelten Inhalte in kontrollierter Form enthalten. Das Team darf nicht allein darauf angewiesen sein, dass eine bestimmte Person später Zugriff auf die Plattformoberfläche besitzt. Ein gesicherter Export oder eine nachvollziehbare Kopie des tatsächlich abgesendeten Standes wird mit der Bestätigung verbunden.

Prüfen Sie außerdem, ob Ablageberechtigungen und Aufbewahrung zum vertraulichen Inhalt passen. Ein öffentlich zugänglicher Projektordner ist für technische Ausnutzungsdetails ungeeignet. Die Dokumentation soll Nachvollziehbarkeit schaffen und zugleich verhindern, dass die Sicherheitsreaktion selbst unnötige Informationen offenlegt.

Wie lässt sich die Meldefähigkeit im Alltag überprüfen?

Die Meldefähigkeit lässt sich durch einen internen Falltest mit konkreten Rollen, Fristen und Belegen prüfen. Ein vorhandenes EU-Login-Konto oder ein schriftlicher Prozess allein reicht nicht. Das Team muss auch unter Zeitdruck einen konsistenten Sachstand erzeugen und die Übermittlung nachweisen können.

Nutzen Sie für eine Übung einen begrenzten Fall: Ein Kunde meldet eine beobachtete Ausnutzung, zwei Versionszweige sind möglicherweise betroffen, und die zuständige Entwicklungsperson ist nicht erreichbar. Die Fallleitung soll in der Übung erklären, welche Informationen fehlen, welche Aussagen bereits belastbar sind und wer die verbleibenden Aufgaben übernimmt.

• Ist die erste Kontaktstelle außerhalb der Bürozeiten erreichbar?
• Kann eine Vertretung auf Herstellerdaten und technische Belege zugreifen?
• Sind Kenntniszeitpunkt und beide frühen Fristen eindeutig dokumentiert?
• Werden Meldungsentwurf und erfolgreiche Übermittlung unterschieden?
• Ist der Weg für ergänzende Informationen und technische Probleme bekannt?
• Können Nutzermaßnahmen unabhängig von der Behördenmeldung vorbereitet werden?

Bewerten Sie die Übung anhand ihrer Ergebnisse. Die wichtigste Kennzahl ist nicht die Zahl angelegter Tickets, sondern ob eine zutreffende Meldung mit gesichertem Eingangsbeleg rechtzeitig möglich war. Festgestellte Lücken werden als konkrete Aufgaben mit Verantwortlichem und Termin behandelt.

Weitere Bausteine finden Sie in der Themenübersicht CRA-Schwachstellen und Meldung. Ein funktionierender SRP-Prozess verbindet technische Reaktion, gesetzliche Meldung und verständliche Nutzerinformation. Erst diese Verbindung macht aus einem Formularzugang eine belastbare Meldefähigkeit.

Quelle und fachlicher Prüfstand: ENISA: CRA SRP AR User Manual und zugehörige Bedienhinweise. Quellen geprüft am 4. Oktober 2026. Redaktion: Jörn Poppenhäger.