Von Redaktion codAIx | 25. Mai 2026

Wenn am Freitagabend ein belastbarer Hinweis auf eine aktiv ausgenutzte Schwachstelle eingeht, bleiben keine drei Arbeitstage für die interne Abstimmung. Nach dem Cyber Resilience Act (CRA) muss die erste Meldung innerhalb von 24 Stunden über die einheitliche Meldeplattform (Single Reporting Platform) der ENISA erfolgen. Dasselbe Zeitfenster gilt für schwerwiegende Sicherheitsvorfälle. Seit dem 11. September 2026 ist dieses Verfahren Pflicht. Entscheidend ist daher, wer melden muss, wann die Frist zu laufen beginnt und welche Informationen zu welchem Zeitpunkt vorliegen müssen.

Der zeitliche Rahmen der CRA-Anwendung

Die Chronologie nach Art. 71 CRA[1] erklärt, weshalb die Meldeprozesse schon vor den übrigen Compliance-Strukturen stehen müssen:

  • 23. Oktober 2024: CRA wird unterzeichnet (Veröffentlichung im Amtsblatt am 20. November 2024)
  • 10. Dezember 2024: CRA tritt in Kraft
  • 11. Juni 2026: Kapitel IV (Art. 35–51 — notifizierende Behörden und notifizierte Stellen) ist anwendbar
  • 11. September 2026: Seit diesem Tag gelten die Meldepflichten nach Art. 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle
  • 11. Dezember 2027: Ab diesem Tag gelten die übrigen CRA-Anforderungen (Sicherheitsanforderungen aus Anhang I, Konformitätsbewertung und Sorgfaltspflichten aus Art. 13) sowie die Sanktionsvorschriften nach Art. 64 CRA

Zwischen dem Beginn der Meldepflichten und den übrigen CRA-Anforderungen liegen 15 Monate. Schwachstellenmanagement-Prozesse müssen daher früher funktionieren als andere Compliance-Massnahmen. Bis dahin sind auch Verstösse gegen Art. 14 nicht nach Art. 64 CRA mit Geldbussen bewehrt; das vom Bundestag am 15. Oktober 2026 beschlossene, noch nicht verkündete Durchführungsgesetz lässt die Bussgeldvorschriften ebenfalls erst am 11. Dezember 2027 in Kraft treten (Art. 4 Abs. 2 i. d. F. der Beschlussempfehlung, BT-Drs. 21/8622; im Regierungsentwurf BT-Drs. 21/6134 noch Art. 4 Abs. 4)[18]. Wer überhaupt unter den CRA fällt, erläutern Artikel 1: SaaS und der CRA und Artikel 2: Drei-Elemente-Test.

Artikel 14: Zwei parallele Melderegimes

Artikel 14 CRA enthält zwei getrennte dreistufige Melderegimes:

  • Art. 14 Abs. 1 und 2: Meldung aktiv ausgenutzter Schwachstellen in Produkten mit digitalen Elementen.
  • Art. 14 Abs. 3 und 4: Meldung schwerwiegender Sicherheitsvorfälle, die sich auf die Sicherheit des Produkts auswirken.

Beide Regimes laufen jeweils dreistufig — Frühwarnung (24 h), Meldung (72 h) und Abschlussbericht. Sie müssen separat gehalten werden, weil Inhalt und Fristauslöser des Abschlussberichts unterschiedlich sind. Bei beiden Regimen kann das als Koordinator benannte CSIRT zudem einen Zwischenbericht über relevante Statusaktualisierungen anfordern (Art. 14 Abs. 6 CRA). Alle Meldungen erfolgen über die gemäss Art. 16 CRA eingerichtete einheitliche Meldeplattform (von ENISA betrieben, oft als CRA Single Reporting Platform / SRP bezeichnet). Der Hersteller reicht jede Meldung nur einmal ein. Im gesetzlichen Regelfall erhalten das als Koordinator benannte CSIRT (vgl. Art. 14 Abs. 7) und ENISA die Meldung gleichzeitig. Weitere zuständige CSIRTs erhalten sie erst über das Koordinator-CSIRT, das die Verbreitung aus den in Art. 16 Abs. 2 UAbs. 2 CRA und der Delegierten Verordnung (EU) 2026/881 konkretisierten Cybersicherheitsgründen aufschieben kann, und zwar nur „so lange, wie unbedingt erforderlich“. Nicht jede Meldung geht also sofort und vollständig an alle Stellen; Einzelheiten und die eng begrenzte Ausnahme für ENISA erläutert der Abschnitt zur Meldeplattform. Verwalter quelloffener Software treffen die Meldepflichten in den Grenzen des Art. 24 Abs. 3 CRA erst ab dem 11. Dezember 2027.

Was ist eine „aktiv ausgenutzte Schwachstelle“?

Vom Begriff der „aktiv ausgenutzten Schwachstelle“ hängt das gesamte Melderegime ab. Dennoch wird er in der Praxis oft unpräzise verwendet. Art. 3 Nr. 42 CRA[1] verlangt verlässliche Nachweise dafür, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Diese drei Merkmale müssen zusammentreffen; theoretische Ausnutzbarkeit allein genügt nicht.

Für die operative Triage bietet die Technische Richtlinie BSI TR-03183-3 (Version 1.0.0 vom 20.08.2025) in Kap. 3.1.3 ein brauchbares Stufenraster, das an die CRA-Definition anschliesst[11]:

  • gültig (valid): Die Schwachstelle erfüllt die Kriterien, die der Hersteller in seiner eigenen Vulnerability Guideline festgelegt hat.
  • validiert (validated): Der Hersteller hat nach Abgleich mit dieser Guideline bestätigt, dass die Kriterien erfüllt sind.
  • validiert und verifiziert bzw. validiert, aber unverifiziert: Ergebnis der anschliessenden Bewertung von Schweregrad und Ausnutzbarkeit.

Diese Stufen sollten im eigenen Prozess getrennt abgebildet werden. Unter dem Druck der 24-Stunden-Frist entsteht so eine dokumentierte Entscheidungskette anstelle einer Bauchentscheidung — siehe dazu auch den Abschnitt zum Klassifikationsdruck weiter unten.

Zero-Days, Bug Bounty und Testlabore: Was nicht meldepflichtig ist

Gerade bei Zero-Days kommt es häufig zu Fehleinschätzungen. Fehlt für eine Schwachstelle noch ein Patch, ist sie nach Nr. 5.2 der FAQ[5] nur dann gemäss Art. 14 zu melden, wenn der Hersteller verlässliche Nachweise für eine Ausnutzung durch einen böswilligen Akteur hat. Ausdrücklich nicht meldepflichtig sind danach ein Zero-Day, den ethische Hacker im Rahmen eines Bug-Bounty-Programms des Herstellers finden und offenlegen, sowie ein Zero-Day, den ein im Auftrag des Herstellers arbeitendes Prüflabor bei Tests entdeckt — vorausgesetzt, es gibt jeweils keinen Beleg für eine vorherige böswillige Ausnutzung. Das entspricht Erwägungsgrund 68 CRA: Schwachstellen, die in guter Absicht zu Test-, Untersuchungs-, Korrektur- oder Offenlegungszwecken entdeckt werden, unterliegen keiner verpflichtenden Meldung. Möglich bleibt in beiden Fällen die freiwillige Meldung nach Art. 15 CRA; je nach Risikolage kann sie sinnvoll sein.

Regime 1: Aktiv ausgenutzte Schwachstellen (Art. 14 Abs. 1, 2)

Stufe 1 — Frühwarnung (24 h)

Unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntnis von einer aktiv ausgenutzten Schwachstelle: Frühwarnung mit mindestens der Angabe der Mitgliedstaaten, in deren Hoheitsgebiet das Produkt nach Kenntnis des Herstellers bereitgestellt wurde.

Stufe 2 — Meldung der Schwachstelle (72 h)

Unverzüglich, in jedem Fall aber innerhalb von 72 Stunden nach Kenntnis: Meldung mit allgemeinen Informationen — soweit verfügbar — über das betreffende Produkt, die allgemeine Art der Ausnutzung und der Schwachstelle, ergriffene Korrektur- oder Risikominderungsmassnahmen, Korrektur- oder Abhilfemassnahmen, die Nutzer ergreifen können, sowie eine Sensibilitätseinstufung der gemeldeten Informationen.

Stufe 3 — Abschlussbericht (14 Tage nach Verfügbarkeit der Abhilfe)

Spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmassnahme zur Verfügung steht, ein Abschlussbericht mit mindestens: Beschreibung der Schwachstelle inklusive Schweregrad und Auswirkungen, falls verfügbar Informationen zu böswilligen Akteuren, sowie Informationen zur bereitgestellten Sicherheitsaktualisierung oder anderen Korrekturmassnahmen.

Wichtig: Die 14-Tage-Uhr startet mit Verfügbarkeit der Abhilfemassnahme — nicht ab Kenntnisnahme. Hersteller, die keine Abhilfe bereitstellen können, geraten nicht automatisch in eine 14-Tage-Frist. Ab dem 11. Dezember 2027 riskieren sie aber Verstösse gegen Anhang I Teil II Nr. 2 (unverzügliche Behebung); für vorher in Verkehr gebrachte Produkte gilt diese Pflicht nicht, sofern sie nicht danach wesentlich geändert werden (siehe „Altprodukte“).

Regime 2: Schwerwiegende Sicherheitsvorfälle (Art. 14 Abs. 3, 4)

Stufe 1 — Frühwarnung (24 h)

Unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnis: Frühwarnung mit zumindest der Angabe, ob der Verdacht besteht, dass der Vorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist, und gegebenenfalls den betroffenen Mitgliedstaaten.

Stufe 2 — Meldung des Sicherheitsvorfalls (72 h)

Unverzüglich, in jedem Fall aber innerhalb von 72 Stunden nach Kenntnis: Meldung mit Art des Vorfalls, einer Erstbewertung, ergriffenen Korrektur- oder Risikominderungsmassnahmen, Massnahmen für Nutzer und Sensibilitätseinstufung.

Stufe 3 — Abschlussbericht (1 Monat nach Übermittlung der 72-h-Meldung)

Innerhalb eines Monats nach Übermittlung der 72-h-Meldung (nicht ab Kenntnisnahme): ausführliche Beschreibung des Vorfalls inkl. Schweregrad und Auswirkungen, Art der Bedrohung beziehungsweise zugrunde liegende Ursache, Angaben zu getroffenen und laufenden Abhilfemassnahmen.

Wann ist ein Sicherheitsvorfall „schwerwiegend“? (Art. 14 Abs. 5)

Die Verordnung definiert das eng. Ein Vorfall gilt als schwerwiegend, wenn:

  • a) er sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder
  • b) er zur Einführung oder Ausführung eines böswilligen Codes im Produkt oder im Netzwerk- und Informationssystem eines Nutzers geführt hat oder dazu führen kann.

Eine grossflächige Ausnutzung, der Bezug zu kritischer Infrastruktur oder ein konkreter Datenabfluss können Indikatoren sein, sind aber keine eigenen Tatbestandsmerkmale: Massgeblich ist allein, ob lit. a oder lit. b erfüllt ist.

Altprodukte und Rückwirkung (Art. 69 Abs. 3 CRA)

Was geschieht mit Produkten, die längst im Markt sind? Auch für sie gilt die Meldepflicht. Nach Art. 69 Abs. 3 CRA (i. V. m. Art. 71 Abs. 2 UAbs. 2) erfassen die Pflichten aus Art. 14 ab dem 11. September 2026 alle Produkte mit digitalen Elementen im Anwendungsbereich der Verordnung — einschliesslich derjenigen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Der Umfang dieser Pflicht ist für Altprodukte aber begrenzt:

  • Nur die Meldung, nicht die Schwachstellenbehandlung. Nach den FAQ der Kommissionsdienststellen (Nr. 5.3) und der Auslegungs-Guidance der Kommission (C(2026) 5252 final, Annex, Rn. 210)[4][5] verlangt der CRA für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, ausschliesslich die Meldung. Die übrigen Pflichten, insbesondere die Schwachstellenbehandlung nach Anhang I Teil II, gelten für diese Produkte nicht. Die FAQ begründen das praktisch: Werkzeuge zum Scannen alter Softwareversionen existieren oft nicht mehr, Build-Umgebungen lassen sich nicht rekonstruieren, Abhängigkeiten sind nicht mehr verfügbar, und Mitarbeitende mit Kenntnis alter Codebasen haben das Unternehmen verlassen.
  • Meldepflicht überdauert den Unterstützungszeitraum. Anders als die Pflichten zur Schwachstellenbehandlung, die nur für die Dauer des Unterstützungszeitraums gelten, bestehen die Meldepflichten nach Rn. 210 der Guidance auch dann fort, wenn ein Produkt nicht mehr unterstützt wird.
  • Keine Rückwirkung. Schwachstellen, deren aktive Ausnutzung dem Hersteller bereits vor dem 11. September 2026 bekannt war, sind nicht nachträglich zu melden (Guidance Rn. 217; FAQ Nr. 5.3). War die Schwachstelle vor diesem Datum zwar bekannt, die Ausnutzung aber nicht — weil sie noch nicht stattgefunden hatte oder der Hersteller davon nichts wusste —, und tritt die Ausnutzung danach ein oder wird sie danach bekannt, greift die Meldepflicht.
  • Die Nutzerinformation bleibt. Auch bei Altprodukten verpflichtet Art. 14 Abs. 8 CRA den Hersteller, die betroffenen und gegebenenfalls alle Nutzer zu informieren. Unterbleibt das rechtzeitig, können die empfangenden CSIRTs die Nutzer selbst informieren, soweit dies verhältnismässig und zur Schadensbegrenzung erforderlich ist (FAQ Nr. 5.3; Guidance Rn. 219 f.).

Wann beginnt die „Kenntnis“?

Die 24-Stunden-Frist beginnt mit der Kenntnisnahme. Inzwischen gibt es dazu zwei Auslegungshilfen: die am 27. Juli 2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der Kommission (Kapitel 9.1, Rn. 209–221)[4] und die seit Dezember 2025 von den Kommissionsdienststellen gepflegten FAQ (aktuell Version 1.4 vom 4. September 2026, Nr. 5.1–5.5)[5]. Beide Dokumente sind rechtlich nicht verbindlich. Die FAQ geben nach eigener Angabe keine offizielle Position der Kommission wieder und werden als lebendes Dokument fortgeschrieben. Gemeinsam mit der juristischen Kommentarliteratur zeichnen die Dokumente allerdings ein klareres — und in einem wichtigen Punkt überraschendes — Bild als der Verordnungstext allein.

Erstens — aus Art. 14 CRA folgt keine Pflicht zum Monitoring. Mehnert leitet im NK-CRA aus Art. 14 ausdrücklich keine Überwachungs- oder Nachforschungspflicht ab. Begründet wird das damit, dass die Vorschrift Fälle fahrlässiger Unkenntnis nicht erfasst, sondern allein an die Kenntnis einer aktiv ausgenutzten Schwachstelle anknüpft (NK-CRA/Mehnert Art. 14 Rn. 3)[12]. Massgeblich ist danach die tatsächliche Kenntnis, ausdrücklich nicht die blosse Möglichkeit der Kenntnisnahme (Rn. 4). Die FAQ der Kommissionsdienststellen gehen in dieselbe Richtung: Nr. 5.1 zählt zwar Kanäle auf, über die ein Hersteller Kenntnis erlangen kann — Hinweise von Kunden oder Partnerorganisationen, Threat-Intelligence-Berichte, Meldungen staatlicher Cybersicherheitsbehörden, Hinweise ethischer Hacker, eigene Telemetrie, Scans oder Honeypots —, stellt anschliessend aber ausdrücklich klar, dass daraus keine Pflicht folgt, solche Aktivitäten durchzuführen oder solche Kanäle zu überwachen, um die Meldepflichten zu erfüllen. Wer allein aus Art. 14 CRA eine Pflicht zum kontinuierlichen Schwachstellen-Monitoring ableitet, überdehnt die Norm.

Zweitens — die Ermittlungspflicht steht an anderer Stelle. Das heisst nicht, dass Hersteller dauerhaft nichts tun müssten. Ab dem 11. Dezember 2027 wird die Sorgfaltspflicht zur Schwachstellenermittlung aus Art. 13 Abs. 8 CRA in Verbindung mit Anhang I Teil II Nr. 1[1][2] verbindlich. Art. 13 Abs. 8 verpflichtet Hersteller, Schwachstellen während des festgelegten Unterstützungszeitraums wirksam und gemäss den grundlegenden Cybersicherheitsanforderungen aus Teil II des Anhangs I zu behandeln. Anhang I Teil II verlangt unter anderem (Nr. 1) Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, einschliesslich einer Software-Stückliste (englisch software bill of materials, SBOM) in einem gängigen maschinenlesbaren Format (siehe Artikel 7: SBOM), (Nr. 3) die Sicherheit des Produkts regelmässig und wirksam zu testen und zu überprüfen, sowie (Nr. 5) eine Strategie für die koordinierte Offenlegung von Schwachstellen aufzustellen und umzusetzen. Genau diese Linie stützt auch die Fussnote zu Nr. 5.1 der FAQ: Aus Art. 14 folgt kein Monitoring — Anhang I Teil II verlangt gleichwohl unter anderem eine zentrale Anlaufstelle für Schwachstellenmeldungen und Massnahmen zum Informationsaustausch über mögliche Schwachstellen. Die abgestufte Logik dieser Sorgfaltspflicht haben wir in Artikel 3: Abgestufte CRA-Pflichten im Detail behandelt.

Drittens — Kenntnis lässt sich nicht durch Nichtbefassung hinauszögern. Die Gegenrichtung gilt ebenso: Wer einen Hinweis erhält, kann die Frist nicht dadurch strecken, dass er ihn liegen lässt. Nach Mehnert (NK-CRA) liegt Kenntnis vor, wenn sie tatsächlich erlangt wird — oder, so weit sei der Wortlaut mit Blick auf den Zweck der Meldepflicht auszulegen, zu dem Zeitpunkt, zu dem unter normalen Umständen mit der Kenntnisnahme zu rechnen ist. Das ist regelmässig der Beginn der nächsten üblichen Geschäftszeit und im Einzelfall zu bestimmen; der blosse Eingang einer E-Mail genügt für sich genommen noch nicht. Wird ausserhalb der üblichen Geschäftszeiten tatsächlich Kenntnis erlangt, ist dieser tatsächliche Zeitpunkt massgeblich (NK-CRA/Mehnert Art. 14 Rn. 4)[12]. Die Guidance der Kommission ergänzt das um die Bewertungsseite: Stellt der Hersteller selbst ein verdächtiges Ereignis fest oder bringt ein Dritter — genannt werden ausdrücklich eine Einzelperson, ein Kunde, eine Einrichtung, eine Behörde, eine Medienorganisation oder eine sonstige Quelle — einen möglichen Vorfall oder eine Schwachstelle zu seiner Kenntnis, muss er das Ereignis unverzüglich bewerten. Als „aware“ gilt er, sobald er nach dieser Erstbewertung einen angemessenen Grad an Gewissheit („a reasonable degree of certainty“) darüber hat, dass eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall vorliegt (Rn. 213)[4]. Wie lange das dauern darf, hängt vom Einzelfall ab; der Schwerpunkt liegt nach Rn. 214 aber auf zügigem Handeln bei dieser Erstbewertung, besonders wenn die Schwachstelle ein erhebliches Risiko bergen kann. Die Guidance orientiert sich dabei ausdrücklich an Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690 und an Abschnitt II(A) der Leitlinien 9/2022 zur Meldung von Verletzungen des Schutzes personenbezogener Daten nach der DSGVO (Rn. 212)[14] — der Begriff soll also über die EU-Rechtsakte hinweg einheitlich verstanden werden.

Aus Art. 14 CRA folgt somit keine Pflicht, aktiv nach Ausnutzungshinweisen zu suchen. Eingehende Hinweise müssen dennoch zügig bearbeitet werden. Praktisch kommt es weniger darauf an, was ein Hersteller hätte wissen können, als darauf, wie schnell aus einem konkreten Hinweis eine belastbare Erstbewertung wird.

Die RondoDox-Kampagne vermittelt eine Vorstellung davon, wie knapp dieses Zeitfenster in der Realität ist. Das Botnet nutzte ab Ende 2025 die kritische Schwachstelle React2Shell (CVE-2025-55182, CVSS-Höchstwert 10.0) in den weit verbreiteten Software-Frameworks React Server Components und Next.js. Anfang Januar 2026 waren laut der Shadowserver Foundation noch rund 85.000 Systeme weltweit angreifbar, davon rund 3.600 in Deutschland (Bericht von The Hacker News, Januar 2026)[19]. Der Vorfall ist kein unmittelbarer CRA-Anwendungsfall — die Schwachstelle wurde vor dem Geltungsbeginn der Meldepflichten ausgenutzt. Er macht aber greifbar, wie schnell eine öffentlich gewordene kritische Schwachstelle in die automatisierte Massenausnutzung gerät. Wer erst dann Zuständigkeiten, Bewertungskriterien und Meldewege klärt, verbraucht die 24 Stunden mit interner Abstimmung. Prozesse vorab aufzubauen, ist deshalb keine Reaktion auf eine unterstellte Kenntnisfiktion, sondern auf die Geschwindigkeit realer Angriffe und die ab Dezember 2027 verbindlichen Anforderungen aus Anhang I Teil II.

Eine Restunsicherheit bleibt: Die verbindliche Auslegung obliegt letztlich dem Gerichtshof der Europäischen Union. Wie die nationalen Marktüberwachungsbehörden den Zeitpunkt der Erstbewertung im Einzelfall beurteilen, ist bisher nicht durch Vollzugspraxis unterlegt. Wer aber Erkennungs- und Triage-Prozesse erst nach der ersten Behördenuntersuchung aufbaut, muss den Zeitpunkt der Kenntnis im Nachhinein rekonstruieren — und ab dem 11. Dezember 2027 zusätzlich mit Geldbussen nach Art. 64 CRA rechnen.

Die einheitliche Meldeplattform (Art. 16 CRA)

ENISA betreibt die nach Art. 16 CRA eingerichtete einheitliche Meldeplattform (Single Reporting Platform, SRP); sie ist seit dem 11. September 2026 unter https://portal.cra-srp.enisa.europa.eu/ in Betrieb[10]. Meldungen nach Art. 14 müssen über diesen Kanal erfolgen. Art. 15 sieht die Plattform auch für freiwillige Meldungen vor; diese Funktion war bis zum 11. Oktober 2026 noch nicht umgesetzt. ENISA kündigt sie für eine spätere Ausbaustufe an[6].

Regelfall und Verbreitung. Nach Art. 14 Abs. 1 und 3 CRA stellt die Plattform die Meldung gleichzeitig dem als Koordinator benannten CSIRT und ENISA zur Verfügung. Das Koordinator-CSIRT verbreitet sie anschliessend über die Plattform an die weiteren zuständigen Koordinator-CSIRTs der Mitgliedstaaten, in denen das Produkt nach Herstellerangaben bereitgestellt wurde. Unter aussergewöhnlichen Umständen kann es diese weitere Verbreitung aus berechtigten Cybersicherheitsgründen so lange aufschieben, wie dies unbedingt erforderlich ist. Die verbindlichen Voraussetzungen konkretisiert die Delegierte Verordnung (EU) 2026/881 (ABl. L vom 20. April 2026): Wegen der Art der Informationen darf das CSIRT nur aufschieben, wenn die Risiken der Verbreitung den Nutzen überwiegen, sich nicht durch Weitergabeprotokolle wie TLP oder PAP beherrschen lassen und zusätzlich etwa der Hersteller dem CSIRT eine wirksame Risikominderung binnen 72 Stunden angekündigt hat, die Angaben die Entwicklung einer Ausnutzungstechnik ermöglichen würden oder ein CVD-Verfahren läuft (Art. 3)[3]. Daneben kommt ein Aufschub bei Zweifeln an der Vertraulichkeit eines bestimmten CSIRT (Art. 4) oder bei einem Sicherheitsvorfall auf der Plattform (Art. 5) in Betracht.

Eng begrenzte Ausnahme für ENISA. Der Aufschub gegenüber anderen CSIRTs beschränkt ENISAs Zugriff grundsätzlich nicht. Nur unter den besonders aussergewöhnlichen Umständen des Art. 16 Abs. 2 UAbs. 3 CRA kann ENISA bei der 72-Stunden-Meldung einer aktiv ausgenutzten Schwachstelle nach Art. 14 Abs. 2 lit. b zunächst einen reduzierten Informationssatz erhalten: dass eine Meldung eingereicht wurde, allgemeine Produktangaben, die allgemeine Art der Ausnutzung und den Hinweis, dass Sicherheitsgründe geltend gemacht wurden. Diese gesetzliche Ausnahme erfasst ihrem Wortlaut nach nicht pauschal Frühwarnungen, Vorfallsmeldungen oder Abschlussberichte[1][9].

Registrierung und aktueller Betriebsstand. Nach den ENISA-Betriebshinweisen erfolgt der Zugang über EU Login. Die Organisation benennt eine primäre zugewiesene Vertretung (Primary Assigned Representative); eine sekundäre Vertretung als Backup ist vorgesehen. Nach dem ersten Zugriff validiert das zuständige CSIRT die Zuordnung parallel zum Meldeprozess — die Validierung blockiert das Einreichen einer Meldung nicht[7]. Eine vorherige Registrierung ist nach BSI und ENISA nicht erforderlich; ENISA rät sogar ausdrücklich davon ab und empfiehlt, sich erst zu registrieren, wenn tatsächlich eine Meldung einzureichen ist (Stand: 11. Oktober 2026)[6][20]. Für die interne Vorbereitung sollten Unternehmen deshalb EU-Login-Konten, Vertretungsbefugnisse und Kontaktdaten vorab klären, ohne bereits eine Plattformregistrierung auszulösen. Eine API gibt es in der ersten Plattformversion nicht; Meldungen werden über die Web-Oberfläche eingereicht. Die Plattform ist zunächst nur auf Englisch verfügbar, und Meldungen sind auf Englisch abzufassen[6][20]. Die Frühwarnung ist zunächst für Koordinator-CSIRT und ENISA sichtbar; weitere betroffene CSIRTs erhalten sie erst nach der manuellen Verbreitung durch das Koordinator-CSIRT[8]. Ist die Plattform vorübergehend nicht erreichbar, sieht das BSI für diesen Ausnahmefall die Meldung per E-Mail an CERT-Bund vor[20].

Abweichung zwischen Plattform und Verordnung. Eine rechtlich wichtige Differenz bleibt: ENISAs aktuelle Einreichungsanleitung beschreibt als Plattformverhalten, dass bei aktivierten Particularly Exceptional Circumstances auch der Abschlussbericht nicht automatisch an ENISA geht[8][9]. Art. 16 Abs. 2 UAbs. 3 CRA beschränkt den reduzierten ENISA-Zugriff seinem Wortlaut nach dagegen ausdrücklich auf die 72-Stunden-Schwachstellenmeldung. Bis ENISA oder die Kommission diese Abweichung klärt, sind technischer Ablauf und gesetzliche Reichweite getrennt zu dokumentieren; die Betriebshinweise dürfen den CRA nicht erweitern.

Wer koordiniert: CERT-Bund und Hauptniederlassung

Koordinator ist nach Art. 14 Abs. 7 CRA das CSIRT des Mitgliedstaates, in dem der Hersteller seine Hauptniederlassung in der Union hat. Für Hersteller mit deutscher EU-Hauptniederlassung übernimmt das CERT-Bund im BSI diese Rolle. Als Hauptniederlassung gilt der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden, hilfsweise der Mitgliedstaat der Niederlassung mit den meisten Beschäftigten (Art. 14 Abs. 7 UAbs. 2 CRA). Diese Zuständigkeit folgt aus der Benennung des BSI als Koordinator-CSIRT im Rahmen der NIS-2-Richtlinie (Art. 3 Nr. 51 CRA i. V. m. Art. 12 Abs. 1 der Richtlinie (EU) 2022/2555)[13] — nicht erst aus dem nationalen CRA-Durchführungsgesetz. Der Entwurf eines nationalen CRA-Durchführungsgesetzes (BT-Drs. 21/6134) regelt demgegenüber die Marktüberwachung (Art. 52 CRA) und die Notifizierung. Nach dem Referentenentwurf des Bundesministeriums des Innern vom 12. März 2026 beschloss das Kabinett den Regierungsentwurf am 29. April 2026; der Bundestag überwies ihn nach der ersten Beratung am 11. Juni 2026 an den federführenden Innenausschuss, der Bundesrat erhob am 12. Juni 2026 keine Einwendungen. Am 14. Oktober 2026 billigte der Innenausschuss den Entwurf mit einer Änderung zum Inkrafttreten einzelner Vorschriften; am 15. Oktober 2026 stimmte der Bundestag zu. Der zweite Durchgang im Bundesrat und die Verkündung standen danach noch aus[18]. Die institutionellen Konsequenzen — Befugnisse, Verfahrensregeln, Vor-Ort-Prüfungen — beleuchten wir vertieft in Artikel 10 dieser Serie.

Die BSI-Anknüpfung gilt nur bei deutscher EU-Hauptniederlassung des Herstellers. Hersteller ohne EU-Hauptniederlassung — etwa Schweizer Softwarehäuser ohne Tochtergesellschaft in der EU — melden nach der Kaskade des Art. 14 Abs. 7 UAbs. 3 CRA über den Endpunkt des CSIRT des Mitgliedstaats, in dem der Bevollmächtigte (Art. 18 CRA) niedergelassen ist, der für die meisten Produkte des Herstellers handelt; fehlt ein Bevollmächtigter, ist der Mitgliedstaat des Einführers (Art. 19 CRA) massgeblich, der die meisten Produkte des Herstellers in Verkehr bringt, danach der des Händlers, der die meisten Produkte bereitstellt — und lässt sich auch so kein Anknüpfungspunkt bestimmen, der Mitgliedstaat, in dem sich die meisten Nutzer des Produkts befinden. Wo SaaS- und Hybrid-Architekturen die Hersteller-Eigenschaft oder die Hauptniederlassung unklar machen, hilft unsere Einordnung in Artikel 4: CRA-Grauzone.

Artikel 15: Freiwillige Meldungen

Neben den verpflichtenden Meldungen nach Art. 14 kennt der CRA auch einen freiwilligen Weg. Nach Art. 15 können Hersteller sowie andere natürliche oder juristische Personen Folgendes melden:

  • Schwachstellen in Produkten mit digitalen Elementen sowie Cyberbedrohungen, die das Risikoprofil eines Produkts beeinflussen können (Art. 15 Abs. 1).
  • Sicherheitsvorfälle mit Auswirkung auf die Sicherheit des Produkts sowie Beinahe-Vorfälle, die zu einem solchen Vorfall hätten führen können (Art. 15 Abs. 2).

Rechtlich folgen freiwillige Meldungen demselben Verfahren über die einheitliche Meldeplattform, aber ohne die 24-h-/72-h-Fristen. Das CSIRT kann verpflichtende Meldungen vorrangig bearbeiten (Art. 15 Abs. 3). Technisch ist die freiwillige Meldemöglichkeit auf der Plattform noch nicht verfügbar (siehe oben). Wichtig: Wenn eine andere Person als der Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall meldet, unterrichtet das CSIRT den Hersteller unverzüglich (Art. 15 Abs. 4). Ein Hinweis einer Behörde kann eine unverzügliche Prüfung auslösen und — abhängig von Inhalt, Verlässlichkeit und Überprüfbarkeit — rasch zu hinreichender Gewissheit führen. Ob bereits Kenntnis im Sinne des Art. 14 CRA vorliegt, bleibt eine Einzelfallfrage (Guidance Rn. 213 f.)[4].

Vertraulichkeit der freiwillig übermittelten Informationen ist in Art. 15 Abs. 5 geregelt; die freiwillige Meldung darf nicht zu zusätzlichen Pflichten der meldenden Person führen.

Davon zu trennen ist die Pflicht zur Coordinated Vulnerability Disclosure Policy. Sie folgt nicht aus Art. 15, sondern aus Anhang I Teil II Nr. 5 und verpflichtet den Hersteller ab dem 11. Dezember 2027, eine eigene CVD-Strategie aufzustellen und umzusetzen. Bei KI-Komponenten können zusätzliche Offenlegungspflichten aus dem AI Act hinzukommen — siehe Artikel 5: AI Act trifft CRA und Artikel 6: Hochrisiko-KI.

Die zweite Meldekette: Hersteller an Lieferant (Art. 13 Abs. 6 CRA)

Neben der B2A-Meldekette zu Behörden (Art. 14) statuiert der CRA eine B2B-Meldepflicht innerhalb der Lieferkette. Anders als Art. 14 gilt diese Pflicht — wie Art. 13 insgesamt — erst ab dem 11. Dezember 2027, und zwar für Produkte, die ab diesem Tag in Verkehr gebracht oder danach wesentlich geändert werden (Art. 69 Abs. 2, Art. 71 Abs. 2 CRA); bis dahin ist die Meldung an den Komponentenhersteller gute, aber freiwillige Praxis. Wer in einer von ihm integrierten Komponente eines Drittanbieters eine Schwachstelle feststellt, muss diese dann gemäss Art. 13 Abs. 6 CRA[1] dem Hersteller oder der Stelle, die die Komponente wartet, melden — unabhängig davon, ob die Schwachstelle zugleich eine Meldepflicht nach Art. 14 auslöst. Ein blosser Verdacht genügt dafür nach dem Wortlaut noch nicht; einem begründeten Verdacht muss der Hersteller aber zunächst selbst durch Untersuchungen und Tests nachgehen (vgl. Wiebe, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 6 Rn. 20)[17].

Davon zu trennen ist die eigene Meldepflicht des Integrators: Wird eine Schwachstelle aus einer integrierten Komponente im eigenen Produkt aktiv ausgenutzt, muss der Hersteller des Endprodukts sie nach Art. 14 CRA melden — unabhängig davon, ob auch der Komponentenhersteller meldet. Ist die Schwachstelle im eigenen Produkt nicht ausnutzbar, etwa weil der betroffene Code nicht erreichbar ist, oder wurde sie dort nicht ausgenutzt, besteht keine Pflichtmeldung; möglich bleibt eine freiwillige Meldung nach Art. 15 CRA (Guidance Rn. 218; FAQ Nr. 5.4)[4][5].

In der täglichen Arbeit entstehen damit drei parallele Adressatenkreise. Die BSI TR-03183-3 (Kap. 3.1.4–3.1.6)[11] kennt für diese Richtungen drei Begriffe, deren Unterschiede im deutschen Sprachgebrauch leicht unter dem allgemeinen Wort „Meldung“ verschwimmen:

  • B2A an Koordinator-CSIRT und ENISA (Art. 14 i. V. m. Art. 16) — bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen. In der Terminologie der BSI-Richtlinie ist das die vulnerability notification: eine allgemeine, nicht öffentliche Information mit vorläufiger Bewertung, ohne technische Details.
  • B2B an den Hersteller oder die Stelle, die die Komponente wartet (Art. 13 Abs. 6; ab dem 11. Dezember 2027) — grundsätzlich bei jeder im Integrationsumfeld festgestellten Schwachstelle der integrierten Version einer Drittkomponente, auch ohne Ausnutzungsindikatoren. Nach der nicht bindenden Guidance entfällt die Meldung, wenn bestätigt werden kann, dass der Hersteller oder die wartende Stelle die Schwachstelle bereits kennt (Rn. 223). Diese Richtung entspricht inhaltlich am ehesten dem vulnerability report, den die TR vor allem für Meldungen von Sicherheitsforschern und CSIRTs an Hersteller verwendet: vertraulich und technisch detailliert, üblicherweise mit Angaben zu Identifikation, Ausnutzung und Reproduktion.
  • B2C an die Nutzer (Art. 14 Abs. 8 CRA; ergänzend ab dem 11. Dezember 2027 Art. 13 Abs. 8 i. V. m. Anhang I Teil II Nr. 8) — über Sicherheitsaktualisierungen und Risiken. Das entspricht der security advisory der TR, die in der Regel öffentlich ist. Die Nutzerinformation nach Art. 14 Abs. 8 muss nach der Guidance aber nicht zwingend öffentlich erfolgen; sie ist risikobasiert und kann auf betroffene Nutzer beschränkt werden. Öffentlich zu machen sind ab dem 11. Dezember 2027 Informationen über behobene Schwachstellen nach Anhang I Teil II Nr. 4, sobald ein Update bereitsteht (Guidance Rn. 220 f.)[4].

Eine ausschliesslich auf das Behörden-Regime ausgerichtete Gestaltung von SBOM-, Erkennungs- und Eskalationsprozessen greift deshalb zu kurz: Die Meldung innerhalb der Lieferkette ist ab dem 11. Dezember 2027 eine eigenständige Pflicht.

Geldbussen ab dem 11. Dezember 2027

Verstösse gegen Anhang I oder gegen die Pflichten aus Art. 13 und 14 sind ab dem 11. Dezember 2027 nach Art. 64 Abs. 2 CRA mit Geldbussen bewehrt: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres (es gilt der höhere Wert)[1]. Bis dahin sind auch verspätete oder unterlassene Meldungen nicht nach Art. 64 CRA mit Geldbussen bewehrt (siehe oben).

Bemessungsgrundlage der Geldbusse: Konzernumsatz

Nach einer in der Kommentarliteratur vertretenen Auffassung ist mit dem weltweiten Jahresumsatz in Art. 64 Abs. 2 CRA in Anlehnung an die EuGH-Rechtsprechung zu Art. 101 und 102 AEUV die wirtschaftliche Einheit gemeint — typischerweise also der Konzernumsatz und nicht nur der Umsatz der einzelnen Konzerngesellschaft (Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 7 Rn. 57)[17]. Zweifelnd NK-CRA/Kühne Art. 64 Rn. 34: Anders als die DSGVO (Erwägungsgrund 150 Satz 3) verweise der CRA nicht auf den Unternehmensbegriff der Art. 101 f. AEUV; das Schrifttum folge soweit ersichtlich gleichwohl der wirtschaftlichen Einheit[12]. Gerichtliche Rechtsprechung zum Unternehmensbegriff des CRA liegt noch nicht vor. Im deutschen OWi-Recht ist die unionsrechtliche Vermutung des bestimmenden Einflusses der Muttergesellschaft nach dem Grundsatz „in dubio pro reo“ nicht anwendbar und reduziert sich auf einen Erfahrungssatz, nicht auf eine rechtliche Beweislastumkehr (Jossen, a. a. O., § 7 Rn. 57 Fn. 44)[17]. Praktisch bedeutet das: Bei einer Tochtergesellschaft ohne nennenswerten Eigenumsatz, deren Mutter im Milliardenbereich liegt, kann sich die Obergrenze der Geldbusse am Mutterumsatz orientieren — ein Umstand, der die operative Risikoabschätzung in Konzernstrukturen massgeblich verschiebt.

Sonderregel für Kleinst- und Kleinunternehmen (Art. 64 Abs. 10 lit. a)

Wichtig für KMU: Die Geldbussen nach Art. 64 Abs. 2 bis 9 (i. d. F. der Berichtigung vom 02.07.2025, ABl. L 2025/90555) gelten nicht gegenüber Herstellern, die als Kleinst- oder Kleinunternehmen im Sinne der KMU-Empfehlung 2003/361/EG[16] gelten, soweit es um die Nichteinhaltung der 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 lit. a oder Art. 14 Abs. 4 lit. a geht. Die Pflicht selbst bleibt bestehen, der Hebel der Geldbusse jedoch nicht. Die Ausnahme betrifft nur die 24-Stunden-Frühwarnung: Versäumte 72-Stunden-Meldungen und Abschlussberichte sowie Verstösse gegen Anhang I und Art. 13 bleiben — vorbehaltlich der allgemeinen Verhältnismässigkeitsregelung — auch für Kleinst- und Kleinunternehmen mit Geldbussen bewehrt, wie alle Geldbussen erst ab dem 11. Dezember 2027.

Kooperation und Offenlegung im Sanktionsverfahren

Eine Art.-14-Meldung begründet nach Art. 17 Abs. 4 CRA keine höhere Haftung. Welche Bedeutung Kooperation, Schadensminderung oder eine freiwillige Offenlegung im nationalen Sanktionsverfahren haben, richtet sich nach dem anwendbaren Verfahrensrecht und der Einzelfallwürdigung; Art. 64 CRA garantiert dafür keine bestimmte Reduktion. Liegt der Meldetatbestand vor, ist fristgerecht zu melden.

Was das BSI zusätzlich erwartet (TR-03183-3)

Wer in Deutschland meldet, sollte neben der Verordnung die Technische Richtlinie BSI TR-03183-3 kennen („Cyber Resilience Requirements for Manufacturers and Products — Part 3: Vulnerability Reports and Notifications“, Version 1.0.0 vom 20. August 2025)[11]. Sie ist nicht bindend, aber die derzeit detaillierteste deutsche behördliche Orientierung zu CVD-Prozessen. Die wichtigsten Punkte, die über den Verordnungstext hinausgehen:

  • Auch die eigene Infrastruktur zählt (Kap. 4.4.2). Bei aktiv ausgenutzten Schwachstellen, die eines der Produkte oder die Infrastruktur des Herstellers betreffen, ist das korrespondierende nationale CSIRT unverzüglich zu informieren; über neue Erkenntnisse, Massnahmen zur Risikominderung und deren Zeitpläne ist laufend abzustimmen. Art. 14 Abs. 1 CRA erfasst demgegenüber nur Schwachstellen im Produkt; eine Kompromittierung der Herstellerinfrastruktur kann aber als schwerwiegender Sicherheitsvorfall nach Art. 14 Abs. 3 meldepflichtig sein (Erwägungsgrund 68).
  • Ein CSIRT, dauerhaft (Kap. 3.1.7). Der Hersteller muss sein korrespondierendes nationales CSIRT nach Art. 14 Abs. 7 CRA bestimmen, während der Bearbeitung einer Schwachstelle bei diesem CSIRT bleiben und sollte für alle Vorgänge dasselbe CSIRT nutzen. In Deutschland ist das CERT-Bund beim BSI.
  • Garantierte Reaktionszeiten gegenüber Meldenden (Kap. 4.4.8). Eine nicht automatisierte Antwort binnen fünf Arbeitstagen, ein detailliertes Feedback binnen zehn Arbeitstagen — ausser bei anonymer Meldung.
  • Offenlegungsfrist 90 Tage (Kap. 4.4.10). Validierte und verifizierte Schwachstellen sind binnen 90 Tagen öffentlich offenzulegen. Eine einmalige Verlängerung um weitere 90 Tage ist in enger Abstimmung mit dem nationalen CSIRT möglich, eine darüber hinausgehende Verlängerung nur ausnahmsweise durch das CSIRT. Publiziert werden soll mindestens in der europäischen Schwachstellendatenbank EUVD der ENISA.
  • CVD-Infrastruktur (Kap. 4.1–4.5). Eine security.txt nach RFC 9116 unter /.well-known/; getrennte Rollen für das Produkt-Sicherheitsteam (PSIRT) und das Infrastruktur-Sicherheitsteam (CSIRT) mit jeweils eigenen funktionalen Postfächern, wobei diese beiden Rollen — ausser bei Kleinstunternehmen im Sinne von Art. 3 Nr. 19 CRA — nicht auf eine einzelne Person fallen dürfen; eine anonyme Meldemöglichkeit; kein Zwang zu Geheimhaltungsvereinbarungen gegenüber Meldenden; keine Strafanzeige gegen Meldende, die gutgläubig vorgehen; jährliche Überprüfung der CVD-Strategie.

Eine Einordnung ist dabei wichtig: Die TR-03183-3 in der Fassung vom August 2025 erwähnt die einheitliche Meldeplattform nach Art. 16 CRA noch nicht und nennt auch keine 24-/72-Stunden-Fristen. Sie beschreibt den direkten Weg vom Hersteller zum nationalen CSIRT. Das ist kein Widerspruch zur Verordnung — wohl aber ein Hinweis darauf, dass die nationale Richtlinie den Plattformkanal noch nicht abbildet und in einer künftigen Fassung nachgeführt werden dürfte.

Das Verhältnis zu NIS-2-Meldepflichten

Bei Überschneidungen mit NIS-2 stellt sich rasch die Frage: Muss dasselbe Sicherheitsereignis zweimal gemeldet werden — einmal unter NIS-2 und einmal unter CRA?

Nicht pauschal. Ist der Hersteller zugleich eine nach NIS-2 verpflichtete wesentliche oder wichtige Einrichtung, etwa als Anbieter von Cloud-Computing-Diensten oder von verwalteten IKT-Diensten, und erfüllt dasselbe Ereignis beide Tatbestände, können CRA- und NIS-2-Meldepflichten kumulativ greifen. Adressaten, Auslöser und Meldewege sind getrennt zu prüfen; eine allgemeine gesetzliche Einmalmeldung gibt es derzeit nicht.

NIS-2 vs. CRA: Unterschiedliche Adressaten, unterschiedliche Auslöser

NIS-2 (Richtlinie (EU) 2022/2555) verpflichtet wesentliche und wichtige Einrichtungen („essential and important entities“) im Sinne von Art. 3 NIS-2 zur Meldung von Sicherheitsvorfällen mit erheblichen Auswirkungen auf ihre Dienste — einschliesslich der drei Fristen: 24 Stunden bis zur Frühwarnung, 72 Stunden bis zur Vorfallmeldung und ein Monat bis zum Abschlussbericht (Art. 23 Abs. 4 NIS-2)[13]. Strukturell ähnelt das den CRA-Fristen, der Adressatenkreis und der Vorfallbegriff sind aber unterschiedlich. Der Begriff „kritische Infrastruktur“ ist dabei kein NIS-2-Begriff. Kritische Einrichtungen werden nach der CER-Richtlinie (EU) 2022/2557[15] bestimmt; nach NIS-2 gelten sie unabhängig von ihrer Grösse als wesentliche Einrichtungen (Art. 2 Abs. 3, Art. 3 Abs. 1 lit. f NIS-2) und unterliegen damit zusätzlich den NIS-2-Meldepflichten.

CRA verpflichtet Hersteller von Produkten mit digitalen Elementen — hier: Softwarehersteller — zur Meldung von aktiv ausgenutzten Schwachstellen in ihren Produkten und von schwerwiegenden Sicherheitsvorfällen, die sich auf die Sicherheit des Produkts auswirken. Dazu kann nach Erwägungsgrund 68 CRA auch eine Kompromittierung des eigenen Update-Freigabekanals gehören.

In der Praxis sind daher unterschiedliche Konstellationen auseinanderzuhalten:

  • Der Softwarehersteller muss eine Schwachstelle nach CRA melden, wenn sie in seinem Produkt enthalten ist und er Kenntnis von ihrer aktiven Ausnutzung erlangt.
  • Die wesentliche oder wichtige Einrichtung muss nach dem anwendbaren NIS-2-Umsetzungsrecht melden, wenn ein erheblicher Sicherheitsvorfall vorliegt. Die blosse Betroffenheit von einer Schwachstelle löst diese Meldepflicht noch nicht aus.
  • Die Meldewege sind zu trennen: nach CRA über die SRP an Koordinator-CSIRT und ENISA; nach NIS-2 über den nach deutschem Fachrecht zuständigen Meldeweg, regelmässig die gemeinsame Meldestelle von BSI und BBK. Sektorale Sonderregeln bleiben unberührt.

Wo sich die Regime berühren

  • Die Auslegungs-Guidance der Kommission zieht den Begriff der „Kenntnis“ ausdrücklich an Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690 heran (Rn. 212)[4][14], damit vergleichbare Meldepflichten aus unterschiedlichen EU-Rechtsakten einheitlich verstanden werden. Eine vollständige Harmonisierung der Verfahren steht noch aus. Der Vorschlag der Kommission für einen Digital Omnibus (COM(2025) 837) sieht unter anderem eine zentrale Meldestelle vor, ist aber noch kein geltendes Recht[21].
  • Wer beiden Regimen unterliegt, sollte Erstbewertung und Zeitstempel einmal erfassen und daraus beide Meldungen ableiten.

Die Kritik: Sind die 24-Stunden-Frist und die parallele Trennung realistisch?

Die 24-Stunden-Frist gehört weiterhin zu den umstrittenen Teilen des Melderegimes. Hinzu kommt eine operative Schwierigkeit: Hersteller müssen im laufenden Betrieb entscheiden, ob ein Ereignis als „aktiv ausgenutzte Schwachstelle“, als „schwerwiegender Sicherheitsvorfall“ oder als beides einzuordnen ist. Davon hängen sowohl die Inhalte der Frühwarnung als auch die Fristlogik des Abschlussberichts ab.

Die Hauptkritikpunkte

Erkennung ist der Engpass. Um eine Schwachstelle als „aktiv ausgenutzt“ zu identifizieren, benötigen Hersteller Telemetrie von Kundengeräten, die Exploit-Versuche erkennt, Integration mit Threat-Intelligence-Quellen, die Fähigkeit, „Forschungs-Chatter“ von echter Ausnutzung zu unterscheiden, sowie schnelle interne Eskalation und Triage. Viele kleine und selbst mittlere Softwarehersteller verfügen über keines dieser Systeme. Aus Art. 14 CRA folgt zwar keine Pflicht, solche Systeme zu betreiben — ohne sie bleibt die Meldefähigkeit aber vom Zufall abhängig, und ab Dezember 2027 greifen ohnehin die Anforderungen aus Anhang I Teil II.

SBOM als Voraussetzung. Ohne eine aktuelle, maschinenlesbare Software-Stückliste lässt sich nicht schnell genug feststellen, welche Versionen eines Produkts betroffen sind. Siehe auch Artikel 7: SBOM für Softwarehersteller.

Klassifikationsdruck. Die Trennung zwischen Schwachstelle (Art. 14 Abs. 1) und schwerwiegendem Sicherheitsvorfall (Art. 14 Abs. 3 mit der Definition in Abs. 5) muss innerhalb der 24-h-Frist getroffen werden. Die Auslegungs-Guidance der Kommission gibt dafür nur einen zeitlichen Rahmen vor (Rn. 213 f.), aber keine Klassifikationskriterien. Das Stufenraster der BSI TR-03183-3 (gültig / validiert / validiert und verifiziert, Kap. 3.1.3)[11] taugt hier als praktisches Triage-Gerüst, ersetzt die rechtliche Einordnung aber nicht.

Internationale Herausforderungen. Softwarehersteller mit verteilten Teams in verschiedenen Zeitzonen können die Eskalation nicht immer innerhalb von 24 Stunden koordinieren.

Branchenkommentar und Ausblick

In Branchenkommentaren wurden ähnliche Bedenken zu den operativen Schwierigkeiten der 24-Stunden-Frist vorgebracht. Solche Positionen sind nicht als Beleg für den Verordnungsinhalt einzuordnen. Der endgültige CRA-Text enthält einige Präzisierungen, die solchen Bedenken Rechnung tragen: die Klarstellung, dass die Frist ab Kenntnisnahme beginnt, der Helpdesk der Koordinator-CSIRTs für Kleinst-, kleine und mittlere Unternehmen (Art. 17 Abs. 6 CRA) sowie die Ausnahme von den Geldbussen für Kleinst- und Kleinunternehmen bei der 24-h-Frühwarnung (Art. 64 Abs. 10 lit. a). Hinzugekommen sind seither die Klarstellungen der Guidance (Kapitel 9.1) und der FAQ zum Fristbeginn und zur fehlenden Monitoringpflicht (siehe „Wann beginnt die ‚Kenntnis‘?“). Die 24-Stunden-Frist bleibt dennoch ambitioniert — realistisch einhaltbar ist sie nur mit kontinuierlichen Prozessen, nicht mit punktuellen Massnahmen.

Warum Meldepflichten-Compliance in der Praxis scheitert

Auf dem Papier wirken 24 Stunden, 72 Stunden, 14 Tage und ein Monat wie handhabbare Fristen. Gespräche mit Herstellern zeigen, wie schnell dieser Eindruck täuscht. Spätestens mit der vollen Anwendung des CRA ab dem 11. Dezember 2027 setzt eine schnelle Meldung bereits eine kontinuierliche Schwachstellenbeobachtung voraus (Art. 13 Abs. 8 CRA i. V. m. Anhang I Teil II Nr. 1 — siehe Artikel 3: Abgestufte CRA-Pflichten). Auch in der Übergangsphase entscheidet die Bearbeitungsgeschwindigkeit, denn mit dem Eingang eines Hinweises beginnt die Zeit für die Erstbewertung. Typische Lücken werden dann sofort sichtbar: Telemetrie und Threat-Intelligence-Feeds laufen nicht zusammen, weshalb Exploit-Aktivitäten erst Tage später erkannt werden. Niemand ist eindeutig für das Schwachstellen-Postfach zuständig; ein Hinweis bleibt über das Wochenende liegen. Die SBOM stammt aus dem letzten Release und beantwortet nicht, welche Produktversionen betroffen sind. Eskalationspfade existieren auf Papier, wurden aber nie unter Zeitdruck getestet. Nachvollziehbare Zeitstempel fehlen ebenfalls — die Einhaltung der Fristen lässt sich gegenüber der Marktüberwachungsbehörde im Nachhinein nicht mehr belegen.

Die Vorbereitung endet deshalb nicht mit einem einmal eingerichteten Meldeweg. Sie ist ein kontinuierlicher Compliance-Prozess, der bei jedem Release, jeder neuen CVE-Meldung und jeder Änderung in der Lieferkette erneut greifen muss. Viele interne Initiativen scheitern an dieser Daueraufgabe: Der Erkennungsprozess wird aufgesetzt, verliert aber innerhalb weniger Monate den Bezug zur aktuellen Produktlandschaft; SBOM-Daten veralten. Geht dann der Hinweis eines Kunden oder einer Behörde ein, beginnt die Abstimmung über Klassifikation, Zuständigkeiten und Meldeinhalt erst, obwohl die Zeit für die Erstbewertung bereits läuft.

Das Wichtigste für Hersteller

  • Seit dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in drei Stufen zu melden: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht (14 Tage nach Verfügbarkeit der Abhilfe beziehungsweise einen Monat nach der 72-Stunden-Meldung) — auch für Produkte, die schon vor dem 11. Dezember 2027 in Verkehr gebracht wurden.
  • Gemeldet wird über die einheitliche Meldeplattform der ENISA; Koordinator ist das CSIRT am Ort der EU-Hauptniederlassung, für Hersteller mit deutscher Hauptniederlassung CERT-Bund im BSI. Eine Registrierung auf Vorrat ist nicht nötig, Meldungen sind auf Englisch abzufassen.
  • Die Frist beginnt mit der Kenntnis: Nach Guidance und Kommentarliteratur zählt die tatsächliche Kenntnis nach einer unverzüglichen Erstbewertung mit angemessenem Grad an Gewissheit. Eine Monitoringpflicht folgt aus Art. 14 nicht; eingehende Hinweise sind aber unverzüglich zu bewerten.
  • Ab dem 11. Dezember 2027 kommen die Pflichten aus Art. 13 und Anhang I Teil II hinzu — darunter die Meldung an Komponentenhersteller, die CVD-Strategie und die Schwachstellenbehandlung — und ab diesem Tag sind Verstösse nach Art. 64 CRA mit Geldbussen bewehrt.
  • Wer zugleich wesentliche oder wichtige Einrichtung nach NIS-2 ist, kann für dasselbe Ereignis doppelt meldepflichtig sein; Adressaten, Auslöser und Meldewege sind getrennt zu prüfen.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • Schwachstellen & CVD: gleicht die SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet sie für die Triage auf. Ob eine Meldepflicht nach Art. 14 besteht, wird gesondert geprüft.
  • Meldepflicht & Incident Response: unterstützt die Prüfung der Meldepflicht nach Art. 14 CRA und bereitet die Angaben für Frühwarnung, Meldung und Abschlussbericht mit Fristenübersicht vor. Prüfung, Freigabe und Einreichung über die einheitliche Meldeplattform bleiben beim verantwortlichen Unternehmen.
  • SBOM & Lieferkette: erstellt die Software-Stückliste auf Wunsch automatisch aus Ihrem Code (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs per Upload; Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, werden manuell erfasst.

Für eine erste Standortbestimmung steht unabhängig von der Plattform der öffentliche CRA-Quick-Check bereit. In wenigen Minuten erhalten Sie eine kostenlose und unverbindliche Ersteinschätzung zur Anwendbarkeit des CRA, zur Produktklasse und zu Ihrem Vorbereitungsstand — einschliesslich der Frage, ob Ihr Meldeprozess für die seit dem 11. September 2026 geltenden Meldepflichten steht.

Querverweise zu vorherigen und folgenden Artikeln der Serie

Diese Meldepflichten bauen auf CRA-Konzepten auf, die in den anderen Teilen der Serie behandelt werden:

Hinweis zur Methodik

Dieser Artikel basiert auf dem offiziellen deutschen Wortlaut der Verordnung (EU) 2024/2847 in der konsolidierten Fassung einschliesslich der Berichtigungen; der Rechtsstand wurde am 11. Oktober 2026 geprüft, der Stand des deutschen Gesetzgebungsverfahrens am 16. Oktober 2026. Die Fristen, Inhalte und Definitionen wurden gegen Art. 3 Nr. 42, Art. 13 Abs. 6 und 8, Art. 14 bis 17, Art. 24 Abs. 3, Art. 64, Art. 69 Abs. 2 und 3 und Art. 71 CRA geprüft. Für Auslegungsfragen wurden Wiebe (Hrsg.), Das neue Recht der Cyberresilienz – Kommentar zur CRA, Nomos 2025 (Jossen, Wiebe)[17], Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026 (Mehnert, Kühne)[12], die nicht bindende Guidance der Kommission C(2026) 5252 final, insbesondere Rn. 209–223, und die ebenfalls nicht bindenden FAQ der Kommissionsdienststellen, Version 1.4 vom 4. September 2026, Nr. 5.1–5.5, herangezogen. Verbindliche Primärquellen gehen diesen Auslegungshilfen vor; eine Leitentscheidung des Gerichtshofs und eine gefestigte Vollzugspraxis liegen nicht vor. Die BSI TR-03183-3 v1.0.0 ist nicht bindend, aber die derzeit detaillierteste deutsche behördliche Orientierung zu CVD-Prozessen. Die Verteilungsregeln wurden gegen Art. 16 Abs. 2 CRA und die Delegierte Verordnung (EU) 2026/881 geprüft. Die Betriebsangaben beruhen auf den ENISA-Hinweisen einschliesslich der am 3. Oktober 2026 aktualisierten SRP-FAQ (letzter Abruf: 11. Oktober 2026) und auf der BSI-Themenseite zur CRA Single Reporting Platform (Stand 22.09.2026, Abruf 13.10.2026). CERT-Bund im BSI ist Koordinator-CSIRT für Hersteller mit deutscher EU-Hauptniederlassung. Dem Entwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847, BT-Drs. 21/6134, hat der Bundestag am 15. Oktober 2026 nach Billigung durch den Innenausschuss mit einer Änderung zum Inkrafttreten einzelner Vorschriften zugestimmt; der zweite Durchgang im Bundesrat und die Verkündung standen danach noch aus.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act), in der Fassung der Berichtigung vom 02.07.2025 (ABl. L 2025/90555), insbesondere Art. 3 Nr. 42 (Definition der aktiv ausgenutzten Schwachstelle), Art. 13 (Pflichten der Hersteller, Abs. 6 Lieferanten-Meldekette, Abs. 8 Schwachstellenbehandlung), Art. 14 (Meldepflichten, inkl. Abs. 6 Zwischenbericht, Abs. 7 Koordinator-CSIRT, Abs. 8 Nutzerinformation), Art. 15 (freiwillige Meldungen), Art. 16 (einheitliche Meldeplattform), Art. 17 Abs. 4 und 6, Art. 18 (Bevollmächtigter), Art. 19 (Einführer), Art. 24 Abs. 3, Art. 64 (Sanktionen, inkl. Abs. 10 lit. a Ausnahme für Kleinst-/Kleinunternehmen), Art. 69 Abs. 2 und 3 (Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden) und Art. 71 (Inkrafttreten und Anwendung), Erwägungsgrund 68, EUR-Lex

[2] Anhang I Teil II der Verordnung (EU) 2024/2847 — Schwachstellenmanagement (Nr. 1 SBOM, Nr. 2 unverzügliche Behebung, Nr. 3 Sicherheitstests, Nr. 4 Offenlegung behobener Schwachstellen, Nr. 5 Coordinated Vulnerability Disclosure Policy, Nr. 8 Information der Nutzer); anwendbar ab dem 11.12.2027

[3] Delegierte Verordnung (EU) 2026/881 der Kommission vom 11. Dezember 2025 — verbindliche Modalitäten und Bedingungen für den Aufschub der Verbreitung von Meldungen aus Cybersicherheitsgründen nach Art. 16 Abs. 2 CRA, ABl. L vom 20.04.2026, EUR-Lex

[4] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ — veröffentlicht am 27.07.2026; nicht verbindlich; ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Herangezogen: Kapitel 9.1 „Reporting obligations“, Rn. 209–221 sowie Rn. 222–223, Europäische Kommission

[5] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026 (Version 1.0 vom 03.12.2025) — insbesondere Nr. 5.1 bis 5.5 (Kenntniserlangung, Zero-Days, Altprodukte, integrierte Komponenten und Verwalter quelloffener Software). Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; lebendes Dokument.

[6] ENISA, „Frequently Asked Questions — Single Reporting Platform (SRP)“, aktualisiert am 03.10.2026 — Registrierungszeitpunkt, Verbreitungslogik, Sprache und Betriebsstand, ENISA

[7] ENISA, „CRA SRP Guidance — Assigned Representative user registration“, Stand September 2026 — EU Login, primäre/sekundäre zugewiesene Vertretung und CSIRT-Validierung, ENISA

[8] ENISA, „CRA SRP Guidance — Assigned Representative notification submission and update“, Stand September 2026 — Einreichungs- und Aktualisierungsablauf, Sichtbarkeit und Verbreitung, ENISA

[9] ENISA, „CRA SRP Guidance — Particular Exceptional Circumstances (PEC)“, Stand 09.09.2026 — technische Umsetzung des begrenzten ENISA-Zugriffs bei 72-Stunden-Schwachstellenmeldungen, ENISA

[10] ENISA, „The CRA Single Reporting Platform is launched“, 11.09.2026 — Betriebsstart und Portalzugang, ENISA

[11] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie TR-03183-3 „Cyber Resilience Requirements for Manufacturers and Products — Part 3: Vulnerability Reports and Notifications“, Version 1.0.0 vom 20.08.2025 (Vorfassung: Initial Draft 0.9.0 vom 20.09.2024) — insbesondere Kap. 3.1.3 (gültige, validierte, verifizierte und aktiv ausgenutzte Schwachstelle), Kap. 3.1.4–3.1.6 (Melde-Terminologie), Kap. 3.1.7 (korrespondierendes nationales CSIRT), Kap. 4.1–4.5 (CVD-Infrastruktur), Kap. 4.4.2 (Information des nationalen CSIRT), Kap. 4.4.8 (Reaktionszeiten), Kap. 4.4.10 (Offenlegung binnen 90 Tagen, EUVD). Nicht bindend; derzeit detaillierteste deutsche behördliche Orientierung zu CVD-Prozessen, BSI

[12] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Mehnert, Art. 14 Rn. 3, 4 (Auslegung des Kenntnisbegriffs in Art. 14 CRA: keine Überwachungs- oder Nachforschungspflicht; tatsächliche Kenntnis bzw. Zeitpunkt, zu dem unter normalen Umständen mit der Kenntnisnahme zu rechnen ist); Kühne, Art. 64 Rn. 34 (Zweifel an der Übertragung des kartellrechtlichen Unternehmensbegriffs auf den CRA)

[13] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 (NIS-2-Richtlinie), insbesondere Art. 2 Abs. 3 und Art. 3 (wesentliche und wichtige Einrichtungen, Abs. 1 lit. f kritische Einrichtungen), Art. 12 Abs. 1 (Koordinator-CSIRT) und Art. 23 (Meldepflichten), EUR-Lex

[14] Durchführungsverordnung (EU) 2024/2690 der Kommission, Erwägungsgrund 31 — Bezugspunkt der Kommissions-Guidance für ein einheitliches Verständnis des Kenntnisbegriffs

[15] Richtlinie (EU) 2022/2557 über die Resilienz kritischer Einrichtungen (CER-Richtlinie) — Bestimmung kritischer Einrichtungen; diese gelten nach Art. 2 Abs. 3 und Art. 3 Abs. 1 lit. f NIS-2 zugleich als wesentliche Einrichtungen, EUR-Lex

[16] Empfehlung 2003/361/EG der Kommission vom 6. Mai 2003 (Definition KMU; relevant für Art. 64 Abs. 10 lit. a CRA), EUR-Lex

[17] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 20 (Hersteller-an-Lieferant-Meldekette nach Art. 13 Abs. 6); Jossen, § 7 Rn. 57 mit Fn. 44 (wirtschaftliche Einheit / Konzernumsatz als Bemessungsgrundlage; Vermutung des bestimmenden Einflusses im deutschen OWi-Recht nur als Erfahrungssatz)

[18] Entwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847, BT-Drs. 21/6134, insbesondere Art. 4 Abs. 4 (Inkrafttreten der Bussgeldvorschriften zum 11.12.2027), und Beschlussempfehlung und Bericht des Innenausschusses, BT-Drs. 21/8622 vom 14.10.2026 (Art. 4 Abs. 1–3 durch einen neuen Abs. 1 ersetzt, bisheriger Abs. 4 wird Abs. 2); Kabinettsbeschluss vom 29. April 2026; erste Beratung und Überweisung an den federführenden Innenausschuss am 11. Juni 2026; keine Einwendungen des Bundesrates am 12. Juni 2026; Billigung durch den Innenausschuss mit einer Änderung zum Inkrafttreten einzelner Vorschriften am 14. Oktober 2026 und Zustimmung des Bundestages am 15. Oktober 2026; zweiter Durchgang im Bundesrat und Verkündung standen danach noch aus (Designation des BSI als Marktüberwachungsbehörde nach Art. 52 CRA und notifizierende Behörde nach Art. 36 Abs. 1 CRA), Bundesregierung, BT-Drs. 21/6134, Deutscher Bundestag, BT-Drs. 21/6512, hib 822/2026, Deutscher Bundestag, 15. Oktober 2026, BT-Drs. 21/8622

[19] The Hacker News, „Weekly Recap: IoT Exploits, Wallet Breaches, Rogue Extensions, AI Abuse & More“ (5. Januar 2026) — Fachmedienbericht zur RondoDox-Kampagne und zur Schwachstelle React2Shell (CVE-2025-55182); herangezogen als illustratives Vorfallbeispiel, nicht als Verordnungsbeleg, The Hacker News

[20] Bundesamt für Sicherheit in der Informationstechnik (BSI), „CRA Single Reporting Platform“, Themenseite, Stand 22.09.2026 (abgerufen am 13.10.2026) — CERT-Bund als koordinierendes CSIRT, keine Registrierungspflicht vor dem Meldebedarf, Meldungen auf Englisch, Meldung per E-Mail nur bei vorübergehender Nichterreichbarkeit der Plattform, BSI

[21] Vorschlag der Kommission COM(2025) 837 (Digital Omnibus) — Gesetzgebungsvorschlag, kein geltendes Recht, EUR-Lex

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 25.05.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: CRA-Konformitätsbewertung: Welches Modul passt zu Ihrem Produkt? — welches Verfahren nach Art. 32 und Anhang VIII CRA einschlägig ist, wann eine notifizierte Stelle erforderlich wird und wie die BSI TR-03183-H Modul H mit einem ISO-27001-ISMS verbindet.