Seit dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle unverzüglich melden, spätestens 24 Stunden nachdem sie davon Kenntnis erlangt haben. Die vollständige Anwendung des CRA folgt im Dezember 2027, die Meldepflicht gilt bereits jetzt.
Das klingt nach einem reinen IT-Thema. Ist es aber nicht. Wer Software entwickelt und verkauft, wer vernetzte Geräte herstellt oder wer Softwareprodukte in seinen Betriebsabläufen einsetzt, ist jetzt Teil eines neuen Compliance-Rahmens. Und weil Datenpannen bei Sicherheitsvorfällen häufig Hand in Hand gehen, berührt der CRA auch die DSGVO direkt.
Was ist der Cyber Resilience Act?
Der Cyber Resilience Act ist eine EU-Verordnung, die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen einheitlich regelt. Gemeint sind Hardware und Software, die mit Netzwerken oder anderen Geräten verbunden werden können. Das reicht von vernetzten Haushaltsgeräten über Industriesteuerungen bis hin zu Unternehmenssoftware.
Ziel ist es, dass Sicherheit nicht nachträglich eingebaut wird, sondern von Anfang an. Hersteller tragen künftig die Verantwortung dafür, dass ihre Produkte über den gesamten Lebenszyklus hinweg sicher bleiben. Dazu gehören Sicherheitsupdates, ein Schwachstellenmanagement und eben: die Meldepflicht.
Zeitplan CRA auf einen Blick:
11. September 2026: Meldepflichten nach Artikel 14 gelten. Und zwar für alle Produkte mit digitalen Elementen am EU Markt, auch für solche, die schon vor diesem Datum verkauft wurden.
11. Dezember 2027: Vollständige Anwendung. Ab dann dürfen nur noch Produkte neu in Verkehr gebracht werden, die alle CRA Anforderungen erfüllen. Produkte, die vorher am Markt waren, fallen nur dann unter die übrigen Pflichten, wenn sie danach wesentlich verändert werden.
Wen trifft die Meldepflicht?
Die Meldepflicht nach Artikel 14 richtet sich an Hersteller von Produkten mit digitalen Elementen. Das sind Unternehmen, die solche Produkte entwickeln, herstellen oder auf dem europäischen Markt anbieten, egal wo der Unternehmenssitz ist.
Konkret betroffen sind unter anderem:
- Softwareunternehmen, die Anwendungen verkaufen oder zum Download anbieten
- Hersteller vernetzter Geräte (IoT, Industriesteuerungen, Smart Home)
- Anbieter von Betriebssystemen, Firewalls, Routern und vergleichbarer Infrastruktur
- Betriebe, die eigene Software oder vernetzte Geräte an Kunden verkaufen oder weitergeben
Nicht erfasst ist reines Software as a Service ohne zugehöriges Produkt. Dafür gelten gegebenenfalls die Pflichten nach NIS2. Erfasst ist Cloud Verarbeitung nur dann, wenn sie Teil eines Produkts ist, etwa die App Cloud einer vernetzten Heizungssteuerung. Ebenfalls nicht erfasst ist Software, die ein Betrieb ausschließlich selbst nutzt.
Die zwei Auslöser der Meldepflicht
Nicht jede Schwachstelle und nicht jeder Vorfall löst die Meldepflicht aus. Der CRA kennt zwei präzise definierte Auslöser.
Auslöser 01
Aktiv ausgenutzte Schwachstelle
Die Meldepflicht greift, wenn verlässliche Anhaltspunkte dafür bestehen, dass Angreifer eine Schwachstelle im eigenen Produkt aktiv ausnutzen. Verlässliche Anhaltspunkte kommen typischerweise aus der Threat Intelligence, der Produkttelemetrie, Kundenmeldungen oder dem Support.
Wichtig: Ein öffentlich bekannter CVE-Eintrag mit Proof of Concept, aber ohne Hinweise auf tatsächliche Ausnutzung, löst die Meldepflicht noch nicht aus. Die Schwachstelle muss aktiv und konkret missbraucht werden.
Auslöser 02
Schwerwiegender Sicherheitsvorfall
Auch ohne eine konkret ausgenutzte Schwachstelle kann ein Vorfall meldepflichtig sein, wenn er die Sicherheit des Produkts erheblich beeinträchtigt. Das klassische Beispiel: Ein Angreifer kompromittiert den Update-Kanal eines Produkts. Es ist noch keine konkrete Schwachstelle im Produkt selbst ausgenutzt worden, aber die Integrität des gesamten Systems steht in Frage.
Der Unterschied zwischen den beiden Auslösern entscheidet über den Weg der Meldung. Ausgenutzte Schwachstellen werden separat erfasst, Vorfälle als eigenständige Kategorie.
Die drei Meldestufen
Sobald ein Auslöser festgestellt ist, beginnt die Uhr zu laufen. Der CRA kennt drei aufeinander aufbauende Meldestufen.
| Meldung | Frist | Mindestinhalt |
|---|---|---|
|
Stufe 1 Frühwarnung |
spätestens 24 Stunden ab Kenntnis | Art des Meldegegenstands, betroffene Mitgliedstaaten, Verdacht auf böswillige Handlung |
|
Stufe 2 Vollständige Meldung |
spätestens 72 Stunden ab Kenntnis | Betroffene Produkte und Versionen, Schweregrad, ergriffene oder geplante Gegenmaßnahmen |
|
Stufe 3 Abschlussbericht |
Schwachstelle: 14 Tage, nachdem eine Korrektur verfügbar ist. Vorfall: 1 Monat nach der Meldung aus Stufe 2 | Ursache, Auswirkungen, umgesetzte Maßnahmen, Details zum Sicherheitsupdate |
Zusätzlich müssen Hersteller die betroffenen Nutzer über die Schwachstelle oder den Vorfall und mögliche Schutzmaßnahmen informieren.
24 Stunden klingt nach wenig. In der Praxis bedeutet das: Ein Meldeprozess muss rund um die Uhr funktionieren. Der Auslöser kommt selten montags um 10 Uhr. Er kommt freitags nachts oder an Feiertagen. Wer keine klaren Verantwortlichkeiten und keinen definierten Entscheidungsprozess hat, wird diese Frist regelmäßig reißen.
Der Meldeweg über die ENISA-Plattform
Meldungen erfolgen über die Single Reporting Platform der ENISA. Die Plattform leitet die Meldung an das als Koordinator benannte CSIRT jenes Mitgliedstaats weiter, in dem der Hersteller seine Hauptniederlassung hat. In Österreich ist das das nationale CSIRT nach dem NISG 2026, in Deutschland das BSI.
Parallelmeldungen nicht vergessen. Die Meldung über die ENISA-Plattform ersetzt keine anderen Meldepflichten. Wer gleichzeitig unter NIS2, DORA oder DSGVO fällt, muss diese Meldewege separat bedienen. Fristen und Adressaten unterscheiden sich teilweise erheblich. Ein koordiniertes Incident-Response-Verfahren, das alle relevanten Meldepflichten gleichzeitig abarbeitet, ist deshalb keine Kür, sondern notwendig.
Was in Österreich zusätzlich gilt
Seit 1. Oktober 2026 ist das NISG 2026 in Kraft, die österreichische Umsetzung der NIS2 Richtlinie. Wesentliche und wichtige Einrichtungen müssen erhebliche Cybersicherheitsvorfälle an ihr sektorspezifisches CSIRT melden, sonst an das nationale CSIRT. Auch hier gilt: Frühwarnung, Meldung, Abschlussbericht nach einem Monat.
Ein nationales Durchführungsgesetz zum CRA gibt es in Österreich noch nicht. Die notifizierende Behörde ist im Bundeskanzleramt angesiedelt, die Marktüberwachung wird erst festgelegt. Die Meldepflicht selbst gilt trotzdem, denn der CRA ist eine EU Verordnung und wirkt direkt.
Die Verbindung zur DSGVO
Ein Sicherheitsvorfall, der CRA-meldepflichtig ist, enthält häufig auch personenbezogene Daten. Damit greift gleichzeitig Artikel 33 DSGVO, der eine Meldung an die zuständige Datenschutzbehörde innerhalb von 72 Stunden vorsieht. Beide Fristen beginnen mit Bekanntwerden des Vorfalls.
Ein Angriff auf die Produktinfrastruktur ist selten nur ein technisches Ereignis. Sobald Kundendaten, Nutzungsprofile oder personenbezogene Metadaten betroffen sind, rückt der Datenschutz in den Vordergrund. Aus der Datenschutzberatungspraxis
Konkret bedeutet das: Wer einen Sicherheitsvorfall nach CRA meldet und dabei feststellt, dass personenbezogene Daten abgeflossen oder kompromittiert wurden, muss parallel die Datenschutzbehörde informieren. In Österreich ist das die Datenschutzbehörde (DSB), in Deutschland die jeweils zuständige Landesbehörde.
Drei Regelwerke, ein Vorfall:
Ein kompromittierter Update Server mit abgeflossenen Kundendaten kann gleichzeitig CRA meldepflichtig sein (ENISA Plattform, 24 Stunden), nach NISG 2026 meldepflichtig (CSIRT, 24 Stunden) und nach DSGVO meldepflichtig (Datenschutzbehörde, 72 Stunden). Ohne abgestimmtes Verfahren fehlt im Ernstfall schlicht die Zeit, alle drei Wege parallel zu bedienen.
Was Unternehmen jetzt konkret aufbauen müssen
Die Meldepflicht entscheidet sich nicht am Gesetzestext, sondern an der Entscheidungsfähigkeit im Ereignisfall. Drei Dinge sind dafür notwendig.
Voraussetzung 01
Klare Verantwortlichkeiten
Fünf Funktionen müssen im Ernstfall besetzt sein: die Koordination (PSIRT-Lead oder vergleichbar), die technische Bestätigung (Engineering), die rechtliche Freigabe (Legal und Compliance), die Kundenkommunikation (Produkt und Support) und die Bewertung nach außen (Kommunikation und Management).
Jede dieser Rollen braucht eine Stellvertretung. Die 24-Stunden-Frist läuft auch dann, wenn die zuständige Person im Urlaub oder krank ist.
Voraussetzung 02
Triage-Kriterien und Entscheidungsmodell
Was ist eine aktiv ausgenutzte Schwachstelle? Was ist ein schwerwiegender Vorfall? Diese Entscheidung muss unter Zeitdruck reproduzierbar getroffen werden können. Ein schriftliches Triage-Modell, das klare Kriterien und Beispiele enthält, ist deshalb kein bürokratischer Aufwand, sondern praktische Notwendigkeit.
Wer diese Entscheidung im Ernstfall ohne Vorbereitung trifft, entscheidet langsam, inkonsistent oder falsch. Alle drei Varianten haben rechtliche Konsequenzen.
Voraussetzung 03
Plattformzugang und Dokumentation
Der Zugang zur ENISA-Meldeplattform muss eingerichtet und getestet sein, bevor der Ernstfall eintritt. Dasselbe gilt für die Meldekanäle nach DSGVO und NIS2. Wer im Ernstfall zum ersten Mal das Formular sucht, hat keine 24 Stunden mehr.
Parallel dazu ist eine laufende Dokumentation aller Meldungen, Fristen und ergriffenen Maßnahmen notwendig, nicht nur um die Behörden zu informieren, sondern auch um im Nachgang nachzuweisen, dass korrekt gehandelt wurde.
Das größere Risiko liegt im Marktzugang
Wer jetzt denkt, Bußgelder seien das eigentliche Problem, unterschätzt den CRA. Die Verordnung enthält einen Mechanismus, der über finanzielle Sanktionen hinausgeht: Produkte ohne nachweisbare Sicherheitsprozesse können vom Markt ausgeschlossen werden. Händler und Plattformbetreiber in der EU müssen ab Dezember 2027 sicherstellen, dass sie nur CRA-konforme Produkte anbieten. Wer nicht liefern kann, verliert Listungen.
Das bedeutet: Die Umsetzung der CRA-Anforderungen ist keine reine Compliance-Übung. Sie ist ein Marktvoraussetzung. Und die Meldepflichten, die seit dem 11. September 2026 gelten, sind der erste sichtbare Teil davon.
Was Ihr Betrieb jetzt prüfen sollte
Die meisten KMU und Handwerksbetriebe sind keine Hersteller im Sinne des CRA. Betroffen sind sie trotzdem, über ihre Lieferanten. Ob Kassensystem, Heizungssteuerung, Zeiterfassung oder Branchensoftware: Wenn Ihr Anbieter seine Pflichten nicht erfüllt, tragen Sie im Ernstfall die Datenpanne. Fünf Fragen helfen bei der Einschätzung:
- Welche Softwareprodukte setzt Ihr Unternehmen ein, die unter den CRA fallen könnten (vernetzte Systeme, Cloud-Dienste, Spezialsoftware)?
- Haben Ihre Softwareanbieter ein nachvollziehbares Schwachstellenmanagement und kommunizieren sie transparent über Sicherheitsvorfälle?
- Sind in Ihren Verträgen mit Softwarelieferanten Melde- und Informationspflichten bei Sicherheitsvorfällen geregelt?
- Ist Ihr eigenes Incident-Response-Verfahren auf mehrere parallele Meldepflichten ausgerichtet (DSGVO plus ggf. NIS2 plus CRA)?
- Wissen Ihre Mitarbeitenden, was zu tun ist, wenn ein Sicherheitsvorfall bekannt wird, und wer die erste Anlaufstelle ist?
Wer diese Fragen sicher mit Ja beantworten kann, ist gut aufgestellt. Wer bei einzelnen Punkten zögert, sollte das als Signal verstehen, die eigene Vorbereitung zu überprüfen.