Cyber Resilience Act: Erste Meldepflichten gelten schon ab September 2026

Warum der 11. September 2026 für Unternehmen entscheidend ist

Der Cyber Resilience Act (CRA) wird häufig mit dem Jahr 2027 verbunden. Dann greifen umfassende Anforderungen an die Sicherheit digitaler Produkte. Eine wichtige Verpflichtung beginnt jedoch deutlich früher.

Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen bestimmte Sicherheitsereignisse melden. Dazu zählen:

• aktiv ausgenutzte Schwachstellen in Produkten
• schwerwiegende Sicherheitsvorfälle, die die Produktsicherheit beeinträchtigen

Diese Meldepflichten betreffen insbesondere Hersteller sowie Produktverantwortliche in Industrie- und Softwareunternehmen. Auch Rollen wie CISO, Produktsecurity-Teams, PSIRT, Legal, Compliance oder Produktmanagement sind direkt eingebunden.

Die Herausforderung: Die Meldefristen sind sehr kurz und betreffen laufende Produktbetriebe. Unternehmen müssen also operativ vorbereitet sein – nicht nur juristisch.

Welche Sicherheitsereignisse meldepflichtig sind

Nicht jede Schwachstelle führt automatisch zu einer Meldepflicht. Entscheidend ist der tatsächliche Sicherheitsbezug.

Aktiv ausgenutzte Schwachstellen

Eine Schwachstelle gilt als aktiv ausgenutzt, wenn belastbare Hinweise vorliegen, dass Angreifer sie in der Praxis nutzen. Das kann beispielsweise der Fall sein bei:

• bestätigten Angriffen
• beobachteten Exploits
• Threat-Intelligence-Hinweisen auf Ausnutzung „in the wild“

Ein einfacher Merksatz lautet daher:

Nicht jede Schwachstelle ist meldepflichtig – meldepflichtig wird sie erst, wenn ihre Ausnutzung in der Realität erkennbar ist.

Schwerwiegende Sicherheitsvorfälle

Auch bestimmte Sicherheitsvorfälle müssen gemeldet werden, wenn sie die Sicherheit eines Produkts erheblich beeinträchtigen. Beispiele können sein:

• unautorisierter Zugriff auf sicherheitsrelevante Funktionen
• Manipulation zentraler Produktfunktionen
• kompromittierte Update-Mechanismen
• eine große Anzahl betroffener Systeme oder Nutzer

Ob ein Vorfall als schwerwiegend gilt, hängt typischerweise von drei Faktoren ab:

• Impact (Auswirkungen des Vorfalls)
• Reichweite (wie viele Systeme oder Nutzer betroffen sind)
• Ausnutzbarkeit (wie leicht der Angriff durchgeführt werden kann)

Wie die Meldung ablaufen muss

Die Meldung erfolgt über eine zentrale europäische Plattform, die sogenannte Single Reporting Platform (SRP). Von dort werden die Informationen an die zuständigen Stellen weitergeleitet.

Der Meldeprozess ist mehrstufig aufgebaut und folgt klaren Zeitfenstern.

Stufe 1: Early Warning (max. 24 Stunden)

Innerhalb von 24 Stunden nach Awareness muss eine erste Meldung erfolgen. Sie enthält ein kurzes Signal, dass ein relevanter Sicherheitsfall vorliegt, sowie erste grundlegende Informationen.

Stufe 2: Full Notification (max. 72 Stunden)

Spätestens 72 Stunden nach Awareness muss eine ausführlichere Meldung erfolgen. Sie enthält unter anderem:

• betroffene Produkte und Versionen
• erste Bewertung des Vorfalls
• aktuelle Maßnahmen
• Hinweise für Kunden oder Nutzer

Stufe 3: Final Report

Der Abschlussbericht folgt später und hängt von der Art des Ereignisses ab:

• bei aktiv ausgenutzten Schwachstellen: spätestens 14 Tage nach verfügbarer Abhilfe
• bei schwerwiegenden Vorfällen: spätestens einen Monat nach der Meldung

Welche Informationen Unternehmen kurzfristig bereitstellen müssen

Damit eine Meldung erfolgen kann, müssen innerhalb kurzer Zeit strukturierte Informationen vorliegen. In der Praxis bedeutet das, dass Unternehmen ein Mindest-Informationspaket schnell zusammenstellen müssen.

Typischerweise gehören dazu:

• Produkt oder Produktlinie
• betroffene Versionen und Release-Daten
• Art des Ereignisses (Schwachstelle oder Vorfall)
• erste Einschätzung der möglichen Auswirkungen
• betroffene Installationsbasis oder Kundengruppen
• aktueller Stand von Workarounds oder Patches
• ein zentraler Ansprechpartner für Rückfragen

Das Problem: Diese Informationen liegen oft in verschiedenen Bereichen – etwa in Engineering, Support, Security oder bei Zulieferern.

Der kritische Faktor: Ein funktionierender Triage-Prozess

Der eigentliche Engpass bei der CRA-Meldepflicht ist selten die Technik. Entscheidend ist vielmehr ein klar definierter Triage-Prozess.

Die Triage beschreibt den Weg von einem ersten Hinweis bis zur Entscheidung, ob ein Ereignis meldepflichtig ist.

Ein typischer Ablauf kann so aussehen:

1. Eingang eines Signals (z. B. über Support, SOC, Threat Intelligence oder Bug Bounty)
2. Erste Prüfung durch Produktsecurity oder PSIRT
3. Klassifizierung des Ereignisses (Schwachstelle oder Incident)
4. Bewertung: aktiv ausgenutzt oder schwerwiegend?
5. Zusammenstellung der Fakten durch Engineering, Produkt und Support
6. Freigabe durch Legal oder Kommunikationsverantwortliche
7. Meldung über die Reporting-Plattform
8. Information von Kunden und Nutzern
9. Abschlussbericht und interne Lessons Learned

Ohne klar definierte Rollen, Entscheidungswege und Freigaben kann dieser Prozess schnell ins Stocken geraten.

Welche Risiken bei Verstößen drohen

Die CRA-Vorgaben sind mit erheblichen Sanktionen verbunden.

Mögliche Konsequenzen sind unter anderem:

• Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes
• behördliche Maßnahmen wie Verkaufsverbote
• Rückrufe oder Einschränkungen der Produktverfügbarkeit

Neben finanziellen Risiken entstehen häufig auch Reputationsschäden und Vertrauensverluste bei Kunden.

Wie sich Unternehmen jetzt vorbereiten sollten

Um die Meldepflicht ab September 2026 erfüllen zu können, müssen Unternehmen mehrere organisatorische Grundlagen schaffen.

1. Melde-Scope und Verantwortlichkeiten definieren

Unternehmen sollten zunächst klären:

• welche Produkte CRA-relevant sind
• welche Versionen betroffen sein können
• wer pro Produkt verantwortlich ist
• welche Kontaktketten im Incident-Fall greifen

2. Entscheidungsregeln und Freigaben festlegen

Ein zentraler Schritt ist die Definition klarer Regeln, etwa:

• wann intern „Awareness“ vorliegt
• wann eine Schwachstelle als aktiv ausgenutzt gilt
• wann ein Vorfall als schwerwiegend einzustufen ist
• wer Meldungen erstellt und freigibt

Auch Vorlagen für die verschiedenen Meldephasen sollten vorbereitet werden.

3. Fakten und Produktdaten schnell verfügbar machen

Damit Meldungen innerhalb der Fristen möglich sind, müssen wichtige Produktinformationen zentral verfügbar sein. Dazu gehören beispielsweise:

• Versionierungs- und Release-Informationen
• Update-Mechanismen
• Support- und Patchzyklen
• zentrale Komponenten oder Abhängigkeiten

4. Lieferkette einbeziehen

Viele Sicherheitsvorfälle hängen mit Drittkomponenten oder Zulieferern zusammen. Unternehmen sollten daher sicherstellen, dass auch ihre Partner schnell relevante Informationen liefern können.

Wichtig sind beispielsweise:

• klare Eskalationskontakte
• definierte Reaktionszeiten
• Verpflichtungen zur Weitergabe von Sicherheitsinformationen

5. Prozesse realistisch testen

Vor Inkrafttreten der Meldepflicht empfiehlt sich ein Probelauf. Dabei können etwa zwei typische Szenarien simuliert werden:

• eine aktiv ausgenutzte Schwachstelle
• ein schwerwiegender Sicherheitsvorfall mit Kundenauswirkungen

Solche Übungen helfen, Prozesslücken, fehlende Daten oder unklare Zuständigkeiten frühzeitig zu erkennen.

Warum Reporting ohne Schwachstellenmanagement kaum funktioniert

Formal führt der CRA ab September 2026 zunächst eine Meldepflicht ein. In der Praxis lässt sich diese jedoch kaum erfüllen, ohne grundlegende Prozesse für das Management von Schwachstellen.

Unternehmen benötigen daher mindestens eine funktionsfähige Struktur für:

• Intake-Kanäle für Sicherheitsmeldungen
• Bewertung und Priorisierung von Schwachstellen
• Prüfung möglicher Exploits
• Koordination von Fixes oder Workarounds
• Kommunikation mit Kunden und Behörden

Mit anderen Worten: Ein funktionierendes Schwachstellenmanagement wird faktisch zur Voraussetzung für eine rechtssichere Meldung.

Fazit

Die erste verpflichtende Vorgabe des Cyber Resilience Act greift früher, als viele Unternehmen erwarten: Bereits ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gemeldet werden.

Die größte Herausforderung liegt dabei nicht in der Meldung selbst, sondern in der Organisation dahinter. Ohne klare Triage-Prozesse, schnelle Datenverfügbarkeit und abgestimmte Verantwortlichkeiten lassen sich die kurzen Fristen kaum einhalten.

Unternehmen sollten daher frühzeitig ihre Meldeprozesse, Verantwortlichkeiten und Informationsflüsse prüfen – und idealerweise vor dem Stichtag realistische Testläufe durchführen.