Die Single Reporting Platform der ENISA ist seit dem 11. September in Betrieb und bittet Hersteller, sich erst zu registrieren, wenn sie etwas zu melden haben. Was das Portal und Art. 14(7) bis zu diesem Tag geklärt sehen wollen.
Die Single Reporting Platform der ENISA ist seit dem 11. September in Betrieb und bittet Hersteller, sich erst zu registrieren, wenn sie etwas zu melden haben. Was das Portal und Art. 14(7) bis zu diesem Tag geklärt sehen wollen.
Am 11. September 2026 hat ENISA „the initial operating capability“ der Single Reporting Platform bereitgestellt (sinngemäss: die erste Betriebsstufe), also des Portals, über das Hersteller nun die Meldungen einreichen, die die Cyberresilienzverordnung (Cyber Resilience Act, CRA) verlangt. Die Dokumente der ENISA zur Plattform liegen nur auf Englisch vor; Zitate daraus stehen im Folgenden deshalb im Original, jeweils mit sinngemässer deutscher Wiedergabe. Das Datum stammt aus der Verordnung selbst. Die Verordnung (EU) 2024/2847 gilt vollständig ab dem 11. Dezember 2027, aber Art. 71(2) nimmt einen Artikel davon aus:
„Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.“
Artikel 14 ist der Meldeartikel, und nach Art. 69(3) gelten seine Pflichten „für alle Produkte mit digitalen Elementen, die in den Anwendungsbereich dieser Verordnung fallen und vor dem 11. Dezember 2027 in den Verkehr gebracht wurden“. Ein Produkt, das seit Jahren verkauft wird, ist damit schon heute meldepflichtig, fünfzehn Monate bevor die Hauptanforderungen der Verordnung gelten.
Art. 14(1) und (3) legen den Mechanismus fest. Ein Hersteller meldet eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit seines Produkts auswirkt, „gleichzeitig dem gemäß Absatz 7 als Koordinator benannten CSIRT und der ENISA“, und zwar über die Plattform, in der Verordnung „einheitliche Meldeplattform“ genannt. Sie reichen einmal ein, beide Empfänger erhalten die Meldung, und das koordinierende CSIRT gibt sie an die CSIRTs der anderen Mitgliedstaaten weiter, in denen das Produkt bereitgestellt wurde.
Ein früherer Beitrag hat behandelt, wann die Meldefrist zu laufen beginnt. Die andere Hälfte des Problems: wohin die Meldung geht, wer sie absenden darf und was das Portal tut, sobald die Uhr läuft.
Die FAQ der ENISA, zuletzt am 17. September aktualisiert, sind bei der Registrierung unmissverständlich:
„To limit the validation workload for designated CSIRTs, manufacturers and, once applicable, open-source software stewards are advised to register and initiate the validation process only when they need to submit a notification.“
Sinngemäss: Um den Validierungsaufwand der benannten CSIRTs zu begrenzen, wird Herstellern und, sobald anwendbar, Verwaltern quelloffener Software empfohlen, sich erst dann zu registrieren und das Validierungsverfahren einzuleiten, wenn sie eine Meldung einreichen müssen.
Der Registrierungsleitfaden wiederholt das: registrieren „only when they need to submit a specific notification, rather than registering pre-emptively“ (sinngemäss: erst, wenn eine konkrete Meldung einzureichen ist, statt vorsorglich). Der Grund steht im Zitat: Jede Registrierung ist ein Validierungsauftrag für ein CSIRT, und vorsorgliche Registrierungen wären Aufträge für Meldungen, die vielleicht nie kommen.
Im Moment der Einreichung kostet das Warten wenig. Die Validierung läuft parallel und blockiert die Meldung nicht: Ein AR, dessen Zuordnung noch nicht verifiziert ist, „may submit up to 20 notifications for that manufacturer before verification becomes mandatory“ (sinngemäss: darf bis zu 20 Meldungen für diesen Hersteller einreichen, bevor die Verifizierung zwingend wird), und laut ENISA dauert die Registrierung nur wenige Minuten, wenn man bereits ein EU-Login-Konto hat. Etwas kostet das Warten dagegen beim Kontenmodell. Die Plattform arbeitet mit Assigned Representatives (ARs), also benannten Vertretungspersonen des Herstellers:
EU-Login-Konten sind laut ENISA persönlich, und MFA ist Pflicht; ein gemeinsames Team-Login gibt es also nicht. „A Primary AR must first have a validated AR–manufacturer association, displayed as 'Verified', before inviting Secondary ARs“ (sinngemäss: Ein Primary AR braucht zuerst eine validierte Zuordnung zwischen AR und Hersteller, angezeigt als „Verified“, bevor er Secondary ARs einladen kann), und eine Einladung, die nicht innerhalb von sieben Tagen angenommen wird, verfällt. Zusammengelesen heisst das: Ein Hersteller, der dem Rat der ENISA folgt, registriert seine erste Person, während ein Vorfall läuft, und kann keine Stellvertretung hinzufügen, bevor ein CSIRT diese Person verifiziert hat. Auch Entwürfe helfen bei einer Übergabe nicht: Sie sind „stored locally in the individual AR's account and are therefore not visible to other ARs associated with the same manufacturer“ (sinngemäss: lokal im Konto des einzelnen AR gespeichert und daher für andere ARs desselben Herstellers nicht sichtbar).
Die Seite des BSI zur Plattform hält für die Security-Response-Rollen hinter diesen Meldungen fest, es „sollte eine verlässliche Vertretung durch mindestens zwei Personen gewährleistet sein“. Nichts im Rat der ENISA hindert Sie daran, schon heute festzulegen, wer diese zwei Personen sind, und ihre persönlichen EU-Login-Konten mit MFA anzulegen, was ENISA ausdrücklich „in advance“ (im Voraus) zulässt. Die Registrierung kann warten, bis es etwas zu melden gibt; die Wahl der zwei Personen nicht, denn die zweite kann erst hinzukommen, wenn ein CSIRT die erste verifiziert hat.
Früh in der Registrierung verlangt das Portal, das koordinierende CSIRT aus einer Drop-down-Liste zu wählen, mit dem Hinweis: „The manufacturer is responsible for identifying the correct CDaC in accordance with Article 14(7) of the CRA.“ (Sinngemäss: Der Hersteller ist dafür verantwortlich, das richtige CDaC gemäss Artikel 14(7) des CRA zu bestimmen; CDaC steht für das als Koordinator benannte CSIRT.) FAQ 18 sagt, was bei einer falschen Wahl passiert: „the notification may be invalidated and will need to be resubmitted to the correct CDaC“ (sinngemäss: Die Meldung kann für ungültig erklärt werden und muss beim richtigen CDaC erneut eingereicht werden). Die 24-Stunden-Frist pausiert nicht, während Sie neu einreichen.
Art. 14(7) gibt den Normalfall vor. Meldungen gehen an das CSIRT des Mitgliedstaats, „in dem die Hersteller ihre Hauptniederlassung in der Union haben“, und als Hauptniederlassung gilt der Mitgliedstaat, „in dem die Entscheidungen im Zusammenhang mit der Cybersicherheit seiner Produkte mit digitalen Elementen überwiegend getroffen werden“. Lässt sich dieser nicht bestimmen, gilt ersatzweise der Mitgliedstaat mit den meisten Beschäftigten in der Union.
Für einen Hersteller mit Sitz in der Schweiz ohne Niederlassung in der Union gilt stattdessen Unterabsatz 3. Zuständig ist das CSIRT im ersten Mitgliedstaat, auf den diese Reihenfolge zutrifft, bestimmt „auf der Grundlage der dem Hersteller zur Verfügung stehenden Informationen“:
Ein Bevollmächtigter ist nach Art. 3(15) eine „in der Union ansässige oder niedergelassene“ Person, die „von einem Hersteller schriftlich beauftragt wurde“; einen zu benennen ist nach Art. 18(1) freiwillig. Ein Schweizer Anbieter ohne Bevollmächtigten, Einführer oder Händler in der Union landet bei Buchstabe d, und das ist zugleich der Schritt, der Daten verlangt, die Sie vielleicht nicht haben: wo Ihre Nutzer sind. Ein Entgegenkommen hat Buchstabe d: Nach der ersten Meldung dort kann ein Hersteller „Meldungen im Zusammenhang mit späteren aktiv ausgenutzten Schwachstellen oder schwerwiegenden Sicherheitsvorfällen … an dasselbe CSIRT richten“.
Einen Fall kann ich aus dem Text nicht entscheiden. Nehmen Sie eine Schweizer Gruppe mit einer Vertriebstochter in Deutschland, deren Entscheidungen zur Produktsicherheit in Zürich fallen. Gibt es eine „Hauptniederlassung in der Union“? Der Entscheidungstest zeigt aus der Union hinaus, der Beschäftigtentest nach Deutschland. FAQ 8 der ENISA sagt nur, dass eine einzige Meldung genügt, auch wenn „its parent company is headquartered outside the EU“ (sinngemäss: die Muttergesellschaft ihren Sitz ausserhalb der EU hat), aber nicht, welches CSIRT sie erhält. Wenn das Ihre Struktur ist, gehört die Frage zu Ihrer Rechtsberatung, besser jetzt gestellt als in Stunde 20.
Schwachstellen und Sicherheitsvorfälle teilen die ersten beiden Schritte und trennen sich beim dritten. Aus Art. 14(2) und (4):
| Schritt | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Sicherheitsvorfall |
|---|---|---|
| Frühwarnung | innerhalb von 24 Stunden nach Kenntniserlangung; Mitgliedstaaten, in denen das Produkt bereitgestellt wurde | innerhalb von 24 Stunden; zudem, „ob der Verdacht besteht, dass der Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist“ |
| Meldung | innerhalb von 72 Stunden; allgemeine Art der Ausnutzung und der Schwachstelle, ergriffene Massnahmen und Massnahmen, die Nutzer ergreifen können, wie sensibel die Informationen sind | innerhalb von 72 Stunden; Art des Sicherheitsvorfalls, „eine erste Bewertung“, ergriffene Massnahmen und Massnahmen, die Nutzer ergreifen können |
| Abschlussbericht | „spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht“ | „innerhalb eines Monats nach Übermittlung der Meldung des Sicherheitsvorfalls“ |
Ein Sicherheitsvorfall gilt nach Art. 14(5) als schwerwiegend, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, „die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von sensiblen oder wichtigen Daten oder Funktionen zu schützen“, oder wenn er dazu geführt hat oder führen kann, dass bösartiger Code im Produkt oder in den Systemen eines Nutzers ausgeführt wird. Das koordinierende CSIRT kann zudem einen Zwischenbericht verlangen (Art. 14(6)). Der Einreichungsleitfaden ergänzt, dass sich die Meldung bis zum Abschlussbericht aktualisieren lässt und danach „becomes non‑editable“ (nicht mehr bearbeitbar ist).
Die Meldungen werden auf Englisch verfasst. Laut FAQ 24 der ENISA ist die Plattform zum Start nur auf Englisch verfügbar, und das BSI sagt es ausdrücklich: „Die Meldungen sind auf Englisch zu verfassen, damit die EU-weite Koordination effizient möglich ist.“ Für ein Team in Lausanne oder Lugano ist das ein weiterer Punkt, den man besser vor einem Vorfall vorbereitet als währenddessen.
Die Plattform zeigt Zähler an, und FAQ 26 beschreibt, wie sie in der aktuellen Version funktionieren:
„the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning. As a result, in some cases, a notification may be displayed as overdue before 72 hours have elapsed since the manufacturer or open-source software steward became aware of the event.“
Sinngemäss: Der 72-Stunden-Zähler zeigt als Fälligkeit einen Zeitpunkt 48 Stunden nach Einreichung der 24-Stunden-Frühwarnung an. Deshalb kann eine Meldung in manchen Fällen als überfällig erscheinen, bevor seit der Kenntniserlangung durch den Hersteller oder den Verwalter quelloffener Software 72 Stunden vergangen sind.
Laut ENISA wird eine künftige Version den Zähler stattdessen am Zeitpunkt der Kenntniserlangung verankern. Bis dahin wirkt die Rechnung in beide Richtungen. Reichen Sie die Frühwarnung zwei Stunden nach Kenntniserlangung ein, zeigt der Zähler die 72-Stunden-Meldung in Stunde 50 als fällig an, früher als das Gesetz verlangt. Reichen Sie sie in Stunde 23 ein, zeigt er Stunde 71, was zufällig nahe dran ist. Der Zähler hängt an Ihrer Einreichung; die Verordnung hängt an Ihrer Kenntnis.
Für Schwachstellen gibt es überhaupt keinen Zähler für den Abschlussbericht, „as the Final Report deadline depends on the date and time when a corrective or mitigating measure becomes available“ (sinngemäss: da die Frist für den Abschlussbericht davon abhängt, wann eine Korrektur- oder Risikominderungsmassnahme verfügbar wird). Dieses Datum lebt in Ihrem Release-Prozess, nicht im Portal. ENISA sagt es direkt: Die Zähler „do not replace the responsibility of manufacturers … to comply with the obligations laid down in CRA“ (sinngemäss: entbinden die Hersteller nicht von ihrer Verantwortung, die im CRA festgelegten Pflichten zu erfüllen).
Die beiden Daten, die über Ihre Fristen entscheiden, also wann Sie Kenntnis erlangt haben und wann die Korrektur verfügbar war, müssen an einem Ort festgehalten werden, den Sie selbst kontrollieren. Das Portal rekonstruiert keines von beiden.
FAQ 25 regelt den Ausfall: warten, bis die Plattform wieder erreichbar ist, und dann einreichen. Wenn Sie „consider that immediate communication is necessary“ (sinngemäss: eine sofortige Kontaktaufnahme für nötig halten), können Sie sich direkt an das benannte CSIRT wenden, aber „the notification must still be submitted through the SRP once it is available again“ (sinngemäss: die Meldung muss trotzdem über die SRP eingereicht werden, sobald diese wieder verfügbar ist). Zu wissen, welches CSIRT das ist und wie man es erreicht, ist wieder dieselbe Frage nach Art. 14(7).
Eine API gibt es nicht: Laut FAQ 15 „notifications must be submitted through the platform interface“ (sinngemäss: Meldungen müssen über die Benutzeroberfläche der Plattform eingereicht werden). Interne Werkzeuge können den Text also vorbereiten, eingeben muss ihn trotzdem eine Person mit EU Login. Freiwillige Meldungen nach Art. 15 sollen laut ENISA erst in einer späteren Phase hinzukommen. Die Information der Nutzer ist eine eigene Pflicht nach Art. 14(8), „gegebenenfalls in einem strukturierten, maschinenlesbaren Format“, und die Meldung an das CSIRT erfüllt sie nicht.
Auch NIS2 ist ein eigener Kanal. Nach der Lesart des BSI für Deutschland kann ein schwerwiegender Sicherheitsvorfall unter beide Regime fallen; dann „ist der Vorfall sowohl nach NIS-2 (via BSI-Portal), als auch nach dem CRA (via CRA-SRP) zu melden“. Das BSI ergänzt, dass nach dem Digital-Omnibus-Vorschlag der Kommission eine CRA-Meldung auch für NIS2 zählen würde, mit der Einschränkung: „Wird die Regelung in dieser Form beschlossen“. Vorerst ist es ein Vorschlag.
Ein Schweizer Datum sollten Sie im Blick behalten: Im August 2025 hat der Bundesrat das BACS beauftragt, zusammen mit dem BAKOM und dem SECO „bis Herbst 2026“ eine Vernehmlassungsvorlage für eine Gesetzgebung zur Cyberresilienz digitaler Produkte zu erarbeiten. Was immer sie vorschlägt: Art. 14 gilt bereits für Produkte im Anwendungsbereich, die Sie auf dem EU-Markt in Verkehr gebracht haben.
ENISA hat Hersteller gebeten, sich noch nicht zu registrieren, und es gibt keinen Grund, dem zu widersprechen. Was dann noch zu tun bleibt, passt auf eine Seite: das koordinierende CSIRT nach Art. 14(7), samt Begründung der Wahl; die zwei namentlich benannten Personen, die als Primary und Secondary AR handeln, jede mit persönlichem EU Login und MFA; wo der Zeitpunkt der Kenntniserlangung und das Datum der Korrektur festgehalten werden; und der englische Text dazu, was Ihr Produkt ist, damit die Frühwarnung nicht bei einem leeren Feld beginnt. Falls Sie noch nicht entschieden haben, was „Kenntnis erlangen“ für Ihr Team bedeutet, ist der frühere Beitrag der Ausgangspunkt.
devguard führt das Vorfallregister, von dem eine solche Meldung ausgeht, mit seinen Zeitstempeln und einer namentlich verantwortlichen Person: devguard.ch/platform.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.