Am 11. September 2026 tritt Artikel 14 des Cyber Resilience Act (CRA) in Kraft, und damit die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Für viele Unternehmen ist der CRA noch kein operatives Thema. Das ist ein Problem.
Was ist der Cyber Resilience Act und wen betrifft er?
Der CRA ist die erste EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Products with Digital Elements, PDE) auf dem europäischen Markt festlegt. Betroffen sind alle Hersteller, die Produkte mit direkter oder indirekter Netzwerkfähigkeit auf dem EU-Markt bereitstellen.
Der Geltungsbereich ist weit: Industrielle Steuerungssysteme (ICS/SCADA), Netzwerkkomponenten, Endpoint-Software, IoT-Devices, mobile Applikationen und vernetzte OT-Systeme fallen ebenso darunter wie Händler und Importeure dieser Produkte.
Der CRA klassifiziert PDEs in drei Kategorien:
- Standardprodukte
Konformitätsbewertung durch den Hersteller selbst (Self-Assessment) - Wichtige Produkte Klasse I & II
z. B. Firewalls, IDS/IPS, industrielle Steuerungen (Third-Party-Assessment erforderlich) - Kritische Produkte
Zertifizierung durch akkreditierte Konformitätsbewertungsstelle
Die drei Meldepflichten nach Artikel 14 CRA
Ab dem 11. September 2026 gelten für Hersteller folgende Meldefristen gegenüber BSI und ENISA über die zentrale Single Reporting Platform (SRP):
Stufe 1
Early Warning (24 Stunden):
Initiale Meldung bei Bekanntwerden einer aktiv ausgenutzten Schwachstelle (Actively Exploited Vulnerability) oder eines schwerwiegenden Sicherheitsvorfalls. Inhalt: Basisinformationen zum Vorfall, betroffene Produkte, initiale Einschätzung.
Stufe 2
Vulnerability Notification (72 Stunden):
Vollständiger Schwachstellenbericht inkl. CVSS-Bewertung, betroffener Produktversionen und bereits eingeleiteter Gegenmaßnahmen.
Stufe 3
Final Report (14 Tage / 1 Monat):
Nach Patch-Bereitstellung oder spätestens einen Monat nach Erstmeldung, inklusive Root-Cause-Analyse und Beschreibung der implementierten Fixes.
Parallel dazu verpflichtet Art. 14 Abs. 8 CRA Hersteller zur aktiven Nutzerbenachrichtigung über Schwachstellen und verfügbare Security Updates.
Was das für CISOs und IT-Verantwortliche bedeutet
Die Meldepflicht ist, operativ betrachtet, eine Prozessfrage. Wer nach einem Incident erst intern eskalieren muss, um Zuständigkeiten zu klären, hat das 24-Stunden-Window bereits überschritten.
Folgende Punkte müssen heute prozessual verankert sein:
- Wer trägt die Meldeverantwortung (Disclosure Owner) und hat Zugang zur SRP?
- Wie wird eine Actively Exploited Vulnerability intern erkannt, triagiert und eskaliert?
- Sind Runbooks für den Meldeprozess dokumentiert und im Rahmen von Tabletop Exercises erprobt?
- Ist die Kommunikationskette zum BSI und zur ENISA-Meldeplattform operativ eingerichtet?
Für Geschäftsführer relevant: Der CRA sieht Sanktionen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes vor (der jeweils höhere Wert gilt).
Der Gesamtzeitplan: September ist erst der Anfang
| Datum | Pflicht |
| Ab sofort | Meldeprozesse aufbauen, dokumentieren und testen |
| 11. Juni 2026 | Notified Bodies nehmen Betrieb auf (Hersteller wichtiger und kritischer Produkte sollten jetzt Prüfkapazitäten reservieren. Wartezeiten sind einzukalkulieren.) |
| 11. September 2026 | Meldepflicht nach Art. 14 CRA in Kraft (Schwachstellen & Vorfälle) |
| 11. Dezember 2027 | Vollständige Anwendbarkeit aller CRA-Anforderungen (Security by Design, 5-Jahres-Support-Pflicht u. a.) |
Was Sie jetzt konkret tun sollten
- Scoping und Klassifizierung:
Ermitteln Sie, welche Ihrer Produkte als PDE einzustufen sind und welcher CRA-Kategorie sie zuzuordnen sind. Der Geltungsbereich ist bewusst weit gefasst, eine frühzeitige Klassifizierung verhindert Lücken im Compliance-Prozess. - Vulnerability-Management-Prozess etablieren:
Sie benötigen einen definierten Prozess zur kontinuierlichen Erkennung aktiv ausgenutzter Schwachstellen in Ihrer Produktlandschaft, idealerweise gestützt durch automatisiertes Monitoring, Threat Intelligence Feeds und regelmäßige Penetrationstests. - Disclosure-Prozess dokumentieren und testen:
Ein theoretischer Meldeprozess ist kein ausreichender Nachweis. Führen Sie Tabletop Exercises durch und simulieren Sie den vollständigen Meldeprozess gegenüber BSI und ENISA, bevor der Ernstfall eintritt. - Supply-Chain-Sicherheit einbeziehen:
Ein signifikanter Anteil von Schwachstellen entsteht in Third-Party-Komponenten und Open-Source-Abhängigkeiten. Software Composition Analysis (SCA) und ein strukturiertes Lieferantenmanagement sind keine optionalen Maßnahmen, sondern CRA-Pflicht. - Incident Response operationalisieren:
Die 24-Stunden-Frist ist nur einzuhalten, wenn das Incident-Response-Team mit klar definierten Rollen, getesteten Playbooks und ggf. externer Kapazität einsatzbereit ist, nicht erst im Ernstfall.
Fazit: Noch 100 Tage zum optimieren
Der Cyber Resilience Act verändert grundlegend, wie Hersteller mit Schwachstellen umgehen müssen, von reaktivem Patch-Management hin zu proaktivem Vulnerability Disclosure und strukturiertem Incident Handling. Wer jetzt die notwendigen Prozesse aufbaut, schafft nicht nur CRA-Konformität, sondern stärkt die operative Resilienz des gesamten Unternehmens.
Sind Ihre Prozesse bereit für die CRA-Meldepflicht?
DigiFors unterstützt Sie mit Vulnerability Management, Penetrationstests und Incident Response, damit Ihre Prozesse am 11. September stehen.
