Die meisten Hersteller haben den 11. Dezember 2027 im Blick: das Datum, ab dem alle Anforderungen des Cyber Resilience Acts vollständig gelten. Weniger bekannt ist, dass eine zentrale Pflicht bereits 15 Monate früher greift. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Diese Meldepflicht betrifft nicht nur neue Produkte, sondern auch Produkte, die heute bereits im Einsatz sind.
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) trat am 10. Dezember 2024 in Kraft und sieht einen gestaffelten Zeitplan vor. Die vollständigen Cybersicherheitsanforderungen, von Security by Design über die Software-Stückliste (SBOM) bis zur CE-Kennzeichnung, gelten erst ab Dezember 2027. Die Meldepflichten nach Artikel 14 zieht der Gesetzgeber dagegen auf den 11. September 2026 vor.
Diese Pflicht ist bewusst vorgezogen: Die EU will früh einen Überblick über aktiv ausgenutzte Schwachstellen in vernetzten Produkten gewinnen. Die Meldepflicht ist damit die erste operative Verpflichtung des CRA an Hersteller. Sie greift, bevor Konformitätsbewertungen, technische Dokumentation oder sichere Entwicklungsprozesse formal gefordert werden.
Was gemeldet werden muss
Gemeldet werden müssen zwei Ereignisarten: aktiv ausgenutzte Schwachstellen in Produkten mit digitalen Elementen sowie schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Sicherheit solcher Produkte. Für beide gilt ein gestuftes Verfahren mit festen Fristen, das mit einer Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung beginnt.
Die Meldung läuft gleichzeitig an das zuständige nationale CSIRT und die EU-Agentur für Cybersicherheit (ENISA), und zwar über die einheitliche Meldeplattform, die die ENISA als zentrale Single Reporting Platform aufbaut. Welche Stelle in Deutschland als CSIRT zuständig ist, regelt das CRA-Durchführungsgesetz; vorgesehen ist das BSI.
Die Fristen im Einzelnen, die Empfänger der Meldung und das Meldeverfahren behandelt der Überblick zu den CRA-Meldepflichten im Detail. Dieser Beitrag konzentriert sich auf die Frage, warum die Meldepflicht auch das bestehende Produktportfolio erfasst.
Warum auch Bestandsprodukte unter die Meldepflicht fallen
Hier liegt das zentrale Missverständnis, das bei vielen Herstellern zu beobachten ist. Die übrigen CRA-Anforderungen (sichere Entwicklung, Konformitätsbewertung, CE-Kennzeichnung und weitere) gelten nach Artikel 69 Absatz 2 nicht pauschal für ältere Produkte. Maßgeblich ist der Stichtag 11. Dezember 2027. Produkte mit digitalen Elementen, die vor diesem Zeitpunkt in Verkehr gebracht wurden, also Bestandsprodukte, unterliegen den übrigen Anforderungen nur dann, wenn sie nach diesem Zeitpunkt einer wesentlichen Änderung unterliegen.
Bestandsprodukte sind damit nicht ohne Weiteres aus dem Schneider. Eine wesentliche Änderung ist nach dem CRA eine Änderung nach dem Inverkehrbringen, die sich auf die Konformität mit den grundlegenden Cybersecurityanforderurngen auswirkt oder den bestimmungsgemäßen Zweck ändert. Ein sicherheitsrelevantes Funktionsupdate kann darunter fallen. Dann kann ein älteres Produkt den vollen Anforderungen des CRA unterliegen, obwohl es vor dem Stichtag auf den Markt kam.
Für die Meldepflichten nach Artikel 14 gilt diese Einschränkung ohnehin nicht. Artikel 69 Absatz 3 stellt ausdrücklich klar, dass die Meldepflichten für alle Produkte mit digitalen Elementen gelten, die in den Anwendungsbereich fallen und vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Die Geltung der Meldepflicht für Bestandsprodukte ist also keine Schlussfolgerung, sondern steht direkt im Verordnungstext. Auch Maschinen, Steuerungen, Sensoren oder Software, die bereits ausgeliefert und beim Kunden in Betrieb sind, unterliegen ab September 2026 der Meldepflicht.
Rückwirkend gilt die Pflicht nicht: Schwachstellen, deren aktive Ausnutzung einem Hersteller bereits vor dem 11. September 2026 bekannt war, müssen nicht nachgemeldet werden. Erfährt der Hersteller dagegen erst nach diesem Stichtag von einer aktiven Ausnutzung, greift die Meldepflicht. Diese Klarstellung stammt aus dem zweiten Entwurf der Auslegungs-Leitlinien der EU-Kommission zum CRA (Abschnitt zu den Meldepflichten) und ist als noch nicht final angenommener Stand zu verstehen.
Was das für Hersteller im Maschinen- und Anlagenbau bedeutet
Für Hersteller im Maschinen-, Anlagen- und Gerätebau hat diese Regelung weitreichende Folgen. Das gesamte installierte Portfolio an vernetzten Produkten, von der Steuerung über das Gateway bis zur Softwarekomponente, fällt ab September 2026 unter die Meldepflicht, sofern es sich um Produkte mit digitalen Elementen im Sinne des CRA handelt.
Das setzt voraus, dass Hersteller wissen, welche ihrer Bestandsprodukte betroffen sind, welche Softwarekomponenten in diesen Produkten enthalten sind und über welche Kanäle sie von aktiv ausgenutzten Schwachstellen erfahren. Die 24-Stunden-Frist für die Frühwarnung lässt keinen Raum für Ad-hoc-Prozesse. Wer am 11. September 2026 keine etablierten Abläufe für die Schwachstellenerkennung und -meldung hat, wird die Fristen nicht einhalten können.
Abgrenzung zur NIS-2-Richtlinie
Die Meldepflichten des CRA ergänzen bestehende Meldepflichten unter der NIS-2-Richtlinie, ersetzen diese aber nicht. NIS-2 adressiert die organisatorische Cybersicherheit von Betreibern kritischer Infrastrukturen, Artikel 14 des CRA zielt auf die produktbezogene Meldepflicht der Hersteller. Ein Unternehmen kann parallel unter beide Regelwerke fallen: als Betreiber unter NIS-2 und als Hersteller unter dem CRA. Die Meldepflichten sind nicht identisch und erfordern jeweils eigene Prozesse.
Fazit
Die CRA-Meldepflichten sind die erste verbindliche operative Anforderung des Cyber Resilience Act. Sie gelten ab dem 11. September 2026, und zwar auch für Produkte, die bereits auf dem Markt sind. Wer sich ausschließlich auf den Stichtag im Dezember 2027 vorbereitet, übersieht eine Pflicht, die das gesamte bestehende Produktportfolio betrifft.
Die entscheidende Frage ist nicht, ob ein Hersteller betroffen ist. Bei vernetzten Produkten mit digitalen Elementen ist das in aller Regel der Fall. Die entscheidende Frage ist, ob die internen Prozesse für die Schwachstellenerkennung und -meldung rechtzeitig stehen.
Kommentar hinzufügen