Von Redaktion codAIx | April 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 — die Plattform leitet die Meldung simultan an das als Koordinator benannte CSIRT und die ENISA weiter. Ab dem 11. September 2026 ist dies 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 treten in Kraft

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). Die Plattform leitet jede einzelne Meldung simultan an das als Koordinator benannte CSIRT (vgl. Art. 14 Abs. 7) und an die ENISA weiter — der Hersteller setzt nur einen Vorgang ab.

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.

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:

  • B2A an Koordinator-CSIRT und ENISA (Art. 14 i. V. m. Art. 16) — bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen.
  • B2B an den Komponenten-Hersteller (Art. 13 Abs. 6) — bei jeder im Integrationsumfeld entdeckten Schwachstelle einer Drittkomponente, auch ohne Ausnutzungsindikatoren.
  • B2C an die Nutzer (Art. 14 Abs. 8 CRA; ergänzend Art. 13 Abs. 8 i. V. m. Anhang I Teil II Nr. 8) — über Sicherheitsaktualisierungen und Risiken.

Wer SBOM-, Detection- 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 formal mit der Kenntnisnahme. Wie ENISA und die nationalen Marktüberwachungsbehörden den Begriff "Kenntnis" im Vollzug auslegen werden, ist Stand 8. Mai 2026 jedoch noch nicht abschliessend geklärt — die ENISA-Konsultationen zur einheitlichen Meldeplattform laufen, eine verbindliche Leitlinie liegt nicht vor. Hersteller sollten sich aus drei Gründen nicht auf eine wohlwollende Auslegung verlassen:

Erstens — Grundsatz aus dem EU-Produktrecht. In der EU-produktrechtlichen Literatur und in der Behördenpraxis zu vergleichbaren Marktüberwachungsregimen wird vertreten, dass sich ein Hersteller nicht auf bewusst herbeigeführte Unkenntnis berufen kann. Die Argumentation "wir haben kein Monitoring, also hatten wir keine Kenntnis" trägt nach dieser Auslegung nicht — der Massstab ist, was ein sorgfältiger Marktteilnehmer hätte wissen müssen ("man hätte es wissen müssen"). Eine spezifische EuGH-Leitentscheidung zu diesem Begriff im CRA-Kontext liegt nicht vor; die Linie stützt sich auf Sekundärliteratur und behördliche Vollzugspraxis. Es erscheint juristisch dennoch unwahrscheinlich, dass die EU-Kommission und ENISA eine Auslegung wählen, die bewusste Sorglosigkeit belohnt.

Zweitens — Übergang in die Vollanwendung. 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. 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 diesem Zeitpunkt 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 — konstruktive Kenntnis bei öffentlich gewordenen Schwachstellen. Sobald eine Schwachstelle öffentlich wird (CVE-Eintrag, BSI-Warnung, Threat-Intelligence-Publikation, Diskussion in Sicherheits-Communities), ist die Argumentation "wir wussten von nichts" faktisch nicht mehr haltbar. Marktüberwachungsbehörden werden in solchen Fällen nach dem Massstab der konstruktiven Kenntnis prüfen, ab wann ein sorgfältiger Hersteller davon hätte erfahren müssen — und die 24-Stunden-Uhr von dort an laufen lassen.

Wie wenig Zeit dabei tatsächlich 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, dass eine öffentlich gewordene kritische Schwachstelle binnen Stunden in die automatisierte Massenausnutzung gerät. Die 24-Stunden-Frist ist deshalb keine willkürlich kurze Vorgabe, sondern folgt der realen Geschwindigkeit der Angreifer. Wer erst nach einem solchen Vorfall mit dem Aufbau eines Melde- und Detektionsprozesses beginnt, ist zu spät.

In der Übergangsphase zwischen September 2026 und Dezember 2027 bleibt eine Restunsicherheit darüber, wie streng die Auslegung tatsächlich ausfallen wird. Wer aber Detection-Prozesse erst nach der ersten Behördenuntersuchung aufbaut, riskiert in jedem Szenario eine offene rechtliche Auseinandersetzung über den Kenntnis-Zeitpunkt — und ab Dezember 2027 zusätzlich die volle Sanktionsbewehrung.

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 Detection-Lü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.

Die Plattform leitet Meldungen simultan an das als Koordinator benannte CSIRT und an die ENISA weiter. 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. Der BMI-Referentenentwurf eines Cyberresilienz-Durchführungsgesetzes vom 12. März 2026 regelt demgegenüber die Marktüberwachung (Art. 52 CRA) und die Notifizierung. 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.

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.

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 Implementierungsrichtlinien der EU und nationale Behörden arbeiten an einer Harmonisierung, um Doppelmeldungen zu vermeiden.

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

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

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 — ohne klare Behörden-Leitlinie.

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). 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 auch in der Übergangsphase davor sollten Hersteller nicht auf eine wohlwollende Auslegung des Kenntnis-Begriffs setzen — wer ohne Detection-Prozesse arbeitet, exponiert sich gegen die Argumentation "man hätte es wissen müssen". Genau hier setzen die typischen Lücken an: Detection-Prozesse, die Exploit-Aktivitäten erst Tage später aufnehmen, weil Telemetrie und Threat-Intelligence-Feeds nicht zusammenlaufen. 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 Detection-Prozess wird einmal aufgesetzt, aber Monate später fehlt der Bezug zur aktuellen Produktlandschaft, SBOM-Daten sind veraltet, und sobald eine Schwachstelle öffentlich wird und damit eine konstruktive Kenntnis kaum noch zu bestreiten ist, läuft die 24-Stunden-Uhr bereits, während interne Abstimmung zu Klassifikation, Zuständigkeiten und Meldeinhalt erst gestartet wird.

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): täglicher 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 8. Mai 2026). Die Fristen-, Inhalts- und Definitionsangaben (Art. 13 Abs. 6 und 8, Art. 14 Abs. 1–5, Art. 15, Art. 16, Art. 64, 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). Implementierungsrichtlinien und Plattformen sind teilweise noch in Entwicklung; eine verbindliche ENISA-Leitlinie zur Auslegung des Kenntnis-Begriffs in Art. 14 CRA liegt zum Redaktionsstand nicht vor. Die Einschätzungen zur Auslegung der "Kenntnis" und zur konstruktiven Kenntnis stützen sich auf etablierte Grundsätze des EU-Produktrechts (New Legislative Framework) sowie auf produktrechtliche Sekundärliteratur und behördliche Vollzugspraxis und sind als Erwartung an die behördliche Praxis zu verstehen, nicht als verbindliche Auslegung. Eine spezifische EuGH-Leitentscheidung zum Begriff der bewusst herbeigeführten Unkenntnis im CRA- bzw. produktrechtlichen Marktüberwachungs-Kontext liegt nicht vor. 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 den BMI-Referentenentwurf eines Cyberresilienz-Durchführungsgesetzes vom 12. März 2026 verwiesen.

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. 13 (Pflichten der Hersteller, Abs. 6 Lieferanten-Meldekette, Abs. 8 Schwachstellenbehandlung), Art. 14 (Meldepflichten), 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) 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)
  • 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
  • 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)
  • BMI-Referentenentwurf eines Cyberresilienz-Durchführungsgesetzes vom 12. März 2026 (Designation des BSI als Marktüberwachungsbehörde nach Art. 52 CRA und notifizierende Behörde nach Art. 36 Abs. 1 CRA)
  • 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: 24.04.2026. Zuletzt geprüft am: 03.07.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.