24 Stunden bis zur Meldung: Die erste CRA-Pflicht gilt seit dem 11. September

Seit Freitag, dem 11. September 2026, gilt die erste operative Pflicht aus dem Cyber Resilience Act. Wer Produkte mit digitalen Elementen auf dem EU-Binnenmarkt anbietet, muss aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle ab sofort melden, und zwar innerhalb von 24 Stunden. Rechtsgrundlage ist Artikel 14 der Verordnung (EU) 2024/2847, dessen vorgezogene Anwendbarkeit in Artikel 71 geregelt ist.

Der Rest der Verordnung greift erst am 11. Dezember 2027. Das führt zu einer Konstellation, die in der Praxis leicht übersehen wird: Die Meldepflicht besteht bereits, die übrigen Anforderungen und die Bußgeldvorschriften noch nicht.

Drei Fristen, eine Plattform

Artikel 14 sieht ein dreistufiges Verfahren vor. Nach Kenntniserlangung ist binnen 24 Stunden eine Frühwarnung abzugeben, binnen 72 Stunden folgt eine detailliertere Meldung. Den Abschlussbericht verlangt die Verordnung bei Schwachstellen spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme, bei schwerwiegenden Sicherheitsvorfällen innerhalb eines Monats.

Gemeldet wird über die CRA Single Reporting Platform, die die EU-Agentur für Cybersicherheit ENISA betreibt. Die Plattform ist ausschließlich englischsprachig; eine Registrierung ist erst im Bedarfsfall nötig, also dann, wenn tatsächlich eine Meldung ansteht. Die Meldung wird der ENISA und dem koordinierenden CSIRT gleichzeitig zugänglich gemacht. Für Deutschland ist das CERT-Bund beim BSI zuständig.

Abgegeben wird die Meldung durch eine benannte Vertretungsperson des Herstellers. Wer diese Rolle innehat und wie die Person außerhalb der Bürozeiten erreichbar ist, ist die erste Frage, die eine 24-Stunden-Frist stellt.

Wer gemeint ist, und wer nicht

Der Begriff Produkt mit digitalen Elementen ist weiter gefasst, als die Assoziation mit vernetzter Hardware vermuten lässt. Er umfasst neben Geräten wie Smart-Home-Komponenten, Firewalls oder Smart Metern auch reine Softwareprodukte: Buchhaltungssoftware, mobile Apps, Spiele. Maßgeblich ist, dass das Produkt direkt oder indirekt mit einem Gerät oder Netz verbunden werden kann und auf dem EU-Markt bereitgestellt wird. Der Sitz des Herstellers spielt keine Rolle.

Nicht erfasst sind nichtkommerzielle Open-Source-Software, Medizinprodukte, Fahrzeuge und Luftfahrtausrüstung, für die eigene Regelwerke gelten, sowie Produkte ausschließlich für Zwecke der nationalen Sicherheit.

Eine Abgrenzung, die für Anbieter von Webanwendungen wichtig ist, betrifft SaaS. Cloud-Dienste als solche gelten nicht als Produkt mit digitalen Elementen; sie fallen je nach Sektor und Größe des Anbieters unter NIS2 oder DORA. Der CRA erfasst Fernverarbeitung nur dann, wenn sie für eine Kernfunktion des Produkts erforderlich ist, also technisch Teil des Produkts ist und nicht eine ergänzende Cloud-Funktion. Viele Anbieter liegen in beiden Regimen gleichzeitig: NIS2 für das Unternehmen als Diensteanbieter, CRA für die Software, die sie verkaufen.

Bemerkenswert ist außerdem, dass die Meldepflicht auch Produkte betrifft, die vor dem Stichtag in Verkehr gebracht wurden. Artikel 69 Absatz 3 erstreckt Artikel 14 ausdrücklich auf den Bestand.

Was aktiv ausgenutzt bedeutet

Die Meldepflicht knüpft nicht an jede kritische Lücke an. Meldepflichtig ist eine Schwachstelle erst, wenn nachweisbar ist, dass böswillige Akteure sie tatsächlich in realen Systemen ausgenutzt haben. Ein veröffentlichter Exploit-Code allein genügt dafür nicht. Die zweite Kategorie sind schwerwiegende Sicherheitsvorfälle, also Ereignisse, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler Daten beeinträchtigen oder das Einschleusen von Schadcode ermöglichen.

Das lässt sich am Beispiel einer Lücke zeigen, die in der vergangenen Woche bekannt wurde. CVE-2026-79696 betrifft die Komponente adk web in Googles Agent Development Kit für Python in den Versionen 2.0.0 bis 2.6.0 und trägt mit CVSS 10.0 die Höchstwertung: Code-Ausführung über das Netz, ohne Anmeldung und ohne Zutun eines Nutzers, sofern pytest in der Umgebung installiert ist. Wer diese Bibliothek in einem eigenen Produkt einsetzt, hat ein dringendes Update-Thema. Eine Meldepflicht nach Artikel 14 entsteht daraus aber nicht automatisch: Die Lücke steht bislang weder in CISAs Katalog bekannter ausgenutzter Schwachstellen, noch liegen Hinweise auf Angriffe vor.

Die Unterscheidung zwischen kritisch und aktiv ausgenutzt entscheidet darüber, ob die Uhr läuft. Sie lässt sich nicht im Moment des Vorfalls zum ersten Mal treffen.

Für Unternehmen, die KI-Bibliotheken und Agenten-Frameworks in eigene Produkte einbauen, hängt daran mehr als eine Formalie. Die Abhängigkeitsketten solcher Komponenten sind lang und ändern sich schnell. Ohne eine aktuelle Stückliste der eingesetzten Software lässt sich innerhalb von 24 Stunden kaum beantworten, ob eine gemeldete Lücke das eigene Produkt überhaupt betrifft.

Bußgelder erst ab Dezember 2027

Die Sanktionsvorschrift des CRA sieht für Verstöße gegen die Herstellerpflichten aus Artikel 13 und die Meldepflichten aus Artikel 14 Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, je nachdem, welcher Betrag höher ist.

Diese Vorschrift wird allerdings erst am 11. Dezember 2027 anwendbar, zusammen mit den übrigen Bestimmungen der Verordnung. Zwischen September 2026 und Dezember 2027 besteht die Pflicht also, ohne dass die CRA-eigene Bußgeldandrohung dahintersteht. Kleinst- und Kleinunternehmen sind zudem dauerhaft von Geldbußen ausgenommen, soweit es um die Verletzung der 24-Stunden-Frist geht; die Meldepflicht selbst bleibt für sie bestehen.

Wer daraus ableitet, die Sache habe Zeit, verschiebt vor allem den Aufbau von Prozessen, die später ohnehin gebraucht werden. Eine Umfrage von ONEKEY unter 200 deutschen Industrieunternehmen für den IoT & OT Cybersecurity Report 2026 zeichnet ein deutliches Bild des Rückstands: 45 Prozent kennen die Anforderungen des CRA kaum oder gar nicht, 60 Prozent können die weiteren Phasen und Fristen nicht benennen. Die 24-Stunden-Meldung nennen 62 Prozent als größte Herausforderung. Nur 18 Prozent geben an, von ihren Zulieferern die nötige CRA-Dokumentation zu bekommen.

Was das für Ihr Unternehmen heißt

• Klären Sie zuerst die Rolle: Sind Sie Hersteller eines Produkts mit digitalen Elementen, oder betreiben Sie einen Dienst? Für eine Software, die Kunden installieren oder als Produkt beziehen, gilt der CRA. Für einen reinen Cloud-Dienst ist eher NIS2 der Maßstab. Viele Anbieter fallen unter beides.
• Benennen Sie eine meldeberechtigte Person und eine Vertretung, bevor der erste Fall eintritt. Eine 24-Stunden-Frist beginnt nicht zwingend an einem Dienstagvormittag.
• Legen Sie fest, wer entscheidet, ob eine Schwachstelle aktiv ausgenutzt wird. Diese Einstufung löst die Frist aus und sollte anhand definierter Kriterien getroffen werden, nicht im Krisenmodus.
• Führen Sie eine Stückliste Ihrer Software, einschließlich der KI-Bibliotheken und Agenten-Komponenten. Ohne SBOM ist die Frage, ob eine fremde Lücke das eigene Produkt betrifft, in 24 Stunden nicht seriös zu beantworten.
• Schauen Sie auf Ihre Bestandsprodukte. Die Meldepflicht gilt auch für Software, die Sie vor dem 11. September ausgeliefert haben und die noch bei Kunden im Einsatz ist.
• Fragen Sie Ihre Zulieferer, wie sie Sie im Ernstfall informieren. Wenn deren Meldung Sie nicht rechtzeitig erreicht, hilft Ihr eigener Prozess wenig.