Cyber Resilience Act: Ab 11. September gilt die Meldepflicht – und die Meldestelle steht noch nicht

Ab dem 11. September 2026 müssen Hersteller vernetzter Produkte aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden. Die Plattform dafür war Ende Juli nicht in Betrieb, ihre Adresse ist bis heute unveröffentlicht. Zeitgleich legt die EU-Kommission 84 Seiten Auslegungshilfe vor. Sie beantwortet vier Fragen, an denen bisher jedes Compliance-Projekt hängen blieb.

Der Cyber Resilience Act trat im Dezember 2024 in Kraft, seine Hauptpflichten greifen erst ab dem 11. Dezember 2027. Dazwischen liegt ein Datum, das in vielen Unternehmen noch nicht auf dem Plan steht: der 11. September 2026. Ab diesem Tag greift die Meldepflicht nach Artikel 14, gleichgültig ob ein Produkt neu ist oder seit Jahren im Feld steht.

Am 27. Juli hat die EU-Kommission dazu eine praktische Anleitung veröffentlicht, gedacht für Kleinstunternehmen und Mittelständler ohne eigene Rechtsabteilung. Sie enthält 67 durchgerechnete Beispiele, Anwendungsfälle und Entscheidungsdiagramme.

Rechtlich bindet das Dokument niemanden. Verbindlich auslegen kann die Verordnung nur der Europäische Gerichtshof. Marktüberwachungsbehörden und Prüfstellen werden sich trotzdem daran orientieren. Warum sich die Lektüre für vernetzte Produkte lohnt, zeigen vier Kapitel, an denen sich in der Praxis alles entscheidet.

Was hat die EU-Kommission am 27. Juli veröffentlicht?

Das Paket besteht aus zwei Teilen: einer kurzen Mitteilung und dem eigentlichen Leitfaden als Anhang. Die Kommission hat den Inhalt gebilligt; förmlich annehmen wird sie das Dokument erst, wenn alle Sprachfassungen vorliegen. Am Inhalt ändert das nichts mehr. Es heißt aber, dass der Leitfaden vorerst nur auf Englisch existiert. Wer als deutscher Mittelständler betroffen ist, kämpft sich durch 84 Seiten englisches Verordnungsvokabular.

Der Leitfaden behandelt unter anderem:

• Wann fällt ein Produkt überhaupt unter die Verordnung?
• Wann gehört eine Cloud-Komponente dazu?
• Wie sind freie und quelloffene Software und ihre Pfleger einzuordnen?
• Was gilt als wesentliche Veränderung?
• Wie lange muss ein Produkt unterstützt werden?
• Wie erfüllt ein Hersteller seine Melde- und Risikobewertungspflichten?

Nicht abgedeckt: die technischen Normen, an denen sich Hersteller später messen lassen können. Die entstehen parallel bei den europäischen Normungsorganisationen. Erste Ergebnisse erwartet die Kommission laut ihrem Umsetzungsfahrplan im dritten Quartal 2026.

Wann gehört die Cloud zum Produkt?

Für IoT ist das der wichtigste Abschnitt. Die Verordnung zählt zu einem Produkt mit digitalen Elementen auch dessen Fernverarbeitungslösungen, also Softwareteile, die außerhalb des Geräts laufen. Wo genau diese Grenze verläuft, blieb bisher offen. Der Leitfaden macht daraus eine Prüfung mit zwei Fragen. Beide müssen mit Ja beantwortet werden.

• Erstens: Verlöre das Produkt ohne diese Datenverarbeitung eine seiner Funktionen?
  Die Kommission zählt auf, was darunter fällt: Befehle an ein Gerät senden, Dateien abgleichen, Nutzer einrichten, konfigurieren, Updates und Sicherheitspatches automatisch verteilen, Identitäten und Zugriffe verwalten. Nicht darunter fällt die Fernauswertung von Telemetriedaten, die nur der Statistik oder der künftigen Produktentwicklung dient. Wichtig für Smart-Home-Produkte: Dass sich eine Funktion auch manuell auslösen lässt, etwa Licht per Schalter statt per App, nimmt der App-Steuerung nicht ihre Einstufung als Fernverarbeitung.
  
  
• Zweitens: Wurde die Software vom Hersteller oder in seinem Auftrag entwickelt?
  „In seinem Auftrag“ meint maßgeschneiderte Lösungen nach eigenen Vorgaben, nicht das bloße Lizenzieren eines fertigen Dienstes. Wer die Lösung anschließend betreibt, spielt keine Rolle. Daraus folgt eine merkbare Faustregel: Bei gemieteter Infrastruktur oder gemieteter Entwicklungsplattform, in der Branche als IaaS und PaaS bekannt, erfüllt die darauf laufende eigene Anwendung dieses zweite Kriterium. Bei zugekaufter Fertigsoftware, also SaaS, erfüllt sie es nicht.

Die Kommission rechnet das an Beispielen durch:

Ein smartes Thermostat, dessen App-Steuerung über eine selbst verantwortete Software auf gemieteter Infrastruktur läuft: Fernverarbeitung, gehört dazu. Der Hersteller muss sie und die genutzte Fremdinfrastruktur in der technischen Dokumentation beschreiben, einschließlich Angaben zum beauftragten Dienst. Außerdem muss er sicherstellen, dass die Schutzmaßnahmen des Anbieters ausreichen, etwa indem er sich Nachweise über erfüllte NIS-2-Pflichten geben lässt. NIS 2 ist die EU-Richtlinie, die Betreibern kritischer und wichtiger Dienste eigene Sicherheitsanforderungen vorschreibt.

Ein Industrieroboter, der Kamerabilder an einen selbst entwickelten Clouddienst schickt und von dort Greifbefehle zurückbekommt: dasselbe Ergebnis.

Ein E-Book-Reader, der gekaufte Bücher bei einem fremden Speicherdienst ablegt: Ohne den Dienst funktioniert das Produkt nicht, aber der Dienst stammt nicht vom Hersteller. Er zählt nicht zum Produkt, gilt aber wie eine Zulieferkomponente. Der Hersteller muss die Risiken bewerten und auf der Produktseite gegensteuern: sichere Anmeldung, Verschlüsselung und Integritätsschutz für die Verbindung zum Speicherdienst. Bei Auswahl und Anbindung des Anbieters schuldet er Sorgfalt.

Und die Entwarnung für alle, die mit Konnektivität arbeiten: Das Mobilfunknetz zählt nicht dazu. Ein Smartphone muss sich korrekt mit einem Netz verbinden können. Ob das Netz gerade läuft, sagt nichts darüber aus, ob das Gerät funktioniert. Das Netz überträgt nur, wie ein Ethernet-Kabel oder ein WLAN-Signal. Gegenüber dem Netzbetreiber muss kein Hersteller Sorgfalt nachweisen.

Zwei weitere Grenzziehungen helfen in der Praxis. Auch eine Lösung auf eigenen Servern im Haus kann Fernverarbeitung sein; es geht nicht um Public Cloud. Und erfasst sind nur die Softwaremodule, die eine Produktfunktion tragen, samt ihren Schnittstellen nach außen. Systeme dahinter, mit denen das Produkt nicht direkt spricht, bleiben draußen, ebenso Personalverwaltung, CRM, Build-Pipelines und Penetrationstests.

Wer haftet für Open-Source-Bausteine im Gerät?

Die Erleichterung fällt breiter aus als erwartet: Wer freie Software in sein Produkt einbaut, haftet nicht für deren eigene Konformität, selbst wenn er Code zu ihrer Pflege beisteuert. Ob ein Baustein unter die Verordnung fällt, hängt allein davon ab, ob derjenige, der ihn veröffentlicht, ihn in Verkehr bringt.

Das anschaulichste Beispiel: Ein einzelner Entwickler veröffentlicht ein Projekt frei und stellt einen Spendenlink daneben. Drei Unternehmen bauen es ein und spenden freiwillig, damit die Pflege weiterläuft. Ergebnis: Das Projekt gilt nicht als in Verkehr gebracht, der Entwickler trägt keine Pflichten. Die drei Unternehmen behalten ihre, und die sind konkret. Sie müssen bei Auswahl und Integration Sorgfalt walten lassen, wie Artikel 13(5) es verlangt, und nach Artikel 13(6) Schwachstellen an das jeweilige Projekt melden sowie ihre Sicherheitskorrekturen dorthin zurückgeben.

Die gute Nachricht für die Open-Source-Gemeinde ist damit für Gerätehersteller die schlechte: Die Last verschiebt sich vollständig auf den, der das Gerät verkauft. Wie das die Ökonomie billiger Hardware verändert, hat WeSpeakIoT-Autor Dirk Roebers an dieser Stelle bereits ausführlich kommentiert.

Wann macht ein Firmware-Update aus dem Gerät ein neues Produkt?

Eine wesentliche Veränderung setzt die Konformitätspflichten wieder in Gang. Entscheidend ist nicht der Umfang der Änderung, sondern ob sie das Risikoprofil verschiebt und ob die ursprüngliche Bewertung dieses Risiko schon abdeckte.

Ein Maschinen-Dashboard, das bisher nur anzeigte und nach dem Update Maschinen steuert und nach Störungen neu startet: wesentlich verändert. Sein Zweck hat sich vom Beobachtungswerkzeug zum Steuerungssystem verschoben. Ein Anlagen-Monitoring dagegen, dessen Steuerfunktionen von Anfang an vorhanden, bewertet und lediglich abgeschaltet waren und später freigeschaltet werden: nicht wesentlich verändert.

Umgekehrt genügt manchmal eine Kleinigkeit. Eine Funktion „Angemeldet bleiben“, die Anmeldetoken lokal speichert, gilt als wesentliche Änderung, weil sie neue Risiken einführt: Tokendiebstahl und Sitzungsübernahme, die vorher niemand bewertet hat.

Daraus folgt eine der wenigen echten Handlungsanweisungen des Dokuments. Wer die Risikobewertung vorausschauend schreibt und geplante Funktionen dort schon mitbewertet, spart sich später Konformitätsarbeit.

Wie meldet man ab dem 11. September?

Die Fristenkaskade ist bekannt: Frühwarnung ohne unangemessene Verzögerung, spätestens binnen 24 Stunden. Ausführlichere Meldung binnen 72 Stunden. Vollbericht binnen 14 Tagen, nachdem eine Gegenmaßnahme bereitsteht, bei schweren Vorfällen binnen eines Monats nach der 72-Stunden-Meldung.

Gemeldet wird gleichzeitig an zwei Stellen: an das zuständige nationale CSIRT, die staatliche Reaktionsstelle für IT-Sicherheitsvorfälle, und an die EU-Agentur ENISA. Vier Klarstellungen aus dem Leitfaden grenzen ein, was die Pflicht tatsächlich verlangt.

Die Uhr läuft nicht ab dem ersten Hinweis. Als in Kenntnis gesetzt gilt ein Hersteller erst, wenn er nach einer ersten Prüfung mit hinreichender Sicherheit davon ausgeht, dass jemand eine Schwachstelle aktiv ausnutzt. Die Kommission stützt sich auf dieselbe Auslegung, die für Datenschutzverletzungen unter der DSGVO gilt. Wer die Ersteinschätzung verschleppt, kann sich darauf nicht berufen.

Alte Vorfälle bleiben draußen. Schwachstellen, deren aktive Ausnutzung schon vor dem 11. September 2026 bekannt war, muss niemand nachmelden. Wusste ein Hersteller dagegen nur von der Schwachstelle, nicht von einer Ausnutzung, und tritt diese später ein, greift die Pflicht.

Für Zulieferkomponenten gilt: Enthält das Produkt eine aktiv ausgenutzte Schwachstelle aus einer Fremdkomponente, muss der Hersteller melden. Lässt sich die Schwachstelle in seinem Produkt nicht ausnutzen, etwa weil der betroffene Code gar nicht erreichbar ist, entfällt die Meldung.

Alte Geräte bleiben drin. Nicht rückwirkend gilt die Pflicht nur für Vorfälle, nicht für Produkte: Sie erfasst auch Geräte, die vor dem 11. Dezember 2027 in Verkehr kamen, und sie läuft weiter, nachdem der Supportzeitraum endet. Damit gilt die Formel „altes Gerät, neues Ereignis“. Wer eine Sensorflotte im Feld hat, ist ab September betroffen, ohne dass sich an einem einzigen Gerät etwas ändert.

Und das Werkzeug?

Hier klafft die Lücke. Gemeldet wird über eine zentrale Plattform, die ENISA betreibt und die eine einzige Einreichung an alle zuständigen Stellen weiterleitet.

Nach dem Stand der ENISA-Angaben vom 31. Juli 2026 läuft diese Plattform noch nicht. Ihre öffentliche Adresse gibt die Agentur erst kurz vor dem Start bekannt, und Schnittstellen zur Anbindung eigener Systeme stellt sie in dieser Phase nicht bereit. Gemeldet wird also von Hand.

Zwei weitere Punkte lohnen sich zu wissen. Die Registrierung läuft über ein EU-Login-Konto, das sich schon jetzt anlegen lässt. Von einer Freigabe auf Vorrat rät ENISA jedoch ab: Sie soll erst anlaufen, wenn tatsächlich eine Meldung ansteht, sonst überlasten die Anfragen die prüfenden Stellen.

Und die Liste, welches nationale CSIRT für welchen Hauptsitz zuständig ist, will die Agentur später veröffentlichen. Wer im Ernstfall melden muss, kann heute nicht nachschlagen, an wen. Vorbereiten lässt sich damit nur, was im eigenen Haus liegt: festlegen, wer eine Meldung freigibt, den Ablauf einmal an einem erfundenen Fall durchspielen und klären, welche Angaben in den ersten 24 Stunden überhaupt vorliegen müssen. Zwei Wochen vor dem Start kündigt ENISA ein Webinar an.

Fazit

Der Leitfaden beantwortet die Fragen, an denen interne CRA-Projekte bisher scheiterten, und er tut das erfreulich konkret: mit durchgerechneten Fällen statt mit Prinzipien. Wer sich bislang auf einen unklaren Anwendungsbereich berufen konnte, hat diese Ausrede verloren.

Zugleich zeigt der Zeitpunkt, wie ungleich weit die Bausteine dieser Verordnung gediehen sind. Die Auslegung liegt vor, vorerst nur auf Englisch. Die technischen Normen entstehen noch. Und das eine Werkzeug, das ab dem 11. September zwingend gebraucht wird, ist sechs Wochen vorher nicht erreichbar. Die Frist steht trotzdem.

Praktisch heißt das: Der Ablauf im eigenen Haus muss vor der Plattform stehen. Wer entscheidet, ob gemeldet wird? Wer darf einreichen? Wie erreicht man diese Person am Wochenende? Diese Fragen braucht keine EU-Infrastruktur. Beantworten sollte man sie nicht zum ersten Mal, während die 24 Stunden bereits laufen.

Quellen: C(2026) 5252, Anhang – Leitlinien der Kommission zur Anwendung des Cyber Resilience Act (nur auf Englisch verfügbar) · Verordnung (EU) 2024/2847 · Meldepflichten, EU-Kommission

- Advertisement -