Cyber Resilience Act (CRA): Bringschuld der Unternehmen per September 2026

Cycode erläutert, warum im CRA-Kontext bereits der 11. September 2026 ein Datum von zentraler Bedeutung ist

[datensicherheit.de, 12.07.2026] Der „Cyber Resilience Act“ (CRA) der EU ist am 11. Dezember 2024 in Kraft getreten. Cycode erinnert in einer aktuellen Stellungnahme, dass dann exakt drei Jahre später alle Unternehmen, die Produkte mit digitalen Elementen anbieten, vollständige „Compliance“ gemäß dieser neuen Verordnung beweisen müssen. Cycode führt hierzu aus, warum jedoch bereits der 11. September 2026 das wichtigere Datum ist.

Foto: Cycode

Jochen Koehler: Unternehmen brauchen durchgängiges Monitoring und klare Meldeprozesse, um Sicherheitsrisiken schnell in den Griff zu bekommen!

Am 11. September 2026 treten CRA-Meldepflichten für Schwachstellen und Sicherheitsvorfälle in Kraft

Bis zum letzten Augenblick zu warten, um erst dann eine CRA-Strategie umzusetzen, könnte fatal sein. „Denn bereits am 11. September 2026 treten die Meldepflichten für Schwachstellen und Sicherheitsvorfälle im Rahmen des CRA in Kraft.“ Ab diesem Datum müssten Unternehmen

• innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Sicherheitsvorfalls eine Frühwarnung an die ENISA (European Network and Information Security Agency) und das zuständige CSIRT (Computer Security Incident Response Team) – CERT-Bund (Computer Emergency Response Team) in Deutschland – übermitteln,
• innerhalb von 72 Stunden eine vollständige Meldung an die Behörden einreichen und
• innerhalb von 14 Tagen nach Bereitstellung einer Korrekturmaßnahme (beziehungsweise innerhalb eines Monats bei schwerwiegenden Vorfällen) einen Abschlussbericht vorlegen.

„Wer diesen Fristen nicht gerecht wird, dem drohen horrende Kosten!“ Bei schwerwiegenden Verstößen seien höchste Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Umsatzes (je nachdem, welcher Betrag höher ist) vorgesehen. Doch auf diese Anforderungen seien die wenigsten Unternehmen Stand heute vorbereitet. Sicherheits- und Produktverantwortliche, welche sich aktuell auf die Frist im September 2026 vorbereiten, sähen sich in der Regel vier zentralen Lücken gegenüber, welche sie schließen müssten.

1. CRA-Lücke: Ungeklärte Verantwortlichkeiten und kein Eskalationspfad

In vielen Unternehmen sei nicht klar, wer die Meldung an die ENISA und das CSIRT tatsächlich einreicht. Auch eine Vertretung für den Krankheits- oder Urlaubsfall der verantwortlichen Person fehle in der Regel.

• Ungeklärt sei zudem häufig, wer überhaupt befugt ist, darüber zu entscheiden, ob ein Hinweis eines „AppSec“-Systems zu einer Schwachstelle als „aktiv ausgenutzt“ einzustufen ist.

Da in den meisten Unternehmen diese Überlegungen erst im akuten Notfall geklärt werden sollten, drohten Verstöße gegen den CRA durch verpasste Fristen und in zweiter Instanz horrende Bußgelder.

2. CRA-Lücke: Verzerrtes Zeitgefühl

Die durchschnittliche Zeit bis zum Erkennen einer aktiv ausgenutzten Schwachstelle im eigenen Produkt sei eben nicht mit der MTTR („Mean Time To Repair“) eines SIEM-Alarms gleichzusetzen.

• Sie hänge vielmehr von Kundenmeldungen, der Einbindung von „Threat Intelligence“ und davon ab, wie schnell ein „Triage-Call“ einberufen werden kann.

Die meisten Teams hätten den vollständigen Ablauf nie gemessen. Viele Unternehmen stellten dann bei einem Testlauf fest, „dass 24 Stunden mit ihrer aktuellen Strategie gar nicht realistisch einzuhalten sind“.

3. CRA-Lücke: Kein sauberes Inventar potenziell betroffener Produkte

Die Meldepflicht gelte für jedes auf dem EU-Markt bereitgestellte Produkt. Viele Unternehmen hätten ein großes Produktportfolio, wüssten aber gar nicht, auf welche davon die Vorschriften des CRA anzuwenden sind.

• Oft herrsche auch Unkenntnis darüber, welche Versionen noch unterstützt werden, welche Komponenten gemeinsam genutzt werden und welche Kunden in der EU ansässig sind.

Ohne dieses Wissen könnten sie unter dem Zeitdruck bei einem tatsächlichen Notfall nicht einmal den nötigen Umfang einer Meldung an die ENISA und das CSIRT definieren.

4. CRA-Lücke: Kein holistisches Monitoring des gesamten „Software Development Lifecycle“

Eine Schwachstelle, welche eine Meldung auslöst, könne im eigenen Code vorkommen. Sie könne allerdings auch aus einer „Dependency“ zu einem Produkt eines Drittanbieters, einer Open-Source-Bibliothek, einer kompromittierten CI/CD-Pipeline, einem offengelegten „Secret“ oder aus KI-generiertem Code stammen.

• „Je schneller Unternehmen Warnsignale mit ihren jeweiligen Produkten, den Auswirkungen auf die Kunden und möglichen Behebungs- oder Korrekturmaßnahmen korrelieren können, desto schneller erfolgt die Frühwarnung.“

Teams, welche mit fragmentierten Scannern und voneinander getrennten ASPM („Application Security Posture Management“)-Dashboards arbeiten, verlören Stunden durch die manuelle Korrelation.

Richtige CRA-Strategie wird zum wichtigsten Faktor

Unternehmen sollten zunächst vollständige Transparenz über alle Produkte mit digitalen Elementen schaffen und diese hinsichtlich ihres Support-Status sowie ihrer regulatorischen Relevanz erfassen.

• Ebenso erforderlich seien klar definierte Verantwortlichkeiten für die Bewertung, Eskalation und Meldung von Sicherheitsvorfällen sowie aktiv ausgenutzten Schwachstellen. Neben klar definierten Ansprechpartnern und Vertretungsregelungen müssten sie auch Entscheidungswege, Rufbereitschaften sowie die Einbindung von Rechtsabteilung und Management festlegen.

Es gelte sicherzustellen, dass Verantwortliche im Ernstfall innerhalb kürzester Zeit nachvollziehbar entscheiden könnten, ob ein Ereignis meldepflichtig ist und wer die erforderlichen Schritte veranlasst.

Auch regelmäßige Übungen unter realistischen Bedingungen für CRA-Konformität erforderlich

„Darüber hinaus müssen technische und organisatorische Prozesse etabliert werden, die eine schnelle Erkennung, Bewertung und Einordnung von Sicherheitsrisiken ermöglichen!“, unterstreicht Jochen Koehler, „Vice President of EMEA Sales“ bei Cycode.

• Er führt aus: „Dazu gehört kontinuierliches Monitoring selbst entwickelter Software und Code-Basen, Open-Source-Komponenten, Drittanbieter-Abhängigkeiten, CI/CD-Umgebungen, Infrastruktur, Container, Secrets und KI-Komponenten.“

Ergänzend seien standardisierte Melde- und Freigabeprozesse, vorbereitete Vorlagen für regulatorische Meldungen, dokumentierte „Runbooks“ sowie regelmäßige Übungen unter realistischen Bedingungen erforderlich.

Weitere Informationen zum Thema:

cycode
About Cycode: Cycode’s Agentic Development Security Platform enables enterprises to secure development from prompt to cloud. Its self-protecting ADLC vision brings security, developers, and agents together with actionable context to prevent, prioritize, and fix the risks that matter.

cycode, 11.08.2025
Introducing Cycode’s VP of EMEA Sales, Jochen Koehler

enisa EUROPEAN UNION AGENCY FOR CYBERSECURITY
Who we are / The European Union Agency for Cybersecurity. Towards a Trusted and Cyber Secure Europe

Bundesamt für Sicherheit in der Informationstechnik
CERT-Bund / CERT-Bund, das Computer Emergency Response Team für Bundesbehörden, ist die zentrale Anlaufstelle für präventive und reaktive Maßnahmen bei sicherheitsrelevanten Vorfällen in Computer-Systemen

datensicherheit.de, 30.04.2026
FTAPI gibt CRA-Tipps für KMU: Cyber Resilience Act oft ein Buch mit 7 Siegeln / Erste Meldepflichten greifen ab September 2026 – FTAPI benennt fünf Schritte, damit Anbieter digitaler Produkte noch rechtzeitig „CRA-ready“ werden

datensicherheit.de, 21.03.2026
Cyber Resilience Act: BSI hat Vorsitz der AdCo CRA / Die Rolle der Vorsitzenden wurde Anna Schwendicke, BSI-Referatsleiterin „Marktaufsicht“, im Rahmen der Sitzung der AdCo CRA am 19. März 2026 in Athen übertragen

datensicherheit.de, 06.04.2025
CRA erzwingt Produktanpassungen: Höchste Zeit für Hersteller zu handeln / Geräte mit ausnutzbaren Cyber-Schwachstellen dürfen nach CRA-Inkrafttreten in der EU bald nicht mehr verkauft werden