Zusammenfassung

  • Seit dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act für Hersteller von Produkten mit digitalen Elementen. Nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls folgen eine Frühwarnung binnen 24 Stunden und eine ausführlichere Meldung binnen 72 Stunden.
  • Die Single Reporting Platform vereinheitlicht die Abgabe, nicht die hoheitliche Entscheidung. Der Hersteller wählt einen nationalen koordinierenden CSIRT, der die Meldung normalerweise weiterleitet; ENISA betreibt die Plattform. Zum Start gibt es nur eine englische Oberfläche, keine API, keine freiwilligen Meldungen und noch keine Meldepflicht für Open-Source-Stewards.

Der auffällige Termin im Cyber Resilience Act ist nicht erst der 11. Dezember 2027.

Dann werden die wichtigsten Vorgaben für sichere Produktgestaltung, Schwachstellenbehandlung und Konformität allgemein anwendbar. Bereits fünfzehn Monate früher, am 11. September 2026, ist Artikel 14 in Kraft getreten. Der Umsetzungsfahrplan der European Commission trennt die beiden Stufen ausdrücklich.

Sobald ein Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem Vorfall mit schwerwiegenden Auswirkungen auf die Sicherheit eines erfassten Produkts erfährt, muss er ohne unangemessene Verzögerung handeln. Die Frühwarnung ist spätestens nach 24 Stunden fällig. Eine Meldung mit allgemeinen Angaben und erster Bewertung muss spätestens nach 72 Stunden vorliegen.

Danach laufen unterschiedliche Abschlussfristen. Nach der Darstellung der European Commission folgt bei einer aktiv ausgenutzten Schwachstelle der Schlussbericht spätestens 14 Tage, nachdem eine Abhilfe oder Eindämmung verfügbar ist. Bei einem schwerwiegenden Vorfall ist er binnen eines Monats nach der 72-Stunden-Meldung fällig.

Damit ist die Übergangszeit bis Ende 2027 keine meldefreie Zeit. Auch bereits angebotene Produkte können heute einen Bericht auslösen, wenn sie in den Anwendungsbereich fallen. Die EU baut zunächst das sensorische System auf, bevor die vollständigen materiellen Produktpflichten greifen.

Kenntnis ist ein Unternehmensereignis

Die gesetzliche Uhr setzt nicht beim Login ein. Sie wartet auch nicht auf eine perfekte forensische Gewissheit. Entscheidend ist, wann der Hersteller Kenntnis vom meldepflichtigen Ereignis erlangt.

Das zwingt Technik, Recht und Führung zu einer gemeinsamen Schwelle. Ein anfänglicher Hinweis kann noch unbestimmt sein. Eine belastbare Beobachtung kann später zeigen, dass ein Akteur die Schwachstelle tatsächlich ohne Erlaubnis ausnutzt. Wieder später kann sich der betroffene Versionsumfang ändern. Jede Stufe braucht einen Zeitstempel, ohne den ursprünglichen Wissensstand nachträglich zu überschreiben.

Der Hersteller muss festhalten, welches Indiz die Meldeschwelle überschritten hat und wer dies entschied. Ein späterer Untersuchungsbericht darf den Beginn der ersten 24 Stunden nicht bequem neu datieren. Umgekehrt ist nicht jede bekannte Schwachstelle automatisch eine aktiv ausgenutzte Schwachstelle.

Eine Meldung durchläuft mehrere Mandate

Über die Single Reporting Platform ist für dasselbe Ereignis nur eine Meldung erforderlich. Das gilt auch für Unternehmensgruppen mit mehreren Niederlassungen oder Tochtergesellschaften in der EU und für Konzerne mit Muttergesellschaft außerhalb der Union. Die interne Abstimmung bleibt Sache des Herstellers.

Bei der Abgabe muss er den zuständigen, als Koordinator benannten CSIRT auswählen. Maßgeblich ist im Regelfall der Hauptsitz des Herstellers. Die richtige Auswahl liegt in seiner Verantwortung. Die von ENISA geführte Liste der Koordinatoren ist somit eine verbindende Schicht zwischen Unternehmensstruktur und Behördenweg.

Im Normalfall steht die Meldung dem gewählten CSIRT und ENISA zur Verfügung. Der zuerst empfangende CSIRT verbreitet sie unverzüglich an die relevanten CSIRTs der Mitgliedstaaten, in denen das Produkt angeboten wurde. Für Vollzugsaufgaben können Informationen außerdem an Marktüberwachungsbehörden gehen.

Das Formular ist einheitlich, die Zuständigkeit nicht. Der Hersteller kontrolliert Produktwissen und interne Zeitpunkte. Der nationale CSIRT bewertet und verteilt zuerst. ENISA betreibt die Infrastruktur und kann den europäischen Datenstrom auswerten. Marktüberwachungsbehörden prüfen, ob Ermittlungen oder Korrekturmaßnahmen notwendig werden.

Ein technischer Eingangsbeleg beweist deshalb nur einen Teil der Kette. Nach der ENISA-FAQ kann die Wahl des falschen Koordinators zur Ungültigkeit und erneuten Abgabe führen. Herstelleridentität, Hauptniederlassung und Marktverfügbarkeit gehören vor einem Vorfall in dieselbe Karte.

Die Ausnahme ist keine private Sperre

Bei einer aktiv ausgenutzten Schwachstelle kann die sofortige weite Verbreitung selbst ein Sicherheitsrisiko erzeugen. Für die 72-Stunden-Meldung gibt es deshalb den eng begrenzten Weg der Particularly Exceptional Circumstances, kurz PEC.

Die ENISA-Anleitung teilt Antrag und Entscheidung. Der Hersteller kennzeichnet die mögliche Ausnahme und kann sie begründen. Der koordinierende CSIRT entscheidet, ob die Verteilung verzögert wird.

Wird sie anerkannt, erhält ENISA zunächst nur begrenzte Angaben. Der nationale Koordinator bleibt für die spätere Weitergabe der vollständigen Meldung an ENISA und die betroffenen CSIRTs verantwortlich.

Der Melder hat damit kein einseitiges Geheimhaltungsrecht. Die Funktion gilt auch nicht für jede unangenehme Sicherheitsmeldung. Prüfbar wird das Verfahren erst, wenn Antragszeitpunkt, Begründung, behördliche Entscheidung und Ende der Verzögerung als getrennte Zustände erhalten bleiben.

Der Startumfang ist kleiner als der spätere Rechtsrahmen

Die erste Version der Plattform nimmt verpflichtende Herstellermeldungen zu aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen entgegen. Freiwillige Meldungen nach Artikel 15 sind noch nicht implementiert. Andere Personen und Organisationen sollen sich vorerst direkt an den passenden nationalen CSIRT wenden.

Auch Open-Source-Software-Stewards unterliegen der eigenen Meldepflicht erst ab dem 11. Dezember 2027. Dass ENISA sie als spätere Nutzer der Plattform beschreibt, zieht ihren gesetzlichen Termin nicht vor.

Zum Start ist die Oberfläche nur auf Englisch verfügbar. Eine Programmierschnittstelle gibt es nicht. Unternehmen können die interne Erkennung und Vorbereitung automatisieren; die rechtsrelevante Abgabe erfolgt dennoch über die Oberfläche. Bei vielen Produkten wird menschliche Bedienkapazität damit zu einem Kontrollfaktor.

Beauftragte Vertreter melden sich über persönliche EU-Login-Konten mit Mehrfaktor-Authentifizierung an. Der nationale Koordinator prüft die Verbindung zwischen Person und Hersteller. Diese Validierung läuft parallel und blockiert die dringende Erstmeldung nicht: Ein noch nicht bestätigter Vertreter darf bis zu zwanzig Meldungen für den Hersteller abgeben, bevor die Prüfung zwingend wird. Die Registrierungsanleitung zeigt, was vor einem Notfall geklärt sein muss: Rechtsträger, Koordinator, Haupt- und Ersatzvertreter, Konten und Zugänge.

Der Bildschirm berechnet nicht das Gesetz

ENISA nennt eine konkrete Einschränkung der ersten Fassung. Der sichtbare 72-Stunden-Zähler setzt derzeit 48 Stunden auf den Zeitpunkt der 24-Stunden-Frühwarnung. Die gesetzliche Frist läuft hingegen 72 Stunden ab Kenntnis. Wird die Frühwarnung früh eingereicht, kann das Portal eine Meldung als überfällig anzeigen, bevor die echten 72 Stunden abgelaufen sind. ENISA will die Logik auf den eingegebenen Kenntniszeitpunkt umstellen.

Weder verkürzt noch verlängert die Anzeige Artikel 14. Sie zeigt den Unterschied zwischen Norm und Umsetzung. Der Hersteller sollte Kenntniszeitpunkt und Beleg, Frühwarnung, selbst berechnete 72-Stunden-Grenze, Portalwert und Eingangsbestätigung einzeln speichern.

Bei einer zeitweiligen Nichtverfügbarkeit bleibt diese Trennung bestehen. ENISA verlangt die Abgabe nach Wiederherstellung. Dringende direkte Kommunikation mit dem zuständigen CSIRT ist möglich, ersetzt aber nicht die spätere Portalübermittlung. Ein einzelner fehlgeschlagener Verbindungsversuch belegt keinen allgemeinen Ausfall.

Betriebstransparenz ohne Schwachstellendaten

Die Öffentlichkeit muss keine aktiven Schwachstellen sehen, um die Infrastruktur beurteilen zu können. Sie muss erkennen können, welche Ausführungsregeln zu einem bestimmten Zeitpunkt galten.

ENISA könnte dafür ein vertraulichkeitswahrendes Status- und Versionsprotokoll veröffentlichen: Verfügbarkeitsereignisse, zugelassene Melderklassen, unterstützte Berichtstypen, Sprachen, API-Stand, Zählerlogik und Inkrafttreten jeder Änderung. Namen, Produkte und technische Schwachstellendetails hätten darin nichts zu suchen.

Das ist meine redaktionelle Empfehlung, keine bestehende CRA-Pflicht und keine Zusage von ENISA. Drei Arbeiten von Lu Heng liefern die Methode: The Policy Mirror fragt nach dem Träger der Befugnis, Running Code Primary nach dem tatsächlich ausgeführten Zustand und Why BTW Media Exists nach der sauberen Grenze zwischen Beleg und institutionellem Wunsch.

Die EU hat einen gemeinsamen Eingang geschaffen. Ob daraus belastbare Aufsicht entsteht, entscheidet die Nachweisführung an jedem weiteren Übergang.

Quellen