CRA-Schwachstellenmeldung: ENISA SRP, 24h/72h/14d-Fristen

Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) macht die Schwachstellenmeldung zur verbindlichen, fristgebundenen gesetzlichen Pflicht für jeden Hersteller eines Produkts mit digitalen Elementen. Ab dem 11. September 2026 verpflichtet Artikel 14 dazu, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die ENISA Single Reporting Platform (SRP) im Takt 24 Stunden / 72 Stunden / 14 Tage zu melden, unterlegt durch eine nach Anhang I Teil II verpflichtende Richtlinie zur koordinierten Schwachstellenoffenlegung (CVD). Diese Seite ist die kanonische Referenz: was das Gesetz verlangt, wann jede Uhr startet, was eine konforme CVD-Richtlinie enthalten muss, wie VEX die Pflicht zur Freiheit von bekannten ausnutzbaren Schwachstellen operativ umsetzt und welche Bußgelder nach Artikel 64 bei Verstößen drohen.

Was verlangt der CRA für die Schwachstellenmeldung?

Artikel 14 der Cyberresilienz-Verordnung ist der operative Kern des Incident-Handling-Regimes. Er legt jedem Hersteller eines Produkts mit digitalen Elementen, das auf dem EU-Markt bereitgestellt wird, drei Pflichten auf:

1. Jede aktiv ausgenutzte Schwachstelle im Produkt gleichzeitig dem Koordinator-CSIRT und ENISA melden, im Takt 24h / 72h / 14d (Art. 14(1), 14(2)).
2. Jeden schwerwiegenden Vorfall, der die Sicherheit des Produkts beeinträchtigt, im Takt 24h / 72h / 1 Monat melden (Art. 14(3), 14(4)).
3. Nutzer des betroffenen Produkts über die Schwachstelle oder den Vorfall und etwaige Korrekturmaßnahmen ohne unangemessene Verzögerung informieren (Art. 14(8)).

Artikel 14 steht neben zwei weiteren Pflichten, die diese Seite ebenfalls behandelt: der nach Anhang I Teil II verpflichtenden CVD-Richtlinie und der Anforderung nach Anhang I Teil I, keine bekannten ausnutzbaren Schwachstellen zu haben. Deshalb ist VEX für ein CRA-konformes Produkt relevant. Keine dieser Pflichten hat eine Größenschwelle. KMU profitieren von einer engen Bußgeldentlastung bei der 24-Stunden-Frist (siehe unten), sind aber nicht von der Meldepflicht befreit.

Die ENISA Single Reporting Platform (SRP)

Die SRP ist der einzige Kanal, über den jede Meldung nach Artikel 14 fließt. Sie existiert, weil Artikel 14(1) verlangt, gleichzeitig dem Koordinator-CSIRT und ENISA zu melden, und 27 separate Einreichungen in der Praxis nicht handhabbar wären. Artikel 16(1) stellt die Plattform unter die operative Verantwortung von ENISA: "Der laufende Betrieb dieser einheitlichen Meldeplattform wird von der ENISA verwaltet und aufrechterhalten."

Wie es in der Praxis funktioniert:

• Sie reichen einmal ein, über den elektronischen Endpunkt des nach Artikel 14(7) als Koordinator benannten CSIRT.
• Die Einreichung gelangt gleichzeitig an den Koordinator-CSIRT und an ENISA.
• Der Koordinator-CSIRT leitet die Meldung dann an die CSIRTs der übrigen Mitgliedstaaten weiter, in denen Ihr Produkt auf dem Markt bereitgestellt wird (Art. 16). Diese sekundäre Weiterleitung liegt in der Verantwortung des CSIRT, nicht des Herstellers.
• Artikel 16(2) erlaubt einem CSIRT, die Weiterleitung von Meldungen in besonders außergewöhnlichen Umständen zu verzögern. Artikel 16(6) erlaubt eine Verzögerung während koordinierter Offenlegung mit Zustimmung des Herstellers.

Stand Mai 2026: Die SRP soll bis zum 11. September 2026 betriebsbereit sein, gemäß der ENISA-SRP-Seite. Die Umsetzung wurde unter ENISA/2025/OP/0001 (4-Jahres-Vertrag) ausgeschrieben, die Ausschreibung schloss im März 2025. Der Anbieter wurde nicht öffentlich bekannt gegeben. Eine Registrierungs-URL wurde nicht veröffentlicht. Eine Testphase vor dem Launch ist geplant; konkrete Termine wurden noch nicht angekündigt. Durchführungsrechtsakte nach Artikel 14, die Formate und Struktur der Meldungen festlegen, waren zum Zeitpunkt der Erstellung noch ausstehend.

Was Hersteller jetzt tun sollten: Identifizieren Sie Ihren Koordinator-CSIRT nach Artikel 14(7), entwerfen und genehmigen Sie Berichtsvorlagen für die 24-Stunden-, 72-Stunden- und 14-Tage-Einreichungen, und legen Sie eine Bereitschaftsrotation außerhalb der Geschäftszeiten fest. Vorlagen und Prozesse können nicht entworfen werden, während die 24-Stunden-Uhr läuft.

Meldefristen im Detail

Sowohl Schwachstellen als auch schwerwiegende Vorfälle folgen einem gestuften Meldemodell. Die Uhren unterscheiden sich beim Abschlussbericht.

Meldeübersicht nach Artikel 14

Stufe	Schwachstelle (Art. 14(2))	Schwerwiegender Vorfall (Art. 14(4))	Startpunkt
Frühwarnung	24 Stunden	24 Stunden	Hersteller erlangt Kenntnis
Detaillierte Meldung	72 Stunden	72 Stunden	Hersteller erlangt Kenntnis
Abschlussbericht	14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme	1 Monat nach der 72-Stunden-Vorfallsmeldung	Unterschiedlicher Startpunkt je Track
Nutzerinformation	Ohne unangemessene Verzögerung	Ohne unangemessene Verzögerung	Gemäß Art. 14(8)

Was jede Einreichung enthält

Frühwarnung (24 Stunden). Mindestinformationen zur Benachrichtigung der Behörden: Identität des Herstellers, betroffenes Produkt und Version, kurze Beschreibung, erste Schweregradbewertung, ob die Ausnutzung bestätigt oder vermutet wird, und eine Angabe zum potenziellen Ausmaß. Die Frühwarnung ist eine Warnung, keine Analyse.

Detaillierte Meldung (72 Stunden). Zwei separate Pflichten liegen auf dieser Stufe. Die 72-Stunden-Schwachstellenmeldung nach Artikel 14(2)(b) betrifft aktiv ausgenutzte Schwachstellen. Die 72-Stunden-Vorfallsmeldung nach Artikel 14(4)(b) betrifft schwerwiegende Vorfälle. In beiden Fällen ergänzt die Einreichung die Frühwarnung um technische Details, betroffene Versionen und Konfigurationen, die Ausnutzungsmethode (falls bekannt), den aktuellen Mitigationsstatus, den geplanten Behebungszeitraum, den bekannten Nutzerkreis und etwaige laufende Koordination mit anderen Parteien.

Abschlussbericht. Für Schwachstellen beginnt die 14-Tage-Frist "spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme" (Art. 14(2)(c)), nicht ab Entdeckung und nicht ab der 72-Stunden-Meldung. Für schwerwiegende Vorfälle läuft die Monatsfrist ab der 72-Stunden-Vorfallsmeldung nach Artikel 14(4)(c). Der Abschlussbericht umfasst Ursachenanalyse, vollständige technische Beschreibung, durchgeführte Behebungsmaßnahmen, umgesetzte Präventionsmaßnahmen und bestätigte Auswirkungsbewertung.

1. Kenntnis des Herstellers. Die 24-Stunden-Uhr startet in dem Moment, in dem eine begründete Annahme aktiver Ausnutzung gebildet wird.
2. + 24 Stunden. Frühwarnung über die ENISA SRP eingereicht (Art. 14(2)(a)).
3. + 72 Stunden. Detaillierte Meldung mit technischen Details, betroffenen Versionen und Mitigationsstatus eingereicht (Art. 14(2)(b)).
4. Korrektur- oder Risikominderungsmaßnahme verfügbar. Die 14-Tage-Frist für den Abschlussbericht startet hier, nicht bei Entdeckung.
5. + 14 Tage. Abschlussbericht eingereicht: Ursachenanalyse, vollständige technische Beschreibung, Behebung, bestätigte Auswirkungen (Art. 14(2)(c)).

Was löst eine Meldepflicht aus?

Artikel 14 deckt zwei Auslöserkategorien ab.

1. Aktiv ausgenutzte Schwachstellen

Eine Schwachstelle in Ihrem Produkt, die:

• Ihnen bekannt ist (intern entdeckt oder extern gemeldet),
• von einem böswilligen Akteur genutzt wurde, und
• Nutzer des Produkts betrifft oder betreffen könnte.

Der CRA definiert eine aktiv ausgenutzte Schwachstelle als eine, bei der "ein böswilliger Akteur einen Fehler ausnutzt". Das ist nicht dasselbe wie öffentliche Offenlegung, ein veröffentlichter Proof-of-Concept oder ein Forscher, der Ausnutzbarkeit demonstriert. Der Auslöser ist tatsächliche böswillige Nutzung.

2. Schwerwiegende Vorfälle

Sicherheitsvorfälle, die die Sicherheit des Produkts beeinträchtigen, die Entwicklungsumgebung auf eine Weise kompromittieren, die die Produktsicherheit betrifft, zu erheblichen Dienstunterbrechungen für Nutzer führen oder zu einer weitreichenden Kompromittierung führen.

Meldepflichtige vs. nicht meldepflichtige Szenarien

Szenario	Meldepflichtig?	Begründung
Sicherheitsforscher meldet Schwachstelle vertraulich	Nein	Kein Ausnutzungsnachweis; über CVD-Prozess behandeln
PoC auf GitHub veröffentlicht	Nein	Veröffentlichung ist keine Ausnutzung
Kunde meldet Aktivität, die mit der Schwachstelle übereinstimmt	Ja	Schwelle der begründeten Annahme erfüllt
Schwachstelle wird in freier Wildbahn ausgenutzt	Ja	Aktive böswillige Nutzung
Komponente in Ihrer SBOM hat bekannte ausgenutzte CVE	Prüfen	Meldepflichtig nur wenn Ausnutzung Ihr Produkt betrifft (VEX ist hier relevant)
Ihr Produkt wird von namentlich bekannten Bedrohungsakteuren angegriffen	Ja	Direkter Ausnutzungsnachweis
Generische Malware nutzt eine Schwachstellenklasse, die Ihr Produkt aufweist	Prüfen	Nur wenn Ihre spezifische Implementierung betroffen ist

Der Standard der "begründeten Annahme"

Forensischer Beweis der Ausnutzung ist nicht erforderlich. Der Artikel-14-Standard ist eine begründete Annahme auf Grundlage verfügbarer Belege: ungewöhnliche Zugriffsmuster, die mit bekannten Exploit-Techniken übereinstimmen, Kundenmeldungen über Kompromittierung, Threat Intelligence, die auf eine gezielte Ausnutzung Ihres Produkts hinweist, oder der Nachweis von Exploit-Code, der für Ihr Produkt entwickelt wurde. Bei Unsicherheit: melden. Eine verfrühte Frühwarnung, die sich als unbegründet erweist, ist weit besser als eine verpasste Frist bei tatsächlicher Ausnutzung, und die 72-Stunden-Meldung kann die Bewertung aktualisieren.

Koordinierte Schwachstellenoffenlegung (CVD): die Verbindung zu Artikel 14

Anhang I Teil II Nummer 5 verpflichtet Hersteller, „eine Richtlinie zur koordinierten Offenlegung von Schwachstellen aufzustellen und umzusetzen". Operativ ist die CVD-Richtlinie der Mechanismus, der externe Forschermeldungen in einen strukturierten Triage-Ablauf überführt und, sobald die Triage aktive Ausnutzung bestätigt, parallel die Meldepflicht nach Artikel 14 auslöst. Die Pflicht gilt für jedes Produkt mit digitalen Elementen; eine KMU- oder Größenschwelle besteht nicht. Das Mindestmaß ist eine öffentliche URL plus eine security.txt-Datei unter /.well-known/security.txt (RFC 9116), damit die Forscher, die die Verordnung adressieren soll, die Meldewege auch finden.

Für die CVD-Richtlinie selbst, einschließlich erforderlicher Inhalte, Offenlegungsfenster, Safe-Harbour-Formulierungen und Vorlagen für die Forscherkommunikation, siehe den eigenen Leitfaden zur koordinierten Schwachstellenoffenlegung. Wie sich CVD in die übrigen Pflichten aus Anhang I Teil II einfügt (SBOM, Behebung, sichere Updates, kostenlose Bereitstellung), erläutert der Leitfaden zum Umgang mit Schwachstellen nach CRA. Diese Seite konzentriert sich auf die Artikel-14-Meldekadenz, die ausgelöst wird, wenn die Triage eine aktive Ausnutzung bestätigt.

VEX: Schwachstellen-Anwendbarkeit kommunizieren

Anhang I Teil I verlangt, dass CRA-Produkte ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden und mit einer sicheren Standardkonfiguration geliefert werden. SBOM-Scans erzeugen lange Listen von CVEs gegen Komponenten, von denen die meisten im spezifischen Produkt tatsächlich nicht ausnutzbar sind. VEX (Vulnerability Exploitability eXchange) ist der Mechanismus, der diese rohen Scan-Ergebnisse in eine verteidigbare "nicht betroffen / betroffen / behoben / in Untersuchung"-Position je CVE überführt, die die Verordnung, die in Entwicklung befindlichen harmonisierten Normen und die deutsche Beschaffung unter BSI TR-03183 Teil 3 erwarten.

Was VEX ist

VEX ist eine strukturierte, maschinenlesbare Aussage darüber, ob eine Schwachstelle in einer Komponente ein bestimmtes Produkt tatsächlich betrifft. Sie beantwortet: "CVE-XXXX existiert in unserem SBOM. Betrifft es unser Produkt, warum oder warum nicht, und was soll der Nutzer tun?" Die vier Kernzustände sind:

Zustand	Bedeutung
not_affected	Schwachstelle existiert in der Komponente, betrifft dieses Produkt aber nicht (anfälliger Codepfad nicht erreichbar, Funktion wird nicht aufgerufen, Konfiguration mitigiert, etc.). Eine Begründung wird erwartet.
affected	Schwachstelle betrifft dieses Produkt. Maßnahme und Empfehlung erwartet.
fixed	Schwachstelle war vorhanden und wurde in dieser Version behoben.
under_investigation	Status noch nicht bestimmt; Bewertung läuft.

CRA-Verbindung

VEX wird im CRA-Text nicht genannt, ist aber das operative Werkzeug hinter drei Klauseln der Verordnung:

• Anhang I Teil I, keine bekannten ausnutzbaren Schwachstellen. Eine not_affected-VEX-Aussage mit dokumentierter Begründung ist der Nachweis, dass Sie einen CVE bewertet und zu dem Schluss gekommen sind, er gilt nicht. Ohne sie ist jede CVE in Ihrer SBOM eine vermutete Haftung.
• Anhang I Teil II, Umgang mit Schwachstellen. VEX ist der Prüfpfad, wie jede CVE von under_investigation zu not_affected, affected oder fixed fortgeschritten ist.
• Artikel 14, Meldeauslöser. Eine als affected markierte Schwachstelle, die bekanntermaßen aktiv ausgenutzt wird, ist genau der Auslöser, der die 24-Stunden-Uhr startet. Eine als not_affected markierte Schwachstelle mit fundierter Begründung ist es nicht.

VEX-Formate

Zwei Formate sind in der Praxis relevant. CycloneDX VEX ist direkt in einem CycloneDX-SBOM unter vulnerabilities[].analysis eingebettet. CSAF VEX ist ein eigenständiges Dokument im CSAF 2.0-Format (das Format, das BSI TR-03183 Teil 3 für Sicherheitshinweise verlangt, und das Format, das deutsche CERTs standardmäßig veröffentlichen und verarbeiten). Beide sind maschinenlesbar und erfüllen dieselbe operative Funktion.

Eine minimale CycloneDX-VEX-Aussage:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

Die CycloneDX 1.5-Spezifikation definiert sechs Analysezustände (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), ein feiner gestuftes Vokabular als die vier Zustände von OpenVEX (not_affected, affected, fixed, under_investigation), auf die es abbildet. BSI TR-03183 Teil 3 erwartet VEX-Aussagen neben SBOMs für CRA-konforme Produkte. Das vollständige SBOM- und BSI-TR-03183-Bild finden Sie im SBOM-Cluster-Leitfaden.

KMU-Ausnahmen und reduzierte Pflichten

Artikel 64(10) gewährt den kleinsten Herstellern eine begrenzte Bußgeldentlastung. Sie befreit niemanden von der Meldepflicht.

Kleinstunternehmen und kleine Unternehmen (definiert als weniger als 50 Beschäftigte und Jahresumsatz oder Bilanzsumme bis 10 Mio. EUR; Kleinstunternehmen: weniger als 10 Beschäftigte, 2 Mio. EUR) sind von Bußgeldern speziell für das Versäumen der 24-Stunden-Frühwarnfristen nach Artikel 14(2)(a) und Artikel 14(4)(a) befreit. Die Entlastung deckt Fristen-Bußgelder nur für die 24-Stunden-Stufe ab.

Weiterhin verpflichtend, ohne KMU-Entlastung:

• Die 72-Stunden-Detailmeldung (Art. 14(2)(b) und 14(4)(b)).
• Der 14-Tage-Abschlussbericht für Schwachstellen und der 1-Monats-Abschlussbericht für schwerwiegende Vorfälle.
• Die CVD-Richtlinie nach Anhang I Teil II.
• Alle anderen CRA-Pflichten einschließlich der Anforderung "keine bekannten ausnutzbaren Schwachstellen" nach Anhang I Teil I.

Mittlere Unternehmen (bis 250 Beschäftigte) sind von der KMU-Entlastung gar nicht erfasst. Die Ausnahme ist eine enge Bußgeld-Carve-out, kein reduziertes Meldungsregime.

Häufige Fehler

• Auf forensische Gewissheit warten, bevor die Uhr gestartet wird. Artikel 14 verwendet den Standard der begründeten Annahme. Auf Beweis zu warten verfehlt die Frist.
• CVD mit Artikel-14-Meldung verwechseln. Eine Forschermeldung ist ein CVD-Eingang; die Artikel-14-Meldung wird ausgelöst, wenn es Nachweis aktiver Ausnutzung gibt. Die CVD-Richtlinie muss einen ausdrücklichen Auslöser dafür enthalten.
• Einzelner Fehlerpunkt bei der Eskalation. Eine Person, die zur Meldung befugt ist und freitagabends nicht erreichbar ist. Die 24-Stunden-Uhr pausiert nicht.
• Erstmaliger Kontakt mit dem Koordinator-CSIRT während eines Vorfalls. Bauen Sie die Beziehung und das Routing jetzt auf, solange keine Uhr läuft.
• Keine veröffentlichte CVD-Richtlinie. Die Pflicht nach Anhang I Teil II ist durch ein internes Dokument nicht erfüllt.
• Keine VEX-Aussagen. Jede CVE in Ihrer SBOM gilt als ausnutzbar, bis Sie das Gegenteil sagen. Anhang I Teil I ist ohne VEX deutlich schwerer zu verteidigen.
• Den SRP-Launch als zukünftiges Problem behandeln. Vorlagen, Bereitschaftsrotationen und CSIRT-Beziehungen müssen vor September 2026 eingerichtet sein, nicht danach.