CRA-Meldepflicht ab 11. September: Was jetzt stehen muss

Die CRA-Meldepflicht startet deutlich vor dem großen Stichtag: Während die meisten Pflichten des Cyber Resilience Act erst am 11. Dezember 2027 greifen, wird Artikel 14 bereits am 11. September 2026 scharf. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle ab dann innerhalb von 24 Stunden melden. Das klingt nach einer Formalie und ist in Wahrheit ein Prozessproblem: Wer die Kette von der Kenntnisnahme bis zur abgesetzten Meldung nicht vorher geübt hat, schafft die Frist nicht. Dieser Beitrag sortiert, wen die Pflicht trifft und was bis zum Stichtag stehen sollte.

Was ab dem 11. September zu melden ist

Meldepflichtig sind zwei Ereignisklassen. Erstens Schwachstellen im eigenen Produkt, die nachweislich aktiv ausgenutzt werden. Zweitens schwerwiegende Vorfälle, die sich auf die Sicherheit des Produkts auswirken. Für beide gilt dieselbe Kaskade: eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine vollständige Meldung binnen 72 Stunden und ein Abschlussbericht, bei Schwachstellen spätestens 14 Tage nach Bereitstellung einer Korrektur, bei Vorfällen spätestens einen Monat nach der Meldung.

Adressaten sind das koordinierende nationale CSIRT, in Deutschland beim BSI angesiedelt, und die ENISA, technisch über eine gemeinsame zentrale Meldeplattform. Die Frühwarnung darf grob sein, sie signalisiert nur, dass etwas passiert ist. Substanz muss erst die 72-Stunden-Meldung liefern. Der vollständige Pflichtenkatalog steht in Artikel 14 der Verordnung.

Wen die Pflicht trifft

Der CRA adressiert Hersteller von Produkten mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, unabhängig vom Firmensitz. Das umfasst neben Geräteherstellern ausdrücklich auch Software-Häuser: Wer ein Produkt vermarktet, eine App, ein Portal als Lizenzprodukt, ein Gerät mit Firmware, fällt darunter. Reine Auftragsentwicklung ohne eigenes Produkt löst die Pflicht dagegen nicht aus, ebenso wenig unentgeltliche Open-Source-Software außerhalb einer kommerziellen Tätigkeit.

Ernst nehmen sollte die Frist auch, wer sich knapp außerhalb wähnt. Die Grenze zwischen Dienstleistung und Produkt ist in gewachsenen Portfolios oft unscharf, und die Bußgelder haben Gewicht: Verstöße gegen die Meldepflichten können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden.

24 Stunden sind ein Prozess, kein Formular

Die eigentliche Arbeit liegt vor der Plattform-Registrierung. Eine Meldekette hat drei Glieder: Jemand erfährt von der Ausnutzung, jemand bewertet und entscheidet, jemand meldet. Jedes Glied braucht einen Namen und eine Vertretung, denn Kenntnisnahme richtet sich nicht nach Bürozeiten. Ein Support-Ticket am Freitagabend, ein Hinweis eines Sicherheitsforschers am Samstag: Die Uhr läuft ab Kenntnis, nicht ab Montag.

Dazu gehört ein geordneter Eingang für Schwachstellenhinweise. Eine Coordinated-Disclosure-Policy und eine security.txt unter /.well-known/ der eigenen Domain kosten einen Nachmittag und sorgen dafür, dass Hinweise dort ankommen, wo die Kette beginnt:

Contact: mailto:security@beispiel-hersteller.de
Policy: https://beispiel-hersteller.de/security/cvd-policy
Preferred-Languages: de, en
Expires: 2027-08-31T22:00:00.000Z

Sinnvoll ist außerdem eine Meldungsvorlage, die die Pflichtangaben der Frühwarnung vorstrukturiert. In der Stresssituation eines echten Vorfalls will niemand zum ersten Mal überlegen, welche Felder die Plattform verlangt.

Betroffenheit in Minuten klären statt in Tagen

Die 24-Stunden-Frist entscheidet sich häufig an einer banalen Frage: Steckt die betroffene Komponente überhaupt in unserem Produkt, und in welcher Version? Wer das erst per Code-Archäologie klärt, verliert den Tag. Eine gepflegte SBOM je Release beantwortet die Frage in Minuten und ist ohnehin Teil der CRA-Vorbereitung, wie in unserem Beitrag zur SBOM-Pflicht im Cyber Resilience Act beschrieben. Welche Werkzeuge SBOMs erzeugen, verwalten und lesbar machen, zeigt der SBOM-Tools-Überblick.

Wer bereits NIS-2-Prozesse aufgebaut hat, ist im Vorteil: Das Muster aus Frühwarnung und Folgemeldung ist dasselbe, die Rollen lassen sich wiederverwenden. Nur der Gegenstand unterscheidet sich. NIS-2 meldet Vorfälle, die die eigene Organisation treffen, der CRA meldet Schwachstellen und Vorfälle des eigenen Produkts. Wie die NIS-2-Seite praktisch aussieht, steht in unserem Artikel zur technischen Umsetzung von NIS-2.

Fazit

Der 11. September ist kein Dokumentations-, sondern ein Übungstermin. Die Meldekette mit benannten Rollen, ein sauberer Schwachstellen-Eingang, eine SBOM je Release und ein Probelauf gegen die Uhr: Damit ist die Pflicht beherrschbar, ohne dass ein neues Compliance-Projekt entsteht. Wer diese Bausteine in Produkt und Pipeline verankern will, dem helfen wir hands-on, vom Meldeprozess bis zur SBOM-Automatisierung: Software-Engineering-Beratung von EverBright.

Häufige Fragen

Ab wann gilt die CRA-Meldepflicht?

Artikel 14 des Cyber Resilience Act gilt ab dem 11. September 2026. Ab diesem Tag müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Sicherheitsauswirkung melden. Die übrigen CRA-Pflichten, etwa Sicherheitsanforderungen und technische Dokumentation, folgen erst zum 11. Dezember 2027.

Welche Fristen verlangt die CRA-Meldung?

Drei Stufen: eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine vollständige Meldung binnen 72 Stunden und ein Abschlussbericht. Letzterer ist bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur fällig, bei schwerwiegenden Vorfällen spätestens einen Monat nach der 72-Stunden-Meldung.

Wer muss nach dem Cyber Resilience Act melden?

Hersteller von Produkten mit digitalen Elementen, die auf dem EU-Markt angeboten werden, unabhängig vom Sitz des Unternehmens. Dazu zählen auch Software-Anbieter mit eigenem Produkt. Reine Auftragsentwicklung und nichtkommerzielle Open-Source-Software lösen die Meldepflicht nicht aus.

Wohin geht die CRA-Meldung?

An das koordinierende nationale CSIRT, in Deutschland beim BSI, und parallel an die ENISA. Technisch läuft beides über eine gemeinsame zentrale Meldeplattform. Die Frühwarnung darf knapp ausfallen, die vollständige Meldung nach 72 Stunden muss Bewertung, Auswirkungen und Gegenmaßnahmen enthalten.

Wie hilft eine SBOM bei der Meldepflicht?

Sie beantwortet die erste Frage jeder Meldung: Ist unser Produkt betroffen, in welcher Version, seit wann? Eine gepflegte Stückliste je Release reduziert diese Klärung von Tagen auf Minuten und liefert die Komponentenangaben, die in der 72-Stunden-Meldung ohnehin gebraucht werden.