CRA-Meldeplattform der ENISA: Was Hersteller bis zum 11. September registriert haben müssen

Kurzantwort: Ab dem 11. September 2026 müssen Hersteller vernetzter Produkte aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die Single Reporting Platform (SRP) der ENISA melden. Zwei Wochen vor der Frist ist die Plattform nicht in Betrieb, ihre Adresse ist nicht veröffentlicht, die Liste der zuständigen CSIRTs fehlt, und ENISA stellt klar: eine Schnittstelle zur Automatisierung wird es zum Start nicht geben. Vorbereiten können Sie trotzdem alles, was nicht an der Plattform hängt: EU-Login-Konto, benannte Vertreter, Meldefelder und ein Triage-Prozess, der die 24-Stunden-Uhr bemerkt.
Das Wichtigste in 30 Sekunden
- Was beginnt: Die Meldepflichten nach Artikel 14 CRA werden am 11. September 2026 anwendbar. Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach 14 Tagen (Schwachstelle) beziehungsweise einem Monat (Vorfall).
- Rechtsgrundlage der Plattform: Artikel 16 CRA, dazu die Delegierte Verordnung vom 11. Dezember 2025 zu Ausnahmen bei der Weitergabe.
- Der Stand: Die SRP ist nicht in Betrieb. Die Adresse ist laut ENISA noch "forthcoming", die Liste der als Koordinatoren benannten CSIRTs ist ebenfalls unbekannt.
- Wörtlich von ENISA: "No Application Programming Interfaces will be provided at this stage." Es gibt zum Start keine API, die Meldung läuft von Hand.
- Registrierung geht schon: über EU Login. Das Konto können Sie heute anlegen, dafür braucht es weder Plattform noch Behörde.
- Die Validierung blockiert nichts: Die Freigabe Ihrer Registrierung durch das koordinierende CSIRT ist keine Voraussetzung für eine Meldung, sie läuft parallel.
- Die stille Verschärfung: Frühwarnung, 72-Stunden-Meldung und Abschlussbericht erreichen die anderen betroffenen CSIRTs erst nach manueller Weitergabe durch den Koordinator.
- Auch Open-Source-Verwalter melden, nach Artikel 24 Absatz 3 CRA, soweit sie an der Entwicklung von Produkten mit digitalen Elementen beteiligt sind.
- Freiwillige Meldungen (Schwachstellen, Bedrohungen, Beinahe-Vorfälle) werden erst nach dem 11. September 2026 freigeschaltet.
- Der Rahmen: Bußgelder bis 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
Was am 11. September 2026 wirklich beginnt
Hier lohnt eine Präzisierung, die in vielen Beiträgen untergeht, auch in unserem eigenen aus dem Februar: Der Cyber Resilience Act ist nicht am 11. September 2026 in Kraft getreten. Die Verordnung (EU) 2024/2847 ist bereits am 10. Dezember 2024 in Kraft getreten. Was sich am 11. September 2026 ändert, ist die Anwendbarkeit eines einzelnen Kapitels: der Meldepflichten.
Der Zeitplan nach Artikel 71 CRA, gestaffelt:
- 10.12.2024: Verordnung in Kraft.
- 11.06.2026: Kapitel IV, Notifizierung der Konformitätsbewertungsstellen.
- 11.09.2026: Meldepflichten nach Artikel 14.
- 11.12.2027: Verordnung vollständig anwendbar, CE-Kennzeichnung.
Der Unterschied ist nicht akademisch. Er entscheidet, welche Pflicht Sie am 12. September nachweisen müssen und welche nicht. Am 11. September 2026 schulden Sie einen funktionierenden Meldeprozess. Eine CE-Kennzeichnung nach CRA schulden Sie erst Ende 2027.
Der Stand der Meldeplattform: nicht in Betrieb, keine Schnittstelle
Artikel 16 CRA weist der ENISA die Einrichtung der Single Reporting Platform zu. Sie ist der Ort, an dem eine Meldung gleichzeitig beim zuständigen nationalen CSIRT und bei der ENISA landet, statt an mehreren Stellen getrennt.
Zum Zeitpunkt dieses Artikels ist die Plattform nicht in Betrieb. ENISA nennt weiter den 11. September 2026 als Datum der Betriebsaufnahme und beschreibt die Adresse der Plattform als noch nicht veröffentlicht. Auch die Liste der als Koordinatoren benannten CSIRTs ist nicht veröffentlicht. Verfügbar sind bislang die Anleitungen, ein Factsheet und eine FAQ. Aber nicht das System.
Der praktisch wichtigste Satz steht in der ENISA-FAQ und ist unmissverständlich: "No Application Programming Interfaces will be provided at this stage." Für Sie heißt das: Die Meldung läuft über ein Webformular, von Hand. Wer geplant hatte, Meldungen direkt aus dem eigenen Schwachstellenmanagement oder einem Ticketsystem abzusetzen, muss diesen Plan für den Start streichen. Das ist keine IT-Frage, sondern eine Organisationsfrage: In 24 Stunden muss ein Mensch mit gültigem Zugang ein Formular ausfüllen können. Auch am Wochenende und Feiertag.
Was ENISA ausdrücklich nicht dokumentiert, ist ein Ersatzweg, falls die Plattform beim Start oder später nicht erreichbar ist. Die Frist läuft trotzdem. Halten Sie den Kontakt zu Ihrem CSIRT und den ENISA-Helpdesk (cra-srp-helpdesk bei enisa.europa.eu). So ist im Ernstfall dokumentiert, damit Sie im Ereignisfall nachweisen können, dass Sie fristgerecht gemeldet haben oder es versucht haben.
Was ENISA im August konkretisiert hat:
Am 3. August 2026 hat ENISA die Anleitung zur Registrierung veröffentlicht, am 14. August 2026 die Beschreibung der Plattformfunktionen. Daraus ergibt sich der Ablauf:
- SRP öffnen und die Rolle Assigned Representative (AR) wählen.
- Das zuständige CSIRT aus einer Auswahlliste bestimmen.
- Über EU Login authentifizieren (ecas.ec.europa.eu), den Zugangsdienst der EU-Institutionen.
- Die rechtliche Vereinbarung annehmen.
- Die vorbelegten persönlichen Angaben bestätigen (Name, E-Mail, gesetzlicher Name).
- Die Herstellerangaben ergänzen (Name, Adresse, Zusatzangaben).
Ein Primary AR lädt weitere Secondary AR per E-Mail ein. Diese Einladung ist sieben Tage gültig. Damit ist die Vertretung lösbar, aber nur, wenn sie vorher geklärt ist: Ein einzelner benannter Mensch im Urlaub ist bei einer 24-Stunden-Frist ein Ausfallrisiko.
ENISA empfiehlt, mit der Registrierung auf der SRP zu warten, bis eine konkrete Meldung ansteht, weil die Validierung ohnehin nachläuft. Was Sie dagegen heute anlegen können und sollten, ist das EU-Login-Konto.
ENISA hat außerdem eine Tabelle der Meldefelder je Stufe veröffentlicht, mit Pflicht-, Bedingungs- und Wahlangaben, sowie Anleitungen, ein Factsheet, Videos und ein Webinar rund zwei Wochen vor dem Start. Wer den Meldeprozess intern beschreibt, sollte diese Felder als Vorlage nehmen.
Die Entlastung: die Freigabe blockiert die Meldung nicht
Die wichtigste Klarstellung der August-Anleitung: Die Validierung der Registrierung eines Assigned Representative durch das koordinierende CSIRT (bei ENISA: CSIRT Designated as Coordinator, CDaC) ist keine Voraussetzung dafür, die Meldepflicht zu erfüllen. Die Prüfung findet nach dem ersten Zugriff statt und läuft parallel.
Das nimmt ein reales Risiko aus dem Prozess. Ohne diese Klarstellung wäre folgende Lage denkbar gewesen: eine aktiv ausgenutzte Schwachstelle, eine laufende 24-Stunden-Frist und ein Konto, das noch auf eine Behördenfreigabe wartet. Das ist ausgeschlossen.
Die stille Verschärfung: die Weitergabe ist Handarbeit
Eine Änderung der August-Fassung wird bisher kaum diskutiert. Betroffene CSIRTs anderer Mitgliedstaaten erhalten die Frühwarnung, die 72-Stunden-Meldung und den Abschlussbericht erst nach manueller Weitergabe durch den koordinierenden CSIRT. Vorher war Handarbeit nur für den Abschlussbericht vorgesehen.
ENISA selbst erhält die Meldung weiter gleichzeitig. Für Sie als Hersteller ändert das an der Pflicht nichts, Sie melden an eine Stelle. Für Ihre Erwartung ändert es viel: Sie können nicht davon ausgehen, dass alle betroffenen Mitgliedstaaten zeitgleich informiert sind. Wenn Sie in mehreren Ländern vertreiben und dort Behörden, Kunden oder Betreiber kritischer Infrastruktur sitzen, ist Ihre eigene Kommunikation mit der Meldung nicht erledigt.
In Ausnahmefällen kann die Weitergabe aus Sicherheitsgründen verzögert werden, geregelt in der Delegierten Verordnung vom 11. Dezember 2025. Der Hersteller kann dafür kennzeichnen, dass die Bedingungen des Artikels 16 Absatz 2 Buchstaben a bis c vorliegen.
Die Namensfalle: zwei Vertreter, die nichts miteinander zu tun haben
Der Assigned Representative ist eine Kontorolle auf der Plattform. Der Bevollmächtigte nach Artikel 18 CRA ist eine rechtliche Funktion für Hersteller ohne Niederlassung in der EU. Ein Unternehmen kann das erste haben, ohne das zweite zu brauchen.
Das ist der Punkt, an dem interne Verfahrensanweisungen auseinanderlaufen. Wer beide Begriffe als dasselbe behandelt, benennt am Ende die falsche Person: entweder einen Juristen, der kein Formular ausfüllen kann, oder einen Techniker ohne Vollmacht. Prüfen Sie Ihre Prozessdokumentation gezielt auf diese Verwechslung.
Auch Open-Source-Verwalter sind in der Pflicht
Ein Punkt, den die deutschen Beiträge zur Frist bisher auslassen: Nicht nur Hersteller melden. Open-Source-Verwalter (open-source software stewards) haben nach Artikel 24 Absatz 3 CRA eigene Meldepflichten, soweit sie sie an der Entwicklung von Produkten mit digitalen Elementen beteiligt sind. ENISA adressiert sie in den Registrierungsanleitungen ausdrücklich mit.
Für Unternehmen ist das doppelt relevant. Wer selbst ein Open-Source-Projekt in einer Stiftung oder einem Verein pflegt, prüft die eigene Rolle. Und wer Fremdkomponenten einsetzt, bekommt mit dieser Pflicht eine zusätzliche Quelle für Meldungen, die den eigenen Produktbestand betreffen.
Bestandsprodukte: erfasst, aber nicht rückwirkend
Hier ist Genauigkeit wichtig. Die Meldepflicht ist nicht auf Neuprodukte beschränkt, sie kann auch Produkte betreffen, die längst im Markt sind. Sie knüpft aber an die Kenntnis des Herstellers an und erstreckt sich nicht auf Kenntnis, die entstanden hat, bevor die Pflicht anwendbar war. Wer also vor dem 11. September 2026 von einer ausgenutzten Schwachstelle erfuhr, muss diese nicht nachmelden. Wer danach Kenntnis erlangt, meldet, auch wenn das Produkt alt ist.
Praktisch verschiebt das den Aufwand von der Produkt-Roadmap zum installierten Bestand. Wer eine Firmware von 2019 noch pflegt oder vertreibt, ist in dieser Menge. Ohne belastbare Übersicht über die aktiven Produktversionen und deren Komponenten, etwa über einen Software Bill of Materials, ist die 24-Stunden-Frist nicht zuverlässig zu halten, da im Ereignisfall die Vorfrage offen bleibt: Betrifft mich das, und in welcher Version?
Die Normungslücke im Hintergrund
Parallel läuft eine zweite Verzögerung. Die Kommission hat im Juli 2026 einen Änderungsentwurf zum Normungsauftrag (Mandat M/606) veröffentlicht, der die Entwurfsfristen für die harmonisierten Normen 2026 um zwei Monate verschiebt: die horizontalen A- und B-Normen auf den 31. Oktober 2026, die produktspezifischen C-Normen auf den 31. Dezember 2026.
Wichtig für die Einordnung: Dieser Beschluss ist noch nicht im Amtsblatt veröffentlicht, die Daten sind vorgeschlagen, nicht rechtlich fixiert. Und bislang ist für keine Produktkategorie eine harmonisierte CRA-Norm im Amtsblatt zitiert. Solange das so bleibt, steht die Konformitätsvermutung nach Artikel 27 nicht zur Verfügung, und der Weg der Selbstbewertung nach Artikel 32 Absatz 2 für Klasse-I-Produkte ist nicht belastbar.
Für den 11. September 2026 ändert das nichts, die Meldepflicht hängt nicht an Normen. Für Ihre Planung auf Dezember 2027 ist es die wichtigere Nachricht.
Checkliste: was bis zum 11. September vorhanden sein muss:
- EU-Login-Konto anlegen, für mindestens zwei Personen. Geht heute, ohne Behörde, ohne Meldeplattform.
- Zuständiges CSIRT bestimmen, nach dem Ort der Hauptniederlassung (Artikel 14 Absatz 7). In Deutschland ist dies das BSI. Die offizielle Liste steht noch aus.
- Primary und Secondary AR benennen, namentlich, mit Vertretungsregel für Urlaub und Wochenende.
- Assigned Representative vom Artikel-18-Bevollmächtigten trennen, in jeder Verfahrensanweisung.
- Sammelpostfach einrichten, auf das Plattformbestätigungen laufen, kein persönliches Postfach.
- Meldefelder als Vorlage übernehmen, aus der ENISA-Feldtabelle, je Meldestufe.
- Triage-Prozess definieren, der beantwortet, wann eine Schwachstelle aktiv ausgenutzt ist und wann die 24-Stunden-Uhr startet.
- Erste Frühwarnung vorschreiben, als ausgefüllte Vorlage. Ein Formular zum ersten Mal unter Zeitdruck zu lesen, ist der vermeidbare Teil des Risikos.
- Produktbestand erfassen, inklusive der alten, noch gepflegten Versionen.
- Rolle als Open-Source-Verwalter prüfen, falls Sie Projekte pflegen.
Die Grundlagen zu Fristen, betroffenen Produkten, SBOM und Bußgeldern stehen im ausführlichen Leitfaden CRA-Meldepflicht ab September 2026. Dieser Artikel ergänzt ihn um den Betriebsstand der Plattform.
Fazit
Die Frist am 11. September 2026 steht, die Plattform dahinter nicht. Diese Asymmetrie ist die eigentliche Nachricht: Die Pflicht ist rechtlich fixiert und nicht verschoben, während das System, über das sie erfüllt werden soll, noch nicht erreichbar ist, zum Start keine Automatisierung erlaubt und für den Ausfall keinen dokumentierten Ersatzweg kennt.
Praktisch kehrt das die übliche Reihenfolge um. Sie können sich nicht auf das Werkzeug vorbereiten, sondern nur auf den Ablauf: benannte Menschen mit funktionierenden Zugängen, eine klare Definition, wann die Uhr läuft, ein vorbereitetes Formular mit den richtigen Feldern und ein Produktbestand, den man im Ereignisfall in Minuten durchsuchen kann. Nichts davon hängt an der SRP. Alles davon entscheidet, ob die 24 Stunden reichen. Bei der Einrichtung dieser Prozesse unterstützt unsere CRA-Beratung.
Häufig gestellte Fragen
Wann ist der CRA verpflichtend?
Gestaffelt. Die Verordnung (EU) 2024/2847 ist seit dem 10. Dezember 2024 in Kraft. Anwendbar werden die Meldepflichten nach Artikel 14 am 11. September 2026, Kapitel IV zur Notifizierung der Konformitätsbewertungsstellen bereits am 11. Juni 2026, und die Verordnung vollständig samt CE-Kennzeichnung am 11. Dezember 2027.
Ab wann gilt die Meldepflicht für Schwachstellen laut CRA?
Ab dem 11. September 2026. Ab diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden: Frühwarnung binnen 24 Stunden ab Kenntnis, ausführliche Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Gegenmaßnahme, bei Vorfällen binnen eines Monats.
Wann muss ein Cyberangriff nach dem CRA gemeldet werden?
Der CRA verlangt eine Meldung bei einem schwerwiegenden Vorfall, der die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigt, und bei einer aktiv ausgenutzten Schwachstelle. Die 24-Stunden-Frist beginnt mit der Kenntnis. Nicht jeder Angriff ist meldepflichtig, entscheidend sind die Auswirkung auf die Produktsicherheit und die aktive Ausnutzung.
Ist die CRA-Meldeplattform schon live?
Nein. Zum 31. August 2026 ist die Single Reporting Platform der ENISA nicht in Betrieb, die öffentliche Adresse ist nicht veröffentlicht und die Liste der als Koordinator benannten CSIRTs steht aus. ENISA nennt weiter den 11. September 2026 als Datum der Betriebsaufnahme und hat im August die Registrierungs- und Einreichungsanleitungen sowie eine FAQ veröffentlicht.
Gibt es eine Schnittstelle, um CRA-Meldungen zu automatisieren?
Zum Start nicht. ENISA stellt in der FAQ zur Meldeplattform ausdrücklich fest, dass derzeit keine Schnittstellen bereitgestellt werden. Die Meldung läuft über ein Webformular, von Hand. Eine direkte Anbindung des eigenen Schwachstellenmanagements ist zum 11. September 2026 nicht möglich.
Muss die CSIRT-Validierung abgeschlossen sein, bevor ich melden darf?
Nein. Die Validierung der Registrierung durch das koordinierende CSIRT ist keine Voraussetzung für die Erfüllung der Meldepflicht. Sie findet nach dem ersten Zugriff statt und läuft parallel zur Meldung. Eine offene Kontofreigabe blockiert die 24-Stunden-Frist also nicht.
Welche Software fällt unter den CRA?
Grundsätzlich alle Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, also Hardware mit Software und eigenständige Software. Es gibt Ausnahmen, etwa für bereits sektorspezifisch regulierte Produkte, und eine Risikoklassifizierung, die den Aufwand bestimmt. Ob Ihr Produkt betroffen ist, klärt unser CRA-Betroffenheitscheck.
Gilt die CRA-Meldepflicht auch für Produkte, die schon lange im Markt sind?
Ja, aber nicht rückwirkend. Erfasst sind auch Produkte, die vor dem 11. September 2026 in Verkehr gebracht wurden. Die Pflicht knüpft jedoch an die Kenntnis des Herstellers an und erstreckt sich nicht auf Kenntnis, die vor Anwendbarkeit der Pflicht entstanden ist. Wer vorher von einer ausgenutzten Schwachstelle wusste, muss sie nicht nachmelden.
Wer ist in Deutschland das zuständige CSIRT für CRA-Meldungen?
Das Bundesamt für Sicherheit in der Informationstechnik (BSI). Maßgeblich ist der Ort der Hauptniederlassung nach Artikel 14 Absatz 7 CRA. Auf der Plattform wählen Hersteller ihr nationales CSIRT aus, die Meldung erreicht dann das CSIRT und die ENISA gleichzeitig. Die offizielle Liste der benannten CSIRTs hat ENISA noch nicht veröffentlicht.
Müssen auch Open-Source-Projekte melden?
Open-Source-Verwalter haben nach Artikel 24 Absatz 3 CRA eigene Meldepflichten, soweit sie mit Produkten mit digitalen Elementen befasst sind. ENISA adressiert sie in den Registrierungsanleitungen zur Meldeplattform ausdrücklich mit. Die Pflichten sind nicht identisch mit denen eines Herstellers.
Was droht bei Verstößen gegen die CRA-Meldepflicht?
Für Verstöße gegen die wesentlichen Cybersicherheits- und Meldepflichten bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Ist der Assigned Representative dasselbe wie der Bevollmächtigte nach Artikel 18 CRA?
Nein. Der Assigned Representative ist eine Kontorolle auf der Meldeplattform, die Meldungen einreicht. Der Bevollmächtigte nach Artikel 18 CRA ist eine rechtliche Funktion für Hersteller ohne Niederlassung in der EU. Ein Unternehmen kann das erste haben, ohne das zweite zu brauchen.
Weitere relevante Beiträge
Vertiefen Sie Ihr Wissen mit ausgewählten Artikeln aus der gleichen Themenwelt.

NIS2-Umsetzungsgesetz (NIS2UmsuCG): Pflichten, Fristen und Haftung
Die neue Klausel zu „vernachlässigbaren“ Tätigkeiten kann Ihr Unternehmen unerwartet in die volle Haftung zwingen – erfahren Sie in 5 Minuten, wie Sie jetzt reagieren.

9. MaRisk-Novelle 2026: Was sich für Banken jetzt ändert
Die 9. MaRisk-Novelle ist final: mehr Proportionalität, SNCI-Erleichterungen, neue Größenklassen. Alle Änderungen, Fristen und der Umsetzungsfahrplan bis 2027.

NIS2 nach einem halben Jahr: Wie gut sind deutsche KMU wirklich aufgestellt?
Warum operative IT-Sicherheit für NIS2 nicht ausreicht – und wie KMU die Lücke zum Managementsystem schließen.
