Ein Vorfall, zwei Meldewege: CRA und NIS2 seit dem 11. September 2026
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle nach dem Cyber Resilience Act melden. Wer zugleich unter NIS2 fällt, bedient zwei Meldepflichten mit eigenen Auslösern, eigenen Fristen und eigenen Kanälen.
Seit dem 11. September 2026 gilt Artikel 14 des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen seitdem aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die übrigen Pflichten der Verordnung greifen erst ab dem 11. Dezember 2027, die Meldepflicht ist ihnen also um mehr als ein Jahr vorgezogen. Sie gilt ausdrücklich auch für Produkte, die schon vor diesem Datum in Verkehr gebracht wurden.
Für viele Unternehmen ist das nicht die erste Meldepflicht. Wer als wichtige oder besonders wichtige Einrichtung unter das NIS2-Umsetzungsgesetz fällt, meldet erhebliche Sicherheitsvorfälle bereits seit Dezember 2025 an das BSI. Wer Software als Produkt vertreibt und zugleich selbst NIS2-Einrichtung ist, hat nun zwei Pflichten, die sich ähneln und doch nicht decken.
Was der CRA verlangt
Gemeldet wird über die Single Reporting Platform, die ENISA zum 11. September in Betrieb genommen hat. Eine einzige Meldung erreicht das als Koordinator zuständige CSIRT und ENISA zugleich. Für Deutschland ist das nach Angabe des BSI das CERT-Bund im BSI. Eine vorherige Registrierung ist nicht erforderlich.
Die Fristen sind gestuft:
- Frühwarnung: unverzüglich, spätestens 24 Stunden, nachdem der Hersteller Kenntnis erlangt hat.
- Meldung: spätestens nach 72 Stunden, mit ersten Angaben zu Art, Auswirkung und Gegenmaßnahmen.
- Abschlussbericht: bei aktiv ausgenutzten Schwachstellen spätestens 14 Tage, nachdem eine Korrektur oder Abhilfe verfügbar ist; bei schwerwiegenden Vorfällen innerhalb eines Monats nach der Meldung.
Hinzu kommt eine Pflicht, die in der Diskussion oft untergeht: Nach Artikel 14 Absatz 8 informiert der Hersteller die betroffenen Nutzer über die Schwachstelle oder den Vorfall und über mögliche Abhilfen. Die Bußgeldvorschriften der Verordnung gelten erst mit ihrer vollen Anwendung ab Dezember 2027. Die Pflicht selbst besteht aber heute.
Warum eine Meldung die andere nicht ersetzt
CRA und NIS2 unterscheiden sich im Gegenstand. Der CRA knüpft an das Produkt an: Eine Schwachstelle gilt als aktiv ausgenutzt, wenn verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie ohne Zustimmung des Systemeigners ausgenutzt hat. Das kann bei einem Kunden geschehen, ohne dass die eigene Infrastruktur betroffen ist. NIS2 knüpft an die Einrichtung an: Ein Sicherheitsvorfall ist nach § 2 Nr. 11 BSIG erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht oder verursachen kann oder Dritte erheblich schädigt.
Daraus folgen drei Konstellationen. Eine ausgenutzte Lücke im ausgelieferten Produkt ist CRA-meldepflichtig, aber nicht zwingend nach NIS2. Ein Ausfall des eigenen Betriebs ist NIS2-meldepflichtig, berührt aber nicht zwingend ein Produkt. Und ein Angriff über eine Produktschwachstelle auf die eigene Umgebung kann beide Pflichten auslösen, mit zwei Meldungen über zwei Kanäle: das BSI-Portal für NIS2, die ENISA-Plattform für den CRA. In Deutschland landen beide beim BSI, aber nicht im selben Vorgang.
Ein Lagebild, zwei Bewertungen
Doppelte Meldewege sind beherrschbar, doppelte Lagebilder nicht. Wer für jede Pflicht eine eigene Chronik führt, meldet früher oder später widersprüchliche Zeitpunkte. Bewährt hat sich ein gemeinsames Vorfallregister mit einer Chronik und zwei getrennten Prüfschritten: Ist ein Produkt betroffen und liegt eine aktive Ausnutzung vor? Ist der Betrieb erheblich gestört oder ein Dritter erheblich geschädigt?
Drei Punkte entscheiden, ob das im Ernstfall trägt. Erstens ein klar definierter Zeitpunkt der Kenntniserlangung, denn an ihm hängen beide 24-Stunden-Fristen. Zweitens eine benannte Stelle, die beide Prüfungen verantwortet und nicht erst im Vorfall bestimmt wird. Drittens Vorlagen für beide Kanäle, damit die Frühwarnung nicht an Formfragen scheitert.
Die Chronik beginnt fast immer mit einer Beobachtung: einem Ausfall, einem abgelaufenen Zertifikat, einer auffälligen Änderung an DNS oder Headern. Perstat, unser Produkt für Monitoring und Security Posture, hält solche Ereignisse mit Zeitstempel fest und liefert damit den Anfang dieser Chronik. Die Bewertung, ob gemeldet werden muss und wo, bleibt eine Entscheidung des Unternehmens.
Zwei Meldepflichten verlangen keine zwei Organisationen. Sie verlangen eine Chronik, die beiden standhält.