Der Cyber Resilience Act ist an einem Punkt angekommen, an dem ein Teil der Pflichten nicht mehr bloß Zukunftsmusik für 2027 ist. Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. ENISA hat dafür die zentrale Single Reporting Platform (SRP) gestartet.

Wichtig ist vor allem: Nicht jede gefundene Schwachstelle muss gemeldet werden. Der CRA nennt konkrete Auslöser. Eine Schwachstelle muss aktiv ausgenutzt werden, oder es muss ein schwerwiegender Sicherheitsvorfall vorliegen, der sich auf die Sicherheit des Produkts auswirkt. Dann beginnt für den Hersteller die Uhr zu laufen.

24 Stunden sind nur der erste Schritt

  • Innerhalb von 24 Stunden nach Kenntnis des Ereignisses muss eine Frühwarnung abgegeben werden.
  • Innerhalb von 72 Stunden folgt die vollständige Meldung.
  • Bei einer aktiv ausgenutzten Schwachstelle muss der Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrektur- oder Risikominderungsmaßnahme eingereicht werden.
  • Bei einem schwerwiegenden Sicherheitsvorfall ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung fällig.

Der Hersteller muss dafür nicht in mehreren Ländern separate Formulare ausfüllen. Die Meldung läuft über die ENISA-Plattform an das zuständige CSIRT, und das System verteilt die Informationen anschließend an die jeweils zuständigen Stellen weiter. Das ist einer der praktischeren Teile des ganzen Konstrukts: Statt eines europäischen Flickenteppichs aus Postfächern gibt es einen gemeinsamen Meldekanal.

WebsiteGarage / Leistungen

Entdecke unsere Leistungen.

Wen betrifft das – und wen nicht?

Der CRA gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. In der Praxis kann das Software und Hardware umfassen. Das bedeutet aber nicht, dass plötzlich jedes Unternehmen mit einer Website eine Sicherheitslücke in seinem WordPress-Plugin an ENISA melden muss.

Entscheidend ist die Rolle des Unternehmens in Bezug auf das Produkt. Wer WordPress, WooCommerce, Hosting oder einen externen SaaS-Dienst lediglich nutzt, wird dadurch nicht zum Hersteller dieser Produkte. Anders kann es aussehen, wenn ein Unternehmen ein eigenes Plugin, eine eigene Anwendung, ein Gerät oder eine andere vom CRA erfasste Lösung entwickelt und kommerziell bereitstellt. Dann sollte die eigene Rolle und der Meldeprozess besser vor dem ersten Vorfall geklärt sein – und nicht erst in Stunde 23.

Und was ist mit Open Source?

Hier führt eine zu grobe Verkürzung schnell in die falsche Richtung. ENISA unterscheidet klar zwischen Herstellern und den im CRA definierten Verwaltern quelloffener Software. Die Meldepflichten nach Artikel 24 Absatz 3 für Verwalter quelloffener Software gelten ab dem 11. Dezember 2027. Wer einfach Open-Source-Code veröffentlicht, unterliegt deshalb nicht automatisch seit September 2026 denselben Meldefristen wie ein Hersteller eines kommerziellen Produkts.

Das größte Problem ist möglicherweise gar nicht das Formular

Die 24 Stunden laufen ab dem Zeitpunkt, an dem der Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall Kenntnis erlangt. Damit verschiebt sich der Schwerpunkt von “melden können” zu “überhaupt bemerken können”. Ein Unternehmen ohne klaren Weg für Sicherheitsmeldungen, ohne Monitoring des eigenen Produkts und ohne verantwortliche Person für die Bewertung eines Vorfalls kann einen Großteil der Frist verlieren, bevor überhaupt jemand merkt, dass die regulatorische Uhr bereits läuft.

Deshalb sollte der Prozess nicht mit einem Link zum ENISA-Portal beginnen. Er sollte mit Antworten auf ganz andere Fragen anfangen: Wer nimmt eine Sicherheitsmeldung entgegen? Wer bewertet, ob eine Schwachstelle aktiv ausgenutzt wird? Wer darf die Entscheidung über eine Meldung treffen? Wo liegen die dafür nötigen technischen Daten? Und wer kommuniziert mit den Kunden? Die Plattform ist nur das letzte Stück dieser Strecke.

WebsiteGarage sagt

Rund um europäisches Digitalrecht entsteht ziemlich schnell ein Wettbewerb um die dramatischste Schlagzeile. Hier ist das Gegenteil interessanter: Die EU hat einen zentralen Meldepunkt geschaffen und einen ziemlich konkreten Takt für die Meldungen vorgegeben. Für ein Unternehmen, das tatsächlich als Hersteller unter den CRA fällt, lässt sich daraus ein Prozess bauen – statt eines Panikrituals nach dem Fund einer CVE.

Genauso wenig sinnvoll ist es allerdings, Pflichten aus irgendeiner fremden Checkliste zu übernehmen, ohne die eigene Rolle zu prüfen. Der Betreiber eines Onlineshops, der Hersteller eines WooCommerce-Plugins und ein Unternehmen, das ein IoT-Gerät verkauft, können völlig unterschiedliche Pflichten haben, obwohl alle drei irgendwie “etwas mit Internet” machen. Erst die Einordnung, dann der Prozess. In umgekehrter Reihenfolge entstehen Dokumente, die im Ordner hervorragend aussehen und bei einem echten Vorfall erstaunlich wenig helfen.