Von Redaktion codAIx | 25. Mai 2026

Der Cyber Resilience Act (CRA) führt ein Melderegime mit strikten Zeitvorgaben ein: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen Softwarehersteller über die einheitliche Meldeplattform nach Art. 16 CRA innerhalb von 24 Stunden mitteilen. 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 gelten jedoch die eng begrenzten Ausnahmen des Art. 16 Abs. 2 CRA. Ab dem 11. September 2026 ist die Meldung nicht mehr optional, sondern Pflicht. Dieser Artikel klärt auf, welche Fristen gelten, wer melden muss und wie die einheitliche Meldeplattform funktioniert.

Die drei Phasen der CRA-Implementierung

Bevor wir in die Details der Meldepflichten einsteigen, ein wichtiger Hinweis zur Chronologie nach Art. 71 CRA:

  • 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

Das bedeutet konkret: Die Meldepflichten kommen 15 Monate vor den anderen CRA-Anforderungen. Dies gibt Herstellern zwar Vorlauf, erzeugt aber auch neue Herausforderungen, da Schwachstellen-Management-Prozesse schneller aufgebaut werden müssen als andere Compliance-Massnahmen. Eine erste Übersicht zur Frage, wer überhaupt unter den CRA fällt, geben wir in Teil 1: SaaS und der CRA und in 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“?

Dieser Begriff trägt das gesamte Melderegime, wird in der Praxis aber häufig unpräzise verwendet. Art. 3 Nr. 42 CRA definiert die aktiv ausgenutzte Schwachstelle als eine Schwachstelle, für die es zuverlässige Belege dafür gibt, dass ein böswilliger Akteur sie in einem System ohne Erlaubnis des Systemeigentümers ausgenutzt hat. Drei Merkmale müssen also zusammenkommen: eine belastbare Beleglage, ein böswilliger Akteur und die fehlende Erlaubnis des Systemeigentümers. Eine theoretisch ausnutzbare Schwachstelle ohne Ausnutzungsbeleg erfüllt die Definition 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.

Wer diese Stufen im eigenen Prozess sauber trennt, hat in der 24-Stunden-Situation eine dokumentierte Entscheidungskette statt 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)

Für die meisten Hersteller ist dies die naheliegendste Frage zum 11. September 2026: Gilt die Meldepflicht auch für Produkte, die längst im Markt sind? Die Antwort lautet ja. Nach Art. 69 Abs. 3 CRA (i. V. m. Art. 71 Abs. 2 Satz 2) gelten die Pflichten aus Art. 14 ab dem 11. September 2026 für 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).

Operativ macht das die Meldelandschaft komplexer, als sie auf den ersten Blick wirkt. Drei Adressatenkreise bestehen parallel — und die BSI TR-03183-3 (Kap. 3.1.4–3.1.6) hält dafür drei unterschiedliche Begriffe bereit, die im deutschen Sprachgebrauch alle unter „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).

Wer SBOM-, Erkennungs- und Eskalationsprozesse nur auf das Behörden-Regime auslegt, übersieht die Lieferketten-Meldung und damit eine eigenständige Pflicht.

Wann beginnt die „Kenntnis“?

Die 24-Stunden-Frist beginnt mit der Kenntnisnahme. Anders als noch im Frühjahr 2026 liegen dazu inzwischen zwei Auslegungshilfen vor: der als Annex zu C(2026) 5252 final veröffentlichte Guidance-Entwurf, dessen Inhalt die Kommission am 27. Juli 2026 gebilligt hat (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. Der Annex enthält demgegenüber den vom Kollegium inhaltlich gebilligten Guidance-Entwurf; seine förmliche Annahme steht noch aus. Daraus folgt keine einfache rechtliche Rangstufe. Zusammen mit der juristischen Kommentarliteratur ergibt sich aber ein deutlich klareres Bild als aus dem Verordnungstext allein — und dieses Bild fällt anders aus, als in der Praxis häufig angenommen wird.

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 Support-Zeitraum 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 Vorfall 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.

Kurz gefasst: Eine Pflicht, aktiv nach Ausnutzungshinweisen zu suchen, folgt aus Art. 14 CRA nicht. Eine Pflicht, eingehende Hinweise zügig zu bearbeiten, sehr wohl. Der praktische Hebel liegt damit nicht in der Frage, ob man von etwas hätte wissen müssen, sondern in der Frage, wie schnell aus einem eingegangenen Hinweis eine belastbare Erstbewertung wird.

Wie wenig Zeit dafür in der Realität bleibt, zeigt die RondoDox-Kampagne: 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 in einer solchen Lage erst anfängt, Zuständigkeiten, Bewertungskriterien und Meldewege zu klären, verbraucht die 24 Stunden mit interner Abstimmung. Der Grund, Prozesse vorab aufzubauen, ist deshalb nicht eine unterstellte Kenntnisfiktion, sondern die Kombination aus der Geschwindigkeit realer Angriffe und den 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 CRA-Meldungen fungieren wird. Diese Plattform ist nicht optional — alle Meldungen nach Art. 14 müssen über diesen Kanal erfolgen; auch freiwillige Meldungen nach Art. 15 laufen über die Plattform.

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 von ENISA am 3. August 2026 aktualisierten 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 11. August 2026 stellt ENISA keine API bereit; auch die öffentliche SRP-Adresse soll erst zum Start 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

Während Art. 14 verpflichtende Meldungen regelt, eröffnet Art. 15 Herstellern und anderen natürlichen oder juristischen Personen die Möglichkeit, freiwillig zu 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).

Die freiwilligen Meldungen folgen 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). Wichtig: Wenn eine andere Person als der Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall 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

Hier liegt in der Praxis eine der häufigsten Fehleinschätzungen. Eine Schwachstelle, für die noch kein Patch verfügbar ist (ein sogenannter Zero-Day), ist nach Abschnitt 5.2 der FAQ nur dann nach Art. 14 zu melden, wenn der Hersteller zuverlässige Belege dafür hat, dass ein böswilliger Akteur sie ausgenutzt 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 — jeweils vorausgesetzt, es gibt keinen Beleg für eine vorherige böswillige Ausnutzung. Das entspricht Erwägungsgrund 68 CRA, wonach Schwachstellen, die in guter Absicht zu Test-, Untersuchungs-, Korrektur- oder Offenlegungszwecken entdeckt werden, keiner verpflichtenden Meldung unterliegen. In beiden Fällen bleibt die freiwillige Meldung nach Art. 15 CRA möglich — und je nach Risikolage sinnvoll.

Achtung: Art. 15 ist nicht dasselbe wie die Pflicht zur Coordinated Vulnerability Disclosure Policy. Diese sitzt in Anhang I Teil II Nr. 5 und ist eine Hersteller-Pflicht, eine eigene CVD-Strategie aufzustellen und umzusetzen. Für KI-Komponenten in Produkten ergeben sich aus dem AI Act zusätzliche Offenlegungspflichten — siehe dazu 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

Eine häufig gestellte Frage lautet: Muss ich das gleiche Sicherheitsereignis zweimal melden — einmal unter NIS-2 und einmal unter CRA?

Die kurze Antwort: Nein, aber es ist kompliziert.

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.

Die Szenarien sind also unterschiedlich:

  • 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 bleibt eine kontroverse Bestimmung des Melderegimes — ergänzt um die operative Komplexität, dass Hersteller im Echtzeitbetrieb entscheiden müssen, ob ein Ereignis eine „aktiv ausgenutzte Schwachstelle“ oder ein „schwerwiegender Sicherheitsvorfall“ ist (oder beides), weil davon die Inhalte der 24-h-Frühwarnung und die Frist-Logik des Abschlussberichts abhängen.

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

Die rechtlichen Fristen klingen auf dem Papier handhabbar — 24 Stunden, 72 Stunden, 14 Tage / 1 Monat. Was uns in Gesprächen mit Herstellern regelmässig begegnet, ist eine andere Realität. Spätestens mit der vollen Anwendung der CRA ab dem 11. Dezember 2027 verlangt die Verordnung nicht erst eine schnelle Meldung, sondern bereits eine kontinuierliche Schwachstellenbeobachtung als Vorstufe (Art. 13 Abs. 8 CRA i. V. m. Anhang I Teil II Nr. 1 — siehe Teil 3: Abgestufte CRA-Pflichten). Und schon in der Übergangsphase davor entscheidet die Bearbeitungsgeschwindigkeit: Sobald ein Hinweis eingeht, läuft die Zeit für die Erstbewertung. Genau hier setzen die typischen Lücken an: Erkennungsprozesse, die Exploit-Aktivitäten erst Tage später aufnehmen, weil Telemetrie und Threat-Intelligence-Feeds nicht zusammenlaufen. Postfächer für Schwachstellenmeldungen, die niemandem eindeutig zugeordnet sind, sodass ein Hinweis über ein Wochenende liegen bleibt. SBOMs, die im letzten Release erstellt und seitdem nicht aktualisiert wurden, sodass im Ernstfall niemand innerhalb von Stunden sagen kann, welche Produktversionen betroffen sind. Eskalationspfade, die zwar auf Papier existieren, aber noch nie unter Zeitdruck getestet wurden. Und fehlende, audit-feste Zeitstempel über den gesamten Meldeprozess hinweg — was die Einhaltung der Fristen gegenüber Marktüberwachungsbehörden nachträglich nicht mehr beweisbar macht.

Das ist kein einmaliges Projekt. Es ist ein kontinuierlicher Compliance-Prozess, der an jedem Release, jeder neuen CVE-Meldung und jeder Änderung in der Lieferkette wieder zuschlägt. Genau daran scheitern in unserer Erfahrung die meisten internen Initiativen: Der Erkennungsprozess wird einmal aufgesetzt, aber Monate später fehlt der Bezug zur aktuellen Produktlandschaft, SBOM-Daten sind veraltet — und wenn dann der Hinweis eines Kunden oder einer Behörde eingeht, beginnt die interne Abstimmung zu Klassifikation, Zuständigkeiten und Meldeinhalt erst, während die Frist für die Erstbewertung bereits läuft.

crAIready für Ihre Meldepflicht-Bereitschaft

crAIready ist die KI-gestützte CRA-Compliance-Plattform, die Sie bei der Umsetzung Ihrer CRA-Meldepflichten unterstützt:

  • Meldepflicht & Incident Response (Modul 5): geführter 24-h-/72-h-/14-Tage-Workflow mit vorbefüllten Feldern und CSAF-konformem Export; die Einreichung beim zuständigen CSIRT nehmen Sie selbst vor — mit Fristtracking und Audit-Log als Nachweis.
  • Schwachstellen & CVD (Modul 3): kontinuierlicher Abgleich gegen NVD, OSV, GitHub Advisory und CISA KEV mit KI-Priorisierung — damit die 24-Stunden-Frist überhaupt einhaltbar ist; inklusive einbettbarer öffentlicher Meldestelle für Security-Researcher.
  • Incident-Response-Pläne (Modul 5): vorbereitete Pläne für CRA und NIS-2.

Eine erste, kostenlose Orientierung — unabhängig von der Plattform — bietet der öffentliche CRA-Quick-Check: In wenigen Minuten erhalten Sie eine orientierende Einschätzung, wo Ihr Unternehmen bei der CRA-Compliance und den Meldepflichten ab dem 11. September 2026 steht.

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 den als Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurf (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; der Annex enthält den vom Kollegium inhaltlich gebilligten Guidance-Entwurf, dessen förmliche Annahme noch aussteht. Daraus folgt keine einfache rechtliche Rangstufe. 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 am 03.08.2026 aktualisierten Betriebshinweisen der ENISA. 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).

Versionsstand der Vorfassung: v20 (Stand: 12.08.2026). Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 25.05.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert. Vorherige Fassung: v19 (Stand: 11.08.2026). Änderungen gegenüber v18: die zu weit gehende Aussage einer ausnahmslos simultanen und vollständigen Weiterleitung korrigiert; Regelfall, Verbreitung an weitere CSIRTs, Aufschub nach Art. 16 Abs. 2 CRA und Delegierter Verordnung (EU) 2026/881 sowie die eng begrenzte ENISA-Ausnahme getrennt dargestellt; die am 03.08.2026 aktualisierten ENISA-Hinweise zu EU Login, Assigned Representatives, CSIRT-Validierung, fehlender API und noch ausstehender öffentlicher SRP-Adresse aufgenommen; Kabinettsdatum und parlamentarischen Stand des deutschen Durchführungsgesetzes korrigiert und aktualisiert. Die Fassung v18 bleibt unverändert archiviert.

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 (Importeur), 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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“ — Inhalt gebilligt am 27.07.2026; ersetzt den Entwurf Ares(2026)2319816 vom 03.03.2026; die förmliche Annahme steht noch aus, bis alle EU-Sprachfassungen vorliegen (Stand 11.08.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. Zuletzt geprüft am: 13.08.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.

Stand: 13.08.2026 (v21 — freigegebene Schlusskorrektur: Anwendbarkeit statt Inkrafttreten der Pflichten formuliert; FAQ und Guidance ohne pauschale Rangstufe institutionell und verfahrensrechtlich abgegrenzt; Zeichensetzung korrigiert. Vorherige Fassung: v20; zeitabhängige Formulierungen unverändert.)