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 Plattform nach Art. 16 CRA erfolgen. Dasselbe Zeitfenster gilt für schwerwiegende Sicherheitsvorfälle. Im gesetzlichen Regelfall erhält ENISA die Meldung gleichzeitig mit dem als Koordinator benannten CSIRT; für die weitere Verbreitung und in besonders aussergewöhnlichen Fällen sieht Art. 16 Abs. 2 CRA eng begrenzte Ausnahmen vor. Vom 11. September 2026 an 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.

Die drei Phasen der CRA-Implementierung

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

  • 23. Oktober 2024: CRA wird verabschiedet
  • 10. Dezember 2024: CRA tritt in Kraft
  • 11. Juni 2026: Kapitel IV (Art. 35–51 — notifizierende Behörden und notifizierte Stellen) wird wirksam
  • 11. September 2026: Phase 1 — Meldepflichten nach Art. 14 (aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle) werden verpflichtend
  • 11. Dezember 2027: Phase 2 — Alle übrigen CRA-Anforderungen (Sicherheitsanforderungen aus Anhang I, Konformitätsbewertung, Sorgfaltspflichten aus Art. 13) sowie die Sanktionsvorschriften nach Art. 64 CRA werden anwendbar

Zwischen den Meldepflichten und den übrigen CRA-Anforderungen liegen 15 Monate. Der Vorlauf ist nur scheinbar komfortabel: Schwachstellen-Management-Prozesse müssen früher funktionieren als andere Compliance-Massnahmen. Wer überhaupt unter den CRA fällt, erläutern Teil 1: SaaS und der CRA und Teil 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. 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 setzt nur einen Vorgang ab. Im gesetzlichen Regelfall erhalten das als Koordinator benannte CSIRT (vgl. Art. 14 Abs. 7) und ENISA die Meldung gleichzeitig. Die weitere Verbreitung an andere zuständige CSIRTs erfolgt dagegen erst durch das Koordinator-CSIRT; sie kann aus den in Art. 16 Abs. 2 CRA und der Delegierten Verordnung (EU) 2026/881 abschliessend konkretisierten Cybersicherheitsgründen aufgeschoben werden. Bei der 72-Stunden-Schwachstellenmeldung kann zudem unter besonders aussergewöhnlichen Umständen auch ENISA zunächst nur einen begrenzten Informationssatz erhalten. Die Aussage „jede Meldung geht immer sofort und vollständig an alle Stellen“ wäre deshalb zu weit.

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 verlangt zuverlässige Belege dafür, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Erlaubnis des Systemeigentümers ausgenutzt hat. Es müssen folglich drei Merkmale zusammentreffen: eine belastbare Beleglage, ein böswilliger Akteur und die fehlende Erlaubnis des Systemeigentümers. 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:

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

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 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, riskieren aber andere Pflichtenverstösse (Anhang I Teil II Nr. 2 zur unverzüglichen Behebung).

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)

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 bzw. 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 — kommen in der Definition aber nur über die Generalklausel der CIA-Triade hinein.

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 Satz 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 der FAQ der Kommissionsdienststellen (Abschnitt 5.3) und der Auslegungs-Guidance der Kommission (C(2026) 5252 final, Annex, Rn. 210) 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 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 5.3; Guidance Rn. 219 f.).

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. Wer in einer von ihm integrierten Komponente eines Drittanbieters eine Schwachstelle feststellt, muss diese gemäss Art. 13 Abs. 6 CRA dem Komponenten-Hersteller melden — unabhängig davon, ob die Schwachstelle zugleich eine Meldepflicht nach Art. 14 auslöst. Ein blosser Verdacht löst diese Meldepflicht allerdings noch nicht aus; bei einem begründeten Verdacht muss der Hersteller zunächst nähere Untersuchungen und Tests vornehmen, um dem Verdacht auf den Grund zu gehen (vgl. Wiebe, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 6 Rn. 20).

In der täglichen Arbeit entstehen damit drei parallele Adressatenkreise. Die BSI TR-03183-3 (Kap. 3.1.4–3.1.6) verwendet dafür drei unterschiedliche Begriffe, die 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 Komponenten-Hersteller (Art. 13 Abs. 6) — bei jeder im Integrationsumfeld entdeckten Schwachstelle einer Drittkomponente, auch ohne Ausnutzungsindikatoren. Diese Richtung entspricht dem vulnerability report: vertraulich und technisch detailliert, üblicherweise mit Angaben zu Identifikation, Ausnutzung und Reproduktion.
  • B2C an die Nutzer (Art. 14 Abs. 8 CRA; ergänzend Art. 13 Abs. 8 i. V. m. Anhang I Teil II Nr. 8 — unverzügliche und grundsätzlich kostenlose Verbreitung von Sicherheitsaktualisierungen samt Hinweisen) — über Sicherheitsaktualisierungen und Risiken. Das ist die security advisory: öffentlich, mit geprüfter Bewertung und Schwerpunkt auf Behebung und Risikominderung; als Verteilformat empfiehlt das BSI das Common Security Advisory Framework (CSAF).

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

Wann beginnt die „Kenntnis“?

Die 24-Stunden-Frist beginnt mit der Kenntnisnahme. Inzwischen gibt es dazu zwei Auslegungshilfen, die im Frühjahr 2026 noch nicht vorlagen: die am 27. Juli 2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der Kommission (Kapitel 9.1, Rn. 209–220) und die von den Kommissionsdienststellen gepflegten FAQ (Version 1.3 vom 1. Juli 2026, Abschnitt 5.1). 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. Der juristische Kommentar zum CRA leitet 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, 1. Aufl. 2026, CRA Art. 14 Rn. 3). 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: Abschnitt 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. Spätestens 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 verbindlich. Art. 13 Abs. 8 verpflichtet Hersteller, Schwachstellen über den festgelegten Unterstützungszeitraum hinweg 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 in einem gängigen maschinenlesbaren Format (siehe Teil 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 Abschnitt 5.1 der FAQ: Aus Art. 14 folgt kein Monitoring — Anhang I Teil II verlangt gleichwohl unter anderem eine zentrale Anlaufstelle für Schwachstellenmeldungen, eine Strategie zur koordinierten Offenlegung und Massnahmen zum Informationsaustausch über mögliche Schwachstellen. Die abgestufte Logik dieser Sorgfaltspflicht haben wir in Teil 3: Abgestufte CRA-Pflichten im Detail behandelt. 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 bussgeldbewehrt: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres (es gilt der höhere Wert).

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 dem juristischen Kommentar 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, 1. Aufl. 2026, CRA Art. 14 Rn. 4). 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). 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) — 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). 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: Guidance und FAQ sind Auslegungshilfen, keine verbindliche Auslegung — diese 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 Dezember 2027 zusätzlich mit der vollen Sanktionsbewehrung rechnen.

Bemessungsgrundlage des Bussgelds: Konzernumsatz

Wenn Art. 64 Abs. 2 CRA auf den weltweiten Jahresumsatz abstellt, ist nach der EuGH-Rechtsprechung zu Art. 101 und 102 AEUV die wirtschaftliche Einheit gemeint — typischerweise also der Konzernumsatz und nicht der Umsatz der einzelnen Konzerngesellschaft (vgl. Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 7 Rn. 57). Im deutschen OWi-Recht wird diese Grundregel durch den Grundsatz „in dubio pro reo“ modifiziert; die Konzernzurechnung wirkt dort als widerlegbarer Erfahrungssatz, nicht als rechtliche Beweislastumkehr (vgl. § 7 Rn. 57 Fn.). Praktisch bedeutet das: Bei einer Tochtergesellschaft ohne nennenswerten Eigenumsatz, deren Mutter im Milliardenbereich liegt, kann sich die Bussgeld-Obergrenze 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 Bussgelder 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 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 Bussgeld-Hebel jedoch nicht. Verstösse gegen die zugrunde liegenden Sicherheitsanforderungen aus Anhang I bleiben hingegen — vorbehaltlich der allgemeinen Verhältnismässigkeitsregelung — auch für Kleinst- und Kleinunternehmen sanktionsbewehrt.

Bussgeld-mildernde Faktoren: Settlement, Selbstanzeige, Kooperation

Operativ relevant für die Krisenkommunikation ist, dass die Bussgeld-Höhe nicht statisch ist. Nach der CRA-Kommentarliteratur (Jossen, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 7 Rn. 61–62) wirken sich insbesondere Settlement-Vereinbarungen, Selbstanzeige und aktive Kooperation mit der Marktüberwachungsbehörde mildernd auf die Sanktionshöhe aus. Wer eine Schwachstelle oder einen Vorfall proaktiv und vollständig meldet, intern unverzüglich aufklärt und der Behörde Zugang zu Telemetrie und Logs gewährt, verbessert die Verhandlungsposition spürbar. Wer im Gegenzug Erkennungslücken kaschiert oder die Aufklärung verzögert, schliesst diesen Hebel von vornherein aus. Für die interne Krisenkommunikation heisst das: Die Entscheidung „melden oder abwarten“ ist auch eine ökonomische Entscheidung über den möglichen Sanktionsrahmen.

Die einheitliche Meldeplattform (Art. 16 CRA)

ENISA betreibt die nach Art. 16 CRA eingerichtete einheitliche Meldeplattform (Single Reporting Platform), die ab dem 11. September 2026 als zentraler Meldekanal für verpflichtende CRA-Meldungen fungieren soll. Meldungen nach Art. 14 müssen über diesen Kanal erfolgen. Art. 15 sieht die Plattform auch für freiwillige Meldungen vor; nach den aktuellen ENISA-Hinweisen wird diese Funktion zum Start jedoch noch nicht verfügbar sein.

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 dafür konkretisiert die Delegierte Verordnung (EU) 2026/881: etwa wenn sensible Angaben unmittelbar die Entwicklung einer Ausnutzungstechnik ermöglichen könnten, eine wirksame Risikominderung binnen 72 Stunden bevorsteht, ein bestimmtes CSIRT die Vertraulichkeit nicht gewährleisten kann oder die Plattform selbst von einem Cybersicherheitsvorfall betroffen ist.

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.

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. ENISA rät ausdrücklich von einer vorsorglichen Vorregistrierung ab: Registriert werden soll erst, wenn tatsächlich eine Meldung einzureichen ist. Für die interne Vorbereitung sollten Unternehmen deshalb EU-Login-Konten, Vertretungsbefugnisse und Kontaktdaten vorab klären, ohne bereits eine Plattformregistrierung auszulösen. Zum Prüfungsstand vom 6. September 2026 ist für die erste Plattformversion keine API vorgesehen; die öffentliche SRP-Adresse soll zum Start am 11. September bereitgestellt werden. 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. 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. 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.

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 Bundesamt für Sicherheit in der Informationstechnik (BSI) diese Rolle. Sie 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) — nicht erst aus dem nationalen CRA-Durchführungsgesetz. Das nationale Cyberresilienz-Durchführungsgesetz regelt demgegenüber die Marktüberwachung (Art. 52 CRA) und die Notifizierung; der Referentenentwurf des Bundesministeriums des Innern datiert vom 12. März 2026, der Regierungsentwurf wurde am 29. April 2026 vom Kabinett beschlossen. Der Bundestag überwies ihn nach der ersten Beratung am 11. Juni 2026 an die Ausschüsse; der Bundesrat erhob am 12. Juni 2026 keine Einwendungen. Zum Prüfungsstand vom 11. August 2026 ist das Gesetz nicht verkündet. 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 melden nach der Kaskade des Art. 14 Abs. 7 UAbs. 3 CRA über den Endpunkt des CSIRT des Mitgliedstaats, in dem ihr Bevollmächtigter (Art. 18 CRA) niedergelassen ist; fehlt ein Bevollmächtigter, ist der Mitgliedstaat des Einführers (Art. 19 CRA) massgeblich, danach der des Händlers — 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 Teil 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 soll ENISA die freiwillige Meldemöglichkeit erst in einer späteren Ausbaustufe bereitstellen; zum Start am 11. September 2026 ist sie noch nicht vorgesehen. 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) — ab diesem Moment beginnt für den Hersteller die Kenntnis im Sinne von Art. 14.

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.

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 Abschnitt 5.2 der FAQ nur dann gemäss Art. 14 zu melden, wenn der Hersteller zuverlässige Belege 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.

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, eine eigene CVD-Strategie aufzustellen und umzusetzen. Bei KI-Komponenten können zusätzliche Offenlegungspflichten aus dem AI Act hinzukommen — siehe Teil 5: AI Act trifft CRA und Teil 6: Hochrisiko-KI.

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). Sie ist nicht bindend, beschreibt aber den praktischen Prüfmassstab derjenigen Behörde, die zugleich das deutsche Koordinator-CSIRT betreibt. 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 CRA erfasst demgegenüber nur Schwachstellen im Produkt.
  • 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?

Grundsätzlich nein. Die Abgrenzung ist allerdings nicht in jedem Fall einfach.

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 dreistufigen Frist 24 Stunden Frühwarnung, 72 Stunden Vollmeldung, ein Monat Abschlussbericht (Art. 23 Abs. 4 NIS-2). Strukturell ähnelt das den CRA-Fristen, der Adressatenkreis und der Vorfallbegriff sind aber unterschiedlich. Der oft synonym gebrauchte Begriff „kritische Infrastruktur“ gehört nicht in den NIS-2-Adressatenkreis: Kritische Einrichtungen werden durch die CER-Richtlinie (EU) 2022/2557 adressiert — eine eigenständige, wenn auch komplementäre Regulierung.

CRA verpflichtet Softwarehersteller zur Meldung von aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen in ihrer Software.

In der Praxis sind daher unterschiedliche Konstellationen auseinanderzuhalten:

  • Ein Softwarehersteller, dessen Produkt von wesentlichen oder wichtigen Einrichtungen genutzt wird, muss die Schwachstelle nach CRA melden.
  • Die wesentliche oder wichtige Einrichtung, die von einer Schwachstelle in der Software des Herstellers betroffen ist, muss nach NIS-2 melden.
  • Die Meldungen gehen an unterschiedliche Behörden (Koordinator-CSIRT/ENISA für CRA, nationale NIS-2-Behörden für die Einrichtung).

Doppelmeldungen vermeiden

Es gibt jedoch Überschneidungen:

  • Wenn ein Softwarehersteller gleichzeitig eine wesentliche oder wichtige Einrichtung im Sinne der NIS-2-Richtlinie ist (z. B. ein Anbieter digitaler Dienste oder ein Telekommunikationsunternehmen mit proprietärer Software), können Meldepflichten kumulativ auftreten.
  • 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), damit vergleichbare Meldepflichten aus unterschiedlichen EU-Rechtsakten einheitlich verstanden werden. Eine vollständige Harmonisierung der Verfahren steht aber noch aus.

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 KMU und sogar 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 ein aktuelles, maschinenlesbares Software Bill of Materials (SBOM) lässt sich nicht schnell genug feststellen, ob überhaupt alle Versionen eines Produkts betroffen sind. Siehe auch Teil 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 Rahmen vor — die Erstbewertung ist unverzüglich vorzunehmen, massgeblich ist ein angemessener Grad an Gewissheit (Rn. 213 f.) —, aber keine Klassifikationskriterien. Das Stufenraster der BSI TR-03183-3 (gültig / validiert / validiert und verifiziert, Kap. 3.1.3) 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 vorgebracht; ein Beispiel ist das Positionspapier des Center for Cybersecurity Policy — einer US-amerikanischen Branchenorganisation —, das die operativen Schwierigkeiten der 24-Stunden-Frist diskutiert. Solche Positionen sind als Branchenkommentar einzuordnen und nicht als Beleg für den Verordnungsinhalt. Die endgültige CRA enthält einige Präzisierungen, die solchen Bedenken Rechnung tragen: die Klarstellung, dass die Frist ab Kenntnisnahme beginnt, der Hinweis auf CSIRT-Helpdesks für KMU sowie die Bussgeld-Ausnahme für Kleinst- und Kleinunternehmen bei der 24-h-Frühwarnung (Art. 64 Abs. 10 lit. a). Hinzugekommen sind seither die Auslegungs-Guidance der Kommission (Kapitel 9.1) und die FAQ der Kommissionsdienststellen, die den Fristbeginn an eine unverzügliche Erstbewertung und einen angemessenen Grad an Gewissheit knüpfen und klarstellen, dass Art. 14 selbst keine Monitoringpflicht begründet. 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 Teil 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.

crAIready für Ihre Meldepflicht-Bereitschaft

crAIready führt die für die Meldebereitschaft erforderlichen CRA-Arbeitsschritte zusammen:

  • Schwachstellen & CVD: crAIready gleicht die per Upload oder über eine angebundene CI-Pipeline bereitgestellte SBOM regelmässig mit OSV, NVD, CISA KEV und EUVD ab und ordnet Hinweise den betroffenen SBOM-Komponenten zu und bereitet verfügbare Bewertungsinformationen für die Triage auf. Die Art.-14-Prüfung erfolgt gesondert, denn ein Schwachstellenhinweis startet noch keine 24-Stunden-Frist. Ergänzend unterstützt crAIready den CVD-Prozess nach Anhang I Teil II Nr. 4–6 CRA.
  • Meldepflicht & Incident Response: crAIready führt Sie durch die unterschiedlichen Abläufe für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Die erforderlichen Angaben werden strukturiert vorbereitet und die jeweils geltenden Fristen übersichtlich dargestellt. Prüfung, Freigabe und Einreichung über die offizielle einheitliche Meldeplattform nach Art. 16 CRA bleiben beim verantwortlichen Unternehmen. Incident-Response-Pläne können produktbezogen hinterlegt werden.

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 Orientierung dazu, wo Ihr Unternehmen bei der CRA-Compliance und den Meldepflichten ab dem 11. September 2026 steht. Keine Rechtsberatung im Sinne des RDG.

Querverweise zu vorherigen und folgenden Artikeln der Serie

Diese Meldepflichten bauen auf grundlegenden CRA-Konzepten auf, die in vorherigen Artikeln behandelt wurden:

Hinweis zur Methodik

Dieser Artikel basiert auf dem offiziellen Wortlaut der Verordnung (EU) 2024/2847 (Cyber Resilience Act) in der deutschen Sprachfassung, abgerufen von EUR-Lex und Springlex (Stand 11. August 2026). Die Fristen-, Inhalts- und Definitionsangaben (Art. 3 Nr. 42, Art. 13 Abs. 6 und 8, Art. 14 Abs. 1–5 und 8, Art. 15, Art. 16 einschliesslich Abs. 2, Art. 64, Art. 69 Abs. 3, Art. 71) wurden gegen den Verordnungstext gegengeprüft. Für Auslegungsfragen zur Hersteller-Lieferanten-Meldekette, zur Bemessungsgrundlage des Bussgelds (wirtschaftliche Einheit / Konzernumsatz) und zu bussgeldmildernden Faktoren stützt sich der Artikel auf den CRA-Kommentar (Wiebe (Hrsg.), Nomos 2025), insbesondere die Beiträge von Wiebe (§ 6) und Jossen (§ 7). Für die Auslegung des Kenntnisbegriffs in Art. 14 CRA stützt sich der Artikel auf den juristischen Kommentar NK-CRA/Mehnert (in: Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Aufl. 2026, Nomos), CRA Art. 14 Rn. 3 und 4, sowie auf die am 27.07.2026 mit Communication C(2026) 5252 final veröffentlichte Guidance der Kommission (Kapitel 9.1, Rn. 209–220) und die FAQ der Kommissionsdienststellen (Version 1.3 vom 01.07.2026, Abschnitte 5.1–5.3). Beide Dokumente sind rechtlich nicht verbindlich. Die FAQ geben nach eigener Angabe keine offizielle Position der Kommission wieder und werden als lebendes Dokument fortgeschrieben. Die verbindliche Auslegung des Unionsrechts obliegt dem Gerichtshof der Europäischen Union; eine Leitentscheidung zum Kenntnisbegriff des Art. 14 CRA liegt nicht vor, ebenso wenig eine dokumentierte Vollzugspraxis der Marktüberwachungsbehörden. Die Angaben zu den nationalen Erwartungen an CVD-Prozesse stammen aus der Technischen Richtlinie BSI TR-03183-3, Version 1.0.0 vom 20.08.2025; sie ist nicht bindend, beschreibt aber den Prüfmassstab des BSI. Die Verteilungsregeln wurden zusätzlich gegen Art. 16 Abs. 2 CRA und die unmittelbar geltende Delegierte Verordnung (EU) 2026/881 geprüft; die Registrierungs- und Ablaufangaben beruhen auf den ENISA-Betriebshinweisen, zuletzt geprüft am 06.09.2026. Die Rolle des BSI als Koordinator-CSIRT folgt aus der NIS-2-Benennung (Art. 3 Nr. 51 CRA i. V. m. Art. 12 Abs. 1 der Richtlinie (EU) 2022/2555); für die Designation des BSI als Marktüberwachungs- und notifizierende Behörde wird auf das Cyberresilienz-Durchführungsgesetz verwiesen (Referentenentwurf des BMI vom 12. März 2026; Regierungsentwurf am 29. April 2026 vom Kabinett beschlossen; erste Beratung und Ausschussüberweisung im Bundestag am 11. Juni 2026; keine Einwendungen des Bundesrates am 12. Juni 2026; Gesetz zum Prüfungsstand vom 11. August 2026 noch nicht verkündet).

Quellen

  • 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), 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. 8 Nutzerinformation), Art. 15 (freiwillige Meldungen), Art. 16 (einheitliche Meldeplattform), Art. 18 (Bevollmächtigter), Art. 19 (Einführer), Art. 64 (Sanktionen, inkl. Abs. 10 lit. a Ausnahme für Kleinst-/Kleinunternehmen), Art. 69 Abs. 3 (Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden) und Art. 71 (Inkrafttreten und Anwendung), EUR-Lex
  • Anhang I Teil II der Verordnung (EU) 2024/2847 — Schwachstellenmanagement (Nr. 1 SBOM, Nr. 3 Sicherheitstests, Nr. 5 Coordinated Vulnerability Disclosure Policy, Nr. 8 Information der Nutzer)
  • 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, EUR-Lex
  • 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–220, Europäische Kommission
  • Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.2026 — insbesondere Abschnitt 5.1 (Wie ein Hersteller Kenntnis erlangen kann; keine Monitoringpflicht), 5.2 (Zero-Days, Bug Bounty, Prüflabore) und 5.3 (Produkte, die vor Geltungsbeginn in Verkehr gebracht wurden). Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Kommission und nicht verbindlich; lebendes Dokument.
  • ENISA, „Frequently Asked Questions — Single Reporting Platform (SRP)“, aktualisiert am 03.08.2026 — Registrierungszeitpunkt, Verbreitungslogik und Betriebsstand, ENISA
  • ENISA, „CRA SRP Guidance — Assigned Representative user registration“, aktualisiert am 03.08.2026 — EU Login, primäre/sekundäre zugewiesene Vertretung und CSIRT-Validierung, ENISA
  • ENISA, „CRA SRP Guidance — Assigned Representative notification submission and update“, aktualisiert am 03.08.2026 — Einreichungs- und Aktualisierungsablauf, Sichtbarkeit und Verbreitung, ENISA
  • 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, aber praktischer Prüfmassstab des BSI, das zugleich das deutsche Koordinator-CSIRT betreibt, BSI
  • NK-CRA/Mehnert, in: Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos, CRA Art. 14 Rn. 3, 4 — juristischer Kommentar zur 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)
  • Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 (NIS-2-Richtlinie), insbesondere Art. 3 (wesentliche und wichtige Einrichtungen) und Art. 23 (Meldepflichten), EUR-Lex
  • Durchführungsverordnung (EU) 2024/2690 der Kommission, Erwägungsgrund 31 — Bezugspunkt der Kommissions-Guidance für ein einheitliches Verständnis des Kenntnisbegriffs
  • Richtlinie (EU) 2022/2557 über die Resilienz kritischer Einrichtungen (CER-Richtlinie) — eigenständiger Adressatenkreis „kritischer Einrichtungen“, abzugrenzen von NIS-2, EUR-Lex
  • Empfehlung 2003/361/EG der Kommission vom 6. Mai 2003 (Definition KMU; relevant für Art. 64 Abs. 10 lit. a CRA), EUR-Lex
  • Wiebe (Hrsg.), CRA-Kommentar, Nomos 2025 — insbesondere Wiebe, § 6 Rn. 20 (Hersteller-an-Lieferant-Meldekette nach Art. 13 Abs. 6); Jossen, § 7 Rn. 57 (wirtschaftliche Einheit / Konzernumsatz als Bemessungsgrundlage); Jossen, § 7 Rn. 61–62 (Settlement, Selbstanzeige, Kooperation als bussgeldmildernde Faktoren)
  • Cyberresilienz-Durchführungsgesetz: Referentenentwurf des Bundesministeriums des Innern vom 12. März 2026; Regierungsentwurf am 29. April 2026 vom Kabinett beschlossen; erste Beratung und Ausschussüberweisung im Bundestag am 11. Juni 2026; keine Einwendungen des Bundesrates am 12. Juni 2026; zum Prüfungsstand vom 11.08.2026 nicht verkündet (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
  • Center for Cybersecurity Policy (US-Branchenorganisation): Vulnerability Management Under The Cyber Resilience Act — als Branchenkommentar, nicht als Verordnungsbeleg, CCSP
  • 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

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. Veröffentlicht am: 25.05.2026. Fachlich geprüft am: 13.08.2026. Produktbeschreibung aktualisiert am: 06.09.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Konformitätsbewertung und CE-Kennzeichnung unter dem CRA — welches der vier Module aus Anhang VIII (A, B, C, H) nach Art. 32 CRA für Ihr Produkt passt, wann eine notifizierte Stelle eingeschaltet werden muss und wie die BSI TR-03183-H Modul H mit einem ISO-27001-ISMS verbindet.