CRA-Meldung von Schwachstellen und Vorfällen

Seit 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.

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:

1. Aktiv ausgenutzte Schwachstellen im Produkt gleichzeitig an den Koordinator-CSIRT und ENISA melden, im Takt 24h / 72h / 14d.
2. Schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts im Takt 24h / 72h / 1 Monat melden.
3. 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 dem Koordinator-CSIRT, die Weiterverteilung in Ausnahmefällen aus gerechtfertigten cybersicherheitsbezogenen Gründen zu verzögern, und zwar nur so lange, wie es unbedingt erforderlich ist. Der Hersteller kann das anregen und die Sensibilität der Information kennzeichnen. Die Entscheidung liegt aber beim CSIRT, nicht bei Ihnen. Daneben gibt es eine zweite, eigenständige Verzögerung für eine Schwachstelle, von der der Koordinator-CSIRT über ein Verfahren zur koordinierten Offenlegung erfahren hat. Dort kann der CSIRT die Meldung aus gerechtfertigten cybersicherheitsbezogenen Gründen zurückhalten, und zwar nicht länger, als es unbedingt erforderlich ist, und bis die an diesem Verfahren Beteiligten der Offenlegung zustimmen. Das sollten Sie kennen, wenn Sie ein Verfahren zur koordinierten Offenlegung führen. Die Entscheidung liegt aber auch hier beim CSIRT, verlassen Sie sich also nicht darauf, dass ein Embargo hält.
• Besondere Ausnahmeumstände, kurz PEC, sind ein engerer und eigenständiger Mechanismus. Sie greifen nur bei der 72-Stunden-Meldung zu einer aktiv ausgenutzten Schwachstelle und nur aus den drei Gründen, die Artikel 16 Absatz 2 nennt: Die Ausnutzung ist auf den Mitgliedstaat Ihres Koordinators beschränkt, eine weitere Verbreitung liefe den wesentlichen Interessen dieses Staates zuwider, oder die Weiterverteilung selbst würde ein unmittelbar bevorstehendes hohes Cybersicherheitsrisiko schaffen. Sie machen das über einen Schalter in der Plattform geltend und können eine Begründung ergänzen; entschieden wird vom Koordinator-CSIRT. Solange es gilt, erhält ENISA weiterhin einen reduzierten Satz: dass eine Meldung erfolgt ist, allgemeine Produktangaben, die allgemeine Art des Exploits und den Hinweis, dass Sicherheitsgründe geltend gemacht wurden. Die vollständige Meldung folgt, sobald die Verzögerung endet. Das Verfahren beschreiben die PEC-Hinweise von ENISA.

Stand 11. September 2026: Die SRP ist unter portal.cra-srp.enisa.europa.eu verfügbar. Sie wählen dort die Rolle „Assigned Representative“, also das SRP-Konto, das für einen Hersteller oder einen Verwalter quelloffener Software meldet, nicht dasselbe wie ein CRA-Bevollmächtigter. Die Anmeldung läuft über ein persönliches EU-Login-Konto mit aktivierter Multi-Faktor-Authentifizierung. ENISA hat FAQ und Registrierungsleitfaden am 10. September 2026 aktualisiert, Oberflächen-Leitfaden und Meldeleitfaden am 9. September 2026. Am 9. September 2026 ist zudem ein 55-seitiges AR User Manual erschienen, der Weg Klick für Klick durch Registrierung, die drei Meldestufen und die Aktualisierung einer Meldung. Das SRP-Glossar liegt in Version 1.3 vor und ist die Feld-für-Feld-Referenz, nur auf Englisch; die Liste der Koordinator-CSIRTs trägt den 10. September 2026. Eine SRP-API gibt es im ersten Release nicht, Meldungen laufen über die Oberfläche. Freiwillige Meldungen kommen erst in einer späteren Phase. ENISA kennzeichnet all das als vorläufigen Kenntnisstand. Legen Sie das EU-Login-Konto jetzt an, nutzen Sie den ENISA-SRP-Onboarding-Leitfaden und wenden Sie sich bei Bedarf an cra-srp-helpdesk@enisa.europa.eu.

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

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.

1. Kenntnis des Herstellers. Die 24-Stunden-Uhr startet, wenn eine unverzügliche Erstbewertung dem Hersteller hinreichende Gewissheit gibt, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird.
2. +24h Frühwarnung. Erste Warnung über die ENISA Single Reporting Platform einreichen.
3. +72h Detaillierte Meldung. Technische Details, betroffene Versionen, Ausnutzungsstatus und Mitigationsstatus ergänzen.
4. Maßnahme verfügbar. Für Schwachstellen beginnt hier die Frist für den Abschlussbericht, nicht bei der Entdeckung.
5. +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

Das SRP-Glossar von ENISA ist die Feld-für-Feld-Referenz dafür, was die Plattform auf jeder Stufe abfragt. Version 1.3 führt 39 Felder auf: 18 gemeinsame Felder, 12 nur für eine aktiv ausgenutzte Schwachstelle und 9 nur für einen schwerwiegenden Vorfall. Es liegt nur auf Englisch vor, und ENISA kennzeichnet es als aktuellen Kenntnisstand mit Änderungsvorbehalt. Codes: X verpflichtend, O optional, C aus dem vorherigen Schritt übernommen oder aktualisiert, I verpflichtend, sofern die Information verfügbar ist, - auf dieser Stufe nicht anwendbar.

Schweregradkriterien (i34): 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: SRP-Glossar von ENISA, Version 1.3, Stand 10. September 2026.

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

Kenntnis und Nachweise

Die CRA-Definition verwendet verlässliche Nachweise, um eine aktiv ausgenutzte Schwachstelle zu bestimmen. Die Kenntnis ist eine separate Prüfung: Nach einer unverzüglichen Erstbewertung muss der Hersteller hinreichende Gewissheit haben, dass eine Schwachstelle in seinem Produkt aktiv ausgenutzt wird. Eine abgeschlossene forensische Untersuchung ist nicht erforderlich.

CVD-Eingang und Meldeschwelle

Die CVD-Richtlinie ist der Eingangskanal, der externe Forschermeldungen in strukturierte Triage überführt. Deutet die Triage auf aktive Ausnutzung hin, ist sie unverzüglich zu bewerten. Die Meldeuhr startet, sobald diese Erstbewertung dem Hersteller hinreichende Gewissheit gibt. 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:

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. Eine unverzügliche Erstbewertung und hinreichende Gewissheit reichen; eine abgeschlossene forensische Untersuchung ist nicht erforderlich.
• CVD mit dringender Meldung verwechseln. Eine Forschermeldung ist CVD-Eingang; die dringende Meldung startet, wenn die Erstbewertung dem Hersteller hinreichende Gewissheit über die aktive Ausnutzung gibt. 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.
• Die SRP-Meldung als Zukunftsproblem behandeln. Vorlagen, Eskalationsrotationen und CSIRT-Beziehungen müssen vor dem ersten Ereignis stehen, nicht danach aufgebaut werden.

1. Das Glossar führt dieses Feld als verpflichtend bei der 24-Stunden-Frühwarnung und hält in derselben Zeile fest, dass es erst mit dem nächsten Release der Plattform kommt. Bis dieses Release da ist, finden Sie es womöglich nicht auf dem Bildschirm. Halten Sie Ihren eigenen Kenntniszeitpunkt fest, damit Sie ihn in beiden Fällen angeben können. ↩︎

2. Das Glossar weist darauf hin, dass dieses Feld im aktuellen Release „Date and time when the incident was detected (UTC time)“ heißt. Erkennung ist nicht dasselbe wie Kenntnisnahme, halten Sie deshalb beides fest. ↩︎