Der Cyber Resilience Act meldet ab September, repariert wird erst 2027

Am 11. September 2026 wird ein einzelner Artikel der Cyberresilienz-Verordnung wirksam: Artikel 14, die Meldepflicht. Wer ein Produkt mit digitalen Elementen unter eigenem Namen verkauft, muss von diesem Tag an binnen 24 Stunden melden, wenn eine Schwachstelle darin aktiv ausgenutzt wird.

Alles andere, woran man beim Cyber Resilience Act zuerst denkt, gilt an diesem Tag noch nicht: keine CE-Kennzeichnung, keine Stückliste der verbauten Software, kein festgelegter Unterstützungszeitraum, keine Marktüberwachung. Das kommt am 11. Dezember 2027.

Diese Reihenfolge klingt nach einer Erleichterung. Sie ist das Gegenteil, und der Grund steht in Artikel 69.

Der Denkfehler: „Der CRA gilt doch erst 2027"

Die Verordnung nimmt Altprodukte ausdrücklich aus. Was vor dem 11. Dezember 2027 in Verkehr gebracht wurde, muss die Sicherheitsanforderungen nicht erfüllen, solange es nicht wesentlich geändert wird. So steht es in Artikel 69 Absatz 2.

Absatz 3 desselben Artikels macht davon eine Ausnahme, und es ist die entscheidende: Die Meldepflichten aus Artikel 14 gelten für alle Produkte im Anwendungsbereich, auch für die, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Der Leitfaden, den die EU-Kommission am 27. Juli 2026 dazu veröffentlicht hat, zieht die Konsequenz in aller Deutlichkeit: Die Meldepflicht besteht auch dann fort, wenn ein Produkt nicht mehr unterstützt wird. Für ein solches Produkt muss der Hersteller melden, ist aber nicht verpflichtet, die Schwachstelle nach Anhang I zu behandeln.

Die Kommission beschreibt in ihren Antworten auf häufige Fragen sogar, warum das oft gar nicht mehr ginge: Werkzeuge zum Prüfen alter Softwarestände existieren womöglich nicht mehr, Bauumgebungen für alten Quellcode lassen sich nicht wiederherstellen, Abhängigkeiten sind nicht mehr verfügbar, und die Leute, die den alten Code kannten, arbeiten längst woanders. Trotzdem, wörtlich: Für solche Produkte müssen Hersteller die Schwachstelle oder den Vorfall melden.

Zusammengefasst: Ab September muss man binnen 24 Stunden über Produkte berichten, die man nicht mehr pflegen muss, nicht mehr bauen kann und teils gar nicht mehr verkauft. Die Pflicht zu melden kommt fünfzehn Monate vor der Pflicht, sicher zu sein, und sie erfasst genau den Bestand, den die Sicherheitspflicht verschont.

Wer seinen Fahrplan an „ab 2027" ausrichtet, plant den einzigen Termin weg, der 2026 schon zählt.

Und die Entlastung, die genauso wenig bekannt ist

Rückwirkend gemeldet werden muss nichts. Der Leitfaden sagt ausdrücklich, dass die Verordnung keine rückwirkende Meldung verlangt: Was dem Hersteller vor dem 11. September 2026 als aktiv ausgenutzt bekannt war, bleibt draußen.

Der Haken daran ist ein praktischer. Wusste jemand von der Schwachstelle, aber nicht von ihrer Ausnutzung, und erfährt er die Ausnutzung erst danach, greift die Pflicht. Wer die Entlastung nutzen will, braucht deshalb einen belegbaren Kenntnisstand zum 10. September. Ein Vermerk, der festhält, was man an diesem Tag wusste, kostet eine Stunde und ist im Zweifel das einzige, was zählt.

Sind wir überhaupt betroffen?

Die Frage lässt sich in drei Schritten beantworten, und die Reihenfolge zählt.

Erstens: Bringen wir ein Produkt mit digitalen Elementen in Verkehr? Software oder Hardware, bereitgestellt auf dem Markt, deren Zweck oder vorhersehbare Nutzung eine Datenverbindung einschließt. Die Verbindung darf direkt oder indirekt sein, und sie muss nicht ständig bestehen: Auch Software, die nur zum Aktualisieren oder zum Austausch von Daten ins Netz geht, ist erfasst. Praktisch bleibt wenig übrig, was gar keine Verbindung hat. Was ausschließlich für den Eigenbedarf entsteht, fällt nicht darunter. Die Kommission stellt das in ihren Antworten klar: Ein Werkzeug, das ein Unternehmen für sich selbst baut, ist nicht in Verkehr gebracht, solange es nicht als eigenes Produkt vertrieben wird.

Zweitens: Steht unser Name darauf? Hersteller ist, wer ein Produkt entwickelt oder entwickeln lässt und es unter seinem Namen oder seiner Marke vermarktet, entgeltlich oder unentgeltlich. Der eigene Name ist das Merkmal, nicht die eigene Programmierarbeit. Wer fremde Bauteile zu einem Gerät zusammensetzt und dieses unter eigener Marke ausliefert, ist Hersteller des Gesamtprodukts, so ausdrücklich der Leitfaden.

Drittens: Ändern wir fremde Produkte wesentlich und geben sie weiter? Dann gilt man als Hersteller des geänderten Teils. Beide Voraussetzungen müssen zusammenkommen. Ändern für den eigenen Gebrauch genügt nicht.

Wer alle drei Fragen mit Nein beantwortet, ist nicht meldepflichtig. Das gilt für die allermeisten Unternehmen, die IT einsetzen statt sie zu verkaufen.

Wer trotzdem hineinrutscht: Maschinen- und Anlagenbauer mit eigener Steuerungssoftware. Wer eine App anbietet, die auf einem Gerät installiert wird. Wer Geräte unter eigener Marke weiterverkauft. Alle drei denken selten zuerst an eine Cybersicherheitsverordnung, und alle drei tragen in ihrem Bestand Produkte von vor 2027.

Und wer gerade nicht hineinrutscht, obwohl es naheliegt: Wer einen reinen Webdienst betreibt, ein Kundenportal etwa oder eine Anwendung, die nur im Browser läuft. Solche Dienste fallen nach Erwägungsgrund 12 nicht unter den Cyber Resilience Act. Die Verordnung nennt als Gegenbeispiel ausdrücklich eine Website, die keinem Produkt zuarbeitet.

Der Erwägungsgrund verweist für Cloud-Dienste auf NIS2. Das heißt aber nicht, dass dort automatisch eine Pflicht entsteht: NIS2 greift nur, wenn der Betreiber selbst in einen der erfassten Sektoren fällt und die Größenschwellen erreicht. Wer beides nicht tut, unterliegt weder der einen noch der anderen Meldepflicht.

Die Grenze verläuft dort, wo ein Dienst zum Bestandteil eines Produkts wird. Steuert eine Cloud-Funktion ein Gerät fern, ohne die es eine seiner Funktionen nicht erfüllen könnte, ist sie Teil des Produkts und fällt mit darunter. Ein Portal, das nur Daten anzeigt, tut das nicht.

Was ein Systemhaus tut, und was nicht

Für den Fall, dass ein Dienstleister im Spiel ist, hat die Kommission in ihrem Leitfaden ein Beispiel aufgenommen, das die Grenze zieht.

Wer technische Unterstützung zu einer Software leistet, die nicht in seiner Verantwortung liegt, bringt diese Software nicht in Verkehr, solange er sie nicht wesentlich ändert. Das genannte Beispiel: Ein Dienstleister veröffentlicht die Software nicht, sondern hilft dem Kunden, sie auf dessen Server zu installieren, ohne sie wesentlich zu ändern. Er gilt damit nicht als jemand, der sie in Verkehr bringt.

Für die Praxis heißt das:

• Installieren, einrichten, betreiben, überwachen, schulen und patchen sind Dienstleistungen. Kein Inverkehrbringen, keine Herstellerpflicht.
• Wesentlich ändern und weitergeben macht zum Hersteller des geänderten Teils.
• Ein eigenes Produkt bauen und unter eigenem Namen ausliefern macht zum Hersteller des Ganzen.

Auch die Erwartung, „maßgeschneidert" befreie von der Verordnung, trägt nicht. Der Sonderstatus erlaubt nur, von zwei einzelnen Anforderungen vertraglich abzuweichen: der sicheren Voreinstellung und den kostenlosen Sicherheitsaktualisierungen. Und eine Standardsoftware, die an viele Kunden verkauft und dabei leicht angepasst wird, ist nach ausdrücklicher Aussage der Kommission nicht maßgeschneidert.

Was gemeldet werden muss, und was nicht

Es gibt zwei Auslöser, nicht einen. Der zweite wird regelmäßig übersehen.

Der erste ist die aktiv ausgenutzte Schwachstelle. Aktiv ausgenutzt heißt: Es liegen verlässliche Nachweise dafür vor, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Eigentümers ausgenutzt hat. Ein Fund aus einem beauftragten Penetrationstest ohne solchen Nachweis ist keine aktiv ausgenutzte Schwachstelle. Dasselbe gilt für einen Fund aus einem Belohnungsprogramm. Beides darf freiwillig gemeldet werden, muss aber nicht.

Der zweite ist der schwerwiegende Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt. Gemeint ist damit etwas anderes als eine Lücke im Produkt: Es geht um die eigenen Entwicklungs-, Herstellungs- oder Wartungsvorgänge. Der Musterfall aus den Erwägungsgründen ist ein Angreifer, der Schadcode erfolgreich in den Kanal einschleust, über den der Hersteller seine Sicherheitsaktualisierungen ausliefert.

Zu Bauteilen von Zulieferern: Steckt die ausgenutzte Schwachstelle in einer eingekauften Komponente, meldet der Hersteller des Endprodukts, und der Hersteller der Komponente ebenfalls, sofern sie eigenständig in Verkehr gebracht wurde. Ist die Schwachstelle im eigenen Produkt gar nicht ausnutzbar, weil der betroffene Code dort nicht erreichbar ist, entfällt die Meldepflicht. Die Meldung an den Zulieferer bleibt davon unberührt.

Wann die Uhr zu laufen beginnt

Der Leitfaden vom Juli 2026 beantwortet die Frage, die vorher offen war: Kenntnis liegt vor, wenn nach einer unverzüglichen Erstbewertung ein vernünftiges Maß an Gewissheit besteht, dass eine Schwachstelle im eigenen Produkt aktiv ausgenutzt wird oder ein schwerwiegender Vorfall die Produktsicherheit beeinträchtigt hat.

Die Betonung liegt auf unverzüglich. Die Uhr lässt sich nicht dadurch anhalten, dass man die Bewertung liegen lässt.

Danach gelten drei Stufen:

• Frühwarnung binnen 24 Stunden. Sie ist kurz. Verlangt werden Hersteller, Produkt, Titel, und, sofern bekannt, die Mitgliedstaaten, in denen das Produkt bereitgestellt wurde.
• Meldung binnen 72 Stunden. Jetzt kommen Art der Ausnutzung, Art der Schwachstelle, ergriffene Maßnahmen, Empfehlungen für Nutzer und eine Einstufung der Sensibilität dazu.
• Abschlussbericht. Bei einer Schwachstelle spätestens 14 Tage, nachdem eine Abhilfe zur Verfügung steht. Bei einem Vorfall innerhalb eines Monats nach der 72-Stunden-Meldung.

Der Unterschied bei der letzten Stufe ist leicht zu übersehen: Bei Schwachstellen läuft die Frist ab Verfügbarkeit der Lösung, bei Vorfällen ab der vorangegangenen Meldung.

Dazu kommt eine Pflicht, die keine Frist trägt, aber Vorbereitung braucht: Der Hersteller muss die betroffenen Nutzer informieren. Eine Veröffentlichungspflicht ist das nicht; der Leitfaden stellt klar, dass die Information auf die betroffenen Kunden beschränkt bleiben darf.

Wohin gemeldet wird, und warum das BSI-Portal nicht der Weg ist

Die Meldung geht gleichzeitig an zwei Stellen: an das als Koordinator benannte nationale CSIRT und an die ENISA. Für Hersteller mit Hauptniederlassung in Deutschland ist das CSIRT das BSI.

Der Weg dorthin ist aber nicht das bekannte BSI-Meldeportal. Das ist das Portal für NIS2. Für den Cyber Resilience Act baut die ENISA eine eigene Plattform, über die alle Meldungen laufen, und deren nationale Endpunkte die CSIRTs bedienen.

Drei Dinge dazu, die man vor September wissen sollte:

• Die Plattform soll zum 11. September einsatzbereit sein. Ihre öffentliche Adresse war Anfang August noch nicht veröffentlicht.
• Gemeldet wird über benannte Vertreter mit einem EU-Login-Konto. Dieses Konto lässt sich jederzeit vorab anlegen.
• Die ENISA rät ausdrücklich davon ab, sich vorsorglich auf der Plattform zu registrieren, um die Prüfung durch die CSIRTs nicht zu überlasten. Erst im Meldefall.
• Eine Schnittstelle für automatisierte Meldungen wird es zum Start nicht geben. Wer viele Produkte führt, braucht dafür Menschen, keine Anbindung.

NIS2 und der CRA sind zwei Pflichten, nicht eine

Beide verlangen Meldungen, und beide arbeiten mit 24 und 72 Stunden. Sie treffen aber unterschiedliche Adressaten und laufen über getrennte Wege.

NIS2 trifft Einrichtungen bestimmter Sektoren ab einer bestimmten Größe und fragt nach erheblichen Störungen der Diensterbringung. Der CRA trifft Hersteller und fragt nach der Sicherheit eines Produkts. NIS2 wird in Deutschland an die gemeinsame Meldestelle von BSI und BBK gemeldet, der CRA an die ENISA-Plattform.

Eine Anrechnungsregel gibt es nicht. Die Verordnung legt den Mitgliedstaaten lediglich nahe, zentrale Anlaufstellen einzurichten. Das ist eine Empfehlung, keine Vorschrift.

Praktisch überschneiden sich beide in genau einem Fall: Ein Unternehmen ist zugleich NIS2-Einrichtung und Hersteller, und ein Vorfall trifft beides. Ein kompromittierter Aktualisierungsweg zum Beispiel stört den eigenen Betrieb und beeinträchtigt die Produktsicherheit. Dann ist zweimal zu melden, über zwei Kanäle, mit teils verschiedenen Abschlussfristen.

Für alle anderen gilt: Eine ausgenutzte Lücke im eigenen Produkt ohne Störung des eigenen Betriebs ist ein reiner CRA-Fall. Ein Verschlüsselungsangriff auf die Verwaltungs-IT ohne Produktbezug ist ein reiner NIS2-Fall.

Was mit den Bußgeldern ist

Der Rahmen ist hoch: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist, unter anderem für Verstöße gegen Artikel 14.

Nur greift er im September noch nicht. Der Sanktionsartikel steht in einem Kapitel, das erst am 11. Dezember 2027 anwendbar wird, ebenso die Marktüberwachung. Der deutsche Gesetzentwurf lässt die entsprechenden Vorschriften folgerichtig ebenfalls erst 2027 in Kraft treten.

Die Pflicht besteht trotzdem ab September. Nur der Apparat, der sie durchsetzt, arbeitet noch nicht. Wer daraus ableitet, man könne den Termin ignorieren, verwechselt zwei Dinge: dass etwas gilt, und dass es sanktioniert wird.

Für Kleinst- und Kleinunternehmen gibt es eine Ausnahme, aber eine schmalere als oft berichtet: Sie betrifft ausschließlich die Nichteinhaltung der 24-Stunden-Frist, nicht die Meldepflicht selbst, und sie gilt nicht für mittlere Unternehmen.

Was bis zum 11. September zu tun ist

• Die eigene Rolle feststellen und aufschreiben. Die drei Fragen von oben, für jedes Produkt einmal beantwortet. Auch ein Nein gehört dokumentiert, weil Kunden und Prüfer danach fragen werden.
• Eine Produktliste anlegen, und zwar mit den Ländern. In welchen EU-Mitgliedstaaten wurde jedes Produkt bereitgestellt? Diese Angabe gehört in die 24-Stunden-Frühwarnung. Sie im Ernstfall zu recherchieren, kostet mehr Zeit, als die Frist hergibt.
• EU-Login-Konten anlegen für die Personen, die im Fall der Fälle melden. Mindestens zwei, mit klarer Vertretungsregelung. Nicht vorab auf der Plattform registrieren.
• Einen Bewertungsschritt einführen, der den Fristbeginn festhält. Wer den Zeitpunkt nicht dokumentiert, an dem die Gewissheit entstand, kann später weder die Einhaltung noch die Rechtzeitigkeit belegen.
• Eine Anlaufstelle für Schwachstellenmeldungen einrichten. Formal erst 2027 Pflicht, praktisch der Weg, über den man ab September überhaupt erst Kenntnis erlangt.
• Zulieferer vertraglich verpflichten, unverzüglich über aktive Ausnutzung zu informieren. Ohne das erfährt man zu spät von etwas, das man selbst melden muss.
• Den Kenntnisstand zum 10. September festhalten. Siehe oben: die Entlastung für Altfälle trägt nur, wenn sie belegbar ist.

Was das für ein Unternehmen konkret bedeutet

• Wer IT nur einsetzt: nicht betroffen. Sinnvoll ist trotzdem, die eigene Rolle sauber zu dokumentieren und CRA-Konformität in die Anforderungen an Lieferanten aufzunehmen. Ab Ende 2027 wird sie an der CE-Kennzeichnung sichtbar.
• Wer ein Produkt unter eigenem Namen verkauft: betroffen, ab September, auch für Altprodukte. Der Aufwand bis dahin liegt in der Vorbereitung, nicht in der Technik.
• Wer Software für andere anpasst oder betreibt: in aller Regel nicht Hersteller. Die Grenze verläuft bei der wesentlichen Änderung, die weitergegeben wird.
• Wer beides ist, NIS2-Einrichtung und Hersteller: zwei Meldewege, getrennt vorbereiten.

Wo wir helfen

Wir klären mit Ihnen, ob und für welche Produkte Sie Hersteller im Sinne der Verordnung sind, halten das Ergebnis belegbar fest und bauen den Meldeweg so auf, dass er die 24 Stunden trägt. Wie das mit einer bestehenden NIS2-Pflicht zusammenspielt, klären wir im selben Zug. Ein erstes Gespräch geht auf uns.

Quellen

• Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung), insbesondere Artikel 3, 13, 14, 22, 64, 69 und 71
• Europäische Kommission, Leitfaden zur Anwendung der Verordnung (EU) 2024/2847, C(2026) 5252, 27. Juli 2026
• Europäische Kommission, Antworten auf häufige Fragen zur Umsetzung des Cyber Resilience Act, Stand 2. Juli 2026
• ENISA, Single Reporting Platform, Antworten auf häufige Fragen, Stand 3. August 2026
• BSI, Cyber Resilience Act
• Entwurf eines Cyberresilienz-Durchführungsgesetzes, Bundestagsdrucksache 21/6134

Stand: 23. August 2026. Das deutsche Durchführungsgesetz ist zu diesem Zeitpunkt im parlamentarischen Verfahren, die erste Lesung war am 11. Juni 2026. Die Adresse der ENISA-Meldeplattform war Anfang August noch nicht veröffentlicht. Vor einer Entscheidung im eigenen Haus gehört der aktuelle Stand dort nachgesehen.