Ab dem 11. September 2026 müssen CRA-Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die ENISA Single Reporting Platform melden. Dieser Leitfaden erklärt, was eine Meldung auslöst, wie die Fristen von 24 Stunden, 72 Stunden, 14 Tagen und 1 Monat funktionieren und wo CVD, VEX und Nutzerinformationen in den Ablauf passen.
Zusammenfassung
- Dringende Meldungen beginnen am 11. September 2026: Beide Meldepfade nutzen eine 24h-Frühwarnung und eine 72h-Meldung; der Abschlussbericht ist bei Schwachstellen 14 Tage nach Verfügbarkeit einer Korrektur- oder Mitigationsmaßnahme fällig und bei schwerwiegenden Vorfällen binnen 1 Monat nach der 72h-Meldung.
- Einmal über die ENISA SRP einreichen: Die Plattform leitet die Meldung an den Koordinator-CSIRT und macht sie für ENISA zugänglich.
- Aktive Ausnutzung verlangt verlässliche Nachweise, dass ein böswilliger Akteur die Schwachstelle ohne Zustimmung des Systemeigners in einem System ausgenutzt hat; Offenlegung, ein öffentlicher PoC oder eine Forscher-Demonstration reichen allein nicht.
- Eine CVD-Richtlinie ist verpflichtend: schriftlich, veröffentlicht, umgesetzt und mit der Meldeschwelle verbunden, wenn die Triage aktive Ausnutzung feststellt.
- VEX unterstützt Meldeentscheidungen, indem dokumentiert wird, ob eine CVE in einer SBOM-Komponente das Produkt tatsächlich betrifft.
- Sanktionsdetails gehören in den Enforcement-Leitfaden: verspätete oder fehlende Meldungen können erhebliches Bußgeldrisiko auslösen; die Stufen und KMU-Ausnahmen stehen in CRA-Bußgelder und Durchsetzung.
Das Meldemodell in der Praxis: Frühwarnung, detaillierte Meldung, Abschlussbericht und Verweis auf die Durchsetzung.
Was gemeldet werden muss
CRA-Meldungen haben zwei verpflichtende Ereignisströme und eine Pflicht zur Nutzerinformation. Die Pflicht liegt beim Hersteller des Produkts mit digitalen Elementen, das auf dem EU-Markt bereitgestellt wird:
- Aktiv ausgenutzte Schwachstellen im Produkt gleichzeitig an den Koordinator-CSIRT und ENISA melden, im Takt 24h / 72h / 14d.
- Schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts im Takt 24h / 72h / 1 Monat melden.
- Betroffene Nutzer ohne unangemessene Verzögerung über die Schwachstelle oder den Vorfall und über Korrekturmaßnahmen informieren.
Diese Seite behandelt außerdem zwei angrenzende Kontrollen, die in die Meldeentscheidung einfließen: die verpflichtende CVD-Richtlinie und Nachweise zur Anwendbarkeit von Schwachstellen wie VEX. Keine dieser Pflichten hat eine Größenschwelle. Kleinstunternehmen und kleine Unternehmen erhalten nur eine enge Bußgeldentlastung für die 24h-Frühwarnung; von der Meldung sind sie nicht befreit.
Die ENISA Single Reporting Platform (SRP)
Die SRP ist der einzige Kanal für verpflichtende CRA-Meldungen zu Schwachstellen und Vorfällen. Sie existiert, weil der Hersteller den Koordinator-CSIRT und ENISA über eine Meldeplattform informieren muss, statt in jedem Mitgliedstaat separat einzureichen, in dem das Produkt verfügbar ist. ENISA richtet und verwaltet die Plattform.
So funktioniert es praktisch:
- Sie reichen einmal ein, über den elektronischen Endpunkt des als Koordinator benannten CSIRT.
- Die Einreichung ist an den Koordinator-CSIRT adressiert und für ENISA gleichzeitig zugänglich, sofern der außergewöhnliche Mechanismus zur Verzögerung der Weiterverteilung nicht greift.
- Der Koordinator-CSIRT verteilt die Meldung anschließend an CSIRTs in anderen Mitgliedstaaten, in denen Ihr Produkt auf dem Markt bereitgestellt wird. Diese Weiterverteilung ist Aufgabe des CSIRT, nicht des Herstellers.
- Die Regel zur verzögerten Weiterverteilung erlaubt einem CSIRT, die Weiterverteilung aus gerechtfertigten cybersicherheitsbezogenen Gründen in Ausnahmefällen zu verzögern. Die Regel zur koordinierten Offenlegung kann mit Zustimmung des Herstellers ebenfalls eine Verzögerung erlauben.
Stand Juni 2026: Die SRP soll bis zum 11. September 2026 betriebsbereit sein, mit einer Testphase davor. ENISA kündigt an, die Zugangs- und Registrierungsanleitung sowie Schulungs- und Testmaterial im Juni 2026 bereitzustellen; diese Unterlagen sind noch nicht veröffentlicht. ENISA hat außerdem angekündigt, dass für diese Phase keine SRP-API bereitgestellt wird. Planen Sie die Meldebereitschaft daher um die Einreichung über die Plattform selbst, nicht über eine API-Anbindung. Zu den Registrierungsmechanismen im Einzelnen siehe ENISA-SRP-Onboarding. Prüfen Sie die Kommissionsseite zur CRA-Meldung und die ENISA-SRP-Seite, bevor Sie sich auf einen konkreten Registrierungsschritt verlassen.
Was Hersteller jetzt tun sollten: Identifizieren Sie Ihren Koordinator-CSIRT, entwerfen und genehmigen Sie Berichtsvorlagen für die 24h-, 72h- und Abschlussberichte in beiden Meldepfaden 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
Beide Ströme, Schwachstellen und schwerwiegende Vorfälle, folgen einem gestuften Meldeverfahren. Die Fristen unterscheiden sich beim Abschlussbericht.
Meldeübersicht
| Phase | Schwachstelle | Schwerwiegender Vorfall | Fristanker |
|---|---|---|---|
| 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 Mitigationsmaßnahme | 1 Monat nach der 72-Stunden-Vorfallsmeldung | Unterschiedlicher Anker je Pfad |
| Nutzerinformation | Ohne unangemessene Verzögerung | Ohne unangemessene Verzögerung | Nutzerinformation |
Was jede Einreichung enthält
Frühwarnung (24 Stunden). Die Frühwarnung ist ein Alarm, keine vollständige Analyse. Für Schwachstellen muss sie ohne unangemessene Verzögerung und binnen 24 Stunden ab Kenntnis erfolgen und gegebenenfalls die Mitgliedstaaten nennen, in denen der Hersteller weiß, dass das Produkt bereitgestellt wurde. Bei schwerwiegenden Vorfällen muss sie mindestens angeben, ob der Vorfall vermutlich durch rechtswidrige oder böswillige Handlungen verursacht wurde. Interne Vorlagen können Produktversion, Schweregrad, Auswirkungsumfang und Verantwortliche ergänzen; das sind operative Felder, nicht sämtlich rechtliche Mindestangaben.
Detaillierte Meldung (72 Stunden). Zwei separate Pflichten liegen auf dieser Stufe. Die 72-Stunden-Schwachstellenmeldung betrifft aktiv ausgenutzte Schwachstellen und enthält allgemeine Informationen zum Produkt, zur Ausnutzung, zur Schwachstelle, zu ergriffenen Maßnahmen, zu Nutzermaßnahmen und gegebenenfalls zur Sensitivität. Die 72-Stunden-Vorfallsmeldung betrifft schwerwiegende Vorfälle und enthält allgemeine Informationen zum Vorfall, eine erste Bewertung, ergriffene Maßnahmen, Nutzermaßnahmen und gegebenenfalls Sensitivität.
Abschlussbericht. Für Schwachstellen beginnt die 14-Tage-Frist, wenn eine Korrektur- oder Mitigationsmaßnahme verfügbar ist, nicht bei Entdeckung und nicht bei der 72-Stunden-Meldung. Der Abschlussbericht muss mindestens Beschreibung, Schweregrad und Auswirkungen der Schwachstelle, verfügbare Informationen zu böswilligen Akteuren sowie Details zum Sicherheitsupdate oder anderen Korrekturmaßnahmen enthalten. Bei schwerwiegenden Vorfällen beginnt die Monatsfrist mit der 72-Stunden-Vorfallsmeldung; der Abschlussbericht muss mindestens eine detaillierte Vorfallbeschreibung, Schweregrad und Auswirkungen, wahrscheinlichen Bedrohungstyp oder Ursache sowie angewandte oder laufende Mitigationsmaßnahmen enthalten.
- Kenntnis des Herstellers. Die 24-Stunden-Uhr startet, wenn der Hersteller von verlässlichen Nachweisen aktiver Ausnutzung Kenntnis erlangt.
- +24h Frühwarnung. Erste Warnung über die ENISA Single Reporting Platform einreichen.
- +72h Detaillierte Meldung. Technische Details, betroffene Versionen, Ausnutzungsstatus und Mitigationsstatus ergänzen.
- Maßnahme verfügbar. Für Schwachstellen beginnt hier die Frist für den Abschlussbericht, nicht bei der Entdeckung.
- +14d Abschlussbericht. Die erforderlichen Abschlussangaben für den Schwachstellen- oder Vorfallpfad einreichen.
Schwerwiegende Vorfälle folgen denselben 24- und 72-Stunden-Eröffnungsschritten; der Abschlussbericht ist binnen 1 Monat nach der 72-Stunden-Meldung fällig.
Datenfelder in der SRP-Meldeformularvorlage
Die FAQ der ENISA-SRP (F16) listet die Felder auf, die bei jeder Meldephase erwartet werden. ENISA stuft diese Felder als voraussichtlich verpflichtend (unmittelbar aus der Verordnung oder als logische Folge) oder optional ein; sie sind daher als vorläufig zu behandeln, bis die Plattform final ist. Codes: X verpflichtend, O optional, C aus dem vorherigen Schritt übernommen oder aktualisiert, A automatisch (nicht für den Einreicher sichtbar), I verpflichtend, sofern die Information verfügbar ist.
| # | Feld | 24h | 72h | Abschluss |
|---|---|---|---|---|
| Gemeinsame Felder | ||||
| 1 | Meldungstyp (Schwachstelle / Vorfall) | X | C | C |
| 2 | Meldestufe (24h / 72h / Abschluss) | X | X | X |
| 3 | Meldezeit, 24h | A | A | A |
| 4 | Meldezeit, 72h | A | A | A |
| 5 | Meldezeit, Abschluss | A | A | A |
| 6 | Meldender | A | A | A |
| 7 | Hersteller | X | C | C |
| 8 | Produkt | X | C | C |
| 9 | Produkttyp (Standard / wichtig / kritisch) | O | C | C |
| 10 | Produktkategorie (wenn Typ wichtig oder kritisch ist) | O | C | C |
| 11 | Mitgliedstaaten, in denen das Produkt verfügbar ist | I | C | C |
| 12 | Titel | X | C | C |
| Schwachstelle | ||||
| v13 | CVE-ID | O | C | C |
| v14 | EUVD-ID | O | C | C |
| v15 | Allgemeine Informationen, insbesondere: | O | X | C |
| v16 | a. Allgemeine Art der Schwachstelle | O | X | C |
| v17 | b. Allgemeine Art der Ausnutzung | O | X | C |
| v18 | Ergriffene Korrektur- oder Mitigationsmaßnahmen | O | X | C |
| v19 | Korrektur- oder Mitigationsmaßnahmen, die Nutzer ergreifen können | O | X | C |
| v20 | Berücksichtigte Informationssensitivität | O | I | C |
| v21 | Datum, an dem eine Korrektur- oder Mitigationsmaßnahme verfügbar wurde | O | O | X |
| v22 | Vollständige Beschreibung der Schwachstelle, einschl.: | O | O | X |
| v23 | a. Schweregrad der Schwachstelle | O | O | X |
| v24 | b. Auswirkungen der Schwachstelle | O | O | X |
| v25 | Böswilliger Akteur, der sie ausgenutzt hat oder ausnutzt | O | O | I |
| v26 | Details zum Sicherheitsupdate oder zu Korrekturmaßnahmen | O | O | X |
| Vorfall | ||||
| i13 | Vorfall vermutlich durch rechtswidrige oder böswillige Handlungen verursacht | X | C | C |
| i14 | Allgemeine Informationen zur Art des Vorfalls | O | X | C |
| i15 | Datum und Uhrzeit der Erkennung des Vorfalls | O | X | C |
| i16 | Datum und Uhrzeit des Eintretens des Vorfalls | O | X | C |
| i17 | Erste Bewertung des Vorfalls | O | X | C |
| i18 | Ergriffene Korrektur- oder Mitigationsmaßnahmen | O | X | C |
| i19 | Korrektur- oder Mitigationsmaßnahmen, die Nutzer ergreifen können | O | X | C |
| i20 | Berücksichtigte Informationssensitivität | O | I | C |
| Detaillierte Beschreibung des Vorfalls, einschl.: | O | O | X | |
| i21 | a. Schweregrad des Vorfalls (Kriterien unten) | O | O | X |
| i23 | b. Auswirkungen des Vorfalls | O | O | X |
| i24 | Art der Bedrohung oder wahrscheinliche Ursache | O | O | X |
| i25 | Angewandte und laufende Mitigationsmaßnahmen | O | O | X |
Schweregradkriterien (i22): Ein schwerwiegender Vorfall liegt vor, wenn er (1) die Fähigkeit des Produkts, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, beeinträchtigt oder beeinträchtigen kann, oder wenn er (2) zur Einführung oder Ausführung böswilligen Codes im Produkt oder im Netzwerk und Informationssystem eines Nutzers geführt hat oder führen kann.
Quelle: ENISA SRP FAQ, F16.
Was eine Meldepflicht auslöst
CRA-Meldungen haben zwei Auslöserkategorien: aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts.
1. Aktiv ausgenutzte Schwachstellen
Eine aktiv ausgenutzte Schwachstelle ist eine Schwachstelle im Produkt, bei der verlässliche Nachweise zeigen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners in einem System ausgenutzt hat. Der Hersteller muss außerdem Kenntnis von dieser Ausnutzung erlangt haben, bevor die Meldeuhr startet.
Das ist nicht dasselbe wie öffentliche Offenlegung, ein veröffentlichter Proof-of-Concept oder eine Demonstration der Ausnutzbarkeit im Labor. Solche Signale gehören in Schwachstellenbehandlung und CVD-Triage, solange sie keine verlässlichen Nachweise böswilliger Ausnutzung gegen ein reales System liefern.
2. Schwerwiegende Vorfälle
Ein schwerwiegender Vorfall ist ein Vorfall mit Auswirkungen auf die Produktsicherheit, der eines der Kriterien erfüllt:
- er beeinträchtigt oder kann die Fähigkeit des Produkts beeinträchtigen, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen; oder
- er hat zur Einführung oder Ausführung böswilligen Codes im Produkt oder im Netzwerk und Informationssystem eines Nutzers geführt oder kann dazu führen.
Meldepflichtige vs. nicht meldepflichtige Szenarien
| Szenario | Meldepflichtig? | Warum |
|---|---|---|
| Forscher meldet Schwachstelle privat | Nein | Kein Ausnutzungsnachweis; über CVD behandeln |
| PoC auf GitHub veröffentlicht | Nein | Veröffentlichung ist keine Ausnutzung |
| Kunde meldet Aktivität, die zu Ausnutzung passt | Prüfen | Melden, wenn die Nachweise verlässlich genug sind, um aktive Ausnutzung zu zeigen |
| Schwachstelle wird in freier Wildbahn ausgenutzt | Ja | Verlässlicher Nachweis böswilliger Nutzung |
| Komponente in Ihrer SBOM hat eine bekannte ausgenutzte CVE | Prüfen | Meldepflichtig nur, wenn die Ausnutzung Ihr Produkt betrifft (VEX ist hier relevant) |
| Ihr Produkt wird von benannten Bedrohungsakteuren angegriffen | Ja | Direkter Ausnutzungsnachweis |
| Generische Malware nutzt eine Schwachstellenklasse, die Ihr Produkt hat | Prüfen | Nur wenn Ihre konkrete Implementierung betroffen ist |
Kenntnis und Nachweise
Die CRA-Definition verwendet verlässliche Nachweise, nicht forensische Gewissheit. Nützliche Nachweise können Exploit-Telemetrie, Kundenberichte über Kompromittierung, Threat Intelligence mit Nennung Ihres Produkts oder Logs mit Exploit-Verhalten gegen das Produkt sein. Sind die Nachweise noch nicht verlässlich, bleibt der Vorgang in CVD- oder Incident-Triage; werden sie verlässlich, startet die 24-Stunden-Uhr, wenn der Hersteller Kenntnis erlangt.
CVD-Eingang und Meldeschwelle
Die CVD-Richtlinie ist der Eingangskanal, der externe Forschermeldungen in strukturierte Triage überführt. Wenn diese Triage verlässliche Nachweise aktiver Ausnutzung ergibt, läuft die dringende Meldung parallel zu Behebung und koordinierter Offenlegung. Die Richtlinie ist für jedes Produkt mit digitalen Elementen verpflichtend, ohne KMU- oder Größenschwelle. Eine öffentliche CVD-Seite plus security.txt unter /.well-known/security.txt ist der praktische Weg, den Meldekanal auffindbar zu machen.
Für die CVD-Richtlinie selbst, einschließlich erforderlicher Inhalte, Offenlegungsfenster, Safe-Harbour-Sprache und Forscherkommunikationsvorlagen, siehe den eigenen CRA-Leitfaden zur koordinierten Schwachstellenoffenlegung. Wie CVD in den weiteren Lebenszyklus der Schwachstellenbehandlung passt, zeigt CRA-Schwachstellenbehandlung.
VEX und Schwachstellen-Anwendbarkeit
VEX (Vulnerability Exploitability eXchange) ist eine strukturierte, maschinenlesbare Aussage darüber, ob eine Schwachstelle in einer SBOM-Komponente ein bestimmtes Produkt tatsächlich betrifft. VEX überführt rohe CVE-Treffer in einen verteidigbaren produktspezifischen Status:
| Status | Bedeutung |
|---|---|
not_affected |
Schwachstelle existiert in der Komponente, betrifft aber dieses Produkt nicht (verwundbarer Codepfad unerreichbar, Funktion nicht aufgerufen, Konfiguration mitigiert usw.). 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. |
Für die Meldung zählt Anwendbarkeit plus aktive Ausnutzung. Eine als affected markierte Schwachstelle mit verlässlichen Nachweisen aktiver Ausnutzung kann die 24h-Frühwarnung auslösen. Eine als not_affected markierte Schwachstelle mit belastbarer Begründung stützt dagegen eine Nichtmeldung. Die CRA nennt VEX nicht, aber VEX ist ein praktischer Weg, diese Begründung aufzubewahren. Formate, Beispiele, Begründungstypen, Tooling und SBOM-Integration behandelt der VEX-Implementierungsleitfaden.
Entlastung für kleine Hersteller
Kleinstunternehmen und kleine Unternehmen (weniger als 50 Beschäftigte und Jahresumsatz oder Bilanzsumme bis 10 Mio. EUR; Kleinstunternehmen: weniger als 10 Beschäftigte, 2 Mio. EUR) sind nur für das Versäumen der ersten 24h-Frühwarnung von Bußgeldern befreit. Die Entlastung betrifft nur diese erste Frist.
Weiterhin erforderlich, ohne KMU-Entlastung:
- Die detaillierte 72h-Meldung.
- Der 14-Tage-Abschlussbericht für Schwachstellen und der 1-Monats-Abschlussbericht für schwerwiegende Vorfälle.
- Die CVD-Richtlinie.
- Alle übrigen CRA-Produktsicherheitspflichten, einschließlich der Basislinie ohne bekannte ausnutzbare Schwachstellen.
Mittlere Unternehmen sind nicht erfasst. Es ist eine enge Bußgeldausnahme, kein reduziertes Meldeprogramm. Die breitere Struktur steht in CRA-Bußgelder und Durchsetzung.
Häufige Fehler
- Auf forensische Gewissheit warten, bevor die Uhr startet. Verlässliche Nachweise reichen; die CRA verlangt keine abgeschlossene forensische Untersuchung vor der Frühwarnung.
- CVD mit dringender Meldung verwechseln. Eine Forschermeldung ist CVD-Eingang; dringende Meldung startet bei verlässlichen Nachweisen aktiver Ausnutzung. Die CVD-Richtlinie muss dafür eine explizite Schwelle enthalten.
- Single Point of Failure in der Eskalation. Eine meldeberechtigte Person ist am Freitagabend nicht erreichbar. Die 24-Stunden-Uhr pausiert nicht.
- Erstkontakt mit dem Koordinator-CSIRT während eines Vorfalls. Beziehung und Routing jetzt aufbauen, solange keine Uhr läuft.
- Keine veröffentlichte CVD-Richtlinie. Eine öffentliche Richtlinie ist erforderlich; ein internes Dokument reicht nicht aus.
- Keine Anwendbarkeitsentscheidungen. Ohne VEX oder einen gleichwertigen Nachweis ist schwer zu verteidigen, warum eine bekannte CVE in Ihrer SBOM in Ihrem Produkt nicht ausnutzbar ist.
- SRP-Start als Zukunftsproblem behandeln. Vorlagen, Eskalationsrotationen und CSIRT-Beziehungen müssen vor September 2026 stehen, nicht danach aufgebaut werden.
Häufig gestellte Fragen
Ab wann gelten die CRA-Meldepflichten?
Die verpflichtende CRA-Meldung von Schwachstellen und Vorfällen beginnt am 11. September 2026. Ab diesem Datum müssen Hersteller die ENISA Single Reporting Platform für Frühwarnung, 72h-Meldung und Abschlussberichte nutzen. Die breiteren Produktsicherheitsanforderungen, einschließlich der Anforderung "keine bekannten ausnutzbaren Schwachstellen", gelten ab dem 11. Dezember 2027.
Was ist die ENISA Single Reporting Platform (SRP)?
Die SRP ist der einheitliche Kanal für verpflichtende CRA-Meldungen und freiwillige Meldungen; ENISA hat angekündigt, dass die Funktionalität für freiwillige Meldungen erst nach dem 11. September 2026 aktiviert wird. Ein Hersteller reicht einmal über den Koordinator-CSIRT-Endpunkt ein; die Meldung ist für ENISA gleichzeitig zugänglich, sofern der außergewöhnliche Verzögerungsmechanismus nicht greift. Aktuelle Hinweise von Kommission und ENISA sagen, dass die Plattform bis 11. September 2026 betriebsbereit sein soll, mit einer Testphase davor. Verfolgen Sie die Kommissionsseite zur CRA-Meldung und die ENISA-SRP-Seite für Registrierungsdetails.
Ist eine Richtlinie zur koordinierten Schwachstellenoffenlegung (CVD) erforderlich?
Ja. Jeder CRA-Hersteller braucht eine CVD-Richtlinie und einen praktischen Eingangskanal für Schwachstellenmeldungen. Die Verordnung schreibt keine vollständige Vorlage vor, aber eine belastbare Richtlinie deckt normalerweise Umfang, Kontaktwege, Bearbeitung, Offenlegungszeitpunkt, Forscherkommunikation und die Eskalationsschwelle für aktive Ausnutzung ab. security.txt wird in der CRA nicht namentlich genannt, ist aber ein praktischer Weg, die Kontaktadresse zu veröffentlichen, die die Schwachstellenbehandlung verlangt.
Was ist VEX und brauche ich es für CRA-Compliance?
VEX ist nicht namentlich verpflichtend, aber ein Anwendbarkeitsnachweis ist sehr nützlich. Er dokumentiert, ob eine CVE in einer SBOM-Komponente für eine konkrete Produktversion not_affected, affected, fixed oder noch under_investigation ist. Dieser Nachweis unterstützt sowohl die Priorisierung der Behebung als auch die Entscheidung, dass eine bekannte CVE nicht meldepflichtig ist, weil sie das Produkt nicht betrifft. Formate und Implementierungsdetails finden Sie im VEX-Implementierungsleitfaden.
Welche Bußgelder drohen bei verspäteten oder fehlenden Meldungen?
Verspätete oder fehlende Meldungen können erhebliches Durchsetzungsrisiko auslösen; nur für Kleinst- und kleine Unternehmen gibt es eine enge Entlastung bei der ersten 24h-Frühwarnung. Siehe CRA-Bußgelder und Durchsetzung für die vollständige Struktur.
Wo reiche ich ein, wenn mein Produkt in mehreren Mitgliedstaaten verkauft wird?
Reichen Sie einmal über den SRP-Endpunkt Ihres Koordinator-CSIRT ein. Für einen EU-Hersteller ist das der Mitgliedstaat, in dem die Cybersicherheitsentscheidungen für das Produkt überwiegend getroffen werden. Gibt es keine Hauptniederlassung in der Union, gilt die Kaskade: Bevollmächtigter, dann Einführer, dann Händler, dann größte Nutzerkonzentration. Sie reichen nicht in jedem Mitgliedstaat separat ein, in dem das Produkt verkauft wird.
Pausiert die 24-Stunden-Uhr an Wochenenden und Feiertagen?
Nein. Die Meldefristen laufen in Kalenderzeit. Die 24h- und 72h-Fristen laufen ab Kenntnis des Herstellers; der Schwachstellen-Abschlussbericht läuft ab Verfügbarkeit einer Korrektur- oder Mitigationsmaßnahme; der Abschlussbericht für schwerwiegende Vorfälle läuft ab der 72h-Vorfallsmeldung. Wochenend- und Feiertagsabdeckung ist daher eine operative Anforderung, kein Nice-to-have.
Wie verhält sich die CRA-Meldung zu NIS 2?
CRA-Meldung und NIS-2-Meldung können beide auf dasselbe Ereignis anwendbar sein, sind aber nicht dieselbe Pflicht. CRA-Meldung ist produktbezogen und läuft über die SRP. NIS-2-Meldung ist organisations- oder dienstbezogen und folgt dem nationalen NIS-2-Kanal für erhebliche Vorfälle. Solange ENISA, Kommission oder nationale Behörden keine endgültigen Routing-Hinweise veröffentlichen, sollte jede Behauptung, eine Einreichung erfülle beide Regime, als unbestätigt gelten.