CRA
Cyber Resilience Act: Meldepflichten für Schwachstellen gelten ab September 2026
Warum der 11. September 2026 für Unternehmen zum Stresstest wird
Der Cyber Resilience Act verändert die Produktsicherheit in Europa grundlegend – und zwar früher, als viele Unternehmen glauben. Bereits ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb engster Fristen melden. Wer erst auf die vollständige Anwendung des CRA Ende 2027 blickt, könnte deshalb eine entscheidende regulatorische Etappe übersehen.
Der Cyber Resilience Act (CRA) der Europäischen Union ist seit dem 10. Dezember 2024 in Kraft. Die meisten Anforderungen der Verordnung gelten zwar erst ab dem 11. Dezember 2027 vollständig. Für Hersteller von Produkten mit digitalen Elementen beginnt der operative Ernstfall jedoch bereits deutlich früher: Am 11. September 2026 treten die verpflichtenden Meldeverfahren für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in Kraft.
Betroffen sind grundsätzlich Hardware- und Softwareprodukte, die auf dem europäischen Markt bereitgestellt werden und direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind. Der CRA soll dafür sorgen, dass Cybersicherheit nicht erst nach einem Angriff berücksichtigt wird, sondern über den gesamten Lebenszyklus eines digitalen Produkts hinweg fest in Entwicklung, Wartung und Schwachstellenmanagement verankert ist.
Für Unternehmen bedeutet das: Bis September müssen nicht sämtliche CRA-Anforderungen vollständig umgesetzt sein. Die Prozesse zur Erkennung, Bewertung, Eskalation und Meldung relevanter Sicherheitsereignisse müssen jedoch funktionieren.
Ab September läuft die regulatorische Uhr
Sobald ein Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erhält, beginnt ein eng getakteter Meldeprozess.
Innerhalb von 24 Stunden muss eine Frühwarnung übermittelt werden. Nach spätestens 72 Stunden ist eine ausführlichere Meldung erforderlich. Bei einer aktiv ausgenutzten Schwachstelle muss zudem spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme ein Abschlussbericht eingereicht werden. Bei schwerwiegenden Sicherheitsvorfällen gilt hierfür eine Frist von einem Monat nach der ausführlichen Meldung.
Als zentraler technischer Zugang entsteht bei der EU-Agentur für Cybersicherheit ENISA die sogenannte Single Reporting Platform. Sie soll als einheitliche Meldestelle dienen und verhindern, dass Hersteller identische Informationen mehrfach an verschiedene nationale Behörden übermitteln müssen.
Die Herausforderung liegt damit nicht nur im Erkennen einer Sicherheitslücke. Unternehmen müssen innerhalb weniger Stunden belastbar beurteilen können, ob ein Ereignis tatsächlich unter die Meldepflicht fällt, welche Produkte und Kunden betroffen sind und welche Informationen den Behörden bereits vorliegen müssen. Genau hier offenbaren sich nach Einschätzung des Security-Anbieters Cycode in vielen Organisationen noch erhebliche Lücken.
Lücke 1: Niemand weiß, wer im Ernstfall entscheidet
In zahlreichen Unternehmen ist bislang nicht eindeutig geregelt, wer eine CRA-Meldung vorbereitet, rechtlich bewertet, freigibt und schließlich übermittelt. Häufig fehlen außerdem belastbare Vertretungsregelungen für Urlaubszeiten, Krankheit oder Vorfälle außerhalb der regulären Geschäftszeiten.
Noch schwieriger ist die inhaltliche Entscheidung: Wer darf verbindlich feststellen, dass eine Schwachstelle aktiv ausgenutzt wird? Reicht ein Hinweis aus einem Application-Security-System? Muss zunächst Threat Intelligence hinzugezogen werden? Welche Rolle übernehmen Product Security, Incident Response, Rechtsabteilung und Geschäftsführung?
Wer diese Fragen erst während eines laufenden Vorfalls klärt, verliert wertvolle Zeit. Aus einem technischen Sicherheitsproblem kann dadurch zusätzlich ein Compliance-Verstoß werden.
Unternehmen benötigen deshalb einen klaren Eskalationspfad. Dieser muss nicht nur Namen und Rollen enthalten, sondern auch Entscheidungsbefugnisse, Vertretungen, Rufbereitschaften und Freigabeprozesse verbindlich festlegen.
Lücke 2: 24 Stunden sind kürzer, als viele Prozesse vermuten lassen
Die Zeit bis zur Erkennung einer aktiv ausgenutzten Schwachstelle lässt sich nicht mit der üblichen Mean Time to Respond eines SIEM-Alarms gleichsetzen. Eine relevante Schwachstelle kann über eine Kundenmeldung, einen Sicherheitsforscher, einen Open-Source-Maintainer, einen Herstellerhinweis oder einen Threat-Intelligence-Dienst bekannt werden. Anschließend müssen Teams prüfen, welche Produktversionen betroffen sind, ob eine tatsächliche Ausnutzung stattfindet und welche Auswirkungen für Nutzer entstehen.
Dafür müssen häufig mehrere Abteilungen zusammenarbeiten. Termine werden koordiniert, technische Erkenntnisse abgeglichen, Management und Rechtsabteilung eingebunden und erste Gegenmaßnahmen bewertet. Was auf dem Papier wie ein kurzer Prozess aussieht, kann in der Praxis viele Stunden beanspruchen.
Erst ein realistischer Testlauf zeigt, ob ein Unternehmen die 24-Stunden-Frist tatsächlich einhalten kann. Tabletop Exercises und simulierte CRA-Vorfälle sollten daher noch vor September zum Pflichtprogramm gehören.
Lücke 3: Das Produktinventar ist unvollständig
Eine belastbare Meldung setzt voraus, dass ein Unternehmen seine betroffenen Produkte kennt. Genau daran mangelt es jedoch häufig.
Hersteller müssen nachvollziehen können, welche Produkte mit digitalen Elementen auf dem EU-Markt angeboten werden, welche Versionen noch unterstützt werden und welche Softwarekomponenten darin enthalten sind. Hinzu kommen gemeinsam genutzte Bibliotheken, Cloud-Dienste, Firmware-Versionen, mobile Anwendungen und angebundene Backend-Systeme.
Wird beispielsweise eine Schwachstelle in einer zentralen Open-Source-Komponente entdeckt, muss innerhalb kurzer Zeit erkennbar sein, in welchen Produkten und Versionen sie eingesetzt wird. Ohne aktuelles Produkt- und Komponentenverzeichnis beginnt unter Zeitdruck eine aufwendige Suche.
Eine Software Bill of Materials kann hierbei eine wichtige Grundlage bilden. Sie allein genügt jedoch nicht. Entscheidend ist die Verbindung zwischen Komponenten, Produktversionen, Supportstatus, Kundenbezug und regulatorischer Relevanz.
Das Inventar muss daher nicht nur vollständig, sondern auch kontinuierlich aktualisiert und technisch auswertbar sein.
Lücke 4: Fragmentierte Tools verhindern eine schnelle Bewertung
Eine meldepflichtige Schwachstelle muss nicht zwangsläufig aus selbst entwickeltem Code stammen. Das Risiko kann ebenso in einer Open-Source-Bibliothek, einer Drittanbieterabhängigkeit, einem Container-Image oder einer kompromittierten CI/CD-Pipeline liegen.
Auch offengelegte Secrets, falsch konfigurierte Cloud-Ressourcen und unsicherer KI-generierter Code können zum Ausgangspunkt eines Vorfalls werden.
Viele Unternehmen überwachen diese Bereiche jedoch mit voneinander getrennten Werkzeugen. Informationen aus Static Application Security Testing, Software Composition Analysis, Cloud Security, Container Security und Secrets Scanning landen in unterschiedlichen Dashboards.
Die eigentliche Bewertung erfolgt anschließend manuell: Welcher Fund betrifft welches Produkt? Wird die verwundbare Komponente tatsächlich verwendet? Welche Kunden könnten betroffen sein? Existiert bereits eine sichere Version oder eine andere Mitigationsmaßnahme?
Diese Fragmentierung kostet genau die Zeit, die der CRA nicht gewährt. Unternehmen benötigen deshalb eine produktbezogene Sicht auf Risiken über den gesamten Software Development Lifecycle hinweg. Einzelne Warnmeldungen müssen mit Code, Komponenten, Laufzeitumgebungen, Produktversionen und möglichen Auswirkungen verknüpft werden können.
CRA-Readiness wird zur Managementaufgabe
Die Vorbereitung auf den 11. September 2026 darf nicht allein an Application-Security- oder Compliance-Teams delegiert werden. Der CRA verbindet technische Schwachstellenbewertung mit rechtlicher Einordnung, Produktverantwortung und unternehmerischer Haftung.
Unternehmen sollten deshalb zunächst sämtliche Produkte mit digitalen Elementen erfassen und deren CRA-Relevanz bewerten. Gleichzeitig müssen sie festlegen, wer Sicherheitsereignisse untersucht, über eine mögliche Meldepflicht entscheidet und die Kommunikation mit den zuständigen Stellen übernimmt.
Vorbereitete Meldevorlagen, dokumentierte Runbooks und definierte Freigabeprozesse reduzieren den Zeitverlust im Ernstfall. Ebenso wichtig sind regelmäßige Übungen, bei denen nicht nur technische Teams, sondern auch Produktmanagement, Rechtsabteilung, Kommunikation und Geschäftsführung beteiligt sind. „Darüber hinaus müssen technische und organisatorische Prozesse etabliert werden, die eine schnelle Erkennung, Bewertung und Einordnung von Sicherheitsrisiken ermöglichen“, erklärt Jochen Koehler, Vice President of EMEA Sales bei Cycode.
Dazu gehöre ein kontinuierliches Monitoring von selbst entwickelter Software, Code-Basen, Open-Source-Komponenten, Drittanbieterabhängigkeiten, CI/CD-Umgebungen, Infrastruktur, Containern, Secrets und KI-Komponenten. Ergänzend seien standardisierte Melde- und Freigabeprozesse, vorbereitete Vorlagen, dokumentierte Runbooks und regelmäßige Übungen unter realistischen Bedingungen erforderlich.
Nicht die Meldung, sondern die Vorbereitung entscheidet
Der 11. September 2026 ist kein Termin, an dem Unternehmen lediglich ein weiteres Meldeformular bereithalten müssen. Das Datum wird zum Praxistest dafür, ob Produkt-, Entwicklungs- und Sicherheitsteams über eine gemeinsame und belastbare Sicht auf Cyberrisiken verfügen.
Wer eine aktiv ausgenutzte Schwachstelle erst mühsam einem Produkt zuordnen muss, Zuständigkeiten während des Vorfalls diskutiert oder technische Ergebnisse aus mehreren Dashboards manuell zusammenführt, wird die engen Meldefristen kaum zuverlässig erfüllen können.
CRA-Compliance beginnt deshalb nicht bei der Behörde, sondern im Entwicklungsprozess. Unternehmen, die Produktsicherheit, Schwachstellenmanagement und Incident Response bereits jetzt zusammenführen, erfüllen nicht nur regulatorische Vorgaben. Sie verkürzen auch ihre Reaktionszeit und begrenzen die Auswirkungen realer Angriffe. Der September-Termin macht aus dieser Fähigkeit nun eine messbare Anforderung.
