Kurz zusammengefasst
Ab dem 11. September 2026 verpflichtet Artikel 14 des EU Cyber Resilience Act Hersteller von Produkten mit digitalen Elementen dazu, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach ihrer Entdeckung an ENISA und nationale Computer Security Incident Response Teams (CSIRTs) zu melden. Ein Triage-Bericht mit einem Lösungsweg folgt nach 72 Stunden; ein abschließender Bericht ist innerhalb von 14 Tagen fällig. Die Pflicht gilt für jeden Hersteller, der Software oder vernetzte Hardware in der EU vertreibt — einschließlich in den USA ansässiger Unternehmen.
Der CRA trat am 11. Dezember 2024 in Kraft. Seine vollständigen Konformitätsanforderungen — CE-Kennzeichnung, Konformitätsbewertungen, Software-Stücklisten — gelten erst ab dem 11. Dezember 2027. Die Meldefrist am 11. September 2026 ist der erste operativ bedeutsame Meilenstein, und er steht in wenigen Tagen bevor. Teams, die noch keine Schwachstellenmanagement- und Sicherheits-Audit-Workflows aufgebaut haben, die auf CRAs Fristen abgestimmt sind, sollten dies als Anstoß zur sofortigen Handlung verstehen.
Was sich am 11. September ändert
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) hat einen Rahmen von Cybersicherheitsanforderungen für jedes Produkt mit einer digitalen Komponente eingeführt, das in der EU verkauft wird. Die Verordnung ist in Wellen strukturiert: Die schwersten Pflichten — Konformitätsbewertungen, CE-Kennzeichnung, SBOM-Pflege — gelten erst ab Dezember 2027. Die erste Welle betrifft die Meldepflichten, und sie erreicht uns diesen Monat.
Artikel 14 erfasst zwei Ereigniskategorien. Erstens aktiv ausgenutzte Schwachstellen: Sicherheitslücken im Produkt eines Herstellers, die Bedrohungsakteure gerade ausnutzen — in einem beliebigen Einsatzkontext, nicht nur gegen die eigenen Kunden des Herstellers. Zweitens schwerwiegende Sicherheitsvorfälle: Ereignisse mit erheblichen Auswirkungen auf die Sicherheit eines Produkts, darunter solche, die den Datenschutz beeinträchtigen, Schadcode in eine Lieferkette einschleusen oder eine Entwicklungs- oder Produktionsumgebung kompromittieren können. In beiden Fällen ist der Auslöser der Moment, in dem der Hersteller Kenntnis erlangt — es gibt keine Schonfrist für interne Untersuchungen, bevor die 24-Stunden-Frist beginnt.
ENISA wird eine Single Reporting Platform betreiben, die jede Meldung sowohl an ENISA selbst als auch an den nationalen CSIRT in dem Mitgliedstaat weiterleitet, in dem der Hersteller ansässig ist, oder, bei Nicht-EU-Herstellern, in dem als Einzelanlaufstelle benannten Mitgliedstaat. Die Plattform ist darauf ausgelegt, maschinenlesbare Benachrichtigungen entgegenzunehmen und zu verhindern, dass Hersteller bei einem einzigen Vorfall vier separate Berichte in vier verschiedenen Portalen einreichen müssen.
Die 24-h / 72-h / 14-Tage-Meldeuhr
Der Zeitplan ist präzise. Sobald ein Hersteller von einem qualifizierenden Ereignis Kenntnis erlangt:
- 24 Stunden — Frühwarnung. Eine vorläufige Meldung an ENISA und den nationalen CSIRT. Die Verordnung verlangt in diesem Stadium keine vollständige technische Analyse, aber die Meldung muss das Ereignis, das betroffene Produkt und eine vorläufige Folgenabschätzung bestätigen. Ziel ist es, den Behörden Einblick zu gewähren, bevor die Information weitergetragen wird — nicht ein vollständiger Vorfallsbericht über Nacht.
- 72 Stunden — Triage-Bericht. Eine detailliertere Meldung, die eine Schweregradbewertung, erste ergriffene Minderungsmaßnahmen und einen Lösungsweg enthält. Ist bereits ein Patch verfügbar, sollte das vermerkt werden; andernfalls ist der Plan zur Erstellung zu beschreiben.
- 14 Tage — Abschlussbericht (Schwachstellen) / 30 Tage (Vorfälle). Eine vollständige Darstellung der Schwachstelle oder des Vorfalls, der angewandten Korrekturmaßnahmen und ihrer Wirksamkeit. Bei Vorfällen verlängert sich das Fenster auf 30 Tage ab dem Zeitpunkt der Kenntnisnahme.
Für Teams, die mit DGSVOs 72-stündiger Meldefrist bei Datenpannen vertraut sind, ist CRAs 24-stündige Erstmeldung deutlich kürzer. Für Teams, die gewohnte koordinierte Schwachstellenoffenlegungsfristen (CVD) von 90 oder mehr Tagen kennen, ist der Kontrast noch schärfer. Die praktische Konsequenz: Schwachstellenerkennung und interne Eskalation dürfen kein langsamer Prozess sein. In dem Moment, in dem das Sicherheitsteam aktive Ausnutzung bestätigt, müssen Rechts- und Compliance-Abteilung binnen Stunden einbezogen werden — nicht erst nach Tagen.
Wer muss sich anpassen — auch US-Anbieter
Die CRA-Pflichten treffen Hersteller: Unternehmen, die Produkte mit digitalen Elementen entwerfen, entwickeln oder herstellen — oder entwerfen, entwickeln oder herstellen lassen — und diese Produkte dann unter ihrem eigenen Namen oder ihrer Marke auf dem EU-Markt bereitstellen. Die Definition ist absichtlich weit gefasst. Sie umfasst handelsübliche Software, SaaS-Plattformen, mobile Anwendungen, Consumer-IoT-Geräte, industrielle Steuerungssysteme, eingebettete Firmware und Netzwerkgeräte.
Importeure und Händler tragen leichtere, aber reale Pflichten: Sie müssen die Herstellerkonformität überprüfen und in einigen Situationen als verantwortliche Stelle handeln, wenn ein Hersteller außerhalb der EU nicht identifiziert werden kann. Die Kern-Meldepflicht aus Artikel 14 liegt jedoch beim Hersteller.
Der geografische Auslöser ist der EU-Markt, nicht der Sitz in der EU. Ein in den USA ansässiger Software-Anbieter, dessen Produkt Unternehmens- oder Verbraucherkunden in Deutschland, Frankreich oder einem anderen EU-Mitgliedstaat zugänglich ist, gilt nach dem CRA als Hersteller. Dasselbe gilt für britische Unternehmen nach dem Brexit, kanadische SaaS-Anbieter und andere Nicht-EU-Einheiten. Wenn Ihr Produkt in der EU verkauft oder vertrieben wird, sind Sie im Anwendungsbereich, und Sie benötigen vor dem 11. September einen Meldeweg zu ENISAs SRP.
Überschneidungen mit DSGVO, NIS2 und DORA
Der CRA ist das vierte große EU-Digitalcompliance-Regelwerk neben DSGVO, NIS2 und DORA. Alle vier teilen genug architektonische DNA — 24-stündige Frühwarnungen, abgestufte Folgeberichte, Meldung an benannte Behörden — um Koordinationsrisiken zu schaffen, wenn sie als separate Programme behandelt werden.
Ein Ransomware-Angriff auf ein vernetztes Gerät könnte beispielsweise gleichzeitig auslösen: einen CRA-Artikel-14-Bericht an ENISA (innerhalb von 24 Stunden als schwerwiegender Vorfall); eine DSGVO-Artikel-33-Meldung an die Aufsichtsbehörde (innerhalb von 72 Stunden, wenn personenbezogene Daten betroffen sind); einen NIS2-Bericht über einen erheblichen Vorfall (innerhalb von 24 Stunden, wenn der Hersteller eine wesentliche oder wichtige Einheit ist); und für SaaS-Anbieter im Finanzsektor einen DORA-Bericht über einen schwerwiegenden Vorfall (innerhalb von 4 Stunden bei hochgradig schwerwiegenden Ereignissen). Jede Meldung geht an eine andere Behörde, folgt einer leicht unterschiedlichen Vorlage und hat unterschiedliche Folgefristen.
Das eigentliche Risiko besteht nicht darin, dass Teams vergessen zu melden; es liegt darin, vier unabhängige Silos aufzubauen und entweder ein Meldezeitfenster zu verpassen, weil das falsche Team die Benachrichtigung verantwortet, oder widersprüchliche Informationen über dasselbe Ereignis an verschiedene Behörden zu senden. Die richtige Architektur ist ein einheitlicher Incident-Triage-Workflow, der als Eingabe die bestätigte Tatsache eines Vorfalls nimmt und als Ausgabe die korrekten Meldungen an die richtigen Behörden zu den richtigen Zeitpunkten erzeugt. Dieser Workflow muss vor dem 11. September abgebildet, dokumentiert und getestet sein — denn der erste echte Vorfall ist kein guter Zeitpunkt, um festzustellen, dass der Prozess nicht funktioniert. Der Aufbau eines einheitlichen DSGVO- und Multi-Regulation-Compliance-Programms ist der Weg, den Teams, die in Europa tätig sind, üblicherweise einschlagen; der CRA fügt einer bestehenden Autobahn eine neue Spur hinzu, anstatt eine völlig neue Straße zu bauen.
Bedeutung für US- und EU-Software-Teams
Die operative Verschiebung ist real, und es lohnt sich, sie präzise zu benennen. Vor dem 11. September konnte ein Software-Anbieter mit einer aktiv ausgenutzten Schwachstelle in seinem Produkt den Offenlegungszeitraum in seinem eigenen Tempo managen: CVD-Prozesse gaben typischerweise Monate; freiwillige Offenlegung gegenüber Behörden war genau das — freiwillig. Ab dem 11. September hat der Staat einen obligatorischen ersten Anspruch auf diesen Zeitplan — 24 Stunden, jedes Mal, unabhängig davon, ob der Anbieter bereit ist, ob der Patch bereit ist oder ob der Exploit öffentlich ist.
Für Engineering-Teams bedeutet das Instrumentierung: Sie können keine aktiv ausgenutzte Schwachstelle melden, von der Sie nichts wissen. Kontinuierliches Monitoring von Threat-Intelligence-Feeds, Anbieter-Advisories und der eigenen Telemetrie auf Ausnutzungszeichen ist unter Artikel 14 keine Best Practice für reife Teams mehr, sondern eine Compliance-Voraussetzung. Dasselbe gilt für eine klare interne Definition dessen, was „Kenntnis erlangen" bedeutet — denn die Uhr beginnt zu laufen, wenn Ihre Organisation es weiß, nicht wenn der CISO das Briefing schreibt.
Für Product Manager und Gründer von EU-orientierten SaaS-Produkten bedeutet das Prozessverantwortung: Die CRA-Meldepflicht liegt beim Hersteller, nicht beim Kunden, nicht beim Cloud-Anbieter und nicht beim Sicherheitsberater. Wenn Ihr Produkt im Anwendungsbereich liegt, ist Ihre juristische Person diejenige mit der 24-Stunden-Uhr, und Sie benötigen eine namentlich genannte Person, die weiß, was zu melden ist und wo.
Die übergeordnete strategische Einschätzung lautet: Der CRA hebt die EU-Cybersicherheitsstandards auf das Niveau, das reife Unternehmenskunden in regulierten Branchen — Banking, Gesundheitswesen, kritische Infrastruktur — seit Jahren fordern. Teams, die bereits SOC-2-Typ-II-Programme oder DSGVO-konforme Incident-Response-Prozesse betreiben, werden die CRA-Mechanismen vertraut finden. Teams, die Sicherheit bisher informell gehandhabt haben, werden feststellen, dass der CRA der Katalysator ist, der informelle Praxis in dokumentierten, prüfbaren Prozess verwandelt.
Was vor dem 11. September zu tun ist
Die Checkliste ist nicht lang, aber jeder Punkt muss tatsächlich erledigt sein — nicht nur geplant.
- Anwendungsbereich bestätigen. Listen Sie jedes Produkt auf, das Ihr Unternehmen auf dem EU-Markt bereitstellt. Hat es eine digitale Komponente — Software, Firmware, Konnektivität — liegt es wahrscheinlich im Anwendungsbereich. Auch Legacy-Produkte, die bereits vor Inkrafttreten des CRA auf dem Markt waren, können erfasst sein, wenn sie Software-Updates erhalten.
- „Kenntnis erlangen" intern definieren. Legen Sie einen klaren Schwellenwert fest, ab dem Ihr Unternehmen als informiert über eine aktiv ausgenutzte Schwachstelle gilt. Dieser Wert bestimmt, wann die 24-Stunden-Frist beginnt. Mehrdeutigkeit hier schafft Compliance-Risiko.
- Kontinuierliches Monitoring aufbauen. Sie können nichts melden, was Sie nicht erkennen. Etablieren oder beauftragen Sie Threat-Intelligence- und Telemetrie-Monitoring auf Anzeichen aktiver Ausnutzung in Ihrem gesamten Produktportfolio.
- Einen Melde-Verantwortlichen benennen. Legen Sie die Person (und eine Vertretung) fest, die CRA-Berichte einreicht. Diese Person sollte die Befugnis haben, Behörden zu benachrichtigen, ohne eine lange interne Genehmigungskette, die das 24-Stunden-Fenster auffressen würde.
- Bei ENISAs SRP registrieren. Die Single Reporting Platform startet am 11. September 2026. Registrieren Sie sich vorab, falls ENISA frühen Zugang ermöglicht; prüfen Sie mindestens, dass Ihre Zugangsdaten vor dem Stichtag bereitstehen.
- Berichtsvorlagen erstellen. Artikel 14s dreistufige Berichtsstruktur ist vorhersehbar. Bereiten Sie Vorlagen für die 24-Stunden-Frühwarnung, den 72-Stunden-Triage-Bericht und den 14-Tage-Abschlussbericht jetzt vor, damit Ihr Team unter Zeitdruck Fakten einträgt, anstatt das Format zu schreiben.
- Regime-Überschneidungen kartieren. Wenn Sie auch NIS2-, DORA- oder DSGVO-Pflichten haben, stellen Sie sicher, dass ein CRA-auslösender Vorfall korrekt in alle anwendbaren Melde-Workflows einfließt.
Häufig gestellte Fragen
Was verlangt der CRA ab dem 11. September 2026?
Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls eine Frühwarnung an ENISA und ihren nationalen CSIRT übermitteln. Ein Triage-Bericht mit einem Lösungsweg folgt innerhalb von 72 Stunden, und ein Abschlussbericht ist innerhalb von 14 Tagen nach Verfügbarkeit eines Patches fällig (30 Tage bei Vorfällen).
Für wen gilt die CRA-Meldepflicht?
Für alle Hersteller, die Produkte mit digitalen Elementen auf dem EU-Markt bereitstellen — darunter Software, SaaS, mobile Apps, IoT-Geräte und eingebettete Systeme. Importeure und Händler haben leichtere Pflichten. Entscheidend: Die Regel gilt auf Basis des Verkaufsorts, nicht des Unternehmenssitzes — US-amerikanische, britische und andere Nicht-EU-Unternehmen, die Software oder Geräte nach Europa liefern, sind vollständig erfasst.
Was gilt als aktiv ausgenutzte Schwachstelle im Sinne des CRA?
Ein Sicherheitsfehler im Produkt eines Herstellers, den Bedrohungsakteure aktiv ausnutzen — in einer beliebigen Einsatzumgebung, nicht nur gegen die eigenen Kunden des Herstellers. Die Verordnung erfasst auch schwerwiegende Sicherheitsvorfälle, darunter Ereignisse, die den Datenschutz beeinträchtigen, Schadcode in eine Lieferkette einschleusen oder Entwicklungs- oder Produktionsumgebungen kompromittieren können.
Wie verhält sich die CRA-Meldepflicht zu DSGVO, NIS2 und DORA?
Alle vier Regelwerke teilen eine 24-stündige Frühwarnstruktur, richten sich aber an unterschiedliche Behörden und haben unterschiedliche Folgefristen. Ein einzelner Vorfall kann gleichzeitig Pflichten unter mehreren Regelwerken auslösen. Bauen Sie einen einheitlichen Incident-Triage-Workflow auf, der festlegt, welche Regelwerke anwendbar sind, und den richtigen Bericht an jeden Regulierer zum richtigen Zeitpunkt erzeugt — anstatt separate Compliance-Prozesse für jedes Regelwerk zu betreiben.
Was sollten Software-Teams vor dem 11. September 2026 tun?
Den Anwendungsbereich bestätigen; intern festlegen, wann die 24-Stunden-Frist beginnt; kontinuierliches Schwachstellen-Monitoring aufbauen oder beauftragen; einen namentlich genannten Melde-Verantwortlichen mit direkter Befugnis zur Einreichung benennen; bei ENISAs Single Reporting Platform registrieren; 24-Stunden-, 72-Stunden- und 14-Tage-Berichtsvorlagen erstellen; und überlappende Pflichten aus DSGVO, NIS2 und DORA kartieren, um fehlende oder widersprüchliche Meldungen zu vermeiden.
Quellen
Europäische Kommission — CRA-Meldepflichten (primäre Regulierungsquelle)
DLA Piper — Die 24-Stunden-Regel des CRA: Vorbereitung auf die Meldepflichten ab September 2026 (August 2026)
Crowell & Moring — EU CRA: Meldezeitfenster 11. September 2026