CRA-Meldepflichten ab September 2026: Was Hersteller jetzt brauchen

Der Cyber Resilience Act gilt in vielen Projektplänen als Thema für 2027. Für die Meldepflichten stimmt das nicht: Artikel 14 der Verordnung (EU) 2024/2847 wird am 11. September 2026 anwendbar, fünfzehn Monate vor dem Rest der Verordnung. Wer ab diesem Tag eine aktiv ausgenutzte Schwachstelle im eigenen Produkt entdeckt, hat 24 Stunden Zeit für die Frühwarnung — unabhängig davon, ob die Konformitätsbewertung, die technische Dokumentation oder das CE-Kennzeichen schon stehen.

Zwei Meldeanlässe — und nur zwei

Artikel 14 kennt genau zwei Pflichtanlässe. Alles andere ist freiwillig und darf, muss aber nicht gemeldet werden.

Die aktiv ausgenutzte Schwachstelle. Eine Schwachstelle im eigenen Produkt, für die belastbare Hinweise vorliegen, dass ein Angreifer sie tatsächlich ausnutzt. Entscheidend ist die Ausnutzung, nicht der Schweregrad: Eine kritische Schwachstelle ohne Ausnutzungsnachweis löst die Pflicht nicht aus, eine mittelschwere mit belegter Ausnutzung schon. Damit wird die Frage „wird das gerade ausgenutzt?" von einer Priorisierungsfrage im Schwachstellenmanagement zu einer regulatorischen Weiche.

Der schwerwiegende Sicherheitsvorfall. Ein Vorfall, der die Entwicklungs-, Herstellungs- oder Wartungsprozesse des Herstellers so beeinträchtigt, dass für die Nutzer ein erhöhtes Cybersicherheitsrisiko entsteht — der klassische Fall ist Schadcode im eigenen Release- oder Update-Kanal. Gemeint ist hier ausdrücklich der Angriff auf den Hersteller, nicht jeder Vorfall beim Kunden.

Freiwillig gemeldet werden können daneben Schwachstellen ohne Ausnutzungsnachweis, Cyberbedrohungen, sonstige Vorfälle und Beinahe-Vorfälle. Diese freiwilligen Meldungen sind ein Angebot, keine Pflicht — und sie sollten in der internen Richtlinie ausdrücklich geregelt sein, damit im Ernstfall niemand improvisiert.

Die Fristen im Detail

Die Kaskade läuft ab Kenntniserlangung. Der Zeitpunkt, zu dem die Uhr startet, ist deshalb selbst dokumentationspflichtig — und in der Praxis der erste Punkt, an dem Prüfungen ansetzen.

Stufe	Frist	Inhalt
Frühwarnung	24 Stunden	Art der Meldung, Hersteller, Produkt, Titel; bei Vorfällen der Verdacht auf rechtswidrige oder böswillige Handlungen
Meldung	72 Stunden	Allgemeine Angaben zu Art und Ausnutzung, ergriffene und geplante Korrektur- oder Minderungsmaßnahmen, betroffene Mitgliedstaaten
Abschlussbericht (Schwachstelle)	14 Tage nach Bereitstellung der Korrekturmaßnahme	Schweregrad, Auswirkungen, CVE- beziehungsweise EUVD-Kennung, Ursache, ausgerollte Behebung
Abschlussbericht (Vorfall)	ein Monat	Beschreibung des Vorfalls, Schweregrad, Ursache, ergriffene Maßnahmen

Wer die Fristen aus NIS2 kennt, erkennt das Muster wieder — die Anlässe, die Empfänger und die Auslöser sind aber andere. Dazu unten mehr.

Die Nutzer zu unterrichten ist eine eigene Pflicht

Neben der Meldung an die Behörden verlangt Artikel 14, die betroffenen Nutzer unverzüglich zu informieren: welche Produkte und Versionen betroffen sind, worin die Schwachstelle besteht und dass sie ausgenutzt wird, welche Minderungsmaßnahmen sofort greifen und wann ein Patch verfügbar ist. Diese Pflicht läuft parallel und ersetzt die behördliche Meldung nicht.

Praktisch ist das der Punkt, an dem Security, Support, Vertrieb und Kommunikation zusammenarbeiten müssen. Eine Kundenkommunikation, die 24 Stunden auf eine Freigabe wartet, ist kein Prozessdetail, sondern ein Rechtsverstoß.

Gemeldet wird bei der ENISA, nicht beim BSI

Die Meldung läuft über die Single Reporting Platform (SRP) der ENISA, die zum 11. September 2026 betriebsbereit sein soll. Der Hersteller meldet dort einmal; die Meldung geht gleichzeitig an die ENISA und an das koordinierende CSIRT, das sich nach der Hauptniederlassung des Herstellers bestimmt. Dieses CSIRT verteilt sie unverzüglich an die weiteren betroffenen CSIRTs und die Marktüberwachungsbehörden. Nur in eng begrenzten Ausnahmefällen darf die Weitergabe aus Sicherheitsgründen verzögert werden.

Für den Zugang braucht es ein EU-Login-Konto. Die Berechtigungsprüfung nimmt das koordinierende CSIRT vor — parallel zur ersten Meldung, nicht vorab. Das ist bequem gedacht, verlagert die Unsicherheit aber in den Ernstfall: Wer erst im Vorfall zum ersten Mal auf die Plattform zugreift, klärt Zugang und Berechtigung unter 24-Stunden-Druck.

Das BSI ist an dieser Stelle nicht der Empfänger. Es ist das deutsche CSIRT und erhält die Meldungen über die europäische Plattform. Parallel arbeitet es an der Technischen Richtlinie TR-03183 mit den Teilen Allgemeine Anforderungen, Software Bill of Materials und Vulnerability Reports and Notifications — für die technische Umsetzung von SBOM und Meldeinhalten ist das die Referenz, die man im Blick behalten sollte.

Auch Bestandsprodukte sind erfasst

Die Übergangsregelung in Artikel 69 CRA unterscheidet zwischen den Produktanforderungen und den Meldepflichten. Absatz 2 nimmt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, von den übrigen Anforderungen weitgehend aus, solange sie nicht wesentlich verändert werden. Absatz 3 macht davon für die Meldepflichten nach Artikel 14 eine ausdrückliche Ausnahme: Sie gelten auch für den Bestand.

Das ist die Bestimmung, die Umfänge sprengt. Meldepflichtig ist nicht nur, was künftig konform entwickelt wird, sondern das gesamte Portfolio im Anwendungsbereich — einschließlich Altprodukten, deren Abkündigung noch aussteht, und Komponenten Dritter darin. Wer keine belastbare Produkt- und Versionsübersicht hat, kann die Frage „sind wir betroffen?" im Vorfall nicht in 24 Stunden beantworten.

Die CRA-Meldung ist nicht die NIS2-Meldung

Beide Regime verlangen 24-Stunden-Meldungen, sonst haben sie wenig gemeinsam. Der Unterschied liegt in der Rolle: NIS2 adressiert Sie als Betreiber Ihrer eigenen IT, der CRA als Hersteller eines Produkts, das andere einsetzen.

	CRA, Artikel 14	NIS2, § 32 BSIG
Adressat	Hersteller von Produkten mit digitalen Elementen	Wichtige und besonders wichtige Einrichtungen
Anlass	Aktiv ausgenutzte Schwachstelle im Produkt, schwerwiegender Vorfall beim Hersteller	Erheblicher Sicherheitsvorfall in der eigenen Einrichtung
Empfänger	ENISA und koordinierendes CSIRT über die Single Reporting Platform	BSI über das BSI-Portal
Abschluss	14 Tage nach Korrekturmaßnahme beziehungsweise ein Monat	ein Monat
Anwendbar ab	11. September 2026	seit Inkrafttreten des BSIG

Ein Hersteller, der zugleich wichtige Einrichtung ist, kann beide Pflichten mit einem einzigen Ereignis auslösen: Der Angriff auf den Build-Server ist ein Vorfall in der eigenen Einrichtung und eine Beeinträchtigung der Herstellungsprozesse. Dann laufen zwei Meldewege parallel — mit unterschiedlichen Portalen, unterschiedlichen Inhalten und derselben Uhr.

Was der Meldeprozess intern voraussetzt

Die 24-Stunden-Frist ist keine Dokumentationsaufgabe, sondern eine Prozessaufgabe. Sie ist nur einzuhalten, wenn die Kette vorher steht:

• Eingang. Ein benannter, veröffentlichter Kanal für Schwachstellenmeldungen — aus dem eigenen Monitoring, von Forschern, von Kunden, aus Threat Intelligence.
• Triage. Eine Bewertung, die zuerst die Frage der Ausnutzung beantwortet und nicht nur den CVSS-Wert notiert.
• Produktzuordnung. Die Verbindung von Schwachstelle zu Produkt, Version und Auslieferungsstand. Ohne SBOM ist das im Zeitrahmen kaum leistbar — warum die SBOM-Pflicht im CRA beim Vulnerability Handling steht und nicht in der Dokumentation, steht in einem eigenen Beitrag.
• Einstufung. Die Entscheidung „CRA-meldepflichtig ja oder nein", getroffen nach dokumentierten Kriterien, nicht nach Bauchgefühl.
• Freigabe. Eine Person mit Entscheidungsbefugnis, erreichbar auch nachts und am Wochenende, mit benannter Vertretung.
• Meldung. Zugang zur SRP, geübt, mit vorbereiteten Textbausteinen für die drei Stufen.
• Kundenkommunikation. Advisory-Vorlage, Verteiler, Freigabeweg.
• Nachweis. Zeitstempel für Kenntniserlangung, Bewertung, Entscheidung und Meldung.

Das ist im Kern ein PSIRT. Wer bereits ein Incident-Response-Verfahren für die eigene IT betreibt, hat die Hälfte — die andere Hälfte ist die Produktsicht, und die fehlt in den meisten Prozessen.

Typische Lücken kurz vor dem Stichtag

Drei Muster fallen in Gesprächen mit Herstellern immer wieder auf:

Niemand ist zuständig. Die Produktentwicklung hält Meldepflichten für ein Compliance-Thema, Compliance hält sie für ein Produktthema. Ergebnis: Es gibt keine Person, die im Vorfall die Einstufung verantwortet.

Der Bestand ist unklar. Welche Produkte in welchen Versionen sind im Markt, welche Komponenten stecken darin, welche davon sind abgekündigt? Ohne diese Übersicht führt Artikel 69 Absatz 3 zu einer Meldepflicht, die faktisch nicht erfüllbar ist.

Die Ausnutzung wird nicht beobachtet. Wer nur den eigenen Code betrachtet, aber keine Quellen zu aktiver Ausnutzung auswertet, erfährt vom auslösenden Ereignis womöglich erst aus der Presse — und die 24 Stunden liefen dann längst.

Fazit

Der CRA ist ab dem 11. September 2026 operativ, nicht erst 2027. Was bis dahin steht, entscheidet nicht über die Konformität des Produkts, sondern über die Reaktionsfähigkeit der Organisation: benannte Zuständigkeit, geübter Zugang zur SRP, dokumentierte Einstufungskriterien, Produkt- und Versionsübersicht, vorbereitete Kundenkommunikation.

Wir prüfen mit Ihnen, ob Ihre Produkte in den Anwendungsbereich fallen, und bauen den Melde- und Schwachstellenprozess auf, der die Fristen trägt — von der Triage bis zum Abschlussbericht. Mehr dazu in unserer Beratung zu Regulatorik und Informationssicherheit und zur Sicherheit in der Lieferkette. Jetzt CRA-Meldeprozess besprechen

FAQ

Ab wann genau gelten die CRA-Meldepflichten und was ist bis dahin zu tun?

Artikel 14 der Verordnung (EU) 2024/2847 wird am 11. September 2026 anwendbar. Ab diesem Tag müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: Frühwarnung binnen 24 Stunden nach Kenntniserlangung, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Bereitstellung einer Korrekturmaßnahme bei Schwachstellen beziehungsweise binnen eines Monats bei Vorfällen. Die übrigen CRA-Anforderungen — sichere Entwicklung, technische Dokumentation, Konformitätsbewertung, CE-Kennzeichnung — gelten erst ab dem 11. Dezember 2027. Bis zum Stichtag sind vier Dinge vorzubereiten: erstens eine Übersicht, welche Produkte in welchen Versionen im Anwendungsbereich sind, einschließlich Bestandsprodukten; zweitens ein EU-Login-Konto und ein geübter Zugang zur Single Reporting Platform der ENISA; drittens dokumentierte Kriterien, nach denen entschieden wird, ob ein Ereignis meldepflichtig ist, samt benannter Freigabeperson mit Vertretung; viertens eine vorbereitete Kundenkommunikation, weil die Unterrichtung der betroffenen Nutzer eine eigenständige Pflicht neben der Behördenmeldung ist.

Gelten die CRA-Meldepflichten auch für Produkte, die schon lange auf dem Markt sind?

Ja. Artikel 69 Absatz 2 CRA nimmt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, von den Produktanforderungen weitgehend aus, solange sie nicht wesentlich verändert werden. Für die Meldepflichten macht Absatz 3 davon eine ausdrückliche Ausnahme: Artikel 14 gilt auch für diese Bestandsprodukte. Praktisch heißt das, dass sich der Umfang der Meldepflicht nicht auf neu entwickelte Produkte beschränkt, sondern das gesamte Portfolio im Anwendungsbereich erfasst — einschließlich älterer Versionen, die noch bei Kunden im Einsatz sind, und einschließlich der darin verbauten Komponenten Dritter. Für Hersteller mit langen Produktlebenszyklen ist das der aufwendigste Teil der Vorbereitung: Ohne eine belastbare Übersicht über ausgelieferte Produkte, Versionsstände und deren Abhängigkeiten lässt sich im Ernstfall nicht binnen 24 Stunden beantworten, ob und welche Produkte von einer aktiv ausgenutzten Schwachstelle betroffen sind. Eine gepflegte Software Bill of Materials ist deshalb weniger eine Dokumentationsübung als die Voraussetzung dafür, die Frist überhaupt einhalten zu können.

Wo wird gemeldet — beim BSI oder bei der ENISA?

Gemeldet wird über die Single Reporting Platform der ENISA, nicht über das BSI-Portal. Der Hersteller gibt seine Meldung einmal ab; sie geht gleichzeitig an die ENISA und an das koordinierende CSIRT, das sich nach der Hauptniederlassung des Herstellers in der Union bestimmt. Dieses CSIRT leitet die Meldung unverzüglich an die weiteren betroffenen CSIRTs und die zuständigen Marktüberwachungsbehörden weiter; nur unter eng begrenzten außergewöhnlichen Umständen darf die Weitergabe aus Sicherheitsgründen verzögert werden. Das BSI ist in diesem Verfahren das deutsche CSIRT und Empfänger über die europäische Plattform, nicht die Meldestelle. Für den Zugang zur Plattform ist ein EU-Login-Konto erforderlich; die Prüfung der Berechtigung nimmt das koordinierende CSIRT parallel zur ersten Meldung vor. Wichtig ist die Abgrenzung zur NIS2-Meldepflicht nach § 32 BSIG: Diese richtet sich an Einrichtungen als Betreiber ihrer eigenen IT, läuft über das BSI-Portal und wird durch einen erheblichen Sicherheitsvorfall in der eigenen Einrichtung ausgelöst. Ein Hersteller, der zugleich wichtige oder besonders wichtige Einrichtung ist, kann mit einem einzigen Ereignis beide Meldewege auslösen und muss beide parallel bedienen.

---

Stand: August 2026. Grundlage: Verordnung (EU) 2024/2847 (CRA), Artikel 14, 16 und 69; Meldepflichten-Seite der Europäischen Kommission; FAQ der ENISA zur Single Reporting Platform; BSI zum Cyber Resilience Act. Für eine individuelle Einordnung empfehlen wir eine Beratung durch Fachexperten.