Cyber Resilience Act: Meldepflicht seit September 2026

Seit dem 11. September 2026 gilt die Meldepflicht des Cyber Resilience Act (CRA). Wer Software oder vernetzte Geräte in der EU anbietet, muss eine aktiv ausgenutzte Schwachstelle im eigenen Produkt innerhalb von 24 Stunden als Frühwarnung melden, nach 72 Stunden folgt die eigentliche Meldung. Gemeldet wird über die Plattform der ENISA, in Deutschland landet die Meldung zusätzlich beim CERT-Bund im BSI. Das betrifft auch Produkte, die längst auf dem Markt sind.

Der Rest des CRA (Security by Design, Updatepflichten, Konformitätsbewertung) greift erst im Dezember 2027. Die Meldepflicht ist der Teil, der schon läuft, und gerade der wird in kleinen Firmen gern auf „machen wir, wenn der CRA kommt“ geschoben.

Diese Einordnung hilft beim Sortieren, ersetzt aber keine rechtliche Prüfung.

Wen trifft die CRA-Meldepflicht?

Der CRA gilt für „Produkte mit digitalen Elementen“, also Software und Hardware, die direkt oder indirekt eine Datenverbindung zu einem Gerät oder Netz haben (Art. 2 und 3 CRA). Das ist bewusst weit gefasst: die App im Store, die Desktop-Software mit Lizenzserver, das Messgerät mit Firmware und Cloud-Anbindung. Entscheidend ist, dass ihr das Produkt im Rahmen einer Geschäftstätigkeit bereitstellt, egal ob gegen Geld oder kostenlos.

Freie Open-Source-Software, die nicht kommerziell bereitgestellt wird, fällt raus. Für sogenannte Open-Source-Stewards, also Organisationen, die freie Software dauerhaft betreuen, gibt es ein leichteres Regime; ihre Meldepflichten beginnen laut EU-Kommission erst am 11. Dezember 2027.

Wichtig für alle, die schon länger Produkte verkaufen: Die meisten CRA-Anforderungen gelten nur für Produkte, die ab Dezember 2027 in Verkehr gebracht (oder wesentlich geändert) werden. Die Meldepflicht ist ausdrücklich ausgenommen. Nach Art. 69 Abs. 3 gilt sie für alle erfassten Produkte, auch die alten.

Kurz zur Abgrenzung, weil es ständig durcheinandergeht: NIS2 trifft Betreiber, also Unternehmen in bestimmten Sektoren, die ihre eigenen Systeme absichern und Vorfälle melden müssen (ob ihr dazugehört, klärt dieser Test). Der CRA trifft Hersteller, und zwar wegen der Produkte, die sie anderen verkaufen. Eine Firma kann beides sein.

Welche Fristen gelten?

Die Uhr startet in beiden Fällen, wenn der Hersteller von der Schwachstelle oder dem Vorfall erfährt (Art. 14 CRA):

„Aktiv ausgenutzt“ heißt: Es gibt verlässliche Hinweise, dass jemand die Lücke tatsächlich ohne Erlaubnis ausgenutzt hat. Eine theoretische Schwachstelle aus dem eigenen Code-Review löst die Pflicht nicht aus. Ein Vorfall ist „schwerwiegend“, wenn er die Fähigkeit des Produkts beeinträchtigt, sensible Daten oder Funktionen zu schützen, oder wenn darüber Schadcode ins Produkt oder in die Systeme eurer Nutzer gelangt ist. Zusätzlich müssen betroffene Nutzer informiert werden, bei Bedarf mit Hinweisen zur Abhilfe (Art. 14 Abs. 8).

Wohin geht die Meldung?

Über die Single Reporting Platform (SRP) der ENISA. Die ist pünktlich zum 11. September gestartet, vorerst als „initial operating capability“. Eine Meldung erreicht gleichzeitig die ENISA und das koordinierende CSIRT des Landes, in dem ihr eure Hauptniederlassung habt. Für deutsche Hersteller ist das laut BSI das CERT-Bund. Registrieren müsst ihr euch vorab nicht, das geht im Ernstfall in wenigen Minuten.

Das klingt beruhigend. Ich würde es trotzdem nicht erst im Ernstfall ausprobieren.

Warum die 24 Stunden das eigentliche Problem sind

Technisch ist eine Frühwarnung nichts: ein Formular, ein paar Angaben, abschicken. Schwer ist, dass die 24 Stunden ab Kenntnis laufen. Und in einer Firma mit acht Entwicklern erfährt es oft eine einzelne Person, per Mail an eine alte Support-Adresse, am Freitagnachmittag.

Die Meldepflicht ist deshalb vor allem ein Organisationsthema. Was ein kleiner Softwarehersteller jetzt braucht, ist überschaubar, muss aber tatsächlich existieren:

1. Ein Weg, von Lücken zu erfahren. Eine erreichbare Security-Kontaktadresse (gern mit security.txt auf der Website) und ein Monitoring eurer Abhängigkeiten. Wer keine Liste hat, welche Bibliotheken in welchem Release stecken, merkt eine ausgenutzte Lücke in einer Abhängigkeit schlicht nicht. Eine SBOM pro Release löst genau das.
2. Ein interner Meldeweg mit Vertretung. Wer entscheidet, ob etwas „aktiv ausgenutzt“ ist? Wer ist dran, wenn diese Person im Urlaub ist? Das muss vorher feststehen, nicht in der Nacht selbst.
3. Eine vorbereitete Frühwarnung. Ein Textbaustein mit Produktbezeichnung, Versionen, Vertriebsländern und Ansprechpartner. Die Frühwarnung soll schnell sein, nicht vollständig.
4. Jemand, der die Plattform schon einmal gesehen hat. ENISA stellt Handbücher und Tutorials bereit. Eine halbe Stunde damit, bevor es brennt, reicht.

Wer Apps oder Software extern entwickeln lässt, sollte das ins Gespräch mit dem Dienstleister mitnehmen: Hersteller im Sinne des CRA seid in der Regel ihr, die Meldung bleibt also bei euch. Umso wichtiger, dass Wartung, Abhängigkeits-Updates und ein Kontaktweg im Vertrag stehen und nicht nur im Kostenvoranschlag für die erste Version.

Was droht bei Verstößen?

Verstöße gegen Art. 14 fallen in die höchste Bußgeldstufe des CRA: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, was höher ist (Art. 64 CRA). Für Kleinst- und Kleinunternehmen sieht Art. 64 Abs. 10 eine Erleichterung bei verpassten 24-Stunden-Frühwarnungen vor; wie weit die genau reicht, lest bitte im Verordnungstext nach, bevor ihr euch darauf verlasst. Die 72-Stunden-Meldung und der Abschlussbericht bleiben ohnehin Pflicht.

Mein Punkt ist ein anderer: Die Bußgelder sind nicht der Grund, das ordentlich aufzusetzen. Der Grund ist, dass eine ausgenutzte Lücke in eurem Produkt ohnehin ein Notfall ist. Die Meldepflicht zwingt euch nur, diesen Notfall vorher einmal durchzuspielen.

Ihr baut Software oder Apps und wollt Meldeweg, SBOM und Update-Prozess einmal sauber aufsetzen? Schreib mir — das ist Teil dessen, wie ich Software entwickle und betreue.