Kurzfassung: Am 11. September 2026 greift der erste operative Teil des EU Cyber Resilience Act: Hersteller müssen aktiv ausgenutzte Schwachstellen und bestimmte schwere Sicherheitsvorfälle über die neue ENISA-Plattform melden. Die erste Warnung ist innerhalb von 24 Stunden fällig, die ausführlichere Meldung innerhalb von 72 Stunden. Der leicht zu übersehende Punkt: Diese Meldepflicht startet mehr als ein Jahr vor den meisten übrigen CRA-Pflichten und kann auch ältere Produkte betreffen.
Wer beim Cyber Resilience Act nur den 11. Dezember 2027 im Kalender hat, kann deshalb zu spät sein. Dieses Datum gilt für den Großteil der technischen und organisatorischen Produktpflichten. Artikel 14 des CRA wird dagegen bereits am 11. September 2026 anwendbar.
24 Stunden, 72 Stunden, dann der Abschlussbericht
Bei einer aktiv ausgenutzten Schwachstelle verlangt die EU zunächst eine Frühwarnung innerhalb von 24 Stunden, nachdem der Hersteller von der aktiven Ausnutzung erfahren hat. Innerhalb von 72 Stunden folgt eine vollständigere Meldung. Ein Abschlussbericht ist spätestens 14 Tage nachdem eine Korrekturmaßnahme verfügbar ist einzureichen.
Für schwere Sicherheitsvorfälle gilt ebenfalls die 24-/72-Stunden-Logik. Der abschließende Bericht ist dort innerhalb eines Monats vorgesehen. Gemeldet wird einmal über die von ENISA betriebene Single Reporting Platform, kurz SRP. Die Meldung geht an den zuständigen CSIRT-Koordinator und wird grundsätzlich gleichzeitig ENISA verfügbar gemacht.
Der eigentliche Haken: Auch ältere Produkte können darunterfallen
ENISA hat seine FAQ zur Plattform am 4. September aktualisiert und dort einen wichtigen Übergangspunkt klargestellt: Die Meldepflicht kann auch Produkte mit digitalen Elementen erfassen, die bereits vor dem 11. Dezember 2027 auf den Markt gebracht wurden, sofern sie in den Anwendungsbereich des CRA fallen.
Entscheidend ist außerdem der Zeitpunkt der Kenntnis. Eine aktiv ausgenutzte Schwachstelle muss nicht rückwirkend gemeldet werden, wenn der Hersteller bereits vor dem 11. September von der Ausnutzung wusste. Erfährt er jedoch erst danach davon, kann die Meldepflicht greifen — auch wenn die Schwachstelle selbst älter ist.
Das Mosaik: Vulnerability Management wird zur Meldekette
Technisch verändert der CRA damit nicht nur die Produktentwicklung, sondern den Incident-Prozess. Hersteller müssen künftig schneller klären, ob eine Schwachstelle tatsächlich aktiv ausgenutzt wird, welche Produkte betroffen sind, wann die interne Kenntnis begann und welche Informationen innerhalb der ersten 24 Stunden belastbar vorliegen.
Das ist besonders relevant bei Fällen wie der von Pandorex analysierten MikroTik-Angriffswelle. Dort lagen Patch, aktive Ausnutzung, Geräteexposition und Kompromittierungsindikatoren zeitlich eng beieinander. Der CRA macht aus genau solchen technischen Fragen zusätzlich einen regulatorischen Zeitstempel: Wann wusste der Hersteller von aktiver Ausnutzung, und wann begann damit die Meldefrist?
Das bedeutet nicht, dass jeder CVE automatisch innerhalb von 24 Stunden an die EU gemeldet werden muss. Der Trigger ist enger: aktiv ausgenutzte Schwachstellen beziehungsweise schwere Sicherheitsvorfälle im Sinne des CRA. Ein normaler Bugfix ohne bekannte aktive Ausnutzung ist nicht dasselbe.
Open Source ist nicht pauschal ausgenommen
Auch bei Open Source ist die verbreitete Kurzform „CRA gilt nicht für Open Source“ zu grob. Die Kommission stellt klar, dass frei verfügbare Open-Source-Software außerhalb kommerzieller Tätigkeit grundsätzlich anders behandelt wird. Wird ein Produkt jedoch im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt, kann es in den CRA fallen.
Daneben kennt der CRA die Rolle des Open-Source Software Steward. ENISA nennt Hersteller und solche Stewards ausdrücklich als Nutzer der Reporting-Plattform. Für einzelne Entwickler, die lediglich Code zu einem Projekt beitragen, das nicht unter ihrer Verantwortung steht, gelten dagegen andere Grenzen.
Was Unternehmen jetzt praktisch trennen müssen
Der erste Compliance-Schritt ist daher nicht automatisch ein neues Security-Produkt. Wichtiger ist eine belastbare interne Kette zwischen Product Security, PSIRT, Entwicklung, Legal und den Personen, die eine SRP-Meldung abgeben dürfen. Wer erst nach einer bestätigten Ausnutzung klärt, wer den 24-Stunden-Timer besitzt, hat den schwierigsten Teil bereits zu spät organisiert.
Gleichzeitig sollte die Frist nicht mit einer Pflicht zu vollständiger Ursachenanalyse verwechselt werden. Gerade deshalb gibt es die gestufte Meldung: frühe Warnung, detailliertere 72-Stunden-Meldung und späterer Abschlussbericht.
Pandorex Analyse
Der wichtigste CRA-Termin für Security-Teams ist kurzfristig nicht Dezember 2027, sondern der 11. September 2026. Ab dann wird aus der Frage „Ist diese Schwachstelle aktiv ausgenutzt?“ in vielen Produktunternehmen zusätzlich eine regulatorische Entscheidung mit sehr kurzer Uhr.
Pandorex Einschätzung: Die größte operative Gefahr ist weniger die Plattform selbst als ein unklarer interner Startpunkt der Meldekette. Unternehmen mit eigener Software oder vernetzten Produkten sollten den CRA deshalb schon jetzt als Incident-Response-Thema behandeln — nicht erst als Produktzertifizierung für 2027.