--- title: "Hersteller von Produkten mit digitalen Elementen melden aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle in der EU; ENISA koordiniert EU-weite Meldungen." sdDatePublished: "2026-09-11T07:15:00Z" source: "https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/Single_Reporting_Platform-CRA/single_reporting_platform-cra.html" topics: - name: "computer security" identifier: "medtop:20000229" - name: "law" identifier: "medtop:20000121" - name: "regulatory authority" identifier: "medtop:20001173" - name: "international organisation" identifier: "medtop:20000644" locations: - "Germany" --- Hersteller von Produkten mit digitalen Elementen melden aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle in der EU; ENISA koordiniert EU-weite Meldungen. BSI - CRA Single Reporting Platform - CRA Single Reporting Platform Ab dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act ( CRA ). Sie betreffen Hersteller von Produkten mit digitalen Elementen im Sinne des CRA , die ihre Produkte auf dem Binnenmarkt der Europäischen Union ( EU ) bereitstellen. Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit von Produkten mit digitalen Elementen. Die von der Agentur der Europäischen Union für Cybersicherheit ( ENISA ) entwickelte und betriebene CRA Single Reporting Platform ( CRA - SRP ) ist die zentrale, EU -weit einheitliche und englischsprachige Meldeplattform. Hersteller übermitteln ihre jeweilige Meldung nur einmal. Die Meldung wird gleichzeitig dem zuständigen, als Koordinator benannten Computer Security Incident Response Team ( CSIRT ) und der ENISA zugänglich gemacht. Das koordinierende CSIRT kann die Informationen anschließend an weitere betroffene CSIRTs und erforderlichenfalls an die zuständigen Marktüberwachungsbehörden weitergeben. In Deutschland ist die CRA -Marktüberwachung ebenso wie das CERT -Bund als koordinierendes CSIRT im Bundesamt für Sicherheit in der Informationstechnik ( BSI ) ansässig. Die Meldung über die CRA - SRP ersetzt nicht andere Verpflichtungen des Herstellers, welche möglicherweise vorgeben, betroffene Nutzerinnen und Nutzer zu informieren und ihnen erforderlichenfalls geeignete Schutzmaßnahmen zu empfehlen. Die CRA - SRP ist über die Adresse https: Für den Zugang ist ein EU - Login -Konto erforderlich. Weitere Informationen sind auf dieser Seite aufgeführt sowie auf der CRA - SRP Webseite der ENISA verfügbar. Hinweis: Bitte beachten Sie, dass vor dem Bedarf einer Meldung über die CRA Single Reporting Platform ( CRA - SRP ) keine Registrierungspflicht besteht. Die CRA - SRP Registrierung und Meldungsabgabe ist im Bedarfsfall innerhalb von wenigen Minuten umsetzbar. Für die Einordnung der nach dem CRA meldepflichtigen Ereignisse gelten die folgenden Definitionen: Gemäß Artikel 3 Nr. 42 CRA ist dies eine Schwachstelle, für die zuverlässige Belege vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis nachweisbar in einem System ausgenutzt hat. Die folgenden beiden Voraussetzungen müssen für eine Meldepflicht gegeben sein: Die Schwachstelle befindet sich in einem Produkt mit digitalen Elementen. Es liegen belastbare Hinweise auf eine tatsächliche Ausnutzung in realen Systemen vor. Ein veröffentlichter Exploit (Code zur Ausnutzung der Schwachstelle), Proof-of-Concept-Code oder Portscans sind nicht ausreichend. Eine grundsätzlich ausnutzbare, allerdings nicht aktiv ausgenutzte Schwachstelle unterliegt nicht der CRA -Meldepflicht. Schwerwiegender Sicherheitsvorfall mit Auswirkungen auf Produkte mit digitalen Elementen Ein Sicherheitsvorfall mit Auswirkungen auf die Sicherheit eines Produkts gilt nach Artikel 3 Nr. 44 sowie Artikel 14 Abs. 5 CRA als schwerwiegend, wenn mindestens eine der folgenden Voraussetzungen erfüllt ist: Der Sicherheitsvorfall beeinträchtigt oder kann die Fähigkeit des Produkts beeinträchtigen, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten beziehungsweise Funktionen zu schützen. Der Sicherheitsvorfall hat zur Einschleusung oder Ausführung schädlichen Codes im Produkt oder im Netzwerk eines Nutzers geführt oder kann dazu führen. Beispiel: Ein Ransomware -Vorfall bei einem Hersteller ist nicht automatisch ein schwerwiegender Sicherheitsvorfall im Sinne des CRA . Dazu müsste er sich auf die Sicherheit des Produkts auswirken oder zur Manipulation von Software , Updates , Signaturschlüsseln oder Produktfunktionen führen können. Es gibt je Meldungskategorie drei aufeinander aufbauende Berichtsvarianten. Die Informationen werden schrittweise ergänzt. Bereits erfasste Informationen werden übernommen. Die Meldungen sind auf Englisch zu verfassen, damit die EU -weite Koordination effizient möglich ist. In der Frühwarnung sind insbesondere die Meldungskategorie, der Hersteller, das betroffene Produkt und ein aussagekräftiger Titel anzugeben. Bei einem Sicherheitsvorfall ist außerdem mitzuteilen, ob der Verdacht besteht, dass dieser auf rechtswidrige oder böswillige Handlungen zurückzuführen ist. Soweit bereits bekannt, können zusätzliche Angaben zum Vorfall, zur Schwachstelle und zu den betroffenen EU -Mitgliedstaaten ergänzt werden. In der detaillierteren Meldung werden die Angaben aus der Frühwarnung ergänzt und konkretisiert. Bei einer aktiv ausgenutzten Schwachstelle sind insbesondere folgende Informationen anzugeben, soweit sie verfügbar sind: allgemeine Beschreibung der Schwachstelle und ihrer Ausnutzung, bereits ergriffene Korrektur- oder Risikominderungsmaßnahmen, Maßnahmen, die Nutzer selbst ergreifen können, Einschätzung der Sensibilität der übermittelten Informationen. Bei einem schwerwiegenden Sicherheitsvorfall sind insbesondere folgende Angaben vorgesehen: Art sowie Zeitpunkt des Vorfalls, Einschätzung der Sensibilität der Informationen. Bei einer aktiv ausgenutzten Schwachstelle enthält der Abschlussbericht insbesondere: eine vollständige Beschreibung der Schwachstelle, Angaben zum ausnutzenden Akteur, soweit bekannt, Einzelheiten zum Sicherheitsupdate oder zu anderen Schutzmaßnahmen, Zeitpunkt, zu dem die Abhilfe verfügbar wurde. Der Abschlussbericht über eine Schwachstelle ist spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Schutzmaßnahme zu übermitteln. Bei einem schwerwiegenden Sicherheitsvorfall enthält der Abschlussbericht insbesondere: eine ausführliche Beschreibung des Sicherheitsvorfalls, Art der Bedrohung oder wahrscheinliche Ursache, bereits umgesetzte und noch laufende Abhilfemaßnahmen. Bis zur Übermittlung des Abschlussberichts können Hersteller bereits abgesendete Meldungen aktualisieren. Die CRA - SRP informiert das koordinierende CSIRT , die ENISA und gegebenenfalls bereits einbezogene weitere CSIRTs automatisch über Änderungen. Weitere Informationen zur Übermittlung von Meldungen über die CRA - SRP stehen auf der ENISA -Webseite zur Verfügung. Nach Übermittlung des Abschlussberichts kann die Meldung von der meldenden Person grundsätzlich nicht mehr bearbeitet werden. Nach Artikel 14 Abs. 2 (aktiv ausgenutzte Schwachstelle) und Artikel 14 Abs. 3 (schwerwiegender Sicherheitsvorfall) gelten für die aufeinander aufbauenden Berichtsvarianten folgende Fristen: Innerhalb von 24 Stunden eine Frühwarnung nach belastbarer Kenntnis des Herstellers über eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf Produkte mit digitalen Elementen. Innerhalb von 72 Stunden eine detailliertere Meldung. Innerhalb von 14 Tagen einen Abschlussbericht nach Bereitstellung einer Abhilfe- Schutzmaßnahme (z. B. Sicherheitsupdate) im Falle einer aktiv ausgenutzten Schwachstelle und einen Monat nach der vorherigen detaillierteren Meldung im Falle eines schwerwiegenden Sicherheitsvorfalls mit Auswirkung auf Produkte mit digitalen Elementen. Die Meldung wird von einer für den Hersteller benannten Vertretungsperson (engl. Assigned Representative ( AR )) übermittelt. Die CRA - SRP unterscheidet zwischen: einem Primary Assigned Representative als primärer Vertretungsperson und einem Secondary Assigned Representative als zusätzlicher beziehungsweise stellvertretender Vertretungsperson. Beide Rollen können Meldungen für den zugeordneten Hersteller übermitteln. Der Primary Assigned Representative kann weitere Secondary Assigned Representatives einladen. Gespeicherte Entwürfe sind ausschließlich für die Person sichtbar, die den jeweiligen Entwurf angelegt hat. Andere Assigned Representatives desselben Herstellers können diese Entwürfe nicht einsehen. Auch Open - Source - Software - Stewards übermitteln die sie betreffenden Meldungen nach Artikel 24 Absatz 3 CRA über die CRA - SRP . Zu einem späteren Zeitpunkt soll die CRA - SRP außerdem freiwillige Meldungen durch natürliche oder juristische Personen ermöglichen. Bei der erstmaligen Registrierung sind folgende Schritte vorgesehen: Rolle als Assigned Representative auswählen. Zuständiges Land mit dem als Koordinator benannten CSIRT auswählen. Über EU - Login authentisieren. Angaben zum vertretenen Hersteller eintragen. Die einzelnen Schritte sind auf der CRA - SRP Webseite der ENISA dargestellt: Welches nationale CSIRT zuständig ist, richtet sich grundsätzlich nach der Hauptniederlassung des Herstellers in der EU . Für Hersteller ohne Niederlassung in der EU gelten die weiteren Kriterien des Artikels 14 Absatz 7 CRA . Häufig gestellte Fragen ( FAQ ) Hier finden Sie die bislang am häufigsten gestellten Fragen (engl. Frequently Asked Questions , FAQ ) und die dazugehörigen Antworten. Wohin übermittle ich eine CRA -Pflichtmeldung, wenn die CRA - SRP vorübergehend nicht erreichbar ist? Nur in diesem Ausnahmefall senden Sie bitte die CRA -Pflichtmeldung per E-Mail an das Computernotfallteam des Bundes, CERT -Bund. Kontaktinformationen und Optionen zur E-Mail -Verschlüsselung stehen auf der Website des CERT -Bund zur Verfügung. Muss ich die CRA -Meldungen in englischer Sprache verfassen? Ja, die CRA - SRP ist englischsprachig, damit Meldungen EU -weit bearbeitet und weitergegeben werden können. Kann ein schwerwiegender Sicherheitsvorfall sowohl nach NIS-2 , als auch nach dem CRA meldepflichtig sein? Ja, das kann vorkommen. In diesem Fall ist der Vorfall sowohl nach NIS-2 (via BSI-Portal ), als auch nach dem CRA (via CRA - SRP ) zu melden. Sie können in der jeweiligen Meldung einen Referenzhinweis vermerken. Mit dem von der EU -Kommission vorgeschlagenen Digital Omnibus soll Artikel 23 NIS-2 um folgenden Absatz 12 ergänzt werden: 2. Artikel 23 wird wie folgt geändert: […] b) Folgender Absatz 12 wird angefügt: "Meldet ein Hersteller einen schwerwiegenden Sicherheitsvorfall gemäß Artikel 14 Absatz 3 der Verordnung ( EU ) 2024 2847 und enthält die Meldung des Sicherheitsvorfalls nach dem genannten Artikel einschlägige Informationen gemäß Absatz 4 des vorliegenden Artikels, so gilt die Meldung des Herstellers nach Artikel 14 Absatz 3 der Verordnung ( EU ) 2024 2847 auch als Meldung von Informationen gemäß Absatz 4 des vorliegenden Artikels." Wird die Regelung in dieser Form beschlossen, könnte eine doppelte Meldung nach NIS-2 und CRA entfallen. Die Meldung über die CRA - SRP würde dann zugleich die entsprechenden Informationspflichten nach NIS-2 erfüllen. Welche Anforderungen müssen mindestens bis zum 11. September 2026 neben der Meldung über die CRA - SRP erfüllt sein, etwa hinsichtlich Security .txt, Coordinated Vulnerability Disclosure ( CVD ) Prozess, CVD - Policy oder eigener Reporting -Webseite? Ab dem 11. September 2026 gelten zunächst die CRA - SRP Meldepflichten. Die übrigen Bestimmungen des CRA gelten grundsätzlich ab dem 11. Dezember 2027. Es ist jedoch sinnvoll, die Empfehlungen der Technischen Richtlinie BSI TR -03183 zum CRA bereits frühzeitig zu berücksichtigen. Im Technischen Umsetzungsdokument Teil 3 des BSI zum CRA wird neben einem Product Security Incident Response Team ( PSIRT )-Funktionspostfach auch ein CSIRT -Funktionspostfach empfohlen.Der CRA bezieht sich jedoch auf Produkte mit digitalen Elementen. Warum wird zusätzlich ein CSIRT benötigt? Eine Trennung zwischen PSIRT und CSIRT kann sinnvoll sein, damit aktiv ausgenutzte Schwachstellen in eigenen Produkten und schwerwiegende Sicherheitsvorfälle im eigenen Netz mit jeweils geeigneten Ressourcen bearbeitet werden. Abhängig von Produktportfolio, Organisationsgröße und IT -Infrastruktur können dieselben Personen beide Aufgaben wahrnehmen und sich gegenseitig vertreten. Unabhängig von der organisatorischen Zuordnung sollte eine verlässliche Vertretung durch mindestens zwei Personen gewährleistet sein. Gelten für Primary AR und Secondary AR ( Backup User ) unterschiedliche Anforderu