Cyber Resilience Act Meldepflicht 2026

Cyber Resilience Act ab 11. September 2026: Die neue 24-Stunden-Frist für Hersteller

von Dr. Joachim Schmitz

Viele Unternehmen verbinden den Cyber Resilience Act bislang vor allem mit dem 11. Dezember 2027. An diesem Tag werden die meisten neuen europäischen Cybersicherheitsanforderungen vollständig anwendbar.

Für Hersteller von Hardware und Software beginnt ein besonders wichtiger Teil der Verordnung jedoch bereits deutlich früher:

Ab dem 11. September 2026 gelten die Meldepflichten aus Artikel 14 des Cyber Resilience Act.

Hersteller müssen dann aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, wenn diese ihre Produkte mit digitalen Elementen betreffen. Die erste Warnung muss grundsätzlich innerhalb von 24 Stunden nach Kenntniserlangung erfolgen. Für die anschließende 72-Stunden-Meldung bleibt ebenfalls nur wenig Zeit.

Ein Cyberangriff ist damit nicht mehr ausschließlich eine Aufgabe für die IT-Abteilung. Ein Vorfall kann binnen weniger Stunden rechtliche, operative und wirtschaftliche Konsequenzen auslösen. Wie schnell daraus eine existenzbedrohende Situation entstehen kann, zeigt auch unser Ratgeber zum Thema Ransomware im Unternehmen.

Das Wichtigste zur CRA-Meldepflicht in Kürze

Meldestufe	Frist	Wesentlicher Inhalt
Frühwarnung	spätestens 24 Stunden	Erste Angaben zum Produkt und zum Ereignis
72-Stunden-Meldung	spätestens 72 Stunden	Allgemeine Informationen, erste Bewertung und bereits ergriffene Maßnahmen
Abschlussbericht bei Schwachstellen	spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme	Detaillierte Beschreibung, Auswirkungen und Sicherheitsupdate
Abschlussbericht bei Vorfällen	innerhalb eines Monats nach der 72-Stunden-Meldung	Ursache, Auswirkungen sowie umgesetzte und geplante Gegenmaßnahmen

Die 72-Stunden-Meldung ist nicht mit dem späteren Abschlussbericht gleichzusetzen. Unternehmen müssen innerhalb von drei Tagen noch keine vollständige forensische Untersuchung abgeschlossen haben. Sie müssen aber den vorhandenen Kenntnisstand strukturiert, nachvollziehbar und fristgerecht melden.

Cyber Resilience Act Meldepflicht 2026 – Was gilt ab dem 11. September 2026?

Ab diesem Stichtag müssen Hersteller insbesondere zwei Arten von Ereignissen melden:

1. aktiv ausgenutzte Schwachstellen in Produkten mit digitalen Elementen
2. schwerwiegende Vorfälle, die Auswirkungen auf die Sicherheit solcher Produkte haben

Die Meldungen werden über die von der Europäischen Agentur für Cybersicherheit ENISA eingerichtete CRA Single Reporting Platform übermittelt.

Die Plattform soll die Mehrfachmeldung an verschiedene nationale Stellen vermeiden. Der Hersteller reicht seine Meldung grundsätzlich einmal ein. Sie wird anschließend an das zuständige, als Koordinator benannte Computer Security Incident Response Team – kurz CSIRT – sowie grundsätzlich an ENISA weitergeleitet.

Wichtig ist die zeitliche Abgrenzung:

Am 11. September 2026 tritt nicht der gesamte Cyber Resilience Act vollständig in Anwendung. Zunächst beginnen insbesondere die Meldepflichten. Die meisten übrigen Herstellerpflichten werden erst ab dem 11. Dezember 2027 anwendbar.

Unternehmen dürfen daraus jedoch nicht schließen, dass sie bis Ende 2027 abwarten können. Ein funktionierendes Meldesystem muss bereits im September 2026 vorhanden sein.

Welche Unternehmen sind vom Cyber Resilience Act betroffen?

Betroffen sind vor allem Unternehmen, die Produkte mit digitalen Elementen unter ihrem eigenen Namen oder ihrer eigenen Marke auf dem europäischen Markt bereitstellen.

Der Begriff des Produkts mit digitalen Elementen umfasst grundsätzlich Hardware und Software, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Verbindung zu einem Gerät oder Netzwerk einschließt.

Dazu können beispielsweise gehören:

• vernetzte Maschinen und Industrieanlagen
• Apps und installierbare Software
• Betriebssysteme
• Router, Firewalls und Netzwerktechnik
• Smart-Home-Produkte
• IoT-Geräte und Sensoren
• Überwachungs- und Zutrittssysteme
• intelligente Haushaltsgeräte
• Firmware und separat vertriebene Softwarekomponenten
• Steuerungs- und Automatisierungssysteme
• Sicherheitssoftware
• cloudgestützte Produkte mit notwendigen Serverfunktionen

Hersteller ist nicht nur, wer ein Produkt vollständig selbst entwickelt oder in der eigenen Fabrik produziert. Hersteller kann auch sein, wer ein Produkt entwickeln oder herstellen lässt und es anschließend unter dem eigenen Namen oder Warenzeichen vermarktet.

Achtung bei White-Label- und Private-Label-Produkten

Ein Unternehmen kann rechtlich als Hersteller gelten, obwohl Entwicklung und Produktion vollständig ausgelagert wurden.

Das betrifft insbesondere Unternehmen, die:

• importierte Produkte mit ihrem eigenen Logo versehen,
• Software unter einer eigenen Marke vertreiben,
• Produkte von Auftragsentwicklern herstellen lassen,
• fremde Hardware als Teil eines eigenen Systems anbieten oder
• bestehende Produkte wesentlich verändern und erneut vermarkten.

Wer beispielsweise ein vernetztes Gerät aus einem Drittstaat importiert und unter der eigenen Marke vertreibt, darf sich nicht darauf verlassen, dass ausschließlich der ursprüngliche Produzent für die CRA-Meldung verantwortlich ist.

Die rechtliche Rolle muss für jedes Produkt und jede Vertriebskonstellation einzeln geprüft werden.

Sind auch SaaS-Anbieter betroffen?

Ein reiner Onlinedienst fällt nicht automatisch allein deshalb unter den Cyber Resilience Act, weil er digital angeboten wird.

Anders kann es aussehen, wenn eine Cloud- oder Serverfunktion zwingender Bestandteil eines erfassten Produkts ist. Der CRA bezeichnet solche Funktionen als Remote Data Processing Solutions.

Entscheidend ist insbesondere, ob das Produkt ohne die entfernte Datenverarbeitung eine seiner vorgesehenen Funktionen nicht erfüllen könnte.

SaaS-Anbieter, Plattformbetreiber und Hersteller cloudgestützter Produkte sollten deshalb unter anderem folgende Fragen prüfen:

• Wird eine Softwarekomponente auf dem Gerät des Nutzers ausgeführt?
• Gibt es eine App, Firmware oder lokal installierte Anwendung?
• Ist die Cloudfunktion für eine Produktfunktion technisch notwendig?
• Wer entwickelt und betreibt die entfernte Datenverarbeitung?
• Wird das Gesamtprodukt unter dem eigenen Namen oder der eigenen Marke angeboten?
• Besteht zwischen der lokalen und der entfernten Komponente eine funktionale Einheit?

Eine pauschale Aussage, dass SaaS immer ausgeschlossen oder immer erfasst sei, wäre daher falsch. Erforderlich ist eine produktbezogene Prüfung.

Was ist eine aktiv ausgenutzte Schwachstelle?

Nicht jede entdeckte Sicherheitslücke muss nach den besonderen CRA-Regeln innerhalb von 24 Stunden gemeldet werden.

Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn zuverlässige Hinweise darauf bestehen, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des betroffenen Systeminhabers tatsächlich ausgenutzt hat.

Eine bloße theoretische Ausnutzbarkeit reicht grundsätzlich nicht aus.

Auch folgende Umstände begründen für sich allein noch nicht zwingend eine CRA-Meldepflicht wegen aktiver Ausnutzung:

• die Vergabe einer CVE-Nummer,
• eine hohe CVSS-Bewertung,
• eine Sicherheitslücke im Quellcode,
• das Ergebnis eines Penetrationstests,
• eine veröffentlichte technische Angriffsmethode oder
• die bloße Existenz eines Proof of Concept.

Der Hersteller muss jedoch unverzüglich prüfen, ob belastbare Hinweise auf eine tatsächliche Ausnutzung vorliegen.

Solche Hinweise können beispielsweise sein:

• bestätigte Angriffe auf Kundensysteme,
• technische Indicators of Compromise,
• Erkenntnisse aus Telemetrie- oder Protokolldaten,
• glaubwürdige Meldungen von Kunden,
• Hinweise von Sicherheitsforschern,
• Warnungen von Behörden,
• Erkenntnisse eines Incident-Response-Dienstleisters oder
• bestätigte Angriffe auf bestimmte Produktversionen.

Unternehmen benötigen daher nicht nur ein technisches Schwachstellenmanagement, sondern auch einen verbindlichen Prozess zur Bewertung eingehender Hinweise.

Wann gilt ein Sicherheitsvorfall als schwerwiegend?

Ein gewöhnlicher IT-Ausfall im Unternehmen ist nicht automatisch ein schwerwiegender CRA-Vorfall.

Die Meldepflicht betrifft Vorfälle, die schwerwiegende Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen haben.

Ein Vorfall kann insbesondere schwerwiegend sein, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann,

• die Verfügbarkeit,
• die Authentizität,
• die Integrität oder
• die Vertraulichkeit

wichtiger Daten oder Funktionen zu schützen.

Erfasst werden können außerdem Vorfälle, die zur Einschleusung oder Ausführung von Schadcode im Produkt oder in den Systemen seiner Nutzer geführt haben oder führen können.

Beispiele für mögliche meldepflichtige Vorfälle

Abhängig vom konkreten Sachverhalt können dazu gehören:

• eine kompromittierte Update-Infrastruktur,
• manipulierte Software- oder Firmwareupdates,
• gestohlene Entwickler- oder Signaturzertifikate,
• Schadcode in einer ausgelieferten Softwareversion,
• die unbefugte Übernahme vernetzter Geräte,
• die Manipulation sicherheitsrelevanter Firmware,
• ein Angriff auf eine notwendige Cloudfunktion,
• eine kompromittierte Software-Lieferkette,
• ein unbefugter Zugriff auf zentrale Produktfunktionen oder
• die Einführung von Schadcode in Systeme der Produktnutzer.

Ein Ransomwareangriff auf die interne Buchhaltung des Herstellers ist dagegen nicht allein deshalb ein CRA-Meldefall. Er kann jedoch andere gesetzliche, datenschutzrechtliche, vertragliche oder versicherungsrechtliche Meldepflichten auslösen.

Die Meldefristen des Cyber Resilience Act

Die Fristen beginnen grundsätzlich mit der Kenntniserlangung des Herstellers.

Frühwarnung innerhalb von 24 Stunden

Die Frühwarnung dient einer schnellen ersten Einordnung. Sie soll noch keine abschließende Ursachenanalyse enthalten.

Zu den wichtigen Angaben können gehören:

• Name des meldenden Herstellers,
• betroffenes Produkt,
• Art der Meldung,
• Zeitpunkt der Kenntniserlangung,
• erste Beschreibung des Ereignisses,
• betroffene Produktversionen,
• betroffene Mitgliedstaaten, soweit bereits bekannt,
• mögliche böswillige oder rechtswidrige Hintergründe sowie
• Ansprechpartner für Rückfragen.

72-Stunden-Meldung

Spätestens innerhalb von 72 Stunden muss eine weitergehende Meldung übermittelt werden.

Sie soll insbesondere enthalten:

• allgemeine Informationen über die Schwachstelle oder den Vorfall,
• eine erste Bewertung,
• bekannte Auswirkungen,
• bereits ergriffene Korrekturmaßnahmen,
• mögliche Minderungsmaßnahmen,
• Schutzmaßnahmen für Nutzer sowie
• eine Einschätzung zur Sensibilität der übermittelten Informationen.

Die 72-Stunden-Meldung darf später ergänzt oder aktualisiert werden. Sie darf aber nicht deshalb unterbleiben, weil zu diesem Zeitpunkt noch nicht alle technischen Ursachen feststehen.

Abschlussbericht

Der Abschlussbericht folgt später.

Bei einer aktiv ausgenutzten Schwachstelle muss er grundsätzlich spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme eingereicht werden.

Bei einem schwerwiegenden Vorfall gilt grundsätzlich eine Frist von einem Monat nach der 72-Stunden-Meldung.

Der Abschlussbericht enthält unter anderem:

• eine ausführliche Beschreibung des Ereignisses,
• den Schweregrad,
• die tatsächlichen oder möglichen Auswirkungen,
• die wahrscheinliche Ursache,
• Informationen über den Angriffsweg, soweit bekannt,
• umgesetzte Gegenmaßnahmen sowie
• Angaben zu Sicherheitsupdates oder anderen Korrekturen.

Die Frist läuft auch am Wochenende

Die Verordnung spricht von Stunden und nicht von Arbeitstagen oder Werktagen.

Wird ein Unternehmen an einem Freitag um 17 Uhr auf einen meldepflichtigen Sachverhalt aufmerksam, darf die Bearbeitung nicht automatisch bis Montagmorgen liegen bleiben.

Die 24-Stunden-Frist endet in diesem Beispiel grundsätzlich am Samstag um 17 Uhr.

Unternehmen benötigen daher einen Prozess, der auch funktioniert:

• außerhalb gewöhnlicher Geschäftszeiten,
• an Wochenenden,
• an Feiertagen,
• während Urlaubszeiten,
• bei Krankheit wichtiger Mitarbeiter und
• bei gleichzeitigem Ausfall der eigenen IT-Infrastruktur.

Ein Prozess, der ausschließlich auf einer einzelnen Person oder einem unüberwachten E-Mail-Postfach beruht, ist für diese Fristen ungeeignet.

Der kritische Zeitpunkt: Wann beginnt die Uhr?

Zu den größten Risiken gehört eine unklare Definition der Kenntniserlangung.

Sicherheitsmeldungen können an sehr unterschiedlichen Stellen eingehen:

• beim Kundenservice,
• beim Produktsupport,
• im Entwicklerteam,
• beim Datenschutzbeauftragten,
• beim externen IT-Dienstleister,
• in einem GitHub-Repository,
• über ein Bug-Bounty-Programm,
• beim Händler oder Vertriebspartner,
• bei einem Geschäftsführer,
• bei der Cyberversicherung oder
• über einen Sicherheitsforscher.

Wird eine glaubwürdige Meldung am Freitag an den Produktsupport geschickt, darf sie nicht bis Montag unbearbeitet bleiben, nur weil die Compliance-Abteilung noch nichts davon weiß.

Das Unternehmen sollte deshalb schriftlich festlegen:

1. Welche Eingangskanäle werden dauerhaft überwacht?
2. Wer nimmt Sicherheitsmeldungen zentral entgegen?
3. Wer dokumentiert den Zeitpunkt des Eingangs?
4. Wer bewertet die Glaubwürdigkeit der Meldung?
5. Wer prüft die CRA-Relevanz?
6. Wer entscheidet über die Meldung?
7. Wer darf die Meldung technisch absenden?
8. Wer übernimmt die Vertretung?

Unklare Zuständigkeiten sind nicht nur ein organisatorisches Problem. Sie können dazu führen, dass die Geschäftsführung gesetzliche Fristen versäumt und sich mit zusätzlichen Haftungsfragen auseinandersetzen muss. Einen Überblick über typische persönliche Risiken finden Geschäftsführer in unserem Beitrag zur Geschäftsführerhaftung.

Gelten die Meldepflichten auch für ältere Produkte?

Die CRA-Meldepflichten beschränken sich nicht ausschließlich auf Produkte, die erst nach dem 11. September 2026 oder nach dem 11. Dezember 2027 neu auf den Markt kommen.

Sie können auch Produkte betreffen, die bereits zuvor auf dem europäischen Markt bereitgestellt wurden.

Unternehmen müssen deshalb auch ältere Produktgenerationen in ihr Meldesystem einbeziehen. Dazu können gehören:

• frühere Softwareversionen,
• ältere Firmwarestände,
• bereits ausgelieferte Maschinensteuerungen,
• eingestellte Apps,
• nicht mehr beworbene Modellreihen,
• Produkte aus übernommenen Unternehmen,
• ältere White-Label-Produkte sowie
• Produkte, deren ursprüngliches Entwicklungsteam nicht mehr vorhanden ist.

Gerade bei Altprodukten fehlen häufig:

• vollständige technische Dokumentationen,
• aktuelle Komponentenlisten,
• erreichbare Entwickler,
• gepflegte Kundenkontakte,
• reproduzierbare Entwicklungsumgebungen oder
• eindeutige Verantwortlichkeiten.

Eine wichtige zeitliche Einschränkung ist zu beachten: Die Meldepflicht soll grundsätzlich nicht rückwirkend für aktive Ausnutzungen gelten, von denen der Hersteller bereits vor Beginn der CRA-Meldepflicht am 11. September 2026 Kenntnis hatte. Erlangt er dagegen erst nach diesem Stichtag Kenntnis, kann auch ein älteres Produkt betroffen sein.

Betroffene Nutzer müssen informiert werden

Die Meldung an ENISA und das zuständige CSIRT ist nicht die einzige Aufgabe.

Hersteller müssen grundsätzlich auch betroffene Nutzer und, soweit erforderlich, weitere Nutzer des Produkts über die Schwachstelle oder den schwerwiegenden Vorfall informieren.

Dabei können unter anderem mitzuteilen sein:

• welche Produkte und Versionen betroffen sind,
• welche Gefahr besteht,
• welche Schutzmaßnahmen Nutzer ergreifen sollten,
• ob ein Update verfügbar ist,
• ob bestimmte Funktionen vorübergehend deaktiviert werden sollten und
• an wen sich Nutzer bei Fragen wenden können.

Dafür benötigt das Unternehmen geeignete Kommunikationswege:

• Sicherheitswarnungen auf der Produktseite,
• Kunden-E-Mail-Verteiler,
• In-App-Meldungen,
• Update- und Patchinformationen,
• Händler- und Vertriebspartnerkommunikation,
• Security Advisories,
• Supportleitfäden und
• vorbereitete Antworten für Vertrieb und Kundenservice.

Die Kommunikation darf nicht so detailliert sein, dass sie weitere Angriffe erleichtert. Gleichzeitig darf sie notwendige Schutzinformationen nicht verschweigen.

Produktsecurity, Rechtsabteilung und Kommunikation müssen deshalb eng zusammenarbeiten. Langwierige Freigabeschleifen dürfen jedoch die gesetzlichen Meldefristen nicht blockieren.

Meldung über die CRA Single Reporting Platform

Die Meldungen sollen über die zentrale CRA Single Reporting Platform eingereicht werden.

Das zuständige CSIRT richtet sich grundsätzlich nach dem Hauptsitz des Herstellers. Bei Herstellern ohne Niederlassung in der Europäischen Union können unter anderem der Sitz eines Bevollmächtigten, eines Importeurs oder weitere gesetzliche Kriterien maßgeblich sein.

ENISA hat angekündigt, dass die Plattform spätestens zum 11. September 2026 betriebsbereit sein soll.

Vertreter von Herstellern benötigen für den Zugang ein EU-Login-Konto. Dieses Konto kann bereits vor dem Stichtag vorbereitet werden. Die konkrete Plattformadresse und weitere technische Hinweise werden von ENISA veröffentlicht.

Unternehmen sollten nicht erst bei einem tatsächlichen Angriff feststellen, dass:

• kein EU-Login vorhanden ist,
• die zuständige Person keine Zugriffsrechte besitzt,
• die Vertretung nicht eingerichtet wurde,
• Produktinformationen fehlen oder
• die internen Freigaberegeln eine rechtzeitige Meldung verhindern.

Welche Abteilungen müssen eingebunden werden?

Ein CRA-Meldefall lässt sich nur selten durch eine einzelne Abteilung bearbeiten.

Typischerweise müssen zusammenarbeiten:

Funktion	Hauptaufgabe
Geschäftsführung	Verantwortlichkeiten, Ressourcen und Eskalationsbefugnisse festlegen
Product Security	Technische Bewertung und Koordination der Sicherheitsanalyse
IT-Sicherheit	Protokolle sichern, Angriffsspuren untersuchen und Systeme schützen
Produktentwicklung	Betroffene Versionen und mögliche Korrekturen bestimmen
Recht und Compliance	CRA-Anwendungsbereich und weitere Meldepflichten prüfen
Datenschutz	Mögliche Verletzungen personenbezogener Daten bewerten
Kommunikation	Nutzerinformationen und öffentliche Aussagen vorbereiten
Vertrieb und Support	Betroffene Kunden identifizieren und Rückmeldungen bündeln
Cyberversicherung	Versicherungsvertragliche Pflichten parallel bearbeiten
Externe Forensik	Untersuchung und Beweissicherung unterstützen

Die Geschäftsführung muss nicht jede technische Einzelentscheidung selbst treffen. Sie muss jedoch dafür sorgen, dass ein belastbarer Prozess vorhanden ist.

Das gilt besonders in Unternehmen, die sich bereits in einer Unternehmenskrise befinden. Dort sind Schlüsselpersonen häufig überlastet, Budgets gekürzt und Dokumentationen unvollständig. Genau dann steigt das Risiko, dass gesetzliche Fristen versäumt werden.

Der 24-/72-Stunden-Notfallplan für Hersteller

Phase 1: Stunde 0 bis 2 – Eingang sichern

Unmittelbar nach Eingang einer Sicherheitsmeldung sollte das Unternehmen:

• Datum und Uhrzeit dokumentieren,
• die Originalmeldung unverändert sichern,
• Protokolle und Beweismittel schützen,
• das betroffene Produkt identifizieren,
• die Produktversion feststellen,
• den Incident Lead informieren und
• unkontrollierte Löschungen oder Veränderungen verhindern.

Der Zeitpunkt der Kenntniserlangung sollte nachvollziehbar dokumentiert werden. Er darf nicht nachträglich künstlich verschoben werden.

Phase 2: Stunde 2 bis 6 – CRA-Relevanz prüfen

Anschließend muss geklärt werden:

• Handelt es sich um ein Produkt mit digitalen Elementen?
• Ist das eigene Unternehmen rechtlich der Hersteller?
• Ist eine eigene oder eine fremde Komponente betroffen?
• Gibt es zuverlässige Hinweise auf aktive Ausnutzung?
• Hat der Vorfall schwerwiegende Auswirkungen auf die Produktsicherheit?
• Welche Produktversionen sind betroffen?
• Welche Nutzer und Mitgliedstaaten könnten betroffen sein?
• Bestehen parallele Meldepflichten?

Noch offene Fragen werden ausdrücklich als offen dokumentiert.

Eine unvollständige Sachlage ist kein Grund, die gesamte Prüfung bis zum Abschluss einer forensischen Analyse aufzuschieben.

Phase 3: Stunde 6 bis 12 – Krisenteam aktivieren

Spätestens jetzt sollten einbezogen werden:

• Geschäftsführung,
• Product Security,
• IT-Sicherheit,
• Produktentwicklung,
• Rechtsabteilung oder externer Rechtsberater,
• Datenschutz,
• Kundenkommunikation,
• Vertrieb und Support,
• Cyberversicherung sowie
• gegebenenfalls externe Forensiker.

Eine Person muss die Gesamtkoordination übernehmen.

Abstimmungen mit Rechtsberatern oder Versicherern sind wichtig. Sie dürfen jedoch nicht dazu führen, dass die gesetzliche CRA-Meldung verspätet eingereicht wird.

Phase 4: Stunde 12 bis 20 – Frühwarnung vorbereiten

Die Frühwarnung sollte mindestens intern beantworten:

• Wer meldet?
• Welches Produkt ist betroffen?
• Welche Versionen könnten betroffen sein?
• Handelt es sich um eine Schwachstelle oder einen Vorfall?
• Wann wurde der Sachverhalt bekannt?
• Gibt es Hinweise auf aktive Ausnutzung?
• Welche Mitgliedstaaten könnten betroffen sein?
• Wird ein böswilliger oder rechtswidriger Hintergrund vermutet?
• Welche Informationen sind besonders sensibel?

Die Frühwarnung ist keine abschließende technische Dokumentation. Sie soll den Behörden ermöglichen, das Ereignis frühzeitig einzuordnen.

Phase 5: Spätestens nach 24 Stunden – Frühwarnung absenden

Die Meldung sollte durch eine vorher bestimmte und technisch autorisierte Person eingereicht werden.

Anschließend sollten gesichert werden:

• Eingangsbestätigung,
• Meldungsnummer,
• abgesendete Inhalte,
• Zeitpunkt der Übermittlung,
• beteiligte Personen,
• Entscheidungsgrundlagen sowie
• noch offene Informationen.

Phase 6: Stunde 24 bis 72 – Hauptmeldung erstellen

Bis zum Ablauf der 72-Stunden-Frist muss das Unternehmen insbesondere untersuchen:

• Art und Umfang des Ereignisses,
• betroffene Produktvarianten,
• bekannte Angriffsmethoden,
• mögliche Auswirkungen,
• bereits umgesetzte Maßnahmen,
• verfügbare Workarounds,
• Schutzmaßnahmen für Nutzer,
• Sensibilität der Informationen sowie
• mögliche parallele gesetzliche Meldungen.

Die 72-Stunden-Meldung muss nicht jede Ursache abschließend erklären. Sie muss aber den aktuellen Kenntnisstand wahrheitsgemäß und nachvollziehbar wiedergeben.

Phase 7: Nach 72 Stunden – Korrektur, Nutzerinformation und Abschlussbericht

Nach der 72-Stunden-Meldung folgen insbesondere:

• Entwicklung und Prüfung von Patches,
• Veröffentlichung von Sicherheitsupdates,
• Information betroffener Nutzer,
• Zwischenberichte auf Anforderung,
• Ursachenanalyse,
• Dokumentation der Gegenmaßnahmen,
• Abschlussbericht,
• Auswertung des Vorfalls sowie
• Anpassung der Entwicklungs- und Sicherheitsprozesse.

Was Unternehmen bis zum 11. September 2026 vorbereiten sollten

1. Vollständiges Produktregister erstellen

Das Register sollte mindestens enthalten:

• Produktname,
• Modell oder Version,
• verantwortliche Gesellschaft,
• rechtliche Herstellerrolle,
• verwendete Drittkomponenten,
• Vertriebsländer,
• Supportzeitraum,
• technische Ansprechpartner,
• externe Entwicklungspartner und
• Kommunikationswege zu den Nutzern.

2. Altprodukte erfassen

Produkte dürfen nicht allein deshalb aus dem Register entfernt werden, weil sie nicht mehr aktiv beworben oder entwickelt werden.

3. Zentrale Meldestelle einrichten

Geeignet ist beispielsweise eine dauerhaft überwachte Adresse für Sicherheitsmeldungen mit automatischer Eskalation.

Die Adresse sollte nicht nur eingerichtet, sondern auch auf Produktseiten, in Dokumentationen und gegenüber Sicherheitsforschern bekannt gemacht werden.

4. Kenntniserlangung definieren

Das Unternehmen benötigt eine klare Arbeitsanweisung, wann und durch wen der Beginn der Meldefrist dokumentiert wird.

5. Entscheidungsmatrix entwickeln

Die Matrix sollte mindestens unterscheiden zwischen:

• gewöhnlicher Schwachstelle,
• aktiv ausgenutzter Schwachstelle,
• gewöhnlichem internen IT-Vorfall,
• schwerwiegendem Produktsicherheitsvorfall,
• möglicher Datenschutzverletzung,
• möglichem NIS2-Vorfall und
• rein vertraglichem Kundenproblem.

6. Meldevorlagen vorbereiten

Sinnvoll sind Vorlagen für:

• 24-Stunden-Frühwarnung,
• 72-Stunden-Meldung,
• Abschlussbericht,
• Nutzerwarnung,
• Geschäftsführungsinformation,
• Händlerinformation und
• Meldung an die Cyberversicherung.

7. Vertretung einrichten

Mindestens zwei Personen sollten organisatorisch und technisch in der Lage sein, eine Meldung einzureichen.

8. Wochenend- und Krankheitsvertretung regeln

Eine einzelne zuständige Person ohne Vertretung ist ein erhebliches Organisationsrisiko.

9. Lieferantenverträge prüfen

Verträge mit Entwicklern, Cloudanbietern, Komponentenherstellern und IT-Dienstleistern sollten eindeutige Informations- und Mitwirkungspflichten enthalten.

Ein Hersteller kann seine eigene 24-Stunden-Frist nicht einhalten, wenn ein Zulieferer sicherheitsrelevante Informationen erst nach mehreren Tagen weitergibt.

10. Krisenübung durchführen

Ein realistischer Testfall sollte beispielsweise an einem Freitagnachmittag beginnen.

Dabei lässt sich prüfen:

• Wer nimmt die Meldung entgegen?
• Wer ist erreichbar?
• Wer entscheidet?
• Sind Produktdaten vorhanden?
• Funktionieren Vertretungen?
• Kann die Meldung technisch übermittelt werden?
• Wie schnell kann eine Nutzerinformation vorbereitet werden?

Warum der Cyber Resilience Act zum wirtschaftlichen Krisenrisiko werden kann

Ein schwerwiegender Produktsicherheitsvorfall kann weit über die IT-Abteilung hinausreichen.

Mögliche wirtschaftliche Folgen sind:

• kurzfristige Forensik- und Entwicklungskosten,
• Rückruf- oder Austauschmaßnahmen,
• hohe zusätzliche Supportkosten,
• Produktions- oder Lieferunterbrechungen,
• Ansprüche wichtiger Kunden,
• Vertragskündigungen,
• Auseinandersetzungen mit der Cyberversicherung,
• Reputationsschäden,
• Liquiditätsengpässe und
• Finanzierungsprobleme.

Besonders kritisch wird es, wenn gleichzeitig Umsätze ausfallen, Kunden Zahlungen zurückhalten und zusätzliche externe Spezialisten beauftragt werden müssen.

Aus einem Sicherheitsvorfall kann dann eine Liquiditätskrise entstehen. Unternehmen sollten in dieser Situation frühzeitig prüfen, ob eine strukturierte Unternehmenssanierung erforderlich wird.

Gefahr für die Zahlungsfähigkeit

Ein Cybervorfall kann die Zahlungsfähigkeit innerhalb kurzer Zeit belasten, beispielsweise wenn:

• die Produktion stillsteht,
• Rechnungen nicht erstellt werden können,
• Kundenzahlungen ausbleiben,
• Ersatzsysteme finanziert werden müssen,
• Vertragsstrafen drohen,
• Kreditversicherer Deckungen reduzieren oder
• die Cyberversicherung ihre Leistung zunächst prüft.

Geschäftsführer sollten dann nicht ausschließlich auf die technische Wiederherstellung warten. Sie benötigen parallel eine belastbare Liquiditätsplanung.

Zeigen sich bereits Rücklastschriften, dauerhaft unbezahlte Verbindlichkeiten oder Probleme bei Löhnen, Steuern und Sozialversicherungsbeiträgen, muss zusätzlich geprüft werden, ob die GmbH zahlungsunfähig werden könnte.

Cybervorfall und Insolvenzantragspflicht

Ein Sicherheitsvorfall hebt die gesetzlichen Pflichten der Geschäftsführung nicht auf.

Auch während eines Cyberangriffs müssen Geschäftsführer die wirtschaftliche Lage überwachen. Sie sollten insbesondere prüfen:

• aktueller Bankbestand,
• fällige Verbindlichkeiten,
• realistische Zahlungseingänge,
• Löhne und Sozialversicherungsbeiträge,
• Steuerzahlungen,
• Kosten der Wiederherstellung,
• erwartete Versicherungsleistungen sowie
• mögliche Kunden- und Lieferantenausfälle.

Ist unklar, ob Zahlungsunfähigkeit oder Überschuldung vorliegt, darf die Prüfung nicht allein wegen des IT-Ausfalls aufgeschoben werden. Welche gesetzlichen Zeitfenster und Risiken dann relevant werden, erläutert unser Ratgeber Insolvenz – wann muss ein Geschäftsführer handeln?.

Häufige Fragen zur CRA-Meldepflicht

Gilt der gesamte Cyber Resilience Act ab dem 11. September 2026?

Nein. Ab diesem Datum gelten insbesondere die Meldepflichten. Die meisten übrigen Vorschriften werden ab dem 11. Dezember 2027 anwendbar.

Muss jede Sicherheitslücke innerhalb von 24 Stunden gemeldet werden?

Nein. Bei Schwachstellen betrifft die besondere Meldepflicht insbesondere aktiv ausgenutzte Schwachstellen. Dafür müssen zuverlässige Hinweise auf eine tatsächliche unbefugte Ausnutzung vorliegen.

Muss nach 72 Stunden bereits die vollständige Ursachenanalyse vorliegen?

Nein. Die 72-Stunden-Meldung enthält allgemeine Informationen, eine erste Bewertung und bereits bekannte Gegenmaßnahmen. Die ausführliche Ursachenanalyse kann im Abschlussbericht folgen.

Gelten die Meldepflichten auch für kleine Unternehmen?

Eine allgemeine Ausnahme allein aufgrund einer geringen Unternehmensgröße besteht nicht. Kleine Unternehmen müssen daher ebenfalls prüfen, ob sie Hersteller eines erfassten Produkts sind.

Sind auch kostenlose Softwareprodukte betroffen?

Entscheidend ist nicht allein, ob ein unmittelbarer Kaufpreis verlangt wird. Auch kostenlos bereitgestellte Software kann im Rahmen einer kommerziellen Tätigkeit angeboten werden. Bei freier und quelloffener Software gelten besondere Abgrenzungen.

Können Open-Source-Projekte betroffen sein?

Rein private oder nicht kommerzielle Open-Source-Entwicklung wird anders behandelt als kommerzielle Bereitstellung. Für sogenannte Open-Source Software Stewards gelten zudem besondere Pflichten.

Darf vor der Meldung die Freigabe der Cyberversicherung abgewartet werden?

Versicherungsvertragliche Prozesse sollten parallel bearbeitet werden. Sie dürfen die gesetzliche CRA-Frist nicht verzögern.

Sind ältere Produkte ausgeschlossen?

Nein. Die Meldepflichten können auch Produkte betreffen, die bereits vor der vollständigen Anwendung des CRA auf dem europäischen Markt bereitgestellt wurden.

Muss auch am Wochenende gemeldet werden?

Die Fristen werden in Stunden angegeben. Unternehmen sollten deshalb einen durchgehend funktionsfähigen Eskalationsprozess einrichten.

Muss der Hersteller auch die Nutzer informieren?

Grundsätzlich müssen betroffene Nutzer und gegebenenfalls weitere Nutzer informiert werden. Erforderliche Schutz-, Minderungs- und Korrekturmaßnahmen sollten verständlich mitgeteilt werden.

Was geschieht, wenn eine betroffene Schwachstelle aus einer fremden Komponente stammt?

Die Verwendung einer Drittkomponente beseitigt die eigene Verantwortung nicht automatisch. Hersteller müssen prüfen, welche eigenen Produkte die Komponente enthalten und ob eine eigene Meldepflicht besteht.

Der 11. September 2026 ist ein eigener Compliance-Stichtag

Der 11. September 2026 ist für Hardwarehersteller, Softwarehäuser und Anbieter vernetzter Produkte ein eigenständiger und unmittelbar relevanter Stichtag.

Die größte Gefahr besteht nicht darin, dass innerhalb von 24 Stunden noch keine vollständige technische Analyse vorliegt. Genau dafür sieht der Cyber Resilience Act ein mehrstufiges Meldeverfahren vor.

Gefährlich ist vielmehr, wenn niemand verbindlich entscheiden kann,

• ob ein Produkt betroffen ist,
• wann das Unternehmen Kenntnis erlangt hat,
• wer die CRA-Relevanz bewertet,
• wer die Meldung absendet,
• wer am Wochenende erreichbar ist und
• wie Nutzer rechtzeitig informiert werden.

Unternehmen sollten deshalb vor dem Stichtag nicht nur eine juristische Prüfung vornehmen. Sie benötigen einen praktisch getesteten Notfallprozess mit klaren Verantwortlichkeiten, Vertretungsregeln, Meldevorlagen, Kommunikationswegen und einem vollständigen Produktregister.

Dieser Beitrag dient der allgemeinen Information und ersetzt keine rechtliche Prüfung des einzelnen Produkts, Geschäftsmodells oder Unternehmens.

Quellen und weiterführende offizielle Informationen

• Europäische Kommission: Cyber Resilience Act – Meldepflichten, Fristen und Single Reporting Platform (Digitale Strategie Europa)
• EUR-Lex: Verordnung (EU) 2024/2847 – Cyber Resilience Act (EUR-Lex)
• ENISA: Häufige Fragen zur CRA Single Reporting Platform (ENISA)
• Europäische Kommission: Zusammenfassung des Cyber Resilience Act und Übergangsregelungen (Digitale Strategie Europa)
• Europäische Kommission: Pflichten der Hersteller nach dem Cyber Resilience Act (Digitale Strategie Europa)
• Europäische Kommission: Anwendungshinweise zum Cyber Resilience Act vom 27. Juli 2026 (Digitale Strategie Europa)
• Europäische Kommission: FAQ zur Umsetzung des Cyber Resilience Act (Digitale Strategie Europa)