Kurzantwort: Ab 11. September 2026 muss jeder Hersteller eines Produkts mit digitalen Elementen eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden melden — auch dann, wenn im eigenen Unternehmen nichts passiert ist. Software zählt dabei genauso als Produkt wie Hardware, und von der Pflicht befreit die Unternehmensgröße nicht. Die inhaltlichen Produktanforderungen des Cyber Resilience Act greifen dagegen erst am 11. Dezember 2027.
Rund um Compliance-Fristen entsteht regelmäßig mehr Lärm als Klarheit. Wer als Unternehmer wöchentlich liest, was alles droht und was alles zu tun ist, blendet das Thema irgendwann aus — und übersieht dann die Frist, die tatsächlich für ihn gilt. Dieser Beitrag beantwortet deshalb nur drei Fragen: Wer ist betroffen, was genau ist zu melden, und was muss dafür vorbereitet sein.
Kurz geprüft, in dreißig Sekunden:
- Vertreiben Sie Software oder Hardware?
- Wird sie im Rahmen einer Geschäftstätigkeit abgegeben?
- Kann sie sich mit einem Gerät oder einem Netz verbinden?
Dreimal ja heißt: Die Meldepflicht könnte Sie betreffen. Die genaue Einordnung hängt vom Einzelfall ab — was dabei zählt, steht im nächsten Abschnitt.
Wer meldepflichtig ist — und wer nicht damit rechnet
Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt für „Produkte mit digitalen Elementen“. Artikel 3 Nummer 1 definiert das so:
„Produkt mit digitalen Elementen“ ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden
Software steht damit gleichrangig neben Hardware. Wer eine App vertreibt, vertreibt ein Produkt im Sinne der Verordnung — auch ohne ein einziges Gerät zu bauen. Für die drei häufigsten Konstellationen bedeutet das:
| Was Sie anbieten | Fällt es unter den Cyber Resilience Act? |
|---|---|
| Eine App, dazu ein Backend, das Sie selbst entwickelt haben | Ja — die App und das Backend, soweit die App ohne dieses nicht funktioniert |
| Eine reine Browser-Anwendung, die Sie als Dienst betreiben | Nein — der Cyber Resilience Act greift nicht. Ob NIS-2 greift, ist eine eigene Frage und hängt am Unternehmen, nicht am Produkt |
| Nur eine mobile Website | Nein — eine Website ist kein Produkt im Sinne der Verordnung |
Die erste Zeile stützt sich auf Erwägungsgrund 11. Dort heißt es, eine Fernverarbeitung liege vor, „wenn eine mobile Anwendung den Zugang zu einer Anwendungsprogrammierschnittstelle oder zu einer Datenbank erfordert, die über einen vom Hersteller entwickelten Dienst bereitgestellt wird“ — dieser Dienst fällt dann mit in den Anwendungsbereich. Allerdings nur so weit, wie die App ohne ihn eine ihrer Funktionen nicht erfüllen könnte (Art. 3 Nr. 2).
Die zweite und dritte Zeile stützen sich auf Erwägungsgrund 12:
Dagegen fallen Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen, oder Cloud-Dienste, die außerhalb der Verantwortung eines Herstellers […] entworfen und entwickelt wurden, nicht in den Anwendungsbereich dieser Verordnung. Die Richtlinie (EU) 2022/2555 gilt für Cloud-Computing-Dienste und Cloud-Dienstmodelle wie SaaS (Software as a Service) […].
Praktisch heißt das: Zwei Anbieter mit demselben Geschäftsmodell können unterschiedlich behandelt werden, je nachdem ob sie ihr Angebot zusätzlich als App ausliefern.
Der Cyber Resilience Act prüft das Produkt, NIS-2 prüft das Unternehmen
An dieser Stelle wird häufig etwas vermischt, das getrennt gehört. Die beiden Regelwerke stellen unterschiedliche Fragen.
Der Cyber Resilience Act fragt: Was bringen Sie auf den Markt? Geprüft wird das einzelne Produkt.
NIS-2 fragt: Was ist Ihr Unternehmen? Artikel 2 Absatz 1 der Richtlinie stellt auf „Einrichtungen der in den Anhang I oder II genannten Art“ ab, die als mittlere Unternehmen gelten oder deren Schwellenwerte überschreiten. Maßgeblich sind also Einrichtungsart und Größe — nicht ein Produkt, eine App oder eine Website.
Eine Website macht daher niemanden NIS-2-relevant. Wohl aber kann die Geschäftstätigkeit selbst hineinführen: Anhang I führt unter „Digitale Infrastruktur“ ausdrücklich die „Anbieter von Cloud-Computing-Diensten“ als eigene Einrichtungsart. Wer SaaS als Geschäft betreibt, kann über diese Tür erfasst sein — als Unternehmen mit dieser Tätigkeit, nicht wegen der Auslieferungsform einer einzelnen Software.
Beide Prüfungen sind unabhängig voneinander zu beantworten. Ein Unternehmen kann unter beide Regelwerke fallen, unter eines von beiden oder unter keines. Ob NIS-2 greift, klärt die Betroffenheitsprüfung — sie ersetzt die CRA-Prüfung nicht und umgekehrt.
Größe schützt vor der Pflicht nicht
Die Wirtschaftskammer Österreich hält fest, dass der Cyber Resilience Act keine größenabhängigen Ausnahmen kennt. Ein Zwei-Personen-Softwarehaus mit einer App im Store ist meldepflichtig, ein Konzern ist es ebenso. Bei den Geldbußen sieht die Verordnung allerdings sehr wohl eine Ausnahme für kleine Unternehmen vor — dazu weiter unten.
Ob das auch auf Ihr Produkt zutrifft, entscheidet seine Einstufung, nicht die Unternehmensgröße.
Was gemeldet werden muss — zwei getrennte Fälle
Artikel 14 kennt zwei Auslöser, und sie werden häufig vermengt. Der erste ist die aktiv ausgenutzte Schwachstelle im eigenen Produkt. Der zweite ist ein schwerwiegender Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt. Beide haben eigene Fristen:
| Aktiv ausgenutzte Schwachstelle | Schwerwiegender Sicherheitsvorfall | |
|---|---|---|
| Frühwarnung | 24 Stunden ab Kenntnis | 24 Stunden ab Kenntnis |
| Meldung mit Details | 72 Stunden ab Kenntnis | 72 Stunden ab Kenntnis |
| Abschlussbericht | 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht | ein Monat nach der 72-Stunden-Meldung |
| Fundstelle | Art. 14 Abs. 2 | Art. 14 Abs. 4 |
Die Verordnung formuliert dabei überwiegend „unverzüglich, in jedem Fall aber innerhalb von“ — die genannten Stunden sind also die Obergrenze, nicht der Regelfall.
Schwachstelle und Sicherheitsvorfall sind nicht dasselbe
Die beiden Begriffe werden im Alltag synonym verwendet. Rechtlich sind es zwei verschiedene Dinge.
Eine Schwachstelle ist eine Schwäche im Produkt. Ein Sicherheitsvorfall ist ein Ereignis, das auf die Sicherheit des Produkts durchschlägt. Als schwerwiegend gilt ein Vorfall in zwei Fällen (Art. 14 Abs. 5):
- Er wirkt sich negativ auf die Fähigkeit des Produkts aus — oder kann sich auswirken —, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen.
- Oder er hat dazu geführt — oder kann dazu führen —, dass böswilliger Code ins Produkt oder in das Netz- und Informationssystem eines Nutzers gelangt oder dort ausgeführt wird.
In der Praxis überschneidet sich beides oft. Wird eine Schwachstelle im eigenen Produkt aktiv ausgenutzt, erfüllt das meist auch die Kriterien eines schwerwiegenden Vorfalls. Dann laufen beide Meldestränge parallel — gleicher 24- und 72-Stunden-Takt, aber zwei verschiedene Abschlussberichte.
Deckungsgleich sind sie trotzdem nicht. Ein Vorfall kann auch ohne Produktschwachstelle entstehen. Wird etwa die Entwicklungs- oder Auslieferungskette eines Herstellers kompromittiert, gelangt böswilliger Code ins Produkt, ohne dass dieses selbst eine Schwäche hatte. Der Meldeprozess muss deshalb beide Fälle kennen und darf nicht nur auf „Schwachstelle entdeckt“ ausgelegt sein.
Und wann gilt eine Schwachstelle als „aktiv ausgenutzt“? Die Verordnung definiert das eng: Es braucht „verlässliche Nachweise“ dafür, dass ein böswilliger Akteur sie „ohne Zustimmung des Systemeigners“ ausgenutzt hat (Art. 3 Nr. 42). Ein Verdacht reicht nicht. Ein Proof of Concept reicht nicht. Und der eigene Penetrationstest, der ja mit Zustimmung läuft, löst die Meldepflicht ebenfalls nicht aus.
Auch die eigenen Nutzer müssen informiert werden
Neben den beiden Meldesträngen an die Behörden steht eine dritte Pflicht, die leicht übersehen wird: Der Hersteller muss die betroffenen Nutzer informieren, samt möglicher Gegenmaßnahmen (Art. 14 Abs. 8). Versäumt er das, dürfen die zuständigen CSIRTs die Nutzer selbst informieren.
Wohin gemeldet wird
Die Meldung geht gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA — über eine einheitliche Meldeplattform. Praktisch ist das eine Einreichung, nicht zwei.
Diese Plattform geht laut ENISA erst zum Stichtag in Betrieb. Die Registrierung läuft über ein EU-Login-Konto, das vorab angelegt werden kann. ENISA rät allerdings dazu, den Validierungsprozess erst dann zu starten, wenn tatsächlich eine Meldung ansteht — sonst überlasten die Anfragen die CSIRTs. Beides entspricht dem Stand zum Zeitpunkt der Veröffentlichung dieses Beitrags.
Die gute Nachricht
Am 11. September 2026 greift ausschließlich Artikel 14. Artikel 71 Absatz 2 legt fest:
Diese Verordnung gilt ab dem 11. Dezember 2027. Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.
Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation und die grundlegenden Sicherheitsanforderungen aus Anhang I folgen damit nach heutigem Stand erst Ende 2027. Vorgezogen ist neben Artikel 14 nur Kapitel IV, die Notifizierung von Konformitätsbewertungsstellen — das betrifft den Aufbau der Prüfstellen, nicht die Hersteller. Wer jetzt handelt, muss also nicht den gesamten Cyber Resilience Act umsetzen. Er muss einen Meldeprozess aufsetzen.
Auch die Strafen greifen erst später. Wer gegen die Meldepflichten verstößt, riskiert Geldbußen bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist (Art. 64 Abs. 2). Diese Bestimmung gehört jedoch nicht zu den vorgezogenen. Sie gilt nach heutigem Stand ebenfalls erst ab dem 11. Dezember 2027. Die Meldepflicht selbst besteht davon unabhängig ab dem 11. September 2026.
Für kleine Unternehmen kommt eine Erleichterung dazu. Hersteller, die als Kleinst- oder Kleinunternehmen gelten, sollen von den Geldbußen ausgenommen sein, wenn sie die 24-Stunden-Frist versäumen. Verwalter quelloffener Software sind bei jedem Verstoß ausgenommen (Art. 64 Abs. 10).
Zwei Einschränkungen dazu. Die Ausnahme betrifft nur die Geldbuße, nicht die Pflicht zu melden. Und der Verordnungstext ist an dieser Stelle nicht eindeutig formuliert — die Ausnahme verweist auf Absätze, in denen die Geldbußen für Meldeverstöße gar nicht stehen. Wer sich darauf stützen will, sollte die Reichweite im Einzelfall anwaltlich klären lassen.
Der Unterschied zu NIS-2 liegt nicht bei den Fristen
Die Vermutung liegt nahe, dass der Cyber Resilience Act strenger getaktet ist als NIS-2. Das trifft nicht zu. Artikel 23 Absatz 4 der Richtlinie (EU) 2022/2555 sieht dieselben Stufen vor: 24 Stunden Frühwarnung, 72 Stunden Meldung, Abschlussbericht spätestens einen Monat nach dieser Meldung. Das österreichische NISG 2026 setzt das in § 34 Absatz 2 fristengleich um. Beim vergleichbaren Fall — dem Sicherheitsvorfall — sind beide Regelwerke deckungsgleich.
Die 14-Tage-Frist ist kein Gegenbeispiel. Sie gilt für den Schwachstellenfall, den NIS-2 überhaupt nicht kennt. Und ihre Uhr startet nicht mit der Meldung, sondern erst, wenn eine Korrekturmaßnahme verfügbar ist.
Zwei Unterschiede sind dagegen real.
Die Auslöseschwelle liegt niedriger. NIS-2 setzt einen erheblichen Sicherheitsvorfall in der eigenen Einrichtung voraus. Der Cyber Resilience Act verlangt die Meldung schon dann, wenn der Hersteller Kenntnis davon erlangt, dass eine Schwachstelle in seinem Produkt irgendwo aktiv ausgenutzt wird. Im eigenen Haus muss dafür nichts geschehen sein.
Der betroffene Kreis ist ein anderer. NIS-2 und das NISG 2026 knüpfen an Einrichtungsart und Unternehmensgröße an, mit einzelnen größenunabhängigen Ausnahmen. Der Cyber Resilience Act knüpft an die Herstellereigenschaft an, unabhängig von der Größe. Ein kleiner Softwarehersteller kann damit meldepflichtig sein, ohne je in den Anwendungsbereich von NIS-2 zu fallen.
Wer beiden Regelwerken unterliegt, sollte den Meldeprozess deshalb einmal bauen und beide Kanäle darin abbilden — die Abläufe unterscheiden sich weniger als die Zuständigkeiten. Wie die 24-Stunden-Frist im NIS-2-Kontext praktisch abläuft, ist im Beitrag zur NIS-2-Meldepflicht beschrieben.
Was bis zum Stichtag vorbereitet sein muss
Die 24-Stunden-Frist ist keine technische, sondern eine organisatorische Anforderung. Entscheidend ist, dass im Ernstfall niemand erst klären muss, wer entscheidet und wohin gemeldet wird. Als Rahmen dafür beschreibt ISO/IEC 27035-1:2023 einen strukturierten Ansatz für Vorbereitung, Erkennung, Meldung, Bewertung und Reaktion auf Sicherheitsvorfälle.
Für die praktische Umsetzung genügt in vielen Unternehmen eine einzige Seite — eine Notfallkarte, die griffbereit liegt und auch dann funktioniert, wenn die IT nicht erreichbar ist. Die Wirtschaftskammer Österreich stellt dafür eine Checkliste bereit. Angelehnt daran, mit dem ersten Punkt „Ruhe bewahren“ vorweg:
- Intern informieren — Sicherheitsverantwortliche, Datenschutzbeauftragte, IT-Betrieb, Geschäftsleitung
- Krisenstab etablieren — wer entscheidet, wer macht was bis wann
- Informationen sammeln — was ist passiert, wie wurde es entdeckt, welche Leistungen sind betroffen
- Kommunikation koordinieren — eine benannte Person spricht nach außen
- Meldepflichten prüfen — Datenschutzbehörde, NIS-Meldestelle, Cyberversicherung, gegebenenfalls Strafanzeige
- Externe Unterstützung holen — die WKO-Cybersecurity-Hotline 0800 888 133 ist kostenlos und rund um die Uhr erreichbar
- Nachbereiten — aus dem Vorfall lernen
Für Hersteller kommt ab dem 11. September 2026 ein Punkt hinzu, den diese Checkliste noch nicht abdeckt: Schritt 5 muss den Cyber Resilience Act mit aufnehmen. Die Meldung an CSIRT und ENISA läuft über die einheitliche Meldeplattform und ist ein eigener Kanal neben der Datenschutzbehörde und der NIS-Meldestelle. Auf die Notfallkarte gehört deshalb, wer das EU-Login-Konto hält und wer die Meldung absetzen darf.
Ein Punkt aus der Praxis steht trotzdem an erster Stelle, obwohl er mit dem Cyber Resilience Act nichts zu tun hat: ein funktionierendes Backup samt geprüftem Wiederanlaufplan. Die Verordnung verlangt das nicht — sie verlangt eine Meldung. Ohne wiederherstellbare Systeme nützt die fristgerechte Meldung dem Unternehmen aber wenig.
Wo ein Unternehmen dabei tatsächlich steht, zeigt eine strukturierte Analyse des Ist-Zustands. Welche Regelwerke überhaupt greifen, klärt die Beratung vorab.
Häufige Fragen
Gilt der Cyber Resilience Act auch für Software, die kostenlos abgegeben wird?
Ja, sofern die Abgabe im Rahmen einer Geschäftstätigkeit erfolgt. Die Verordnung stellt ausdrücklich auf die „entgeltliche oder unentgeltliche Abgabe“ ab (Art. 3 Nr. 22). Nicht der Preis entscheidet also, sondern der geschäftliche Zusammenhang.
Was gilt für freie und quelloffene Software?
Für Verwalter quelloffener Software gilt ein eigenes, leichteres Regime. Gemeint sind damit juristische Personen, die selbst keine Hersteller sind, die Entwicklung solcher Produkte aber systematisch unterstützen — etwa Stiftungen. Sie brauchen eine dokumentierte Cybersicherheitsstrategie. Melden müssen sie, soweit sie an der Entwicklung beteiligt sind. Geldbußen treffen sie nicht. (Art. 3 Nr. 14, Art. 24, Art. 64 Abs. 10)
Muss gemeldet werden, wenn die Schwachstelle bekannt, aber noch nicht ausgenutzt ist?
Nein. Artikel 14 Absatz 1 knüpft ausdrücklich an die aktiv ausgenutzte Schwachstelle an. Eine bekannte, aber nicht ausgenutzte Schwachstelle löst die Meldepflicht nach dieser Bestimmung nicht aus.
Gilt die Meldepflicht auch, wenn der Vorfall bei einem Kunden aufgetreten ist?
Ja. Artikel 14 Absatz 1 stellt darauf ab, dass die Schwachstelle im Produkt enthalten ist und der Hersteller von ihrer aktiven Ausnutzung Kenntnis erlangt. Wo die Ausnutzung stattfindet, ist für die Meldepflicht nicht maßgeblich.
Bedeutet „innerhalb von 24 Stunden“, dass man 24 Stunden Zeit hat?
Nein. Die Verordnung formuliert „unverzüglich, in jedem Fall aber innerhalb von 24 Stunden“. Die 24 Stunden sind die äußerste Grenze; gemeldet werden muss, sobald es möglich ist.
Kann die Behörde nach der Meldung weitere Berichte verlangen?
Ja. Nach Artikel 14 Absatz 6 kann das als Koordinator benannte CSIRT, das die Meldung ursprünglich erhalten hat, einen Zwischenbericht über den Stand anfordern — zusätzlich zu Frühwarnung, Meldung und Abschlussbericht.
Reicht ein bestehender Notfallplan aus dem Datenschutz?
Als Grundgerüst ja, als vollständige Lösung nicht. Ein auf die Datenschutz-Grundverordnung ausgerichteter Plan kennt die Datenschutzbehörde als Meldestelle, nicht die einheitliche Meldeplattform des Cyber Resilience Act. Der Meldeweg ist zu ergänzen, die Struktur kann bleiben.
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Art. 2, Art. 3, Art. 14, Art. 71, Erwägungsgründe 11 und 12 — EUR-Lex
- Richtlinie (EU) 2022/2555 (NIS-2), Art. 2, Art. 23, Anhang I — EUR-Lex
- Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026), § 34 — RIS
- Wirtschaftskammer Österreich, Cyber Resilience Act — Übersicht — wko.at
- Wirtschaftskammer Österreich, „Ich habe einen Vorfall“ — Checkliste — wko.at
- ENISA, Single Reporting Platform — Frequently Asked Questions — enisa.europa.eu
- ISO/IEC 27035-1:2023, Information security incident management — Part 1: Principles and process — iso.org
