Schwachstellen-Meldepflicht ab September 2026

Was sich ab September 2026 ändert

Während die vollumfänglichen CRA-Pflichten erst am 11. Dezember 2027 greifen, gilt eine wichtige Ausnahme: **Die Schwachstellen-Meldepflicht nach Artikel 14 der EU-Verordnung 2024/2847 tritt bereits am 11. September 2026 in Kraft.**¹

Konkret bedeutet das: Ab diesem Datum müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb enger Fristen an europäische und nationale Behörden melden — unabhängig davon, ob sie die übrigen CRA-Pflichten bereits vollständig umgesetzt haben.

Wer am 12. September 2026 keine dokumentierten Meldeprozesse hat, verstößt bereits gegen geltendes EU-Recht.

Praxis-Einschätzung: September 2026 klingt noch weit weg. Ist es nicht. Ein funktionierender Meldeprozess ist nicht in einer Woche aufgesetzt — er erfordert interne Zuständigkeiten, vorbereitete Meldevorlagen, ENISA-Kontaktdaten, einen Eskalationsplan für Krisensituationen und getestete Abläufe. Wer damit im August 2026 anfängt, wird die ersten Wochen auf Abruf arbeiten. Wer jetzt anfängt, hat Zeit, den Prozess in Ruhe zu entwickeln und zu testen.

Wen die Meldepflicht trifft

Pflicht nach Artikel 14 CRA: Die Meldepflicht gilt für alle Hersteller von Produkten mit digitalen Elementen, die ihren Sitz in der EU haben oder deren Produkte auf dem EU-Markt bereitgestellt werden.¹

Ausgenommen sind:

• Produkte, die ausschließlich für militärische oder nationale Sicherheitszwecke entwickelt wurden (Artikel 2 Absatz 5)
• Open-Source-Software, die nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird — allerdings ist die Abgrenzung im Einzelfall zu prüfen

Händler und Importeure haben eigene, weniger strenge Meldepflichten (Weiterleitung an Hersteller), sind aber nicht direkt gegenüber ENISA meldepflichtig.

Das ist der Punkt, den viele übersehen: Betroffen sind nicht nur große Softwarekonzerne. Ein IoT-Startup, das Temperaturregler mit WLAN-Schnittstelle verkauft, fällt genauso darunter wie ein Maschinenbauer, der industrielle MQTT-Gateways für die Fertigungsautomatisierung liefert. Sobald das Produkt digitale Elemente enthält und auf dem EU-Markt landet, greift Artikel 14.

Ein Hersteller von embedded-Software für Heizungssteuerungen — typischerweise fünf bis fünfzehn Entwickler, kein eigenes Security-Team — trifft dieselbe Frist wie ein Netzwerkhersteller mit hundert Sicherheitsingenieuren. Die Verordnung unterscheidet hier nicht nach Unternehmensgröße.

Was gemeldet werden muss

Artikel 14 unterscheidet zwei Kategorien meldepflichtiger Ereignisse:¹

Kategorie 1: Aktiv ausgenutzte Schwachstellen

Eine Schwachstelle gilt als „aktiv ausgenutzt” (englisch: exploited vulnerability), wenn es konkrete Hinweise darauf gibt, dass ein Angreifer sie in der Praxis zur Kompromittierung von Systemen nutzt. Dazu zählen:

• Einträge im CISA KEV-Katalog (Known Exploited Vulnerabilities)
• Threat-Intelligence-Meldungen mit Exploit-Nachweis
• Eigene Beobachtungen in Incident-Response-Berichten

Eine rein theoretische oder proof-of-concept-basierte Schwachstelle ohne nachgewiesene Ausnutzung fällt nicht in diese Kategorie, sollte aber im Rahmen des Schwachstellenmanagements nach Anhang I dennoch behandelt werden.

Kategorie 2: Schwerwiegende Sicherheitsvorfälle

Ein Sicherheitsvorfall gilt als meldepflichtig, wenn er die Sicherheit des Produkts oder seiner Nutzer erheblich beeinträchtigt. Als schwerwiegend gilt ein Vorfall insbesondere dann, wenn er:

• die Verfügbarkeit, Integrität oder Vertraulichkeit des Produkts dauerhaft beeinträchtigt,
• eine große Anzahl von Nutzern betrifft,
• zu erheblichen Schäden bei Nutzern führen kann.

Die drei Meldefristen

Pflicht nach Artikel 14 Abs. 1–3 CRA: Die Fristenstruktur ist gestaffelt und orientiert sich am NIS2-Vorbild:¹

Die 24-Stunden-Frist beginnt mit dem Zeitpunkt, zu dem der Hersteller Kenntnis von der aktiven Ausnutzung erlangt — nicht mit dem Zeitpunkt der Entdeckung der Schwachstelle selbst. Interne Monitoring- und Eskalationsprozesse müssen deshalb so ausgelegt sein, dass Kenntnis nicht unnötig verzögert wird.

Praxis-Einschätzung: Die 24-Stunden-Frist klingt machbar. Bis man merkt, was dafür tatsächlich bereitstehen muss. Sicherheitsvorfälle werden oft nachts, am Wochenende oder während der Urlaubszeit entdeckt. Dann muss innerhalb von 24 Stunden jemand erreichbar sein, eine Einschätzung treffen, eine Meldung bei ENISA einreichen und intern eskalieren. Ohne vorbereitete Abläufe, klare Zuständigkeiten und vorausgefüllte Meldevorlagen ist diese Frist unter Krisendruck praktisch nicht einzuhalten. Das ist mehr Prozessarbeit, als die meisten Hersteller beim ersten Lesen erwarten.

Was die Meldung enthalten muss

Pflicht nach Artikel 14 Absatz 3 CRA: Der Abschlussbericht nach 14 Tagen muss mindestens folgende Informationen enthalten:¹

1. Produktidentifikation — Name, Version(en), Hersteller, CVE-Nummer falls zugewiesen
2. Beschreibung der Schwachstelle — Angriffsvektor, CVSS-Score oder vergleichbare Bewertung
3. Ausnutzungs-Status — Nachweis der aktiven Ausnutzung, bekannte Angriffs-Toolkits oder Kampagnen
4. Betroffene Nutzerbasis — Schätzung der betroffenen Systeme oder Installationen
5. Ergriffene Sofortmaßnahmen — Workarounds, temporäre Fixes, Kommunikation an Nutzer
6. Stand der Patch-Entwicklung — geplanter Zeitplan für einen permanenten Fix
7. Koordination — ob und mit welchen CERTs, Forschern oder Herstellern koordiniert wurde
8. Empfehlungen für Nutzer — konkrete Handlungsanweisungen bis zur Verfügbarkeit eines Patches

Was viele CRA-Berater nicht sagen: Ein Hersteller von embedded-Software für Heizungssteuerungen — typischerweise ein kleines Team, kein eigenes Security-Operations-Center — muss denselben Abschlussbericht liefern wie ein großer Netzwerkhersteller. In der Praxis erleben wir, dass genau diese Unternehmen die Anforderungen unterschätzen, weil sie sich nicht als „Cybersicherheitsakteure” verstehen. Sind sie aber.

Wohin wird gemeldet?

Die ENISA betreibt als zuständige EU-Agentur eine Single-Entry-Point-Plattform für CRA-Meldungen.² Hersteller melden primär an diese Plattform; ENISA koordiniert dann mit den nationalen Behörden.

Zusätzlich kann eine direkte Meldung an die zuständige nationale Behörde erforderlich sein. In Deutschland ist das für Cybersicherheit das BSI (Bundesamt für Sicherheit in der Informationstechnik) als nationales CSIRT (CERT-Bund).³

Praktischer Schritt jetzt: Recherchieren Sie den aktuellen Stand der ENISA-Meldeplattform unter https://www.enisa.europa.eu/topics/cyber-resilience-act und richten Sie BSI-Kontaktdaten in Ihrem internen Meldeprozess ein. Diese Kontaktdaten sollten nicht erst im Ernstfall gesucht werden.

Abgrenzung zur NIS2-Meldepflicht

NIS2 und CRA haben beide Meldepflichten — aber sie adressieren unterschiedliche Akteure:

Was viele CRA-Berater nicht sagen: Ein Hersteller, der gleichzeitig eine wichtige Einrichtung nach NIS2 ist — z.B. ein IT-Infrastruktur-Unternehmen, das selbst Netzwerkkomponenten betreibt und vertreibt — kann beiden Meldepflichten gleichzeitig unterliegen. Die Meldungen sind dabei nicht deckungsgleich. Es müssen ggf. zwei separate Meldungen erfolgen, mit unterschiedlichen Fristen und unterschiedlichen Empfängern.

Mehr zu den Unterschieden: CRA vs. NIS2 — Unterschiede und Überschneidungen

Praktische Vorbereitung bis September 2026

Drei Maßnahmen sind prioritär, um die Meldepflicht ab September 2026 erfüllen zu können. Das sind keine bloßen Empfehlungen — ohne diese Maßnahmen ist die Pflicht nach Artikel 14 nicht erfüllbar.

1. Vulnerability-Disclosure-Policy (VDP) veröffentlichen

Pflicht nach Artikel 13 Absatz 6 CRA: Eine VDP ist bereits vor Inverkehrbringen vorgeschrieben. Eine gute VDP enthält:

• Kontaktadresse für Sicherheitsmeldungen (dedizierte E-Mail oder Formular)
• Reaktionszeitraum (z.B. Eingangsbestätigung innerhalb von 5 Werktagen)
• Safe-Harbor-Erklärung für gutgläubige Forscher
• Informationen zur koordinierten Offenlegung

Praxis-Einschätzung: Die VDP ist das Einfachste auf dieser Liste — eine security@-Adresse und ein öffentliches Dokument sind an einem halben Tag erledigt. Der interne Prozess, der dahintersteht, ist die eigentliche Arbeit. Wer die VDP veröffentlicht, ohne den Eingang von Meldungen intern zu organisieren, schafft ein Compliance-Dokument ohne operative Wirkung.

2. Internen Meldeprozess dokumentieren

Schriftlich festlegen: Wer nimmt Meldungen entgegen? Wer entscheidet innerhalb der 24-Stunden-Frist? Wer füllt die eigentliche ENISA-Meldung aus? Ohne einen vordefinierten Prozess ist die 24-Stunden-Frist unter Krisendruck praktisch nicht einhaltbar.

Empfohlene Bestandteile des internen Prozesses:

• Rund-um-die-Uhr-Erreichbarkeit des Security-Ansprechpartners (nicht nur eine E-Mail-Adresse — eine Telefonnummer)
• Eskalationspfad: Wer entscheidet, ob ein Vorfall meldepflichtig ist?
• Vorausgefüllte Meldevorlagen für ENISA und BSI
• Dokumentation des Zeitpunkts der „Kenntnis” (relevant für Fristbeginn)
• Testlauf: Haben Sie den Prozess schon einmal durchgespielt? Ein simulierter Vorfall deckt Lücken auf, bevor es ernst wird.

3. Monitoring und CVE-Tracking aufbauen

Wer aktiv ausgenutzte Schwachstellen melden soll, muss sie zuerst erkennen. Dazu brauchen Hersteller:

• Abonnement von CVE-Feeds für verwendete Komponenten (z.B. über NIST NVD, GitHub Advisory Database)
• Abgleich mit dem CISA KEV-Katalog für bekannte ausgenutzte Schwachstellen
• Automatische Alerts bei kritischen CVSS-Scores (≥ 7.0) für eigene Produkte
• Einen verantwortlichen Ansprechpartner, der diese Alerts auch auswertet — ein Alert, der niemanden erreicht, nützt nichts

Wirtschaftliche Perspektive: Nicht-Meldung ist die teuerste Option. Ein Verstoß gegen Artikel 14 fällt unter die höchste Bußgeldstufe nach Artikel 64 — bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Hinzu kommt: Andere EU-Regulierungen (DSGVO) zeigen, dass Bußgelder tatsächlich verhängt werden — auch bei KMUs, auch bei erstmaligen Verstößen. Die Investition in einen funktionierenden Meldeprozess ist verglichen damit gering.

Verhältnis zur koordinierten Schwachstellen-Offenlegung

ENISA hat Leitlinien zur Koordinierten Schwachstellen-Offenlegung (Coordinated Vulnerability Disclosure, CVD) veröffentlicht.² Diese empfehlen, vor der öffentlichen Bekanntgabe einer Schwachstelle dem Hersteller eine angemessene Reaktionszeit einzuräumen (üblicherweise 90 Tage).

Die CRA-Meldepflicht an ENISA und die öffentliche Offenlegung sind zwei verschiedene Schritte. Die ENISA-Meldung ist vertraulich und dient der Behördenkoordination; die öffentliche Offenlegung (z.B. CVE-Veröffentlichung, Security Advisory) folgt nach koordiniertem Zeitplan.

Nächste Schritte

Prüfen Sie zuerst, welche Ihrer Produkte dem CRA unterliegen und welcher Risikoklasse sie angehören — das beeinflusst die Priorität der Vorbereitungsmaßnahmen:

CRA-Pflichten für Hersteller — vollständige Übersicht

Kostenlosen CRA-Check starten — in 4 Schritten erfahren Sie, welche Pflichten konkret für Ihr Produkt gelten.

Das CRA Evidence Pack enthält eine fertige Vorlage für den internen Meldeprozess, eine VDP-Vorlage und ein ausgefülltes Beispiel einer ENISA-Meldung.

Quellen

1. EU-Verordnung 2024/2847 (Cyber Resilience Act), Artikel 14: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. ENISA — Leitlinien zur koordinierten Schwachstellen-Offenlegung: https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure-policies-in-the-eu
3. BSI — CERT-Bund, Meldestelle für IT-Sicherheitsvorfälle: https://www.bsi.bund.de/DE/IT-Sicherheitsvorfaelle/CERT-Bund/cert-bund_node.html
4. ENISA — CRA-Implementierungsseite: https://www.enisa.europa.eu/topics/cyber-resilience-act
5. CISA — Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
6. NIST — National Vulnerability Database (NVD): https://nvd.nist.gov/