Seit dem 11. September 2026 gilt der erste verbindliche Teil des Cyber Resilience Act (CRA): die Meldepflicht nach Artikel 14. Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, läuft beim Hersteller ab diesem Moment eine feste Uhr.

Das klingt nach einem Thema für Konzerne. Betroffen sind aber auch kleine Softwarehäuser und Freelancer, und für Betreiber in der Produktion ändert sich, wie sie an Informationen kommen.

Die drei Fristen

Sobald ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall hat, gilt ein gestaffeltes Meldeverfahren:

Frist	Meldung	Inhalt
24 Stunden	Frühwarnung	Dass eine Lücke aktiv ausgenutzt wird bzw. ein schwerer Vorfall vorliegt
72 Stunden	Schwachstellenmeldung	Art der Lücke und des Exploits, erste Bewertung, bereits getroffene Maßnahmen und Maßnahmen, die Nutzer selbst ergreifen können
14 Tage nach dem Fix	Abschlussbericht	Ausführlicher Bericht, sobald eine Korrektur verfügbar ist

Bei einem schwerwiegenden Vorfall (statt einer Schwachstelle) ist der Abschlussbericht spätestens einen Monat nach der 72-Stunden-Meldung fällig.

Empfänger sind die EU-Agentur für Cybersicherheit (ENISA) und das zuständige nationale CSIRT. Gemeldet wird über die zentrale Single Reporting Platform der ENISA. Welches CSIRT zuständig ist, richtet sich nach dem Hauptsitz des Herstellers in der EU.

Wichtig: Die Fristen laufen ab Kenntnis, nicht ab dem Zeitpunkt der Meldung auf der Plattform.

Was als „aktiv ausgenutzt“ gilt

Meldepflichtig ist nicht jede Schwachstelle. Es braucht verlässliche Hinweise, dass ein Angreifer die Lücke tatsächlich in einem fremden System ohne Erlaubnis ausgenutzt hat. Eine theoretisch kritische Lücke mit hohem CVSS-Wert allein löst die Pflicht nicht aus.

Auch für Produkte, die schon im Feld sind

Die meisten CRA-Pflichten (Konformität, CE-Kennzeichnung, Security by Design) gelten erst ab dem 11. Dezember 2027 und nur für Produkte, die ab dann neu in Verkehr gebracht werden.

Die Meldepflicht ist die Ausnahme: Sie gilt auch für Produkte, die bereits vorher verkauft wurden. Ein Hersteller kann also für ein altes Produkt meldepflichtig sein, obwohl es von den übrigen Anforderungen ausgenommen ist.

Wer ist „Hersteller“? Auch Softwareentwickler

Im Sinne des CRA ist Hersteller, wer ein Produkt mit digitalen Elementen entwickelt oder herstellt und es unter eigenem Namen oder eigener Marke auf den Markt bringt. Hardware ist dafür nicht nötig. Software allein reicht.

Fall	Hersteller im Sinne des CRA?
Eigene App, Plugin oder Tool, das verkauft wird	ja
Individualsoftware für einen einzelnen Geschäftskunden	ja, mit Sonderregeln: Vertraglich ist einiges anpassbar, sichere Standardkonfiguration und kostenlose Sicherheitsupdates bleiben Pflicht
Kostenlose Open-Source-Software ohne Geschäftsmodell	grundsätzlich nein
Open Source mit kommerziellem Hintergrund	kann darunter fallen, im Einzelfall prüfen
Reiner SaaS-/Cloud-Dienst	in der Regel nein, außer er ist für die Funktion eines Produkts nötig

Gerade kleine Softwarehäuser und Freelancer haben das oft nicht auf dem Schirm. Wer ein WordPress-Plugin, eine Frappe-App oder ein kleines Tool unter eigenem Namen verkauft, ist Hersteller und muss im Ernstfall innerhalb von 24 Stunden melden können.

Wie sichtbar sind die Meldungen für Betreiber?

Hier liegt der Knackpunkt für die Produktion:

Die ersten Meldungen sind nicht öffentlich. Frühwarnung und 72-Stunden-Meldung gehen vertraulich an ENISA und CSIRT. So sollen Angreifer keine Details zu Lücken bekommen, die noch nicht geschlossen sind.
Das CSIRT kann die Weitergabe verzögern, wenn es dafür berechtigte Sicherheitsgründe gibt, etwa ein laufendes koordiniertes Offenlegungsverfahren.
Betreiber erfahren davon über den Hersteller. In der Praxis heißt das: über Security Advisories, Release Notes und Handlungsempfehlungen, meist sobald ein Fix oder eine Mitigation verfügbar ist.

Die Meldepflicht liegt beim Hersteller. Das Lesen und Umsetzen bleibt beim Betreiber.

Ein aktuelles Beispiel: Siemens Software Center

Im Oktober 2026 wurde eine Schwachstelle im Siemens Software Center (CVE-2026-110936, DLL-Side-Loading) aktiv ausgenutzt. Angreifer verteilten eine echte, signierte Kopie mit untergeschobenen DLLs. Siemens hat am 15. Oktober das Advisory SSA-580366 veröffentlicht. Der Fix ist Version 4.0.9.8, Installationen aktualisieren sich beim nächsten Start selbst.

Zeitlich fällt so ein Fall genau in die neue Meldepflicht. Für Betreiber zeigt er, worauf es ankommt: Die Information kam über das Advisory des Herstellers. Wer es nicht verfolgt hat, wusste nichts davon.

Mehr dazu im Beitrag Siemens Patch Day Oktober 2026.

Checkliste

Für Betreiber

Liste der eingesetzten Hersteller und Produkte pflegen (Steuerungen, Software, Edge-Geräte, Engineering-Tools).
Für jeden Hersteller festlegen, wo die Advisories erscheinen (z. B. Siemens ProductCERT, CISA ICS Advisories, BSI WID) und wer sie liest.
Advisories nicht nur nach CVSS bewerten, sondern prüfen: Wird die Lücke aktiv ausgenutzt? Gibt es einen Fix oder nur Mitigations?
Bei Lieferanten nachfragen, wie sie im Ernstfall informieren.

Für Softwareentwickler und kleine Softwarehäuser

Prüfen, ob Sie Hersteller im Sinne des CRA sind.
Zuständiges CSIRT und Zugang zur ENISA Single Reporting Platform klären, bevor es eilt.
Einen Ablauf festlegen: Wer bewertet eine gemeldete Lücke, wer meldet, wer informiert die Kunden?
Einen Kanal für Security Advisories an Ihre Kunden einrichten.
Bei Unsicherheit zu Individualsoftware oder Open Source fachlich beraten lassen, z. B. durch einen Fachanwalt oder die IHK.

Quellen

Hinweis: Dieser Beitrag ist keine Rechtsberatung. Ob und wie Ihr Unternehmen betroffen ist, sollte im Einzelfall geprüft werden.

CRA-Meldepflicht seit 11. September 2026: Was Hersteller, Softwareentwickler und Betreiber wissen müssen