Wie Sie eine CRA-Meldung auf der zentralen Meldeplattform der ENISA einreichen, aus deren eigenem Handbuch

Artikel 14(7) des Cyber Resilience Act, Verordnung (EU) 2024/2847, sagt, dass die Meldungen eines Herstellers über eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall „über die in Artikel 16 genannte zentrale Meldeplattform übermittelt“ werden. Nicht per E-Mail an ein CSIRT, nicht über ein nationales Portal: über die Plattform. Die ENISA hat sie am 11. September 2026, dem Tag, an dem die Pflicht begann, unter portal.cra-srp.enisa.europa.eu eröffnet und daneben ein Benutzerhandbuch, ein Glossar jedes Feldes, eine Reihe von Leitfäden und 31 Antworten auf häufig gestellte Fragen veröffentlicht.

Dieser Artikel ist die Lektüre dieser Dokumente von Anfang bis Ende, für einen Hersteller, der die Plattform noch nie gesehen hat und ihr in Stunde eins eines Vorfalls begegnen wird. Alles unten stammt aus den Seiten der ENISA, wie sie am 12. September 2026 standen, oder aus der Verordnung. Wo die Plattform etwas tut, was die Verordnung nicht vorsieht, steht es dabei.

Was die Plattform ist, und was sie noch nicht ist

Die Plattform der ENISA ist die, die Artikel 16(1) ihr aufgetragen hat: „Die ENISA richtet eine zentrale Meldeplattform ein. Der tägliche Betrieb dieser zentralen Meldeplattform wird von der ENISA verwaltet und gepflegt.“ Ihr Sinn ist, dass Sie einmal einreichen. Die Meldung wird der ENISA und dem von Ihnen gewählten als Koordinator benannten CSIRT zugänglich gemacht, und dieses CSIRT gibt sie an die Koordinatoren der anderen Mitgliedstaaten weiter, in denen das Produkt nach Ihrer Angabe verfügbar ist, sowie an seine Marktüberwachungsbehörde. Die Weitergabe ist deren Aufgabe, nicht Ihre.

Vier Grenzen zum Start, jede in den FAQ der ENISA genannt:

• Sie nimmt nur Pflichtmeldungen nach Artikel 14 entgegen. Freiwillige Meldungen nach Artikel 15, durch Hersteller oder andere, sind zum Start nicht verfügbar. Die Pflichten der Verwalter quelloffener Software nach Artikel 24(3) gelten ab dem 11. Dezember 2027, und die Plattform nimmt sie dann entgegen.
• Sie ist nur auf Englisch verfügbar. Weitere Sprachen sollen in einer späteren Phase geprüft werden; das Faktenblatt wird übersetzt, die Plattform nicht.
• Es gibt keine API. In den Worten der ENISA: Zur ersten Veröffentlichung wird keine Programmierschnittstelle bereitgestellt, Meldungen müssen also über die Oberfläche der Plattform eingereicht werden. Ein Hersteller mit vielen Produkten reicht jede von Hand ein.
• Eine Meldung je Schwachstelle oder Vorfall, für den gesamten Konzern. Wie viele EU-Tochtergesellschaften ein Hersteller auch hat und wo die Muttergesellschaft sitzt, die FAQ sagen, dass eine Meldung erforderlich ist und dass die interne Abstimmung, damit genau eine eingereicht wird, in der Verantwortung des Herstellers liegt.

Wer sich anmeldet: die beauftragten Vertreter

Die Plattform kennt keine Unternehmen. Sie kennt Personen, beauftragte Vertreter genannt, die für einen Hersteller handeln. Jede braucht ein persönliches EU-Login-Konto mit eingeschalteter Multi-Faktor-Authentifizierung; die FAQ sagen, das Konto könne im Voraus angelegt werden, es werde kein Unternehmens-Authentifizierungsverfahren verwendet, und weil EU-Login-Konten persönlich sind, nutze die meldende Person ihr eigenes.

Es gibt zwei Rollen. Der Primary AR registriert sich direkt: Plattform öffnen, Rolle wählen, das als Koordinator benannte CSIRT aus einem Auswahlmenü wählen, über EU Login authentifizieren, die rechtliche Vereinbarung akzeptieren, den von EU Login gelieferten Namen und die E-Mail-Adresse bestätigen und den Namen des Herstellers eingeben. Damit wird der Hersteller in der Plattform angelegt und die Verknüpfung zwischen Person und Hersteller dem Koordinator zur Prüfung vorgelegt. Es gibt einen Primary AR je Hersteller. Ein Secondary AR kommt per E-Mail-Einladung eines Primary AR hinzu, dessen Verknüpfung bereits geprüft ist und als Verified angezeigt wird; der Einladungslink läuft nach 7 Tagen ab. Je Hersteller kann es bis zu 20 Secondary ARs geben. Ein Secondary AR kann Meldungen einreichen und aktualisieren, sieht aber nur die, die er selbst eingereicht hat; der Primary AR sieht alles, was für den Hersteller eingereicht wurde, verwaltet die Verknüpfung und lädt die anderen ein oder entfernt sie. Ein Secondary AR kann die Primary-Rolle beanspruchen, vorbehaltlich der Zustimmung des Koordinators.

Zwei Dinge zur Prüfung zählen in Stunde eins. Erstens blockiert sie Sie nicht: Der Koordinator prüft die Verknüpfung nach der Registrierung und parallel zur Meldung, und ein ungeprüfter Vertreter kann bis zu 20 Meldungen einreichen, bevor die Prüfung verpflichtend wird. Zweitens bittet die ENISA Sie, es nicht früh zu tun. Ihr Leitfaden sagt, Herstellern werde geraten, „sich erst dann zu registrieren und den Prüfprozess erst dann anzustoßen, wenn sie eine konkrete Meldung einreichen müssen, statt sich vorsorglich zu registrieren“, um die Prüflast der Koordinatoren gering zu halten, und ergänzt, mit bestehendem EU-Login dauere die Registrierung wenige Minuten. Die Vorbereitung ist also das EU-Login mit MFA, für die meldende Person und eine Vertretung; die Registrierung ist eine Aufgabe für den Tag selbst.

Die Nutzungsbedingungen, Version 1.0 vom 10. September 2026, enthalten den Teil, den Ihre Rechtsabteilung sehen will: Mit der Registrierung oder Einreichung „versichern und garantieren“ die Nutzer, „dass sie die beauftragten Vertreter ihrer Organisation und befugt sind, in deren Namen zu handeln“, und der Koordinator darf das prüfen. Halten Sie die Befugnis schriftlich fest, bevor der Tag kommt, an dem sie gebraucht wird.

Welchen Koordinator Sie wählen

Das Auswahlmenü bei der Registrierung, und das Feld in jeder Meldung, ist das als Koordinator benannte CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung in der Union hat; Artikel 14(7) definiert sie als den Staat, „in dem die Entscheidungen im Zusammenhang mit der Cybersicherheit seiner Produkte mit digitalen Elementen überwiegend getroffen werden“, oder, wenn sich das nicht bestimmen lässt, den Staat mit den meisten Beschäftigten; und ohne Hauptniederlassung in der Union den Staat des Bevollmächtigten, dann den des Einführers, den des Händlers und den Staat mit den meisten Nutzern. Die FAQ der ENISA wiederholen die ganze Kaskade und ergänzen eine Folge, die die Verordnung nicht ausspricht: „Wird das falsche CDaC gewählt, kann die Meldung für ungültig erklärt werden und muss beim richtigen CDaC erneut eingereicht werden.“ Eine rote Warnung im Dashboard ist die Art, wie Sie es erfahren.

Die ENISA hat die Liste der Koordinatoren am 10. September 2026 veröffentlicht, und in zwei Staaten ist es nicht das nationale CSIRT. Die Liste, und die zwei Ausnahmen, stehen in einem eigenen Artikel; die Tabelle steht auch auf der Seite zu den Meldefristen.

Die drei Einreichungen, und was jede abfragt

Artikel 14 verlangt drei Einreichungen: eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht. Auf der Plattform sind es drei Reiter eines Meldedatensatzes. Sie eröffnen eine neue Meldung für die Frühwarnung, kehren dann für die 72-Stunden-Meldung zu demselben Datensatz zurück und noch einmal für den Abschlussbericht; jede spätere Stufe ist mit dem vorausgefüllt, was Sie zuvor eingegeben haben, und das Glossar kennzeichnet jedes Feld als erforderlich, optional oder aus der vorherigen Stufe übernommen. Die Tabelle unten ist die Spalte der Anforderungen des Glossars, je Stufe. Felder, die nur für einen Typ gelten, sind mit AEV für eine aktiv ausgenutzte Schwachstelle und SI für einen schwerwiegenden Vorfall gekennzeichnet.

Das ist die Struktur der Verordnung selbst mit eingezeichneten Feldgrenzen. Artikel 14(2)(a) verlangt von der Frühwarnung, „gegebenenfalls die Mitgliedstaaten anzugeben, in deren Hoheitsgebiet das Produkt mit digitalen Elementen nach Kenntnis des Herstellers bereitgestellt wurde“; das ist das Mitgliedstaaten-Feld, erforderlich von der ersten Minute an. Artikel 14(2)(b) verlangt von der 72-Stunden-Meldung allgemeine Informationen zum Produkt, zur allgemeinen Art des Exploits und der Schwachstelle, zu den ergriffenen Abhilfemaßnahmen und denen, die Nutzer ergreifen können, und dazu, wie sensibel der Hersteller die Information einschätzt; das sind die Felder, die auf der zweiten Stufe von optional auf erforderlich wechseln. Artikel 14(2)(c) verlangt vom Abschlussbericht Schwere und Auswirkung, den Akteur, soweit verfügbar, und das Sicherheitsupdate oder die Abhilfemaßnahme; die dritte Spalte.

Zwei praktische Beschränkungen aus dem Glossar: Ein Titel fasst 255 Zeichen und eine Zusammenfassung 4.000, und jeder Zeitstempel wird in UTC eingegeben. Das Glossar bittet außerdem, keine vertraulichen technischen Details in den Titel zu schreiben und, falls der Zeitpunkt der Kenntniserlangung eine Schätzung ist, das in der Beschreibung zu sagen. Eine Fußnote sollte man kennen, bevor man ein Feld sucht, das nicht da ist: Für eine Schwachstelle kennzeichnet das Glossar das Datum der Kenntniserlangung als erforderlich und sagt dann, das Feld „wird in der nächsten Version der Plattform verfügbar sein“; für einen Vorfall existiert es heute unter dem Namen „Datum und Uhrzeit, zu der der Vorfall erkannt wurde“.

Der Zähler, den die Plattform nach eigener Aussage falsch berechnet

Das Dashboard zeigt Zähler für die 72-Stunden-Meldung und den Abschlussbericht, mit Erinnerungs-E-Mails und Überfälligkeitswarnungen, die davon gesteuert werden. FAQ 26 sagt, wie sie berechnet werden, und das lohnt sich zweimal zu lesen. Der 72-Stunden-Zähler „zeigt eine Fälligkeit 48 Stunden nach Einreichung der 24-Stunden-Frühwarnung an“, nicht 72 Stunden nach der Kenntniserlangung. Wenn Sie die Frühwarnung in Stunde vier eingereicht haben, zeigt die Plattform die Meldung in Stunde 52 als fällig an, und „in manchen Fällen kann eine Meldung als überfällig angezeigt werden, bevor 72 Stunden seit der Kenntniserlangung des Herstellers oder Verwalters quelloffener Software vergangen sind“. Die ENISA sagt, die Logik werde in einer künftigen Version auf das Feld der Kenntniserlangung umgestellt. Bis dahin ist die Uhr der Plattform nicht die Uhr der Verordnung, und die FAQ sagen, die Zähler „ersetzen nicht die Verantwortung der Hersteller“, die eigenen Fristen von Artikel 14 einzuhalten.

Für den Abschlussbericht gibt es zwei Zähler, und einer fehlt mit Absicht. Für einen schwerwiegenden Vorfall zählt die Plattform einen Monat ab Einreichung der 72-Stunden-Meldung, das ist Artikel 14(4)(c). Für eine aktiv ausgenutzte Schwachstelle gibt es keinen Zähler, weil Artikel 14(2)(c) 14 Tage ab Verfügbarkeit einer Abhilfemaßnahme läuft und die Plattform dieses Datum nicht kennen kann, bevor Sie es eingeben. Das ist dieselbe Unterscheidung, die die meisten Darstellungen der CRA-Fristen übersehen, und der Grund, warum der Rechner auf unserer Seite zu den Fristen das Datum der Abhilfe gesondert abfragt.

Nachdem Sie auf Einreichen gedrückt haben

Ein gespeicherter Entwurf bleibt nur für Sie sichtbar. Mit der Einreichung der Frühwarnung wird sie gespeichert, dem Koordinator und der ENISA zugänglich gemacht, und eine E-Mail und eine Warnung gehen an den Koordinator, an die ENISA und an jeden Vertreter des Herstellers. Die Koordinatoren der anderen von Ihnen genannten Mitgliedstaaten erhalten nichts automatisch: Der Leitfaden der ENISA sagt, betroffene CSIRTs „erhalten die Frühwarnung erst nach manueller Weitergabe durch das als Koordinator benannte CSIRT“. Dasselbe gilt für die 72-Stunden-Meldung und den Abschlussbericht.

Sie können eine Meldung auf jeder Stufe aktualisieren, bis der Abschlussbericht eingereicht ist; danach macht die Plattform sie unveränderbar, und eine vom Koordinator geschlossene Meldung lässt sich ebenfalls nicht mehr aktualisieren. Eine Aktualisierung benachrichtigt den Koordinator, die ENISA und jedes CSIRT, das die Meldung bereits erhalten hat. Warnungen im Dashboard sind blau, solange sie ungelesen sind; rote „erscheinen nur, wenn eine außergewöhnliche oder kritische Aktion stattgefunden hat“, das Beispiel der ENISA ist, dass der Koordinator eine Einreichung für ungültig erklärt hat.

Um eine verzögerte Weitergabe bitten

Artikel 16(2) sagt, der Koordinator „übermittelt die Meldung unverzüglich“ an die Koordinatoren der Mitgliedstaaten, in denen das Produkt verfügbar ist, und schafft dann zwei Ausnahmen. In Ausnahmefällen, „insbesondere auf Ersuchen des Herstellers und im Lichte des vom Hersteller angegebenen Sensibilitätsgrads der gemeldeten Informationen“, darf der Koordinator die Weitergabe aus begründeten cybersicherheitsbezogenen Gründen für den unbedingt notwendigen Zeitraum verzögern. Und unter „besonders außergewöhnlichen Umständen“, wenn der Hersteller in der 72-Stunden-Meldung eines von drei Dingen angibt, gehen nur die Tatsache der Meldung, die allgemeinen Informationen zum Produkt, die allgemeine Art des Exploits und die Tatsache, dass Gründe geltend gemacht wurden, an die ENISA, bis die vollständige Meldung weitergegeben wird. Die drei, wörtlich:

(a) dass die gemeldete Schwachstelle von einem böswilligen Akteur aktiv ausgenutzt wurde und nach den verfügbaren Informationen in keinem anderen Mitgliedstaat als dem des als Koordinator benannten CSIRT, dem der Hersteller die Schwachstelle gemeldet hat, ausgenutzt wurde; (b) dass jede sofortige weitere Verbreitung der gemeldeten Schwachstelle wahrscheinlich zur Bereitstellung von Informationen führen würde, deren Offenlegung den wesentlichen Interessen dieses Mitgliedstaats zuwiderliefe; oder (c) dass die gemeldete Schwachstelle ein unmittelbar bevorstehendes hohes Cybersicherheitsrisiko birgt, das sich aus der weiteren Verbreitung ergibt;

Auf der Plattform ist das ein Schalter, und er ist an genau einer Stelle verfügbar: in der 72-Stunden-Meldung einer aktiv ausgenutzten Schwachstelle. Wird er eingeschaltet, erscheint ein „PEC delay reason“ mit den drei Gründen als Kontrollkästchen und einer optionalen Begründung mit 800 Zeichen, „die dem als Koordinator benannten CSIRT bei seiner Entscheidung helfen kann“. Der Weitergabestatus wird zu „72h Submitted under PEC“, die ENISA erhält nur die eingeschränkten Informationen, und die Entscheidung, ob und wann weitergegeben wird, liegt beim Koordinator, nicht beim Hersteller. Ein Schalter ist ein Ersuchen.

Was der Koordinator mit diesem Ersuchen tun darf, regelt jetzt die Delegierte Verordnung (EU) 2026/881 der Kommission vom 11. Dezember 2025, veröffentlicht im Amtsblatt am 20. April 2026. Artikel 3 erlaubt dem Koordinator, die Weitergabe nur dann zu verzögern, wenn die Cybersicherheitsrisiken der Weitergabe ihren Nutzen überwiegen, diese Risiken nicht durch Beschränkungen wie das Traffic Light Protocol beherrschbar sind und eine von vier Bedingungen erfüllt ist: Der Hersteller hat mitgeteilt, dass eine wirksame Abhilfe innerhalb von 72 Stunden erwartet wird, wobei die Verzögerung endet, wenn sie ausbleibt; die Meldung enthält genug, um einen Exploit zu bauen, „insbesondere wenn die Schwachstelle von Akteuren mit begrenzten Fähigkeiten und Ressourcen leicht erkannt und ausgenutzt werden kann“; der Koordinator kann den anderen CSIRTs genug für eine Abhilfe mitteilen, ohne die vollständige Meldung; oder der Koordinator hat von der Schwachstelle als vertrauenswürdiger Vermittler in einer koordinierten Offenlegung erfahren. Im zweiten und dritten Fall geht die vollständige Meldung hinaus, sobald eine Abhilfe verfügbar ist. Die Artikel 4 und 5 fügen Gründe hinzu, die die Empfänger betreffen, nicht den Hersteller: ein CSIRT, oder die Plattform selbst, das einen Vorfall erlitten hat, der Zweifel an seiner Fähigkeit weckt, die Meldung vertraulich zu halten.

Die ehrliche Beschreibung des Schalters ist also diese: Wenn innerhalb von drei Tagen ein Patch kommt oder die Details einem wenig versierten Angreifer einen funktionierenden Exploit in die Hand gäben, sagen Sie es, kreuzen Sie den passenden Grund an und geben Sie dem Koordinator die Fakten in den 800 Zeichen. Dann planen Sie so, als fände die Weitergabe trotzdem statt.

Wenn die Plattform ausfällt

FAQ 25: Ist die Plattform vorübergehend nicht verfügbar, warten Sie, bis sie wieder da ist, und reichen dann ein. Halten Sie in der Zwischenzeit eine sofortige Mitteilung für notwendig, dürfen Sie Ihren Koordinator direkt kontaktieren, aber „die Meldung muss dennoch über die SRP eingereicht werden, sobald sie wieder verfügbar ist“. Manche Koordinatoren haben eine Rückfalllösung veröffentlicht: Das irische NCSC nennt eine Notfall-E-Mail-Adresse für den Fall, dass die ENISA die Plattform für offline erklärt hat, und sagt, Einreichungen dorthin würden nur dann angenommen. Artikel 17(6) verpflichtet jeden Koordinator, Helpdesk-Unterstützung zu Artikel 14 zu leisten, „insbesondere“ für Kleinst-, kleine und mittlere Hersteller; der Helpdesk der ENISA selbst ist per E-Mail über die FAQ-Seite erreichbar.

Fünf Dinge, die die FAQ klären

1. Keine rückwirkende Meldung. Ein Hersteller, der die aktive Ausnutzung schon vor dem 11. September 2026 kannte, muss sie jetzt nicht melden; Kenntniserlangung nach diesem Datum löst die Pflicht aus, auch wenn die Schwachstelle selbst alt oder bekannt war.
2. Produkte, die bereits auf dem Markt sind, sind erfasst. Artikel 14 gilt ab dem 11. September 2026 für jedes Produkt mit digitalen Elementen im Anwendungsbereich der Verordnung, einschließlich Produkten, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.
3. Komponenten Dritter. Für eine Schwachstelle in einer Komponente, die Sie integrieren, verweist die ENISA auf Abschnitt 5.4 der Umsetzungs-FAQ der Kommission und auf Randnummer 218 der Leitlinien der Kommission vom 27. Juli 2026, statt in eigenen Worten zu antworten. Lesen Sie diese, bevor Sie entscheiden, dass Sie nicht derjenige sind, der melden muss.
4. Die Meldung erhöht Ihre Haftung nicht. Artikel 17(4): „Die bloße Tatsache der Meldung ... führt nicht zu einer erhöhten Haftung der meldenden natürlichen oder juristischen Person.“
5. Nach der Behebung wird die Schwachstelle öffentlich. Artikel 17(5): Sobald ein Sicherheitsupdate oder eine andere Abhilfemaßnahme verfügbar ist, nimmt die ENISA die gemeldete Schwachstelle im Einvernehmen mit dem Hersteller in die europäische Schwachstellendatenbank auf.

Was Sie vorbereiten, bevor Sie irgendetwas davon brauchen

• EU-Login-Konten mit Multi-Faktor-Authentifizierung für die meldende Person und eine Vertretung, heute angelegt, und eine schriftliche Befugnis für beide.
• Ihr Mitgliedstaat und Ihr Koordinator, nach Artikel 14(7) bestimmt und ins Vorfallsverfahren geschrieben, damit in Stunde eins niemand zwischen Einträgen eines Auswahlmenüs wählt.
• Ein Produktverzeichnis mit den genauen Versions-, Build-, Modell- oder Firmware-Kennungen, die das Versionsfeld abfragt, und eine Liste der Mitgliedstaaten, in denen jedes Produkt bereitgestellt wird, weil dieses Feld in der Frühwarnung erforderlich ist.
• Eine Konvention für „Kenntnis erlangt“ und eine Regel, dass der Zeitstempel in dem Moment, in dem er gesetzt wird, in UTC festgehalten wird.
• Ein einseitiger Entwurf der Frühwarnungsfelder in einem Dokument, aus dem Sie kopieren können: Titel unter 255 Zeichen, Zusammenfassung unter 4.000, die zwei Daten, die Mitgliedstaaten.
• Ein Name dafür, wer innerhalb der ersten 72 Stunden entscheidet, ob das Kästchen für die Ausnahmesituation angekreuzt wird, und aufgrund welcher Fakten.

Nichts davon nimmt Ihnen die Plattform ab, und dieser Artikel auch nicht. Was er kann, ist, aus Stunde eins eine Frage des Tippens statt des Lesens zu machen.

Quellen

• ENISA, Seiten zur Single Reporting Platform: die Hauptseite, die FAQ (aktualisiert am 11. September 2026), die Leitfäden zu Nutzerregistrierung, Einreichung und Aktualisierung von Meldungen, Oberflächenfunktionen und besonderen Ausnahmesituationen (aktualisiert am 9. und 10. September 2026), das SRP-Glossar, das AR User Manual und die Nutzungsbedingungen v1.0 vom 10. September 2026, alle abgelesen am 12. September 2026.
• ENISA, List of CSIRTs Designated as Coordinators, zuletzt aktualisiert am 10. September 2026.
• Verordnung (EU) 2024/2847, Artikel 14, 16 und 17 sowie Artikel 71(2).
• Delegierte Verordnung (EU) 2026/881 der Kommission vom 11. Dezember 2025, Artikel 3 bis 5, ABl. L vom 20. April 2026.
• Europäische Kommission, Leitlinien C(2026) 5252 vom 27. Juli 2026 und die FAQ zur Umsetzung des CRA, Abschnitt 5.
• NCSC Irland, Seite zu den Meldepflichten des Cyber Resilience Act, aktualisiert am 11. September 2026.

Dies ist keine Rechtsberatung. Das Glossar ist eine Tabelle mit 39 Feldern und die FAQ sind 31 Fragen; beides ist kurz genug, um es zu lesen, bevor Sie es brauchen.