Die CRA-Meldeplattform im Betrieb — vom Konto bis zum Abschlussbericht

/01Was seit dem 11. September gilt — und was nicht

Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen zwei Ereignisse melden: jede aktiv ausgenutzte Schwachstelle in ihrem Produkt und jeden schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt. Gemeldet wird über die Single Reporting Platform der ENISA, gleichzeitig an das zuständige Koordinator-CSIRT und an die ENISA selbst — in drei Stufen mit 24 Stunden, 72 Stunden und einem Abschlussbericht.

Das ist Artikel 14 des Cyber Resilience Act, der nach Artikel 71 als einzige materielle Herstellerpflicht vorgezogen wurde. Der Rest der Verordnung gilt erst ab dem 11. Dezember 2027: grundlegende Anforderungen nach Anhang I, Konformitätsbewertung, CE-Kennzeichnung, Software-Stückliste in der technischen Dokumentation. Die Grundlagen, Fristen und Produktklassen haben wir im Juli in Cyber Resilience Act: In 7 Wochen greift die 24-Stunden-Meldepflicht beschrieben. Hier geht es um das, was seit dem Stichtag tatsächlich passiert: das Konto, die Rollen, die Entscheidung, ob ein Fund meldepflichtig ist, und den Ablauf im Ernstfall.

Zwei Abgrenzungen vorweg, weil sie in Gesprächen regelmäßig durcheinandergehen.

• Nicht jede Schwachstelle ist meldepflichtig. Eine neu veröffentlichte CVE in einer Bibliothek Ihrer Firmware löst die Meldepflicht nicht aus. Es braucht „verlässliche Nachweise“, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat (Art. 3 Nr. 42).
• Freiwillige Meldungen gibt es noch nicht. Die Plattform nimmt derzeit nur Pflichtmeldungen an. Beinahe-Vorfälle oder Bedrohungshinweise nach Artikel 15 sollen in einer späteren Ausbaustufe folgen, so die FAQ der ENISA.

Wichtig für Bestandsprodukte: Die Pflicht gilt auch für Geräte, die längst im Markt sind. Rückwirkend melden müssen Sie aber nichts. Maßgeblich ist, wann Sie Kenntnis erlangen — wer eine ausgenutzte Lücke vor dem 11. September kannte, muss sie nicht nachmelden; wer sie danach entdeckt, muss melden, auch wenn sie seit Jahren im Produkt steckt.

/02Wer meldet, und an welches CSIRT

Melden muss der Hersteller. Das ist nach Art. 3 Nr. 13 jeder, der Produkte mit digitalen Elementen entwickelt oder herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet. Importeure und Händler melden nicht selbst über die Plattform; finden sie eine ausgenutzte Lücke, läuft der Weg über den Hersteller. Die ENISA weist ausdrücklich darauf hin, dass Meldungen von Nicht-Herstellern auf der Plattform als ungültig markiert werden können — diese wenden sich direkt an ihr nationales CSIRT.

Zuständig ist das als Koordinator benannte CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung in der Union hat. Die Verordnung definiert das pragmatisch: dort, wo die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Lässt sich das nicht bestimmen, zählt der Standort mit den meisten Beschäftigten in der EU. Für Deutschland führt die ENISA-Liste der Koordinator-CSIRTs (Stand 10.09.2026) CERT-Bund beim BSI.

In der Praxis wird es bei Unternehmensgruppen interessant. Ein Maschinenbauer mit Hauptsitz in Oberfranken, Entwicklung in Tschechien und Vertrieb über eine österreichische Tochter muss festlegen, wo die Sicherheitsentscheidungen für die Steuerungs-Firmware tatsächlich fallen. Die ENISA warnt, dass eine Meldung an das falsche CSIRT für ungültig erklärt werden und eine erneute Meldung nötig werden kann. Pro Schwachstelle oder Vorfall genügt eine Meldung, auch bei mehreren EU-Niederlassungen — die interne Abstimmung darüber, wer sie abgibt, bleibt Ihre Aufgabe.

Die Weiterleitung übernimmt dann das System: Das empfangende CSIRT gibt die Meldung nach Art. 16 Abs. 2 unverzüglich an die CSIRTs der Staaten weiter, in denen das Produkt bereitgestellt wurde. Deshalb verlangt die Frühwarnung die Angabe dieser Mitgliedstaaten. Wer seine Absatzländer nicht aus dem ERP ziehen kann, verliert hier die ersten Minuten.

/03Das Konto auf der Single Reporting Platform

Die Plattform läuft unter portal.cra-srp.enisa.europa.eu und ist seit dem 11. September in einer ersten Ausbaustufe („initial operating capability“) in Betrieb. Wer meldet, tut das als „Assigned Representative“ (AR) eines Herstellers. Die Anmeldung erfolgt über EU Login, das Identitätssystem der EU-Kommission. Die Konten sind persönlich, eine Mehrfaktor-Anmeldung ist Pflicht, und eine zusätzliche Authentisierung des Unternehmens findet derzeit nicht statt — die Bindung an die Firma entsteht über die Verifizierung durch das CSIRT.

Die Verifizierung der Zuordnung Person–Hersteller übernimmt das CSIRT, und Verfahren wie Dauer unterscheiden sich je Land. Sie blockiert die Meldung aber nicht: Ein noch nicht verifizierter AR darf bis zu 20 Meldungen für den Hersteller abgeben, bevor die Verifizierung zwingend wird. Die ENISA rät, die Herstellerregistrierung erst anzustoßen, wenn eine Meldung tatsächlich ansteht. Das EU-Login-Konto selbst lässt sich dagegen vorab anlegen.

Unsere Empfehlung weicht davon nur in einem Punkt ab: Legen Sie die persönlichen EU-Login-Konten für zwei bis drei Personen jetzt an, mit eingerichtetem zweiten Faktor, und dokumentieren Sie, wer im Ernstfall Primary AR wird. Die Herstellerregistrierung können Sie, wie empfohlen, im Ereignisfall auslösen. Was Sie nicht wollen, ist ein Samstagabend, an dem die einzige Person mit Konto im Urlaub ist und der Stellvertreter erst einen Authentifikator auf dem Diensthandy einrichten muss.

Zwei weitere Eigenheiten gehören in die Vorbereitung. Die Plattform ist bislang nur auf Englisch verfügbar — englische Textbausteine für Produkt, Ausnutzung und Kundenmaßnahmen sparen im Ernstfall eine halbe Stunde. Und es gibt im ersten Release keine Programmierschnittstelle: Wer intern ein Ticketsystem oder SIEM mit Meldeprozess automatisiert, endet am Webformular. Das Formular passt sich der Meldeart an und fragt unter anderem CVE- und EUVD-Kennungen, Angaben zur Ausnutzung und zu Abhilfemaßnahmen ab; welche Felder in welcher Stufe Pflicht sind, steht im SRP-Glossar der ENISA.

/04Meldepflichtig oder nicht? Die Entscheidungstabelle

Die meisten Fehlentscheidungen der ersten Wochen dürften hier fallen, nicht beim Ausfüllen des Formulars. Zwei Fragen trennen: Gibt es verlässliche Nachweise einer Ausnutzung? Und betrifft das Ereignis die Sicherheit des Produkts selbst oder nur Ihre eigene IT?

Die dritte Zeile ist die unbequeme. Steht eine Lücke im KEV-Katalog, weil sie in Routern eines anderen Herstellers ausgenutzt wird, und dieselbe Bibliothek steckt in Ihrer Steuerung, ist das ein Indiz, aber nach dem Wortlaut nicht zwingend ein Nachweis für eine Ausnutzung in Ihrem Produkt. Die ENISA verweist für Drittkomponenten auf die FAQ und Leitlinien der Kommission. Ehrlich: Hier gibt es noch keine gefestigte Praxis. Wer nicht meldet, sollte die Begründung datiert ablegen; wer im Zweifel meldet, verliert wenig — eine Frühwarnung ist kurz.

Bei Vorfällen ist die Frage nach dem Produktbezug entscheidend. Der Hersteller-Vorfall, der in der Praxis am ehesten zur Meldung führt, ist nicht der verschlüsselte Fileserver, sondern der kompromittierte Teil der Lieferkette: Build-Server, Signaturschlüssel, Update-Verteilung, Fernwartungsportal. Gerade diese Systeme gehören oft „der Entwicklung“ und sind schlecht überwacht.

/05Die drei Fristen im Wortlaut

Die Fristen sind bekannt, ihre Auslöser weniger — beim Abschlussbericht laufen die Uhren für Schwachstelle und Vorfall unterschiedlich.

Zwei Folgen daraus. Erstens: Der Abschlussbericht zur Schwachstelle hat keinen festen Kalendertag. Er hängt am Patch. Steht nach drei Tagen ein Workaround bereit — etwa das Abschalten des betroffenen Dienstes per Konfiguration —, kann bereits das als Risikominderungsmaßnahme gelten und die 14 Tage starten. Zweitens: Alle Stufen laufen ab Kenntnis. Die Verordnung definiert nicht minutengenau, wann ein Unternehmen Kenntnis hat; Ihr Prozess sollte es tun. Ein praxistauglicher Ansatz ist der Zeitpunkt, an dem eine benannte, fachkundige Person den Nachweis gesehen und als plausibel eingestuft hat — mit Uhrzeit im Ticket.

Neben den Behörden müssen Sie nach Abs. 8 die betroffenen Nutzer informieren, gegebenenfalls alle Nutzer, samt Maßnahmen, die diese selbst ergreifen können, wo sinnvoll maschinenlesbar. Ein VEX-Dokument oder ein Security Advisory im CSAF-Format ist dafür das naheliegende Werkzeug. Versäumen Sie das, darf das CSIRT die Nutzer selbst informieren. Das ist der Moment, in dem eine Meldepflicht zum Reputationsthema wird.

Zur Einordnung des Drucks: Verstöße gegen Artikel 14 können nach Art. 64 Abs. 2 mit bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.

/06Durchgespielt: ein Maschinenbauer mit Steuerungs-Firmware

Ein konstruiertes, aber typisches Beispiel. Ein Maschinenbauer mit 300 Beschäftigten liefert Verpackungsmaschinen mit einem Bedienpanel aus. Auf dem Panel läuft eine Linux-Firmware mit eingebettetem Webserver für Diagnose und Fernwartung. Ausgeliefert wird nach Deutschland, Österreich, Polen und Frankreich. Eine Software-Stückliste im CycloneDX-Format liegt für jedes Firmware-Release im Build-Archiv — das ist der Unterschied zwischen einer Stunde und einem Tag Recherche.

Stunde 0: der Anruf

Montag, 9:40 Uhr. Ein Kunde aus Polen meldet dem Service, dass auf dem Panel ein unbekanntes Konto angelegt wurde. Seine IT schickt Webserver-Logs mit Anfragen, die eine Pfadmanipulation im Diagnoseinterface ausnutzen. Der Service leitet das Ticket, wie vorab festgelegt, an das Produkt-Sicherheitsteam weiter.

Stunde 1–3: Nachweis und Betroffenheit

Die Sicherheitsverantwortliche prüft die Logs und stuft sie um 11:05 Uhr als verlässlichen Nachweis einer Ausnutzung ein. Diese Uhrzeit steht im Ticket; ab hier laufen 24 Stunden. Die erste Frage ist, welche Firmware-Stände die betroffene Komponente enthalten:

$ for f in sbom/hmi-fw-*.cdx.json; do
    printf '%s  ' "$f"
    jq -r '.components[] | select(.name=="lighttpd") | .version' "$f"
  done

sbom/hmi-fw-3.2.0.cdx.json  1.4.59
sbom/hmi-fw-3.3.2.cdx.json  1.4.63
sbom/hmi-fw-3.4.1.cdx.json  1.4.63

# Beispielausgabe, konstruiert. Deutung: alle drei ausgelieferten
# Stände enthalten den Webserver; die Lücke liegt laut Analyse aber
# im eigenen Diagnose-Handler, nicht in lighttpd. Die SBOM beantwortet
# „wo steckt die Komponente“, nicht „wo steckt der Fehler“.

Der Kommentar in der Ausgabe ist der eigentliche Lerneffekt: Die SBOM verkürzt die Suche, ersetzt aber nicht die Analyse. Hier sitzt der Fehler im eigenen Code, der in allen drei Ständen steckt. Aus dem ERP kommt die Länderliste: Deutschland, Österreich, Polen, Frankreich.

Stunde 4–8: Frühwarnung

Der Primary AR meldet sich per EU Login an, registriert den Hersteller und wählt das Koordinator-CSIRT — hier CERT-Bund, weil die Sicherheitsentscheidungen am deutschen Hauptsitz fallen —, und gibt um 15:30 Uhr die Frühwarnung ab: aktiv ausgenutzte Schwachstelle, Produktlinie, betroffene Mitgliedstaaten. Mehr verlangt diese Stufe nicht. Wer hier auf vollständige Analyse wartet, reißt die Frist.

Tag 1–3: Meldung und Nutzerinformation

Am Dienstag steht ein Workaround: Diagnoseinterface per Konfigurationsschalter abschalten, Fernwartung nur noch über das VPN-Gateway des Kunden. Das ist eine Risikominderungsmaßnahme im Sinne von Abs. 2 c. Am Mittwochvormittag geht die 72-Stunden-Meldung raus, mit Art der Ausnutzung, Workaround und den Schritten, die Kunden selbst gehen können. Parallel erhalten alle Kunden mit betroffenen Ständen ein Security Advisory. Achtung: Weil der Workaround am Dienstag verfügbar wurde, läuft ab dann die 14-Tage-Frist für den Abschlussbericht — nicht erst ab dem Firmware-Fix.

Tag 3–16: Fix und Abschlussbericht

Firmware 3.4.2 mit korrigiertem Handler wird nach Test freigegeben. Der Abschlussbericht beschreibt Schwachstelle, Schweregrad und Auswirkungen, das, was über den Angreifer bekannt ist, und die bereitgestellte Korrektur. Intern folgt ein Post-Mortem: Warum hat der Penetrationstest des Diagnoseinterfaces den Fehler nicht gefunden, und warum war das Interface ab Werk aktiv?

Was das Beispiel zeigt: Die Plattform war in keinem Schritt der Engpass. Engpässe waren die Weiterleitung vom Service an die richtige Person, die Länderliste und die Erkenntnis, dass der Workaround die Uhr startet. Alle drei lassen sich vorher lösen.

/07Wo es hakt: Eigenheiten der ersten Wochen

Die Plattform ist neu, und die ENISA sagt selbst, dass sie sie anhand der Betriebserfahrung weiterentwickelt. Einige Punkte sollten Sie kennen, bevor Sie sie unter Zeitdruck entdecken.

Der 72-Stunden-Zähler zählt anders als das Gesetz

Laut FAQ zeigt die Plattform die Fälligkeit der 72-Stunden-Meldung derzeit 48 Stunden nach Abgabe der Frühwarnung an. Geben Sie die Frühwarnung nach 20 Stunden ab, steht dort Stunde 68, nach zwei Stunden schon Stunde 50 — die Anzeige liegt also stets vor der gesetzlichen Frist, nie danach, aber sie ist nicht die Frist. Eine künftige Version soll ab Kenntnisnahme zählen. Bis dahin gilt: Führen Sie die Fristen im eigenen Ticket, nicht auf der Plattform. Für den Abschlussbericht bei Schwachstellen gibt es dort derzeit gar keinen Zähler.

Kein Ausweichkanal

Ist die Plattform nicht erreichbar, sollen Hersteller warten und die Meldung nachreichen, sobald sie wieder läuft. Eilt es, dürfen Sie das CSIRT direkt kontaktieren; die Meldung über die Plattform bleibt trotzdem Pflicht. Ein E-Mail- oder Offline-Formular gibt es nicht. Halten Sie deshalb die Kontaktdaten von CERT-Bund im Notfallhandbuch bereit, und dokumentieren Sie den Zeitpunkt, zu dem die Plattform nicht erreichbar war.

Komponenten und der Maintainer

Liegt die Lücke in einer fremden Komponente, etwa einer Open-Source-Bibliothek, verlangt Art. 13 Abs. 6 zusätzlich, sie der Stelle zu melden, die die Komponente herstellt oder wartet. Das ist keine Meldung über die Plattform, sondern ein eigener Kanal, meist ein Security-Kontakt im Projekt. Wer den nicht vorher herausgesucht hat, sucht ihn in der Hektik.

Entwürfe sind privat

Entwürfe sieht nur, wer sie angelegt hat. Fällt die Person während einer laufenden Meldung aus, beginnt die Vertretung bei null. Gewöhnen Sie sich an, Formularinhalte parallel im Ticket abzulegen.

/08Die Vorbereitung in einer Liste

Was in den Wochen nach dem Stichtag vorhanden sein sollte. Die Liste ist bewusst knapp; jeder Punkt ist in ein bis zwei Stunden erledigt.

CRA-MELDEWEG · Stand ____ · verantwortlich ____

[ ] Hauptniederlassung festgelegt und begründet (Art. 14 Abs. 7)
    -> Koordinator-CSIRT: ____  (DE: CERT-Bund, BSI)
[ ] Primary AR benannt, 1-2 Secondary ARs als Vertretung
[ ] EU-Login-Konten angelegt, zweiter Faktor eingerichtet, getestet
[ ] Eingangskanäle definiert: Service, Vertrieb, security@, Kundenportal
    -> landen alle in EINER Ticket-Queue mit Zeitstempel
[ ] „Kenntnis“ definiert: wer stuft ein, ab wann läuft die Uhr
[ ] Länderliste je Produktlinie aus ERP abrufbar (Frühwarnung)
[ ] SBOM je ausgeliefertem Firmware-Stand im Archiv, abfragbar
[ ] Englische Textbausteine: Produkt, Ausnutzung, Kundenmaßnahmen
[ ] Vorlage Security Advisory / VEX für Nutzerinformation (Abs. 8)
[ ] Security-Kontakte der wichtigsten Fremdkomponenten (Art. 13 Abs. 6)
[ ] Kontaktdaten CERT-Bund im Notfallhandbuch (Plattformausfall)
[ ] Build-, Signatur-, Update- und Fernwartungssysteme im Monitoring
[ ] Trockenübung: ein Szenario, Frühwarnung bis Stunde 6 geschafft?

Der letzte Punkt ist der wertvollste. Eine Übung von zwei Stunden mit einem ausgedachten Fall zeigt, an welcher Stelle Ihr Ablauf hängt — meist bei der Weiterleitung aus dem Service oder bei der Frage, wer entscheidet. Wer bereits einen Incident Response Plan hat, hängt den Meldeweg als eigenen Runbook-Abschnitt an; ein neues Dokumentenwerk braucht es nicht. Ein ISMS nach ISO 27001 liefert die Vorfallprozesse, an die er andockt.

Die SBOM-Zeile verdient einen eigenen Satz: Ohne sie ist die Frage „welche Stände sind betroffen“ Handarbeit in alten Build-Verzeichnissen. Wie man sie im Build erzeugt, steht in SBOM in der Praxis — die Meldepflicht ist der erste Moment, in dem sie sich unter Zeitdruck bezahlt macht.

/09Wann sich ein eigener Meldeprozess lohnt — und wann nicht

Nicht jedes Unternehmen, das über den CRA liest, ist Hersteller. Die Frage lohnt sich ehrlich zu beantworten, bevor Sie Konten anlegen.

Kaum relevant ist das Thema, wenn Sie keine Produkte mit digitalen Elementen unter eigenem Namen in Verkehr bringen. Ein Lohnfertiger, der nach Zeichnung Gehäuse fräst, ein Handwerksbetrieb, der Fremdgeräte installiert, ein Händler ohne eigene Marke: Für sie ist Artikel 14 kein Arbeitsauftrag. Händler und Importeure sollten aber wissen, an welchen Hersteller sie Hinweise weitergeben.

Ein schlanker Prozess genügt, wenn Sie ein überschaubares Portfolio mit wenigen Firmware-Linien haben, kaum Fernzugriff auf ausgelieferte Geräte und keine eigene Update-Infrastruktur. Dann reichen die Liste aus Abschnitt acht, zwei Konten und eine Übung im Jahr.

Ein belastbarer Prozess mit Überwachung ist nötig, wenn Ihre Geräte vernetzt beim Kunden stehen, Sie Updates selbst verteilen, Fernwartung anbieten oder Kunden aus regulierten Branchen beliefern, die nach einem Vorfall Auskunft verlangen. Dann ist die Meldung das kleinere Problem. Das größere ist, überhaupt rechtzeitig zu bemerken, dass etwas passiert — auf Build-Servern, im Signaturprozess, im Fernwartungsportal. Ohne Protokollierung und jemanden, der die Alarme liest, beginnt die 24-Stunden-Uhr erst, wenn ein Kunde anruft.

Die meisten KMU mit eigener Gerätesoftware rutschen in die dritte Gruppe, sobald Fernwartung dazukommt. Unterstützung bei Bestandsaufnahme und Lückenliste bietet Compliance & KRITIS; die Überwachung der Infrastruktur übernimmt auf Wunsch ein SOC.

/10Häufige Fragen