CRA Response Center Demo anfragen

Leitfaden Stand Lesezeit 10 Min.

Aktiv ausgenutzte Schwachstelle: Was meldepflichtig ist und was nicht

Die Meldepflicht nach Artikel 14 greift nicht bei jeder Schwachstelle, sondern nur, wenn verlässliche Nachweise für eine Ausnutzung vorliegen. Diese Seite erklärt die Definition, grenzt sie von CVE-Einträgen, Scanner-Funden und Forschertests ab und zeigt, wie Sie im Zweifel vorgehen.

Eine aktiv ausgenutzte Schwachstelle ist nach Artikel 3 Nummer 42 der Verordnung (EU) 2024/2847 eine Schwachstelle, zu der verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Nur solche Schwachstellen lösen die Meldepflicht nach Artikel 14 Absatz 1 aus. Ein Eintrag in der Schwachstellendatenbank CVE, ein hoher CVSS-Wert (die übliche Zahl für die Schwere einer Lücke), ein Scanner-Fund oder ein Exploit, den ein Sicherheitsforscher vorführt, reichen für sich allein nicht. Entscheidend ist, ob jemand die Lücke in Ihrem Produkt tatsächlich gegen den Willen des Betreibers genutzt hat, und ob Sie das mit hinreichender Gewissheit wissen.

Das Wichtigste

  • Meldepflichtig ist nur eine Schwachstelle, die in Ihrem Produkt enthalten ist und für deren Ausnutzung durch einen böswilligen Akteur verlässliche Nachweise vorliegen (Artikel 3 Nummer 42, Artikel 14 Absatz 1).
  • Kein Auslöser: CVE-Veröffentlichung, CVSS-Wert, Proof of Concept ohne echte Ausnutzung, Funde aus gutgläubigen Tests (Erwägungsgrund 68).
  • Schwachstellen in Drittkomponenten sind meldepflichtig, wenn sie in Ihrem Produkt enthalten und dort ausgenutzt sind. Sonst: Upstream melden und optional freiwillig nach Artikel 15 (Leitlinie Rn. 218).
  • Die CRA-Meldung ersetzt keine Meldung nach DSGVO, NIS2 oder DORA (Erwägungsgrund 72).
  • Im Zweifel sofort prüfen und die Prüfung dokumentieren. Melden ist das Ergebnis der Prüfung, nicht ihr Ersatz.

Was sagt die Definition in Artikel 3 Nummer 42?

Die Verordnung unterscheidet drei Stufen. Eine Schwachstelle ist nach Artikel 3 Nummer 40 eine Schwäche, Anfälligkeit oder Fehlfunktion eines Produkts, die bei einer Cyberbedrohung ausgenutzt werden kann. Eine ausnutzbare Schwachstelle nach Nummer 41 kann von einem unbefugten Dritten unter praktischen Betriebsbedingungen wirksam genutzt werden. Erst die dritte Stufe löst die Meldepflicht aus:

"aktiv ausgenutzte Schwachstelle" bezeichnet eine Schwachstelle, zu der verlässliche Nachweise dafür vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat.

Artikel 3 Nummer 42 CRA

Drei Merkmale müssen zusammenkommen:

  • Verlässliche Nachweise. Eine Vermutung oder die bloße Möglichkeit reichen nicht. Was im Einzelfall als verlässlich gilt (Protokolldaten, Spuren auf Kundensystemen, ein Hinweis des CSIRT), legt die Verordnung nicht fest; die Leitlinie der Kommission bleibt hier abstrakt.
  • Ein böswilliger Akteur. Jemand hat die Lücke mit schädlicher Absicht genutzt. Ein Tester oder Forscher, der sie im Rahmen einer Prüfung nachstellt, ist kein böswilliger Akteur.
  • Ohne Zustimmung des Systemeigners. Die Ausnutzung geschah gegen den Willen dessen, der das System betreibt. Ein beauftragter Penetrationstest erfüllt dieses Merkmal nicht.

Dazu kommt die Grenze aus Artikel 14 Absatz 1: Die Pflicht gilt nur für Schwachstellen, die in dem Produkt enthalten sind, und nur, wenn der Hersteller davon Kenntnis erlangt. Wann die 24-Stunden-Frist beginnt, erklärt der Leitfaden Ab wann läuft die 24-Stunden-Frist?.

Was ist kein Auslöser?

Die meisten Schwachstellen, mit denen ein Hersteller im Alltag zu tun hat, sind nicht meldepflichtig. Vier Fälle kommen besonders oft vor:

  • Ein CVE-Eintrag allein. CVE ist das öffentliche Verzeichnis bekannter Schwachstellen. Dass eine Lücke dort steht, sagt nichts darüber aus, ob sie in Ihrem Produkt ausgenutzt wird. Die Leitlinie der Kommission hält, in anderem Zusammenhang (Rn. 230 bis 235 zu bekannten ausnutzbaren Schwachstellen nach Anhang I Teil I Nummer 2), fest: Dass eine Schwachstelle gemeldet oder gefunden wurde, bedeutet nicht, dass sie in der Praxis ausnutzbar oder auf das konkrete Produkt anwendbar ist.
  • Ein hoher CVSS-Wert. CVSS bewertet, wie schwer eine Schwachstelle theoretisch wiegt, nicht, ob sie ausgenutzt wird. Ein Wert von 9,8 ohne Ausnutzungsnachweis ist kein Auslöser; ein Wert von 5,0 mit belegter Ausnutzung ist einer.
  • Ein Proof of Concept ohne Ausnutzung. Ein Proof of Concept zeigt, dass eine Lücke grundsätzlich nutzbar ist. Veröffentlicht ein Forscher einen solchen Nachweis, liegt noch keine Ausnutzung durch einen böswilligen Akteur vor. Ab jetzt sollten Sie aber Telemetrie, Kundenmeldungen und Supportanfragen aufmerksam beobachten.
  • Funde aus gutgläubigen Tests. Erwägungsgrund 68 nimmt Schwachstellen, die bei in gutem Glauben ausgeführten Tests, Untersuchungen, Korrekturen oder Offenlegungen entdeckt werden, ausdrücklich aus. Ein Penetrationstest oder eine Meldung aus Ihrem Verfahren zur koordinierten Offenlegung sind solche Fälle.

Was dagegen reicht: die Ausnutzung bei einem einzigen Kunden. Die Definition spricht von einem System, nicht von vielen. Erwägungsgrund 68 nennt als Beispiel eine Sicherheitsverletzung bei Nutzern, die darauf zurückgeht, dass ein böswilliger Akteur einen Fehler im Produkt nutzt, etwa eine Schwäche in der Identifizierungs- oder Authentifizierungsfunktion.

Wie zählen Schwachstellen in Drittkomponenten?

Kaum ein Produkt besteht nur aus eigenem Code. Bibliotheken, Betriebssysteme, Protokollstapel und Open-Source-Komponenten stecken in fast jedem Gerät und jeder Software. Die Leitlinie der Kommission (C(2026) 5252, Rn. 218) zieht hier eine klare Linie: Eine aktiv ausgenutzte Schwachstelle aus einer Drittkomponente ist zu melden, wenn die Komponente in Ihrem Produkt enthalten ist. Nicht meldepflichtig ist sie in zwei Fällen:

  • Die Schwachstelle ist in Ihrem Produkt nicht ausnutzbar, weil der verwundbare Code dort nicht erreichbar ist.
  • Die Schwachstelle wurde in Ihrem Produkt nicht ausgenutzt, auch wenn sie in einem anderen Produkt mit derselben Komponente ausgenutzt wurde.

In beiden Fällen bleibt eine freiwillige Meldung nach Artikel 15 möglich. Die übrigen Pflichten bleiben: Nach Artikel 13 Absatz 6 melden Sie die Schwachstelle dem Hersteller der Komponente (Upstream-Meldung) und behandeln sie nach Anhang I Teil II im eigenen Produkt. Die Meldung des Komponentenherstellers ersetzt Ihre nicht, wenn die Lücke in Ihrem Produkt ausgenutzt wird. Mehr dazu im Leitfaden Open Source und CRA.

Entscheidungsbaum: Liegt ein Auslöser vor?

Die folgenden Fragen führen in der Reihenfolge der Verordnung durch die Prüfung. Die Antwort bestimmt den nächsten Schritt.

  1. Betrifft die Schwachstelle ein Produkt, das Sie als Hersteller in der EU bereitstellen?Nein: keine Pflicht nach Artikel 14; als Importeur, Händler oder Nutzer gelten andere Pflichten. Ja: weiter mit Frage 2.
  2. Ist die Schwachstelle in Ihrem Produkt enthalten und dort erreichbar?Nein: keine Pflicht nach Artikel 14, Begründung dokumentieren. Ja: weiter mit Frage 3.
  3. Liegen Hinweise auf eine Ausnutzung durch einen böswilligen Akteur ohne Zustimmung des Systemeigners vor?Nein, es ist ein CVE-Eintrag, ein Scanner-Fund, ein Proof of Concept oder ein gutgläubiger Test: keine Pflicht nach Artikel 14; Schwachstelle nach Anhang I Teil II behandeln, bei Drittkomponenten Upstream melden. Ja oder unklar: weiter mit Frage 4.
  4. Sind die Hinweise nach einer sofortigen Erstbewertung verlässlich?Ergibt die Bewertung mit hinreichender Gewissheit, dass die Ausnutzung in Ihrem Produkt stattfindet: Kenntnis liegt vor, die 24-Stunden-Frist läuft (Rn. 213). Bleibt es beim Verdacht: Prüfung fortsetzen, jeden Schritt mit Zeitstempel festhalten, freiwillige Meldung nach Artikel 15 erwägen.
  5. Wurde die Ausnutzung erst nach dem 11. September 2026 bekannt?Nein, Sie wussten schon vorher davon: keine Nachmeldung (Rn. 217, ENISA-FAQ 13). Ja: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe (Artikel 14 Absatz 2), Nutzer informieren nach Absatz 8.

Wie verhält sich die CRA-Meldung zu DSGVO, NIS2 und DORA?

Die Meldung nach Artikel 14 ersetzt keine andere Meldepflicht. Erwägungsgrund 72 nennt die Datenschutz-Grundverordnung (EU) 2016/679, die NIS2-Richtlinie (EU) 2022/2555, die DORA-Verordnung (EU) 2022/2554 und die ePrivacy-Richtlinie 2002/58/EG ausdrücklich als ergänzende Meldepflichten. In der Praxis heißt das:

  • DSGVO: Sind personenbezogene Daten betroffen, meldet der Verantwortliche nach Artikel 33 DSGVO binnen 72 Stunden an die Datenschutzaufsicht und informiert gegebenenfalls nach Artikel 34 die betroffenen Personen. Maßstab ist das Risiko für Rechte und Freiheiten.
  • NIS2: Ist der Hersteller zugleich wichtige oder wesentliche Einrichtung, meldet er einen Vorfall in seiner eigenen Infrastruktur nach Artikel 23 NIS2, in Deutschland nach § 32 BSIG, an das BSI. Maßstab ist die erhebliche Störung des Betriebs. Mehr dazu im Leitfaden CRA und NIS2 im Vergleich.
  • DORA: Finanzunternehmen melden Vorfälle in ihrer Informationstechnik zusätzlich nach den Regeln dieser Verordnung.

Die Schwellen sind verschieden, die Formulare auch. Ein Vorteil bleibt: Die Leitlinie der Kommission hat den Begriff der Kenntnis bewusst an NIS2 und an die Leitlinien zur Datenpannenmeldung nach DSGVO angeglichen (Rn. 212). Der Zeitpunkt, ab dem die Fristen laufen, kann damit einmal bestimmt und für alle Regime verwendet werden.

Was bringt die freiwillige Meldung nach Artikel 15?

Artikel 15 erlaubt, Schwachstellen und Cyberbedrohungen (Absatz 1) sowie Vorfälle und Beinahe-Vorfälle (Absatz 2) freiwillig an das koordinierende CSIRT oder die ENISA zu melden. Nach Absatz 5 erzeugt eine freiwillige Meldung keine zusätzlichen Pflichten; sie löst die Fristen aus Artikel 14 nicht aus. Nach Absatz 4 unterrichtet das CSIRT den Hersteller unverzüglich, wenn ein Dritter eine aktiv ausgenutzte Schwachstelle in dessen Produkt meldet; ab diesem Hinweis beginnt die Erstbewertung. Die Single Reporting Platform hat die freiwillige Meldung am 3. Oktober 2026 noch nicht umgesetzt (ENISA-FAQ 27); wie sie bis dahin einzureichen ist, sagt die ENISA nicht.

Im Zweifel prüfen lassen, nicht im Zweifel melden

Dieser Grundsatz klingt nach Zurückhaltung. Gemeint ist das Gegenteil. Die Verordnung verlangt eine Meldung, wenn verlässliche Nachweise vorliegen, und Verlässlichkeit entsteht durch Prüfung, nicht durch Reflex. Wer bei jedem Scanner-Fund eine Frühwarnung absetzt, belastet das CSIRT mit Meldungen ohne Auslöser und gewöhnt die eigene Organisation an Fehlalarme. Außerdem muss er binnen 72 Stunden Angaben zur Art der Ausnutzung nachliefern, die es nicht gibt.

Umgekehrt darf die Prüfung nicht zum Vorwand für Verzögerung werden. Die Erstbewertung muss sofort beginnen (Rn. 213), und Kenntnis liegt mit hinreichender Gewissheit vor, nicht erst mit vollständiger Ursachenanalyse. Eine künstlich hinausgezögerte Bewertung verschiebt die Kenntnis nicht glaubwürdig. Das Prüfen muss also jemand übernehmen, der sofort erreichbar ist, auch nachts und am Wochenende. Genau das ist der Kern der Bereitschaft: Jede Meldung an Ihre Sicherheitsadresse wird sofort angesehen, eingeordnet und mit Zeitstempel festgehalten; bei Verdacht auf Ausnutzung wird die verantwortliche Person geweckt. CRA Response Center stellt Annahme, Prüfung und Rufkette bereit und führt die Fristen-Uhren; die Entscheidung, ob ein Auslöser vorliegt, und die Einreichung bleiben beim Hersteller.

Typische Fehler

  • Jede CVE in der Stückliste als meldepflichtig behandeln. Das überflutet das CSIRT und bindet Ihre Leute mit Meldungen ohne Auslöser.
  • Kundenberichte über "merkwürdige Logins" nicht als verdächtiges Ereignis werten. Genau solche Hinweise sind der typische Beginn einer Kenntnis.
  • Den Zeitpunkt der Kenntnis nicht festhalten. Die Plattform hat am 3. Oktober 2026 noch kein Feld dafür. Ohne eigenes Protokoll lässt sich die 24-Stunden-Frist später weder belegen noch verteidigen.
  • Drittkomponenten falsch einordnen. Entweder die Upstream-Meldung nach Artikel 13 Absatz 6 vergessen oder die eigene Pflichtmeldung unterlassen, weil der Komponentenhersteller schon gemeldet hat.

Häufige Fragen

Löst eine CVE-Veröffentlichung die Meldepflicht aus?

Nein. Ein CVE-Eintrag belegt, dass eine Schwachstelle bekannt ist, nicht, dass sie ausgenutzt wird. Meldepflichtig wird sie erst, wenn verlässliche Nachweise für eine Ausnutzung durch einen böswilligen Akteur ohne Zustimmung des Systemeigners vorliegen (Artikel 3 Nummer 42).

Muss ich einen Exploit melden, den ein Forscher mir vorführt?

Nein, solange keine Ausnutzung durch einen böswilligen Akteur belegt ist. Erwägungsgrund 68 nimmt gutgläubige Tests und Offenlegungen aus. Das Verfahren zur koordinierten Offenlegung läuft trotzdem.

Ein Kunde meldet einen Angriff über unser Produkt. Reicht das?

Es ist ein verdächtiges Ereignis, das sofort bewertet werden muss. Kenntnis liegt vor, sobald die Erstbewertung die Ausnutzung in Ihrem Produkt mit hinreichender Gewissheit bestätigt (Leitlinie Rn. 213). Beide Zeitpunkte gehören ins Protokoll.

Die Schwachstelle liegt in einer eingekauften Komponente. Muss ich melden?

Ja, wenn die Komponente in Ihrem Produkt enthalten ist und die Schwachstelle dort ausgenutzt wird. Nein, wenn der verwundbare Code in Ihrem Produkt nicht erreichbar ist oder die Ausnutzung nur in fremden Produkten belegt ist (Leitlinie Rn. 218). In jedem Fall melden Sie die Schwachstelle dem Komponentenhersteller (Artikel 13 Absatz 6).

Muss ich Fälle aus der Zeit vor dem 11. September 2026 nachmelden?

Nein. Ausnutzungen, von denen Sie schon vor dem 11. September 2026 wussten, sind nicht nachzumelden (Leitlinie Rn. 217). War nur die Schwachstelle bekannt und wird die Ausnutzung erst danach bekannt, ist zu melden.

Ersetzt die CRA-Meldung die DSGVO- oder NIS2-Meldung?

Nein. Erwägungsgrund 72 nennt DSGVO, NIS2, DORA und die ePrivacy-Richtlinie als ergänzende Meldepflichten. Alle laufen parallel, mit eigenen Schwellen und Formularen.

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