Cyber Resilience Act: Meldepflicht seit 11. September 2026
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden – auch für längst verkaufte Produkte. Welche Software betroffen ist, warum reine Webanwendungen meist nicht und wer bei Auftragsentwicklung meldet.
Was seit dem 11. September 2026 gilt
Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen zwei Dinge melden: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die ihre Produkte betreffen. Grundlage ist Artikel 14 des Cyber Resilience Act, der Verordnung (EU) 2024/2847. Es ist der erste Teil der Verordnung, der für Hersteller verbindlich greift – die übrigen Herstellerpflichten, von der sicheren Grundkonfiguration bis zur CE-Kennzeichnung, gelten erst ab dem 11. Dezember 2027.
Die Reihenfolge überrascht viele. Wer den Cyber Resilience Act bisher als Thema für Ende 2027 eingeplant hat, hat übersehen, dass die Meldepflicht ein gutes Jahr früher kommt und nach Artikel 69 Absatz 3 ausdrücklich auch für Produkte gilt, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Eine App, die seit 2023 im Store steht, ist also heute schon meldepflichtig, obwohl sie die übrigen Anforderungen nie erfüllen musste.
Daraus folgt eine nüchterne Lage: Melden muss ein Hersteller bereits, bevor er die Anforderungen kennen muss, an denen sich seine Software später messen lassen muss. Wer jetzt einen Meldeprozess aufsetzt, baut damit das Fundament, das ab Dezember 2027 ohnehin verlangt wird.
Die Fristen: 24 Stunden, 72 Stunden, 14 Tage
Die Meldung erfolgt in drei Stufen. Binnen 24 Stunden, nachdem der Hersteller von einer aktiv ausgenutzten Schwachstelle Kenntnis erlangt hat, ist eine Frühwarnung fällig – einschließlich der Angabe, in welchen Mitgliedstaaten das Produkt bereitgestellt wird. Binnen 72 Stunden folgt die eigentliche Meldung mit allgemeinen Angaben zum Produkt, zur Art der Ausnutzung und zu bereits ergriffenen oder geplanten Gegenmaßnahmen.
Spätestens 14 Tage, nachdem eine Korrektur oder Abhilfemaßnahme verfügbar ist, folgt der Abschlussbericht: Beschreibung der Schwachstelle, Schweregrad, Auswirkungen und Angaben zum Update. Bei schwerwiegenden Sicherheitsvorfällen gilt für den Abschlussbericht eine Frist von einem Monat nach der Meldung. Die Uhr läuft dabei ab Kenntnis, nicht ab Behebung – wer erst untersucht und dann meldet, ist bei der Frühwarnung bereits zu spät.
Gemeldet wird über die Single Reporting Platform der ENISA, die CRA-SRP; die Meldung geht dort gleichzeitig an die ENISA und an das koordinierende CSIRT des Mitgliedstaats, in dem nach Angabe des BSI die wesentlichen Entscheidungen zur Cybersicherheit des Produkts getroffen werden. Für Deutschland ist das das CERT-Bund im BSI. Eine Registrierung vorab ist nicht nötig. Zusätzlich verlangt Artikel 14 Absatz 8, die betroffenen Nutzer zeitnah über die Schwachstelle und mögliche Schutzmaßnahmen zu informieren – die Behördenmeldung ersetzt die Information der Kunden nicht.
Meldepflichtig ist nicht jede Lücke
Die Meldepflicht greift nur bei aktiv ausgenutzten Schwachstellen, nicht bei jeder Lücke, die ein Hersteller findet. Eine Schwachstelle, die im eigenen Code-Review auffällt und geschlossen wird, bevor jemand sie missbraucht, löst keine Meldung nach Artikel 14 aus. Erst wenn es verlässliche Hinweise gibt, dass ein Angreifer sie tatsächlich nutzt, beginnt die 24-Stunden-Frist.
Ein schwerwiegender Sicherheitsvorfall liegt vor, wenn ein Vorfall die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler Daten oder Funktionen zu schützen – oder wenn er dazu geführt hat oder führen kann, dass Schadcode in das Produkt oder in die Systeme der Nutzer gelangt. Ein kompromittierter Update-Server ist das Lehrbuchbeispiel.
Diese Grenze ist wichtig, weil sie den Aufwand bestimmt. Ein Hersteller, der gut testet und seine Abhängigkeiten aktuell hält, wird selten melden müssen. Wer dagegen nicht weiß, welche Bibliotheken in seinem Produkt stecken, kann eine aktive Ausnutzung weder erkennen noch rechtzeitig melden.
Welche Software betroffen ist
Betroffen ist Software, die als Produkt mit digitalen Elementen in Verkehr gebracht wird – also Software, die beim Nutzer läuft oder ausgeliefert wird. Dazu zählen Desktop-Programme, mobile Apps, Firmware, Browser-Erweiterungen, installierbare Server-Software und kostenpflichtige Plugins für Systeme wie WordPress oder Shopware. Auf die Unternehmensgröße kommt es dabei nicht an.
Erfasst ist außerdem die sogenannte Datenfernverarbeitung nach Artikel 3 Nummer 2: eine vom Hersteller oder in seiner Verantwortung entwickelte Verarbeitung aus der Ferne, ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Das klassische Beispiel nennt Erwägungsgrund 11: die Cloud-Funktion, mit der sich ein Smart-Home-Gerät aus der Ferne steuern lässt. Ebenso erfasst ist das Backend einer App, wenn die App ohne den Zugriff auf eine Schnittstelle oder Datenbank des Herstellers nicht funktioniert.
Für die Praxis ergibt das eine einfache Prüffrage: Gibt es ein Stück Software, das beim Kunden installiert oder ausgeliefert wird? Wenn ja, ist dieses Stück ein Produkt – und alles, was der Hersteller im Hintergrund betreibt, damit es funktioniert, gehört mit dazu.
Reine SaaS und Websites: meist nicht erfasst
Reine Software als Dienst, die ausschließlich im Browser läuft und zu keinem installierten Produkt gehört, fällt in aller Regel nicht unter den Cyber Resilience Act. Erwägungsgrund 12 verweist für Cloud-Dienste wie SaaS, PaaS und IaaS ausdrücklich auf die NIS-2-Richtlinie, und Erwägungsgrund 11 nimmt Websites aus, die keine Funktion eines Produkts unterstützen. Eine Firmenwebsite, ein Blog oder ein Online-Shop sind deshalb keine Produkte im Sinne der Verordnung.
Auch die Kommission zieht die Grenze eng: Nicht als Datenfernverarbeitung gelten nach ihren FAQ Telemetriedaten, die nicht ins Produkt zurückfließen, Websites ohne Produktfunktion und Systeme für den eigenen Betrieb des Herstellers, etwa Lohnabrechnung oder CRM. Wer eine reine Webanwendung betreibt, ist mit der Meldepflicht nach Artikel 14 also typischerweise nicht adressiert.
Das ist die Grenze der Sache, und sie gehört ausgesprochen: Die Ausnahme hängt an der Architektur, nicht am Geschäftsmodell. Bekommt dieselbe Webanwendung eine Desktop-App oder eine mobile App, die ohne das Backend nicht funktioniert, ist das Backend ab diesem Moment Teil eines Produkts – und meldepflichtig. Und wer aus dem Cyber Resilience Act herausfällt, kann trotzdem unter NIS-2 fallen.
Individualsoftware: Wer ist bei einer Auftragsentwicklung Hersteller?
Hersteller ist nach Artikel 3 Nummer 13, wer ein Produkt entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet. Lässt ein Unternehmen eine App von einer Agentur bauen und veröffentlicht sie unter eigenem Namen im Store, ist das Unternehmen Hersteller – mit allen Meldepflichten, auch wenn es keine Zeile Code selbst geschrieben hat.
Anders liegt es bei Software, die ein Unternehmen ausschließlich für den eigenen Gebrauch nutzt. Nach den FAQ der Kommission findet kein Inverkehrbringen statt, wenn ein Produkt nur für die eigene Verwendung hergestellt wird; ein internes Werkzeug fällt damit nicht unter den Cyber Resilience Act, solange es nicht später an andere weitergegeben oder verkauft wird. Für echte Einzelanfertigungen, die auf den Zweck eines bestimmten Geschäftskunden zugeschnitten sind, sieht Anhang I zudem Erleichterungen vor: Von der sicheren Standardkonfiguration darf abgewichen werden, wenn Hersteller und Geschäftskunde das ausdrücklich vereinbaren. Die Kommission verlangt dafür einen dokumentierten Nachweis; eine Standardsoftware mit ein paar Anpassungen gilt nicht als Einzelanfertigung.
Ob eine Agentur, die eine installierbare Software für einen einzelnen Kunden baut, selbst als Hersteller gilt, beantwortet die Verordnung nicht für jeden Fall eindeutig. Die belastbare Antwort ist deshalb vertraglich: Im Entwicklungsvertrag gehört festgehalten, wer das Produkt in Verkehr bringt, wer Schwachstellenmeldungen entgegennimmt und wer innerhalb von 24 Stunden meldet. Eine Lücke an dieser Stelle fällt erst auf, wenn die Frist bereits läuft.
Open Source, Bibliotheken und die SBOM
Freie und quelloffene Software, die ihre Entwickler nicht zu Geld machen, gilt nach den Erwägungsgründen 17 und 18 nicht als Geschäftstätigkeit und fällt damit nicht unter die Herstellerpflichten. Stiftungen, die solche Projekte dauerhaft tragen, unterliegen als Verwalter einem leichteren Regime. Wer eine Open-Source-Bibliothek dagegen in ein Produkt einbaut, das er verkauft, trägt die volle Verantwortung für das Gesamtprodukt – einschließlich der fremden Bausteine.
Deshalb verlangt Anhang I Teil II eine Software-Stückliste, die SBOM: ein maschinenlesbares Verzeichnis aller Komponenten und ihrer Abhängigkeiten. Veröffentlicht werden muss sie nicht; das BSI stellt klar, dass die Verordnung die Erstellung verlangt, nicht die Publikation. Die formalen Anforderungen beschreibt die Technische Richtlinie TR-03183 des BSI.
Die SBOM ist im Kontext der Meldepflicht das wichtigste Werkzeug, auch wenn sie formal erst ab Dezember 2027 vorgeschrieben ist. Wird eine Lücke in einer verbreiteten Bibliothek aktiv ausgenutzt, beantwortet die Stückliste in Minuten, welche eigenen Produkte betroffen sind. Ohne sie beginnt in dem Moment eine Suche, für die 24 Stunden selten reichen.
Was jetzt konkret zu tun ist
Der erste Schritt ist eine Bestandsaufnahme: Welche eigenen Produkte werden installiert oder ausgeliefert, welche Backends gehören zu ihnen, und welche davon sind seit Jahren im Markt? Reine Webanwendungen ohne zugehörige App gehören auf eine eigene Liste, die gegen NIS-2 statt gegen den Cyber Resilience Act geprüft wird.
Für die Produkte auf der ersten Liste braucht es einen Meldeprozess mit Namen: wer Hinweise auf Schwachstellen entgegennimmt, wer entscheidet, ob eine aktive Ausnutzung vorliegt, und wer die Meldung auf der Plattform abgibt – auch am Wochenende. Dazu eine erreichbare Kontaktadresse für Sicherheitshinweise und eine aktuelle SBOM je Produkt, die sich in einer Build-Pipeline automatisch erzeugen lässt.
Bei Verstößen gegen Artikel 14 sieht Artikel 64 Absatz 2 Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Für Kleinst- und Kleinunternehmen schließt Artikel 64 Absatz 10 eine Geldbuße allein für das Versäumen der 24-Stunden-Frist aus – die übrigen Fristen und die Pflicht zur Meldung selbst bleiben bestehen. Die Erleichterung ist also kein Grund, den Prozess aufzuschieben, sondern ein Puffer für die erste Nacht.
Rechtsgrundlagen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act)(öffnet in neuem Tab)Erwägungsgründe 17 bis 19 zur Ausnahme für nicht monetarisierte Open Source
- BSI: Cyber Resilience Act – Meldepflicht startet (11.09.2026)(öffnet in neuem Tab)Meldung über die Single Reporting Platform der ENISA; koordinierendes CSIRT in Deutschland ist das CERT-Bund im BSI