CRA-Meldepflichten: Was Hersteller seit dem 11. September 2026 melden müssen, an wen und wie schnell

Seit dem 11. September 2026 verpflichtet Artikel 14 der Cyberresilienzverordnung (CRA) Hersteller von Produkten mit digitalen Elementen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden nach Kenntniserlangung zu melden. Innerhalb von 72 Stunden folgt eine Meldung, danach ein Abschlussbericht. Die Meldungen gehen über eine einzige Plattform an ein CSIRT und die ENISA. Melden muss der Hersteller, nicht der Nutzer.

Dieser Leitfaden behandelt, was zu melden ist, Fristen und Inhalte, wer die Meldungen erhält, die Information der Nutzer, den Anwendungsbereich, NIS2, Sanktionen, was die Pflicht offen lässt, und eine Checkliste.

Phase	Aktiv ausgenutzte Schwachstelle	Schwerwiegender Sicherheitsvorfall
Frühwarnung	Innerhalb von 24 Stunden nach Kenntniserlangung	Innerhalb von 24 Stunden nach Kenntniserlangung
Meldung	Innerhalb von 72 Stunden nach Kenntniserlangung	Innerhalb von 72 Stunden nach Kenntniserlangung
Abschlussbericht	Spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme	Innerhalb eines Monats nach der Meldung des Vorfalls
Empfänger	Als Koordinator benanntes CSIRT und ENISA, über die einheitliche Meldeplattform	Dieselben

Was müssen Hersteller nach dem CRA melden?

Zwei Dinge, die beide das Produkt betreffen, nicht das Unternehmen.

Aktiv ausgenutzte Schwachstellen

Artikel 14 Absatz 1 erfasst jede aktiv ausgenutzte Schwachstelle, die in dem Produkt enthalten ist. Artikel 3 Nummer 42 legt die Schwelle fest: zuverlässige Nachweise, dass ein böswilliger Akteur sie ohne Erlaubnis des Systemeigentümers in einem System ausgenutzt hat.

Eine Schwachstelle, die bei Tests in gutem Glauben gefunden wurde und bei der es keine Anzeichen einer böswilligen Nutzung gibt, sollte laut Erwägungsgrund 68 nicht der Meldepflicht unterliegen. Nach Artikel 15 können Sie sie freiwillig melden, ebenso Beinahe-Vorfälle.

Dem Wortlaut nach umfasst eine im Produkt enthaltene Schwachstelle auch Komponenten, die Sie nicht selbst geschrieben haben; die FAQ der Kommission zum CRA behandelt diesen Fall in Abschnitt 5.4. In der Praxis werden viele Meldungen im Code anderer beginnen.

Schwerwiegende Sicherheitsvorfälle

Artikel 14 Absatz 3 erfasst jeden schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Sicherheit des Produkts. Nach Artikel 14 Absatz 5 ist ein Sicherheitsvorfall schwerwiegend, wenn er

1. die Fähigkeit des Produkts, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, beeinträchtigt oder beeinträchtigen kann; oder
2. dazu geführt hat oder führen könnte, dass Schadcode in das Produkt oder in die Netz- und Informationssysteme eines Nutzers eingeschleust oder dort ausgeführt wird.

Die Erwägungsgründe nennen Beispiele: Schadcode, der in den Verteilungskanal Ihrer Sicherheitsupdates eingeschleust wird, oder ein Sicherheitsvorfall in Ihren Entwicklungs-, Produktions- oder Wartungsprozessen, der das Risiko für die Nutzer erhöht. Ihre interne Sicherheit fällt darunter, soweit sie berührt, was Sie ausliefern.

Welche Meldefristen gelten nach dem CRA, und was gehört in jede Meldung?

Für die Fristen von 24 und 72 Stunden gilt: unverzüglich, in jedem Fall aber innerhalb der genannten Frist.

1. Frühwarnung, 24 Stunden. Die Mitgliedstaaten, in denen das Produkt nach Ihrer Kenntnis verfügbar ist; bei einem Sicherheitsvorfall außerdem, ob Sie eine rechtswidrige oder böswillige Handlung vermuten.
2. Meldung, 72 Stunden. Allgemeine Informationen zum Produkt und zur Art der Ausnutzung und der Schwachstelle (oder des Sicherheitsvorfalls, mit einer ersten Bewertung), ergriffene Maßnahmen, Maßnahmen, die Nutzer ergreifen können, und wie sensibel Sie die Informationen einschätzen.
3. Zwischenbericht. Das empfangende CSIRT kann einen Bericht zum aktuellen Stand anfordern (Artikel 14 Absatz 6).
4. Abschlussbericht. Eine Beschreibung mit Schweregrad und Auswirkungen. Bei einer Schwachstelle kommen ein etwa bekannter böswilliger Akteur und das Sicherheitsupdate hinzu, bei einem Sicherheitsvorfall die wahrscheinliche Art der Bedrohung oder die Grundursache sowie die angewandten und laufenden Abhilfemaßnahmen.

MELDEBOGEN NACH ARTIKEL 14 CRA

Produkt, betroffene Versionen: ..................................
Typ:          [ ] Aktiv ausgenutzte Schwachstelle
              [ ] Schwerwiegender Sicherheitsvorfall
Kenntnis am:  Datum/Uhrzeit (UTC) ...... Quelle .................
Entschieden von: Name, Funktion .................................
Mitgliedstaaten, in denen das Produkt verfügbar ist: ............

Frühwarnung fällig (Kenntnis + 24 h): ...........................
  Vorfall: rechtswidrige oder böswillige Handlung vermutet? J / N
Meldung fällig (Kenntnis + 72 h): ...............................
  Art der Ausnutzung oder des Vorfalls, ergriffene Maßnahmen,
  Maßnahmen für Nutzer, Sensibilität der Informationen
Abschlussbericht fällig: ........................................
  Schwachstelle: 14 Tage nach Verfügbarkeit von Korrektur oder
    Abhilfemaßnahme
  Vorfall: ein Monat nach der Meldung
  Beschreibung, Schweregrad, Auswirkungen, Akteur oder
  Grundursache, Sicherheitsupdate

Nutzer informiert (Art. 14 Abs. 8): Datum ..... Kanal ...........
  maschinenlesbares Format? J / N

Wer erhält CRA-Meldungen zu Schwachstellen?

Sie melden einmal, über die einheitliche Meldeplattform, die die ENISA nach Artikel 16 betreibt. Die ENISA hat die Plattform am 11. September 2026 mit ihrer anfänglichen Betriebsfähigkeit gestartet. Jede Meldung geht gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA.

Dieses CSIRT sitzt im Mitgliedstaat Ihrer Hauptniederlassung, also dort, wo die Entscheidungen über die Cybersicherheit Ihrer Produkte überwiegend getroffen werden. Ohne Niederlassung in der EU legt Artikel 14 Absatz 7 eine Rangfolge fest: Bevollmächtigter, dann Einführer, dann Händler, jeweils nach Anzahl der Produkte, dann der Mitgliedstaat mit den meisten Nutzern. Es sind dieselben CSIRTs, die nach NIS2 die Offenlegung von Schwachstellen koordinieren, wie im Beitrag zum NIS2-Rahmen für die Offenlegung von Schwachstellen beschrieben.

Das empfangende CSIRT leitet die Meldung an die CSIRTs der Mitgliedstaaten weiter, in denen das Produkt nach Ihren Angaben verfügbar ist. Unter außergewöhnlichen Umständen, insbesondere auf Ihren Antrag, kann es dies aus gerechtfertigten Gründen der Cybersicherheit aufschieben, jedoch nicht länger als unbedingt erforderlich (Artikel 16 Absatz 2).

Aus der FAQ der ENISA:

• Jede Person, die Meldungen einreicht, braucht ein Konto bei EU Login mit Multi-Faktor-Authentifizierung und muss sich als benannter Vertreter registrieren.
• Die ENISA empfiehlt, sich zu registrieren, wenn Sie melden müssen; die Validierung läuft parallel und blockiert eine erste Meldung nicht.
• Ist die Plattform ausgefallen, warten Sie und reichen Sie die Meldung ein, sobald sie wieder verfügbar ist. Wenn Sie früher kommunizieren müssen, können Sie sich direkt an Ihr CSIRT wenden, müssen die Meldung aber trotzdem auf der Plattform einreichen.

Müssen Sie Ihre Nutzer informieren?

Ja. Artikel 14 Absatz 8 verpflichtet Sie, die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den Sicherheitsvorfall zu informieren und, falls erforderlich, über Maßnahmen, die sie zur Abschwächung ergreifen können. Nutzen Sie dafür gegebenenfalls ein strukturiertes, maschinenlesbares Format. Informieren Sie sie nicht rechtzeitig, können die CSIRTs, denen Sie gemeldet haben, dies übernehmen.

Wer ist Hersteller, und welche Produkte fallen darunter?

Hersteller ist, wer Produkte mit digitalen Elementen entwickelt oder herstellt oder herstellen lässt und sie unter eigenem Namen oder eigener Marke vermarktet, sei es entgeltlich, zur Monetarisierung oder unentgeltlich (Artikel 3 Nummer 13). Ein Produkt mit digitalen Elementen ist Software oder Hardware samt ihren Datenfernverarbeitungslösungen, einschließlich separat verkaufter Komponenten, sofern die bestimmungsgemäße oder vorhersehbare Verwendung eine Datenverbindung zu einem Gerät oder Netz einschließt (Artikel 2 Absatz 1 und Artikel 3 Nummer 1).

Das reicht weiter als Softwareanbieter: ein vernetzter Sensor, eine industrielle Steuerung, ein Router, eingebettete Firmware, das Cloud-Backend, ohne das ein Gerät nicht funktioniert. Reines SaaS fällt in der Regel nicht darunter: Erwägungsgrund 12 nimmt Cloud-Dienste, die außerhalb der Verantwortung eines Herstellers entwickelt werden, vom CRA aus und hält fest, dass NIS2 SaaS abdeckt. Ausgenommen sind Produkte, die unter die EU-Vorschriften über Medizinprodukte, In-vitro-Diagnostika, die Typgenehmigung von Kraftfahrzeugen, zertifizierte Erzeugnisse der Zivilluftfahrt und Schiffsausrüstung fallen, sowie Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung hergestellt werden.

Zum zeitlichen Ablauf:

• Produkte, die bereits auf dem Markt sind, sind erfasst. Artikel 69 Absatz 3 wendet Artikel 14 auf alle Produkte an, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Ein 2023 verkaufter Router fällt darunter.
• Der Rest des CRA folgt später. Grundlegende Anforderungen, Konformitätsbewertung und CE-Kennzeichnung gelten ab dem 11. Dezember 2027 und erfassen ältere Produkte erst nach einer wesentlichen Änderung (Artikel 69 Absatz 2).
• Verwalter quelloffener Software melden laut Kommission ab dem 11. Dezember 2027.
• Bereits vorbei: das Inkrafttreten (10. Dezember 2024) und der Geltungsbeginn der Vorschriften über die Notifizierung von Konformitätsbewertungsstellen (11. Juni 2026).

Wie verhalten sich die CRA-Meldepflichten zur Meldung von Sicherheitsvorfällen nach NIS2?

NIS2 fragt, ob Ihre Organisation sicher ist. Der CRA fragt nach dem Produkt, das Sie verkaufen. Ein Unternehmen kann außerhalb von NIS2 und innerhalb des CRA liegen oder unter beide fallen und für ein Ereignis zwei Meldungen schulden.

	NIS2 Artikel 23	CRA Artikel 14
Wer meldet	Wesentliche und wichtige Einrichtungen	Hersteller von Produkten mit digitalen Elementen
Auslöser	Erheblicher Sicherheitsvorfall, der Ihre Dienste beeinträchtigt	Ausgenutzte Schwachstelle oder schwerwiegender Sicherheitsvorfall in Ihrem Produkt
Frühwarnung	24 Stunden	24 Stunden
Meldung	72 Stunden	72 Stunden
Abschlussbericht	Ein Monat nach der Meldung	14 Tage nach der Korrektur oder ein Monat nach der Meldung
Empfänger	CSIRT oder zuständige Behörde	Koordinierendes CSIRT und ENISA, über die Plattform

Anhang II der NIS2 führt Hersteller von Datenverarbeitungsgeräten, elektronischen und optischen Erzeugnissen, elektrischen Ausrüstungen und Maschinen auf; mittlere und größere Unternehmen fallen in den Anwendungsbereich von NIS2. In einem solchen Unternehmen kann ein kompromittierter Update-Server zugleich ein schwerwiegender Sicherheitsvorfall nach dem CRA und ein erheblicher Sicherheitsvorfall nach NIS2 sein. Legen Sie in der Praxis fest, welche Ereignisse welche Meldung auslösen, und erstellen Sie beide aus einer einzigen Vorfallsdokumentation. Die NIS2-Seite behandeln der Beitrag zu den NIS2-Meldefristen für Sicherheitsvorfälle und die Seite zur NIS2-Compliance.

Der CRA erreicht Sie auch über Ihre Kunden. Eine Einrichtung unter NIS2 muss die Qualität der Produkte ihrer unmittelbaren Anbieter und deren Verfahren für eine sichere Entwicklung berücksichtigen (Sicherheit der Lieferkette nach NIS2). Rechnen Sie in Sicherheitsfragebögen und Verträgen mit der Frage „Wie melden Sie ausgenutzte Schwachstellen?“, wie es Telekommunikationszulieferer unter NIS2 bereits erleben.

Was passiert, wenn Sie eine CRA-Frist versäumen?

Artikel 64 Absatz 2 sieht für Verstöße gegen Artikel 14 Geldbußen von bis zu 15 Mio. EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist; die Mitgliedstaaten legen die Sanktionsvorschriften fest. Nach Artikel 64 Absatz 10 Buchstabe a gelten die Geldbußen nicht für Hersteller, die Kleinstunternehmen oder kleine Unternehmen sind und die 24-Stunden-Frist für die Frühwarnung (Artikel 14 Absatz 2 Buchstabe a oder Absatz 4 Buchstabe a) versäumen, und die Zusammenfassung der Kommission versteht die Vorschrift ebenso. Der Absatz ist jedoch als Ausnahme von den Absätzen 3 bis 9 formuliert, während die Geldbuße für Artikel 14 in Absatz 2 steht; betrachten Sie die Ausnahme daher nicht als gesichert. Die 72-Stunden-Meldung und den Abschlussbericht deckt sie nie ab.

Artikel 71 zieht nur Artikel 14 und die Vorschriften über Konformitätsbewertungsstellen vor; alles andere, auch Artikel 64, gilt ab dem 11. Dezember 2027. Das betrifft den Zeitplan der Durchsetzung, nicht die Pflicht, die seit dem 11. September 2026 gilt.

Was lässt die CRA-Meldepflicht offen?

Die Meldung ist die leichtere Hälfte. Artikel 14 ist verfahrensbezogen: eine Person benennen, die richtigen Kanäle beobachten, innerhalb der Frist melden. Dazu, wie Sie überhaupt davon erfahren, sagt er nichts, und genau dort liegt das Risiko. Die Kenntnis kommt oft von außen: von einem Forscher, einem Kunden, einer Warnmeldung eines CSIRT. Eine 24-Stunden-Frist ist leicht einzuhalten, wenn Sie in Stunde null Bescheid wissen. Sie ist nicht einzuhalten, wenn Sie am neunten Tag davon erfahren, weil die Sicherheitskontaktadresse in einem Postfach landet, das niemand liest.

Die schwierigere Frage folgt nach der Meldung: Jeder Kunde fragt, wie lange die Schwachstelle bestand und ob er betroffen ist. Für die Antwort brauchen Sie ein Verzeichnis dessen, was in jeder Produktversion steckt, eine Aufstellung, welcher Kunde welche Version nutzt, und Logs Ihrer Build- und Update-Infrastruktur. Die Verordnung verlangt, dass Sie melden, was Sie wissen. Sie verschafft Ihnen kein Wissen.

Ein Teil davon wird später Pflicht. Ab dem 11. Dezember 2027 verlangt Anhang I Teil II eine Software-Stückliste, die mindestens die Abhängigkeiten der obersten Ebene abdeckt, eine Strategie zur koordinierten Offenlegung von Schwachstellen und eine Kontaktadresse für Schwachstellenmeldungen. Die heutige Meldepflicht setzt voraus, dass Sie diese bereits haben.

Die Lücke zu schließen heißt, diese Aufzeichnungen zu verbinden, sodass aus einer CVE in einer Komponente innerhalb von Stunden eine Liste betroffener Versionen und Kunden wird und eine Person entscheidet, was meldepflichtig ist. So arbeitet die CloudSoul Plattform: automatisierte Erfassung von Nachweisen aus Ihren Systemen, mit Human-in-the-Loop-Expertise. Wenn Sie nicht sicher sind, ob Ihr Release- und Schwachstellenprozess standhalten würde, sagt Ihnen ein Sicherheitsaudit das, bevor es ein Sicherheitsvorfall tut.

Checkliste zu den CRA-Meldepflichten

• Klären Sie, ob Sie Produkte mit digitalen Elementen auf dem EU-Markt in Verkehr bringen, einschließlich Produkten, die vor dem 11. September 2026 verkauft wurden.
• Benennen Sie die Person, die entscheidet, ob eine Meldung erforderlich ist, und eine Vertretung; beide müssen auch außerhalb der Geschäftszeiten erreichbar sein.
• Richten Sie für beide schon jetzt Konten bei EU Login mit Multi-Faktor-Authentifizierung ein.
• Veröffentlichen Sie eine Sicherheitskontaktadresse und stellen Sie sicher, dass sie jeden Tag jemand liest.
• Führen Sie für jede Produktversion ein Komponentenverzeichnis und gleichen Sie Schwachstellen-Feeds damit ab.
• Halten Sie für jedes Produkt Ihre Hauptniederlassung, Ihr CSIRT und die Mitgliedstaaten fest, in denen es verkauft wird.
• Bereiten Sie einen Kanal vor, um betroffene Nutzer zu informieren, gegebenenfalls in einem maschinenlesbaren Format.
• Wenn Sie auch unter NIS2 fallen, legen Sie fest, welche Ereignisse eine Meldung auslösen und welche beide.

Quellen

• Verordnung (EU) 2024/2847 (Cyberresilienzverordnung), Artikel 2, 3, 14, 15, 16, 64, 69 und 71, Anhang I und Erwägungsgründe 12, 67 und 68, EUR-Lex.
• Europäische Kommission, Cyberresilienzverordnung: Meldepflichten und Zusammenfassung des Rechtstexts.
• ENISA, Start der einheitlichen Meldeplattform des CRA und FAQ zur einheitlichen Meldeplattform.
• Richtlinie (EU) 2022/2555 (NIS2), Artikel 23 und Anhang II, EUR-Lex.

Häufige Fragen