CRA Meldepflichten: Was Hersteller ab September 2026 melden müssen

Der Cyber Resilience Act (CRA) gilt vollständig erst ab dem 11. Dezember 2027, aber Artikel 14 greift 15 Monate früher. Diese frühe Anwendbarkeit ist kein Zufall: Regulatoren wollen schnell Transparenz über Schwachstellen in Produkten, die bereits auf dem Markt sind. Während CE-Kennzeichnung, technische Dokumentation und die meisten Annex-I-Anforderungen bis Ende 2027 Zeit haben, müssen Hersteller den Meldeprozess für Schwachstellen und Vorfälle bereits ab September 2026 nachweisbar aufgebaut haben.

Dieser Artikel richtet sich an Hersteller von Produkten mit digitalen Elementen, insbesondere an Maschinenbauer und Industrieunternehmen, die Firmware oder vernetzte Steuerungseinheiten ausliefern. Er setzt Grundkenntnisse des CRA voraus; einen kompakten Einstieg bietet unser Artikel: Was kommt auf Maschinenbauer zu?. Hier geht es um die konkreten operativen Fragen: Was löst eine Meldepflicht aus? Wer meldet? Wohin? Innerhalb welcher Fristen? Und wie lässt sich der Prozess bis September 2026 aufbauen?

Was muss gemeldet werden?

Artikel 14 Absatz 1 und 2 definiert zwei unabhängige Meldepflichten. Die erste betrifft aktiv ausgenutzte Schwachstellen (Exploited Vulnerabilities): Artikel 3 CRA definiert das präzise. Es müssen verlässliche Nachweise vorliegen, dass ein böswilliger Akteur die Schwachstelle in einem System ohne Zustimmung des Systemeigentümers ausgenutzt hat. In der Praxis bedeutet das konkret: Ein Alert aus dem Security Information and Event Management (SIEM) System allein reicht nicht. Verlässliche Nachweise liefern etablierte externe Quellen wie der CISA KEV-Katalog oder die ENISA EUVD, ein Threat-Intelligence-Feed mit technischen Indikatoren, oder eine eigene forensische Analyse, die eine tatsächliche Ausnutzung belegt. Gerüchte, Proof-of-Concept-Exploits ohne Nachweis realer Angriffe oder unbestätigte Meldungen aus Foren erfüllen den Schwellenwert nicht. Und das Beweiserfordernis gilt unabhängig davon, ob bereits ein Patch vorliegt. Die zweite betrifft schwerwiegende Sicherheitsvorfälle (Severe Security Incidents): Vorfälle mit erheblicher Auswirkung auf die Sicherheit des Produkts, etwa unautorisierter Zugriff, Datenverlust oder die Unterbrechung einer sicherheitskritischen Produktfunktion.

Ein wichtiger Punkt ist die Abgrenzung zum allgemeinen Vulnerability Management: Nicht jede bekannte Schwachstelle löst eine Sofortmeldung nach Artikel 14 aus. Bekannte CVEs ohne nachgewiesene aktive Ausnutzung fallen unter die kontinuierlichen Anforderungen aus Annex I, Teil II des CRA. Wer diese Anforderungen noch nicht im Detail kennt, schaut in unseren Artikel: Schwachstellenbehandlung nach Annex I.

Den Mindestinhalt der einzelnen Meldestufen legen Artikel 14 Absatz 2 (Schwachstellen) und Absatz 4 (Vorfälle) fest. Artikel 14 Absatz 8 regelt dagegen die separate Pflicht, betroffene Nutzer des Produkts zu informieren. Die Meldung erfolgt parallel zur Behördenmeldung und nicht als Teil davon.

Wer muss melden?

Die primäre Meldepflicht liegt beim Hersteller. Er meldet direkt an ENISA, sobald er Kenntnis von einem der oben genannten Auslöser erlangt. Importeure und Händler haben keine eigene direkte Meldepflicht an ENISA, sind aber verpflichtet, den Hersteller unverzüglich zu informieren, wenn sie von einer ausgenutzten Schwachstelle oder einem Vorfall erfahren. Ein eigener ENISA-Report ist von Importeur oder Händler nur dann notwendig, wenn der Hersteller nicht erreichbar oder nicht kooperativ ist.

Der CRA führt mit Artikel 24 außerdem die Kategorie der Verwalter quelloffener Software (Open-Source Stewards) ein. Artikel 24 Absatz 3 schreibt vor, dass die Meldepflicht für aktiv ausgenutzte Schwachstellen nach Artikel 14 Absatz 1 für sie gilt, soweit sie an der Entwicklung der betroffenen Produkte beteiligt sind. Die Meldepflicht für schwerwiegende Sicherheitsvorfälle nach Artikel 14 Absatz 3 gilt für sie, wenn solche Vorfälle die Netz- und Informationssysteme beeinträchtigen, die sie für die Produktentwicklung bereitstellen.

Für Maschinenbauer ist die Einordnung meistens klar: Wer ein Produkt mit digitaler Komponente entwickelt und in der EU in Verkehr bringt, ist Hersteller im Sinne des CRA, auch wenn das Kerngeschäft mechanische Fertigung ist. Intern sollte jetzt die Frage geklärt werden, wer die Meldung verantwortet: Product Owner, CISO oder Compliance-Beauftragter. Diese Zuständigkeit muss vor dem ersten Ernstfall stehen.

Eine Ausnahme gilt für Produkte, die unter sektorspezifische Unionsregulierung fallen – darunter Medizinprodukte (MDR/IVDR), Luftfahrtprodukte (EU 2018/1139) oder bestimmte Fahrzeugsysteme (EU 2019/2144). Für diese gilt der CRA explizit nicht. Das betrifft eine Minderheit der Maschinenbaubranche, ist aber relevant, wenn ein Hersteller parallel zu Standardmaschinen auch Produkte in einem dieser regulierten Bereiche entwickelt.

Wohin wird gemeldet?

Die im CRA vorgesehene Meldestelle ist die ENISA Single Reporting Platform (SRP), die laut Verordnung vor dem 11. September 2026 betriebsbereit sein muss. Das Prinzip ist bewusst als One-stop-shop ausgelegt: Der Hersteller gibt die Meldung einmal auf der SRP ein, und die Plattform übernimmt die Weiterleitung. Die SRP leitet die Meldung dann unverzüglich an die zuständigen nationalen CSIRTs und, falls das Produkt in mehreren EU-Ländern verbreitet ist, an weitere betroffene CSIRTs (Computer Security Incident Response Teams) weiter. In Deutschland ist das BSI das gemäß § 3 BSIG benannte nationale CSIRT und zugleich die vorgesehene Marktüberwachungsbehörde für den CRA.

Was gilt, wenn die SRP am 11. September 2026 noch nicht verfügbar ist? Die Meldepflicht aus Artikel 14 entfällt nicht, weil die Plattform fehlt. Die SRP ist das technische Mittel zur Erfüllung der Pflicht, nicht ihre Voraussetzung. Das BSI weist selbst darauf hin, dass die Meldepflicht unabhängig vom Bereitstellungsstand der Plattform gilt. Solange die SRP nicht operativ ist, ist davon auszugehen, dass Hersteller über die nationalen Meldekanäle des BSI melden müssen und die Übergangskommunikation von ENISA und BSI aktiv beobachten sollten. Auf „die Plattform war noch nicht verfügbar” werden sich Marktüberwachungsbehörden nicht einlassen.

Davon zu unterscheiden ist die ENISA European Vulnerability Database (EUVD), die seit Juni 2025 operativ ist. Die EUVD ist keine Meldeplattform, sondern eine öffentliche Schwachstellendatenbank, die Informationen aus nationalen CSIRTs, Herstellermeldungen und dem CVE-Programm aggregiert. Für Hersteller ist sie als Monitoring-Quelle relevant: Wenn eine eigene Komponente in der EUVD als aktiv ausgenutzt erscheint, ist das ein direkter Auslöser für Artikel 14.

Die drei Meldestufen und ihre Fristen

Artikel 14 schreibt für beide Meldearten ein dreistufiges Verfahren vor, das dem Muster aus NIS2 ähnelt. Die ersten beiden Stufen sind für ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle identisch aufgebaut; der Abschlussbericht folgt unterschiedlichen Fristen und Inhalten.

Aktiv ausgenutzte Schwachstellen (Art. 14 Abs. 2)

Schwerwiegende Sicherheitsvorfälle (Art. 14 Abs. 4)

Die Fristen beginnen ab dem Zeitpunkt, zu dem der Hersteller Kenntnis erlangt hat, nicht ab der Entdeckung durch Dritte oder der Veröffentlichung in einer Datenbank. Hier liegt eine der größten praktischen Herausforderungen für Industrieunternehmen: In vielen Betrieben gibt es keine 24/7-Überwachungsfunktion. Wer empfängt eine Meldung an einem Samstagabend, und wer trifft die erste Einschätzung innerhalb von 24 Stunden?

Intern braucht es deshalb eine klare Definition, was “Kenntnis erlangt” bedeutet, und die Dokumentation dieses Zeitpunkts ist die Grundlage für den Nachweis, dass die Fristen eingehalten wurden. Welche Konsequenzen Fristversäumnisse haben können, beschreibt unser Artikel: Der CRA und seine Sanktionen.

CRA vs. NIS2

Viele Industrieunternehmen sind bereits von der NIS2-Richtlinie betroffen und haben Meldeprozesse für Sicherheitsvorfälle aufgebaut. Eine häufige Fehleinschätzung ist die Annahme, bestehende NIS2-Meldeprozesse deckten auch die CRA-Anforderungen ab. Die beiden Regelwerke unterscheiden sich in Adressat, Gegenstand und Meldestelle grundlegend.

NIS2 ist eine Betreiberpflicht und fragt: Was ist mit dem eigenen Dienst oder der eigenen Einrichtung passiert? CRA Artikel 14 ist eine Herstellerpflicht und fragt: Was ist mit dem Produkt passiert? Ein Maschinenbauer, der kritische Infrastruktur beliefert und selbst als KRITIS-Betreiber eingestuft ist, kann unter beide Pflichten gleichzeitig fallen. In diesem Fall sind zwei getrennte Meldeprozesse notwendig, die aber Schnittstellen haben sollten: Wer im Betrieb einen Vorfall erkennt, muss prüfen, ob dadurch auch ein Produktereignis im Sinne von Artikel 14 ausgelöst wurde. Eine vollständige Übersicht über die NIS2-Pflichten bietet die NIS2-Richtlinie (EU) 2022/2555.

Praktische Vorbereitung

Vier operative Bausteine müssen bis September 2026 vorhanden sein.

Vulnerability Monitoring

Die Grundlage für jede Meldung ist zu wissen, was im Produkt steckt. Eine aktuelle SBOM je Produktversion, automatisch abgeglichen gegen den CISA Known Exploited Vulnerabilities Catalog und die ENISA EUVD, ist der automatisierbare Kern des Monitorings. Beide Quellen sind kostenfrei und maschinenlesbar. Wenn eine Komponente in diesen Katalogen als aktiv ausgenutzt erscheint, ist das der Auslöser nach Artikel 14. Wie eine SBOM erstellt wird, zeigt unser Artikel Governance: Software Bill of Materials (SBOM). Auf die Besonderheiten und Herausforderungen für Embedded Systeme und PLC-Umgebungen gehen wir im Artikel SBOM für Embedded Systeme ein.

Interner Meldeprozess

Ein interner Eskalationsprozess klärt die Fragen, die im Ernstfall keine Zeit mehr haben: Wer erkennt einen potenziellen Auslöser? Wer bewertet, ob aktive Ausnutzung vorliegt? Wer initiiert die Meldung über die ENISA SRP? Und wer ist erreichbar, wenn das außerhalb der Geschäftszeiten passiert? Der Zeitpunkt der Kenntniserlangung muss schriftlich dokumentiert werden, da er die Fristen auslöst. Eine interne Definition, wann ein Produkt als betroffen gilt, verhindert Unklarheiten im Ernstfall.

Meldevorlagen und SRP-Zugang

Für jede der drei Meldungsstufen (Early Warning, Intermediate Report, Final Report) sollte eine vorbereitete Vorlage existieren, die im Ernstfall nur noch mit produktspezifischen Daten gefüllt wird. Sobald die ENISA SRP für Registrierungen geöffnet ist, lohnt es sich, Zugangsdaten einzurichten und das Formular vorab durchzuspielen. Außerdem muss geklärt sein, wer die Zeichnungsbefugnis für ENISA-Meldungen hat.

Dry Run

Ein Prozesstest vor dem Ernstfall ist der sicherste Weg, Lücken zu finden. Spiel einen fiktiven Vorfall durch (Tabletop Exercise): Eine Komponente erscheint am Montagmorgen im KEV-Katalog als aktiv ausgenutzt. Kannst du die Early Warning bis Dienstagmorgen einreichen? Hast du alle notwendigen Informationen für den Intermediate Report nach 72 Stunden? Das Ergebnis dieser Übung dokumentierst du als Nachweis eines funktionierenden Meldeprozesses.

Kurzcheckliste für den Aufbau des Meldeprozesses bis September 2026:

• SBOM je Produktversion erstellt und versioniert
• Automatisiertes Monitoring gegen CISA KEV und ENISA EUVD eingerichtet
• Zuständigkeiten intern geklärt (Erkennung, Bewertung, Meldung)
• Erreichbarkeit außerhalb der Geschäftszeiten geregelt
• Definition von “Kenntnis erlangt” schriftlich festgelegt und dokumentiert
• Zugangsdaten ENISA SRP eingerichtet (sobald Registrierung möglich)
• Meldevorlagen für Early Warning, Intermediate Report und Final Report vorbereitet
• Tabletop Exercise durchgeführt und Ergebnis dokumentiert

Jetzt anfangen, bevor der erste Ernstfall eintritt

Artikel 14 ist kein Vorlauf auf 2027, sondern eine eigenständige Pflicht, die ab September 2026 gilt. Die Kernaussagen auf einen Blick: aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle im Produkt über die ENISA SRP melden, in drei Stufen innerhalb von 24 Stunden, 72 Stunden und 14 Tagen. Einen separaten Report an das BSI oder andere nationale Behörden braucht es nach aktuellem Stand nicht. Und eine bestehende NIS2-Meldepflicht ersetzt die CRA-Anforderungen nicht, auch wenn ein Unternehmen beides ist: Betreiber und Hersteller.

Der Meldeprozess ist einer der besser abgrenzbaren Bausteine der CRA-Vorbereitung. Er baut auf einem funktionierenden Vulnerability Monitoring auf, braucht klare interne Zuständigkeiten und einen getesteten Ablauf. Wer damit jetzt anfängt, hat die Zeit für einen geordneten Aufbau. Wer wartet, bis der erste echte Vorfall eintritt, baut den Prozess unter Druck.

Wie steht dein Unternehmen beim Thema Vulnerability Monitoring und Incident-Meldeprozess? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.