Die kurze Antwort
Die Meldepflicht des EU Cyber Resilience Act ist jetzt in Kraft. Seit dem 11. September 2026 muss jeder Hersteller eines „Produkts mit digitalen Elementen“, das in der EU verkauft wird, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle an ENISA und sein nationales CSIRT melden — eine Frühwarnung binnen 24 Stunden, eine ausführlichere Meldung binnen 72 Stunden und einen Abschlussbericht binnen 14 Tagen. Die Uhr läuft ab dem Moment, in dem Sie Kenntnis erlangen, nicht erst nach Abschluss der Bestätigung, und die Regel erreicht bereits am Markt befindliche Produkte sowie Anbieter mit Sitz außerhalb der EU.
Für Engineering-Verantwortliche liegt der Haken darin, dass dies eine Prozesspflicht mit knapper Frist ist, die mehr als ein Jahr vor den Design- und Dokumentationsanforderungen des CRA greift. Zu wissen, dass eine ausgenutzte Schwachstelle existiert, ist nicht länger nur eine interne Schweregradeinschätzung; es ist der Start eines regulatorischen Zeitplans. Wer das gelassen bewältigt, behandelt Erkennung und Offenlegung ausgenutzter Schwachstellen als eingeübte Fähigkeit — genau den Muskel, den wir in einem Penetrationstest und Sicherheitsaudit aufbauen, wo das Auffinden und Priorisieren echter, ausnutzbarer Probleme der ganze Zweck ist.
Was am 11. September in Kraft trat
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist das horizontale Cybersicherheitsgesetz der EU für „Produkte mit digitalen Elementen“ — praktisch jede Software oder Hardware, die sich mit einem Gerät oder Netzwerk verbinden kann, von Firmware und Betriebssystemen über mobile Apps und SaaS-nahe Komponenten bis zu vernetzter Consumer-Technik. Die meisten seiner Pflichten — sichere Entwicklung, Dokumentation, Konformität — gelten erst ab dem 11. Dezember 2027. Doch die Verordnung hat eine Pflicht vorgezogen, und diese ist am 11. September 2026 in Kraft getreten: die Meldepflicht.
Ab diesem Datum muss ein Hersteller, der Kenntnis davon erlangt, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird, oder von einem schwerwiegenden Vorfall, der die Sicherheit des Produkts beeinträchtigt, die EU-Agentur für Cybersicherheit (ENISA) und das zuständige nationale Computer Security Incident Response Team (CSIRT) informieren. Der Zeitplan ist gestaffelt und eng: eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine ausführlichere technische Meldung binnen 72 Stunden und ein Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme bei ausgenutzten Schwachstellen — oder binnen eines Monats bei schwerwiegenden Vorfällen.
Zwei Konstruktionsentscheidungen machen das schwerer, als es aussieht. Erstens ist der Auslöser die Kenntnisnahme, nicht die Bestätigung: unabhängige juristische Analysen betonen, dass die Uhr läuft, sobald ein Hersteller von dem Problem Kenntnis erlangt — ein Team kann also keine gemächliche interne Untersuchung führen und erst danach zu zählen beginnen. Zweitens laufen Meldungen über die neue Single Reporting Platform der ENISA, die am selben Tag live ging; zum Start ist sie ein manuelles Web-Portal ohne öffentliche API und ohne Kanal für freiwillige Meldungen, sodass die Einreichung noch nicht in eine Incident-Pipeline skriptbar ist. Ein CSIRT, das die Meldung erhält, teilt sie mit weiteren relevanten nationalen Teams.
Wer betroffen ist — auch DACH-Teams
Das häufigste Missverständnis ist, dies sei ein Problem allein für EU-Unternehmen. Ist es nicht. Die Pflicht knüpft an das Bereitstellen eines Produkts auf dem EU-Markt an, sodass ein US-, britischer oder anderer Nicht-EU-Hersteller, der Software, eine SaaS-Komponente oder ein vernetztes Gerät an EU-Kunden liefert, klar im Anwendungsbereich liegt. Ein Anbieter mit Sitz in Austin, London oder Zürich mit europäischen Nutzern erbt dieselbe 24-Stunden-Uhr wie einer in Berlin. Diese extraterritoriale Reichweite ist gewollt, und der Durchsetzungsrahmen ist real: Geldbußen können 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes erreichen, je nachdem, welcher Betrag höher ist.
Die zweite Überraschung ist die Reichweite in den Bestand. Die Meldepflicht ist der einzige Teil des CRA, der für bereits am Markt befindliche Produkte gilt, nicht nur für neue, die nach einem künftigen Stichtag bereitgestellt werden. Vor Jahren ausgelieferte Firmware, eine in ein Gerät eingebettete Bibliothek oder eine lange vor Inkrafttreten des CRA veröffentlichte Anwendung fallen ab dem 11. September unter die Pflicht, sobald eine enthaltene Schwachstelle aktiv ausgenutzt wird. Für Teams, die langlebige Produkte bauen — und für alle, die Individualsoftware ausliefern, die im vernetzten Produkt eines Kunden landet — heißt das praktisch: Alter Code, den Sie nicht mehr aktiv weiterentwickeln, kann dennoch ein Meldeereignis am selben Tag auslösen.
Open-Source-Verwalter erhalten mehr Anlauf: Ihre spezifischen Pflichten gelten erst später, ab dem 11. Dezember 2027, in Anerkennung dessen, wie sich nicht-kommerzielle Maintainer von Herstellern unterscheiden. Kommerzielle Anbieter jedoch, die Open-Source-Komponenten in ein Produkt einbinden, dürfen nicht aufschieben — enthält das ausgelieferte Produkt einen ausgenutzten Fehler, meldet der Hersteller, der es auf den Markt bringt.
Was das für Softwareteams bedeutet
Die erste Verschiebung: Schwachstellenbehandlung wird zu einem regulierten Zeitplan, nicht zu einer internen Präferenz. Viele Teams betreiben bereits einen Coordinated-Disclosure-Prozess, aber in eigenem Takt. Der CRA gibt den Takt für den schlimmsten Fall vor: aktive Ausnutzung in freier Wildbahn. Das bedeutet: Sie brauchen eine eindeutige interne Definition von „Kenntnis“ und „aktiv ausgenutzt“, eine benannte Entscheidungsperson, die diese Einschätzung auch außerhalb der Geschäftszeiten treffen kann, und eine Meldung, die Sie ohne wochenlanges Entwerfen fertigstellen. Verankern Sie das in derselben Sicherheitsdisziplin, die Sie über Ihre Cloud- und DevOps-Pipeline anwenden — Asset-Inventar, Abhängigkeits- und SBOM-Transparenz, Monitoring — denn Sie können nicht binnen 24 Stunden über ein Produkt melden, dessen Komponenten Sie nicht auflisten können.
Die zweite Verschiebung ist Nachweisbarkeit und Nachvollziehbarkeit. Eine gestaffelte Meldung nach 24 Stunden, 72 Stunden und 14 Tagen ist faktisch die Forderung nach einem rekonstruierbaren Zeitverlauf: wann Sie von dem Problem erfuhren, was Sie zu jedem Schritt wussten, worin die Abhilfemaßnahme bestand und wann sie ausgeliefert wurde. Teams, die Erkennung, Triage und Patch-Entscheidungen als erstklassige Ereignisse protokollieren, erzeugen diese Erzählung fast nebenbei; Teams, die Sicherheitsarbeit als informelles Wissen behandeln, müssen sie unter der Frist eines Regulierers mühsam zusammensuchen. Das ist dieselbe Haltung, die die 72-Stunden-Meldepflicht der DSGVO belohnt hat — der CRA weitet diesen Reflex lediglich von Datenschutzvorfällen auf die Produktsicherheit aus.
Die dritte Verschiebung ist Überschneidung und Entflechtung. Ein einziger ausgenutzter Fehler kann nun CRA-Meldung, DSGVO-Meldung und — bei Betreibern kritischer Infrastruktur — NIS2- oder DORA-Vorfallpflichten zugleich auslösen, jede mit eigenem Empfänger und eigener Uhr. Gerade für FinTech- und HealthTech-Anbieter lautet die Antwort nicht, parallele Ad-hoc-Prozesse zu fahren, sondern einen einzigen Incident-Workflow zu gestalten, der mit dem richtigen Inhalt und Timing an die richtigen Behörden verzweigt. Diese Verkabelung im Voraus richtig hinzubekommen, ist weit günstiger, als die Konflikte mitten im Vorfall zu entdecken.
Was jetzt zu tun ist
- Marktexposition klären. Listen Sie jedes Produkt mit digitalen Elementen auf, das Sie in der EU bereitstellen — einschließlich SaaS-gelieferter und eingebetteter Komponenten sowie noch im Feld befindlicher Bestandsprodukte. Erreicht eines davon EU-Nutzer, sind Sie im Anwendungsbereich, unabhängig vom Standort.
- „Kenntnis“ und „aktiv ausgenutzt“ definieren. Halten Sie die Kriterien und die benannte verantwortliche Person schriftlich fest. Unklarheit hier verbrennt das 24-Stunden-Fenster, denn die Uhr startet bei Kenntnisnahme, nicht am Ende Ihrer Untersuchung.
- Meldungen vorbereiten. Entwerfen Sie die Vorlagen für 24 Stunden, 72 Stunden und 14 Tage jetzt und richten Sie Zugang und Workflow auf der Single Reporting Platform der ENISA ein. Ohne API zum Start erfolgt die Einreichung manuell — üben Sie sie, damit sie zur Routine wird, nicht zur Improvisation.
- In das Engineering einbetten. Sorgen Sie dafür, dass Erkennung, Abhängigkeits- und SBOM-Transparenz sowie Patch-Entscheidungen als Ereignisse protokolliert werden, damit sich der Zeitverlauf der Meldung von selbst zusammensetzt. Über Komponenten, die Sie nicht sehen, können Sie nicht schnell melden.
- Mit DSGVO, NIS2 und DORA entflechten. Ordnen Sie zu, welche Vorfälle welche Pflichten auslösen, und gestalten Sie einen Workflow, der mit korrektem Inhalt und korrekter Uhr an jede Behörde verzweigt, statt separater, konkurrierender Verfahren.
Häufig gestellte Fragen
Was hat sich am 11. September 2026 geändert?
Die Meldepflichten des EU Cyber Resilience Act (Verordnung (EU) 2024/2847) sind anwendbar geworden. Hersteller von Produkten mit digitalen Elementen, die in der EU verkauft werden, müssen nun aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle an ENISA und das zuständige nationale CSIRT melden. Die weiterreichenden CRA-Cybersicherheitsanforderungen gelten erst später, ab dem 11. Dezember 2027, doch die Meldepflicht ist bereits jetzt in Kraft.
Wie sieht die Meldefrist aus?
Bei einer aktiv ausgenutzten Schwachstelle: eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine ausführlichere Meldung binnen 72 Stunden und ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme. Schwerwiegende Vorfälle folgen den 24- und 72-Stunden-Schritten mit einem Abschlussbericht binnen eines Monats. Die Uhr startet bei Kenntnisnahme, nicht am Ende der internen Bestätigung.
Gilt der CRA für Unternehmen außerhalb der EU?
Ja. Die Pflicht knüpft an das Bereitstellen eines Produkts auf dem EU-Markt an, sodass ein US-, britischer, Schweizer oder anderer Nicht-EU-Hersteller, der Software, eine SaaS-Komponente oder ein vernetztes Gerät an EU-Kunden verkauft, im Anwendungsbereich liegt. Geldbußen können 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes erreichen, je nachdem, welcher Betrag höher ist.
Sind Bestandsprodukte erfasst?
Ja. Die Meldepflicht erreicht bereits am EU-Markt befindliche Produkte, nicht nur neue. Ein Router, ein Firmware-Image, eine Bibliothek oder eine Anwendung, die vor Inkrafttreten des CRA ausgeliefert wurde, fällt ab dem 11. September 2026 unter die Pflicht, sofern sie eine aktiv ausgenutzte Schwachstelle enthält. Es ist der Teil des CRA, der den Bestand zuerst berührt.
Wie reicht man eine Meldung ein?
Über die Single Reporting Platform (SRP) der ENISA, aktiv seit dem 11. September 2026. Sie leitet die Meldung an das CSIRT in Ihrem Haupt-Mitgliedstaat und weiter an andere relevante nationale Teams. Zum Start ist sie ein manuelles Web-Portal ohne öffentliche API und ohne Option für freiwillige Meldungen, sodass der praktische Schritt darin besteht, Vorlagen, Verantwortliche und Entscheidungsregeln vor einem Vorfall vorzubereiten, statt die Einreichung automatisieren zu wollen.
Quellen
Europäische Kommission — Cyber Resilience Act: Meldepflichten
TechHQ — EU Cyber Resilience Act reporting: was sich am 11. September geändert hat
Crowell & Moring — EU CRA: Meldefrist für Vorfälle/Schwachstellen zum 11. September 2026