CRA Response Center Demo anfragen

Leitfaden Stand Lesezeit 10 Min.

Schwerwiegender Sicherheitsvorfall nach CRA: Abgrenzung mit Beispielen

Der zweite Auslöser der Meldepflicht trifft nicht das Produkt beim Kunden, sondern meist den Hersteller selbst: Update-Server, Signaturschlüssel, Entwicklungsumgebung. Diese Seite erklärt, wann ein Vorfall schwerwiegend ist, und grenzt ihn mit Beispielen ab.

Ein schwerwiegender Sicherheitsvorfall ist nach Artikel 14 Absatz 5 der Verordnung (EU) 2024/2847 ein Vorfall, der die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, sensible oder wichtige Daten oder Funktionen zu schützen. Schwerwiegend ist auch ein Vorfall, der zur Einführung oder Ausführung von Schadcode im Produkt oder im Netz- und Informationssystem eines Nutzers geführt hat oder führen kann. Solche Vorfälle muss der Hersteller nach Artikel 14 Absatz 3 melden, sobald er davon Kenntnis erlangt. Anders als die aktiv ausgenutzte Schwachstelle ist der Vorfall ein Ereignis, kein Zustand: Es ist etwas passiert, typischerweise in der Infrastruktur des Herstellers, das die Sicherheit des Produkts beim Nutzer gefährdet.

Das Wichtigste

  • Meldepflichtig sind Vorfälle, die sich auf die Sicherheit des Produkts auswirken und schwerwiegend sind (Artikel 14 Absatz 3 und 5). Nicht jede IT-Störung beim Hersteller fällt darunter.
  • Schwerwiegend heißt: sensible oder wichtige Daten oder Funktionen des Produkts sind gefährdet, oder Schadcode kann ins Produkt oder zum Nutzer gelangen.
  • Erwägungsgrund 68 nennt als Beispiel ein Schadprogramm im Freigabekanal für Sicherheitsupdates.
  • Fristen: Frühwarnung in 24 Stunden, Meldung in 72 Stunden, Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung (Artikel 14 Absatz 4).
  • Eine NIS2-Meldung der eigenen Einrichtung und eine DSGVO-Meldung laufen parallel und ersetzen die CRA-Meldung nicht.

Was sagt die Verordnung in Artikel 14 Absatz 3 und 5?

Die Verordnung baut den Begriff in drei Schritten auf. Ein Sicherheitsvorfall ist nach Artikel 3 Nummer 43 das, was Artikel 6 Nummer 6 der NIS2-Richtlinie (der EU-Richtlinie zur Netz- und Informationssicherheit) darunter versteht. Ein Sicherheitsvorfall mit Auswirkungen auf die Sicherheit des Produkts ist nach Artikel 3 Nummer 44 ein Vorfall, der sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen zu schützen. Das Wort schwerwiegend steht nicht in Artikel 3, sondern in Artikel 14 Absatz 5. Danach ist ein Vorfall schwerwiegend, wenn er

  • Buchstabe a: die Fähigkeit des Produkts, sensible oder wichtige Daten oder Funktionen zu schützen, beeinträchtigt oder beeinträchtigen kann, oder
  • Buchstabe b: zur Einführung oder Ausführung eines böswilligen Codes in einem Produkt mit digitalen Elementen oder im Netz- und Informationssystem eines Nutzers geführt hat oder führen kann.

Zwei Dinge fallen auf. Erstens genügt die Möglichkeit: "beeinträchtigen kann", "führen kann". Der Schaden muss nicht eingetreten sein. Zweitens geht es um die Sicherheit des Produkts, nicht um die des Herstellers als Organisation. Ein Vorfall in der Buchhaltung des Herstellers fällt nicht unter Artikel 14, solange er das Produkt nicht berührt.

Erwägungsgrund 68 füllt das mit einem Bild: Schwerwiegend ist ein Vorfall, der die Entwicklungs-, Herstellungs- oder Wartungsprozesse des Herstellers so beeinträchtigt, dass das Risiko für die Nutzer steigt, etwa ein Schadprogramm im Freigabekanal für Sicherheitsupdates. Im selben Erwägungsgrund steht das Beispiel für die aktiv ausgenutzte Schwachstelle: eine Sicherheitsverletzung bei Nutzern, die auf eine Schwäche in der Identifizierungs- oder Authentifizierungsfunktion zurückgeht. Beide Beispiele zeigen, wohin die Verordnung blickt: auf Schutzfunktionen und auf den Weg, über den Code zum Nutzer gelangt.

Worin unterscheidet sich der Vorfall von der Schwachstelle?

Die aktiv ausgenutzte Schwachstelle ist ein Zustand des Produkts: Im Produkt steckt ein Fehler, und jemand nutzt ihn in einem Kundensystem aus. Der schwerwiegende Sicherheitsvorfall ist ein Ereignis: Etwas ist passiert, meist beim Hersteller, und dadurch ist die Sicherheit des Produkts gefährdet. In der Praxis liegen die Vorfälle in Build-Pipelines (den Systemen, die aus Quellcode die auslieferbare Software erzeugen), auf Update-Servern, bei Signaturschlüsseln, in Supportzugängen oder in Backends, die als Fernverarbeitung Teil des Produkts sind.

MerkmalAktiv ausgenutzte SchwachstelleSchwerwiegender Sicherheitsvorfall
GrundlageArtikel 14 Absatz 1, Artikel 3 Nummer 42Artikel 14 Absatz 3 und 5, Artikel 3 Nummer 44
Was es istEin Zustand: Fehler im Produkt, der ausgenutzt wirdEin Ereignis, das die Produktsicherheit gefährdet
Wo es typischerweise passiertIn Systemen der NutzerIn der Infrastruktur des Herstellers oder im Produkt selbst
SchwelleVerlässliche Nachweise einer Ausnutzung durch einen böswilligen AkteurSensible Daten oder Funktionen gefährdet, oder Schadcode möglich
Frühwarnung24 Stunden ab Kenntnis (Absatz 2 Buchstabe a)24 Stunden ab Kenntnis, mit Angabe, ob Verdacht auf rechtswidrige oder böswillige Handlungen besteht (Absatz 4 Buchstabe a)
AbschlussberichtSpätestens 14 Tage nach Verfügbarkeit einer AbhilfeInnerhalb eines Monats nach der 72-Stunden-Meldung

Beide Auslöser können zusammenfallen, etwa wenn ein Update-Server über eine Schwachstelle in einer Software angegriffen wird, die zugleich Teil des Produkts beim Kunden ist. Dann sind beide Wege zu prüfen.

Welche Fristen gelten beim Vorfall?

Artikel 14 Absatz 4 ordnet dieselbe Dreiteilung an wie bei der Schwachstelle. Alle Fristen laufen ab Kenntnis, nicht ab dem Ereignis. Kenntnis liegt nach der Leitlinie der Kommission (C(2026) 5252, Rn. 213) vor, wenn der Hersteller nach einer sofortigen Erstbewertung mit hinreichender Gewissheit weiß, dass ein schwerwiegender Vorfall eingetreten ist und die Sicherheit seines Produkts beeinträchtigt hat.

  1. Frühwarnung, 24 StundenDass ein schwerwiegender Vorfall vorliegt, und ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht (Artikel 14 Absatz 4 Buchstabe a). Die Plattform fragt außerdem Datum und Uhrzeit der Erkennung ab.
  2. Meldung, 72 StundenAllgemeine Angaben zum Vorfall, Datum und Uhrzeit des Auftretens und eine erste Bewertung. Das CSIRT kann nach Artikel 14 Absatz 6 zusätzlich einen Zwischenbericht anfordern.
  3. Abschlussbericht, ein MonatInnerhalb eines Monats nach der 72-Stunden-Meldung: laufende Abhilfemaßnahmen, Schweregrad, Auswirkung, Bedrohungstyp und Grundursache. Anders als bei der Schwachstelle hängt diese Frist nicht davon ab, ob eine Abhilfe verfügbar ist.

Der Weg ist derselbe wie bei der Schwachstelle: die Single Reporting Platform der ENISA, von dort an das koordinierende CSIRT, in Deutschland CERT-Bund im BSI. Schritt für Schritt erklärt das der Leitfaden ENISA Single Reporting Platform: Registrierung und Meldung.

Beispiele: Was ist schwerwiegend und was nicht?

Die folgenden Fälle sind erfunden. Sie zeigen, wie die Prüfung nach Artikel 14 Absatz 5 abläuft. Die Spalte "CRA" sagt, ob der Vorfall nach Artikel 14 meldepflichtig ist; die letzte Spalte, welche anderen Pflichten daneben greifen können.

FallCRABegründungDaneben
Ein Hersteller von Steuerungen entdeckt Schadcode auf dem Server, über den signierte Firmware-Updates an Kunden ausgeliefert werden.JaSchadcode kann über den Update-Kanal zu Nutzern gelangen (Absatz 5 Buchstabe b); das Beispiel aus Erwägungsgrund 68.NIS2, wenn der Hersteller Einrichtung ist.
Ein Angreifer verschlüsselt Buchhaltung und Mailsystem eines Maschinenbauers. Entwicklung, Update-Server und Fernwartung sind nicht betroffen.NeinDer Vorfall berührt die Sicherheit des Produkts nicht (Artikel 3 Nummer 44). Die Abgrenzung wird dokumentiert.NIS2 und DSGVO, je nach Betroffenheit.
Ein Angreifer erlangt Zugang zum Fernwartungsportal eines Anlagenbauers, über das Techniker auf Kundenanlagen zugreifen.JaDer Zugang erlaubt Eingriffe in Funktionen und Daten der Produkte beim Nutzer und kann zu Schadcode im Netz des Nutzers führen (Buchstabe a und b).NIS2, DSGVO, Kunden informieren nach Artikel 14 Absatz 8.
Mitarbeiter eines Softwareherstellers erhalten eine gezielte Phishing-Mail. Niemand klickt, nichts wird kompromittiert.NeinEin Beinahe-Vorfall (Artikel 3 Nummer 45), kein eingetretener Vorfall. Freiwillige Meldung nach Artikel 15 Absatz 2 möglich.Keine Pflicht.
Das Cloud-Backend, ohne das ein vernetztes Messgerät nicht arbeitet, wird kompromittiert; Messdaten der Kunden waren für Dritte einsehbar.JaDas Backend ist als Fernverarbeitung Teil des Produkts; die Vertraulichkeit von Daten ist beeinträchtigt (Buchstabe a).DSGVO bei personenbezogenen Daten, NIS2 je nach Einrichtung.

Ob ein Backend zum Produkt gehört, erklärt der Leitfaden SaaS, Cloud und Fernverarbeitung. Offen bleibt, ob ein Hersteller, der das Backend selbst betreibt, denselben Vorfall nach CRA und als Nutzer doppelt zu melden hat.

Wie spielt die NIS2-Meldung der eigenen Einrichtung hinein?

Viele Hersteller sind zugleich wichtige oder wesentliche Einrichtung nach NIS2, in Deutschland umgesetzt im BSI-Gesetz. Dann treffen zwei Meldepflichten zusammen, die unterschiedlich fragen:

  • NIS2 fragt nach der Einrichtung: Ist der Betrieb erheblich gestört? Die Meldung geht nach Artikel 23 NIS2 beziehungsweise § 32 BSIG an das BSI, mit den Zeitstufen 24 Stunden, 72 Stunden und ein Monat.
  • Der CRA fragt nach dem Produkt: Ist die Sicherheit des Produkts beim Nutzer gefährdet? Die Meldung geht nach Artikel 14 Absatz 3 über die Single Reporting Platform an CERT-Bund und die ENISA.

Beide Meldungen landen in Deutschland beim BSI, aber auf verschiedenen Wegen und mit verschiedenen Formularen. Eine behördliche Aussage, dass die eine Meldung die andere ersetzt, gibt es nicht; Erwägungsgrund 72 nennt NIS2, DSGVO und DORA ausdrücklich als ergänzende Pflichten. Sind personenbezogene Daten betroffen, kommt Artikel 33 DSGVO mit 72 Stunden an die Datenschutzaufsicht hinzu. Immerhin hat die Leitlinie der Kommission den Kenntnisbegriff an NIS2 und DSGVO angeglichen (Rn. 212); der Zeitstempel kann einmal bestimmt werden. Den Vergleich beider Regime zieht der Leitfaden CRA und NIS2 im Vergleich.

Wann und wie sind Nutzer zu informieren?

Artikel 14 Absatz 8 verpflichtet den Hersteller, nach Kenntnis eines schwerwiegenden Vorfalls die betroffenen Nutzer und gegebenenfalls alle Nutzer zu informieren, einschließlich möglicher Maßnahmen zur Risikominderung. Eine Stundenfrist nennt der Absatz nicht; die Information muss rechtzeitig erfolgen, sonst können die koordinierenden CSIRTs selbst informieren. Beim Vorfall ist das oft dringlicher als bei der Schwachstelle: Wer Schadcode über den Update-Kanal ausgeliefert haben könnte, muss den Kunden sagen, welche Updates sie nicht einspielen oder wieder entfernen sollen. Was in eine solche Information gehört, erklärt der Leitfaden Nutzer informieren nach Artikel 14 Absatz 8.

Was das praktisch heißt

Der schwerwiegende Vorfall ist der Fall, in dem die IT-Sicherheit des Herstellers und die Produktsicherheit zusammenfallen. Drei Vorbereitungen helfen. Erstens: Die Liste der Systeme, die die Produktsicherheit tragen, muss vorher stehen: Build-Server, Update-Server, Signaturschlüssel, Supportzugänge, Backends. Wird eines davon angegriffen, ist die Prüfung nach Artikel 14 Absatz 5 sofort fällig. Zweitens: Wer bei einem IT-Vorfall ohnehin alarmiert wird (IT-Leitung, Geschäftsführung, Datenschutz), muss die Frage "Ist ein Produkt betroffen?" auf dem Zettel haben. Sonst läuft die NIS2-Meldung, und die CRA-Meldung wird vergessen. Drittens: Jeder Zeitstempel gehört ins Protokoll, denn die Plattform hat am 3. Oktober 2026 noch kein Feld für den Kenntniszeitpunkt. CRA Response Center hält für diese Fälle die Rufkette, die Fristen-Uhren für beide Auslöser und das Nachweis-Protokoll bereit; Bewertung und Einreichung bleiben beim Hersteller.

Häufige Fragen

Ist jeder Cyberangriff auf unser Unternehmen ein schwerwiegender Sicherheitsvorfall nach CRA?

Nein. Artikel 14 Absatz 3 erfasst nur Vorfälle, die sich auf die Sicherheit des Produkts auswirken, und Absatz 5 verlangt zusätzlich, dass sensible Daten oder Funktionen gefährdet sind oder Schadcode ins Produkt oder zum Nutzer gelangen kann. Ein Angriff auf die Verwaltung ohne Bezug zum Produkt fällt nicht darunter, kann aber nach NIS2 oder DSGVO meldepflichtig sein.

Wann beginnt die 24-Stunden-Frist beim Vorfall?

Mit Kenntnis, also wenn der Hersteller nach einer sofortigen Erstbewertung mit hinreichender Gewissheit weiß, dass ein schwerwiegender Vorfall eingetreten ist und die Sicherheit des Produkts beeinträchtigt hat (Leitlinie Rn. 213). Nicht mit dem Angriff selbst und nicht mit der vollständigen Ursachenanalyse.

Was muss in der Frühwarnung beim Vorfall stehen?

Dass ein schwerwiegender Vorfall vorliegt und ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht (Artikel 14 Absatz 4 Buchstabe a). Die Plattform fragt zusätzlich Datum und Uhrzeit der Erkennung ab.

Wir haben nach NIS2 an das BSI gemeldet. Ist die CRA-Meldung damit erledigt?

Nein. Beide Pflichten laufen parallel, mit eigenen Formularen und Wegen. Erwägungsgrund 72 nennt NIS2 als ergänzende Meldepflicht, und es gibt keine behördliche Aussage, dass eine Meldung die andere ersetzt.

Zählt ein abgewehrter Angriff?

Ein Angriff ohne Kompromittierung ist ein Beinahe-Vorfall nach Artikel 3 Nummer 45. Er ist nicht nach Artikel 14 meldepflichtig, kann aber freiwillig nach Artikel 15 Absatz 2 gemeldet werden, ohne dass daraus Pflichten entstehen (Absatz 5).

Weiterlesen

Quellen

Die Meldepflicht läuft. Wer nimmt bei Ihnen nachts ab?

CRA Response Center nimmt Schwachstellen-Meldungen an, prüft sie, weckt Ihre Rufkette und führt die Fristen-Uhren. Ab 190 Euro im Monat, Einrichtung zum Festpreis.

Demo anfragen