Dieser Artikel wurde erstmals am 28.04.2026 veröffentlicht und am 13.10.2026 auf Basis des zu diesem Zeitpunkt bekannten Rechts- und Informationsstands aktualisiert.
Die meisten Produktpflichten des Cyber Resilience Act (CRA) gelten ab dem 11. Dezember 2027. Die Meldepflichten nach Artikel 14 gelten jedoch bereits seit dem 11. September 2026. Hersteller müssen seitdem aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die ENISA Single Reporting Platform melden. Die Pflicht kann auch Produkte betreffen, die bereits vor dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wurden.
Dieser Beitrag richtet sich an Hersteller von Produkten mit digitalen Elementen, insbesondere an Maschinenbauer und Industrieunternehmen, die Firmware oder vernetzte Steuerungseinheiten ausliefern. Einen kompakten CRA-Einstieg bietet unser Artikel: Was kommt auf Maschinenbauer zu?. Hier geht es um die operative Umsetzung: Was löst eine Meldung aus, wer meldet, wohin und innerhalb welcher Fristen?
Artikel 14 unterscheidet zwei meldepflichtige Ereignisse: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Für Schwachstellen regelt Absatz 2 das Meldeverfahren; für Sicherheitsvorfälle gelten die Absätze 3 bis 5.
Eine aktiv ausgenutzte Schwachstelle (actively exploited vulnerability) liegt vor, wenn verlässliche Nachweise zeigen, dass ein Angreifer sie in einem System ohne Zustimmung des Systemeigentümers ausgenutzt hat. Ein Alert aus einem Security Information and Event Management (SIEM) System allein belegt das nicht. Ein Eintrag im CISA KEV-Katalog, in der ENISA EUVD, ein Threat-Intelligence-Feed oder eine forensische Analyse kann belastbare Hinweise liefern. Diese müssen zum betroffenen Produkt und zur ausgelieferten Version passen; ein Katalogtreffer allein bestätigt nicht automatisch, dass das eigene Produkt betroffen ist. Die Meldung hängt nicht davon ab, ob bereits ein Patch verfügbar ist.
Ein schwerwiegender Sicherheitsvorfall (severe incident) liegt nach Artikel 14 Absatz 5 vor, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit wichtiger Daten oder Funktionen zu schützen. Auch die Ausführung oder mögliche Ausführung von Schadcode kann darunterfallen. Beispiele wie unautorisierter Zugriff oder Datenverlust sind deshalb anhand dieser gesetzlichen Kriterien im Einzelfall zu bewerten.
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.
| Kategorie | Auslöser | Praxisbeispiel Maschinenbau | Meldepflicht nach Art. 14 |
|---|---|---|---|
| Aktiv ausgenutzte Schwachstelle | Schwachstelle wird von Angreifer ausgenutzt | Firmware-Lücke in einer SPS wird in freier Wildbahn ausgenutzt | Ja |
| Schwerwiegender Sicherheitsvorfall | Erhebliche Auswirkung auf Produktsicherheit | Unautorisierter Zugriff auf ein vernetztes Steuergerät | Ja |
| Bekannte Schwachstelle (nicht ausgenutzt) | CVE ohne Nachweis aktiver Ausnutzung | Bekannte Library-Schwachstelle, kein aktiver Exploit bekannt | Nicht allein deshalb; weiter Vulnerability Management |
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.
Die Meldepflicht nach Artikel 14 liegt beim Hersteller. Er reicht die Meldung über die ENISA Single Reporting Platform (SRP) beim zuständigen koordinierenden CSIRT ein; die Meldung wird gleichzeitig ENISA bereitgestellt.
Importeure und Händler werden nicht allein durch ihre Rolle zu Meldepflichtigen nach Artikel 14. Sie müssen den Hersteller über bekannt gewordene Risiken informieren und ihre eigenen Pflichten nach den Artikeln 19 und 20 erfüllen. Die Kriterien in Artikel 14 Absatz 7 bestimmen, welches CSIRT die Meldung koordiniert, wenn der Hersteller keine Hauptniederlassung in der EU hat; sie begründen keine allgemeine Pflicht zur Ersatzmeldung, nur weil ein Hersteller nicht reagiert. Übernimmt ein Importeur oder Händler selbst die Herstellerrolle, etwa durch eigenes Branding oder eine wesentliche Änderung, gelten für ihn die Herstellerpflichten.
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.
| Rolle | Meldepflicht nach Art. 14 | Weitere Pflicht |
|---|---|---|
| Hersteller | Ja, über SRP an koordinierendes CSIRT | ENISA erhält Meldung gleichzeitig |
| Importeur | Nicht allein aufgrund der Importeurrolle | Hersteller informieren; Pflichten nach Art. 19 erfüllen |
| Händler | Nicht allein aufgrund der Händlerrolle | Hersteller informieren; Pflichten nach Art. 20 erfüllen |
| Open-Source Steward | Ab 11.12.2027, im Rahmen von Art. 24(3) | Eigene Meldeprozesse für erfasste Produkte |
Die Meldepflichten für Open-Source Stewards beginnen am 11. Dezember 2027. Sie gelten nur im Umfang des Artikels 24 Absatz 3: für aktiv ausgenutzte Schwachstellen, soweit der Steward an der Entwicklung des betroffenen Produkts beteiligt ist, und für schwerwiegende Vorfälle, wenn sie die vom Steward für die Produktentwicklung bereitgestellten Netz- und Informationssysteme betreffen.
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.
Die ENISA Single Reporting Platform (SRP) ist seit dem 11. September 2026 in Betrieb. Hersteller reichen die Meldung einmal ein und wählen das koordinierende CSIRT. Zuständig ist grundsätzlich das CSIRT des Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung hat; für andere Konstellationen gelten die Kriterien aus Artikel 14 Absatz 7.
Die Meldung wird gleichzeitig ENISA bereitgestellt. Das koordinierende CSIRT teilt sie mit den zuständigen CSIRTs weiterer Mitgliedstaaten, in denen das Produkt verfügbar ist, und kann relevante Informationen an Marktüberwachungsbehörden weitergeben. Unter den in Artikel 16 Absatz 2 geregelten Ausnahmebedingungen kann die Weitergabe verzögert werden. Für Hersteller mit Hauptniederlassung in Deutschland nennt das BSI CERT-Bund als koordinierendes CSIRT.
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 eine Monitoring-Quelle: Ein Eintrag zu einer eigenen Komponente ist ein Anlass, Produktversion und tatsächliche Betroffenheit zu prüfen. Erst wenn die Schwachstelle im eigenen Produkt enthalten und aktiv ausgenutzt ist, ist Artikel 14 zu bewerten.
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.
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.
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.
| Kriterium | NIS2 | CRA Artikel 14 |
|---|---|---|
| Adressat | Betreiber wesentlicher und wichtiger Einrichtungen | Hersteller von Produkten mit digitalen Elementen |
| Was wird gemeldet? | Vorfälle mit Auswirkung auf den eigenen Betrieb | Schwachstellen und Vorfälle im Produkt selbst |
| Meldestelle | Nationales CSIRT (BSI) direkt | ENISA SRP |
| Final Report Frist | 1 Monat | 14 Tage nach Patch (Schwachstelle) / 1 Monat nach 72h-Meldung (Vorfall) |
| Ziel | Resilienz kritischer Infrastrukturen | Sicherheit von Produkten im Markt |
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.
Vier operative Bausteine helfen, die laufenden Meldepflichten verlässlich einzuhalten.
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 ein Anlass, betroffene Produktversionen und die Anwendbarkeit von Artikel 14 zu prüfen. 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.
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.
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. Die ENISA SRP ist bereits verfügbar. Richte den Zugang für die meldeberechtigten Personen ein und prüfe den Ablauf anhand der aktuellen ENISA-Anleitungen und FAQs. Außerdem muss geklärt sein, wer die Zeichnungsbefugnis für ENISA-Meldungen hat.
Ein Prozesstest vor dem Ernstfall hilft, Lücken zu finden; eine Tabletop-Übung ist dabei eine praktische Empfehlung, keine eigene Meldepflicht nach Artikel 14. Spiel einen fiktiven Vorfall durch: 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? Dokumentiere Ergebnisse und Verbesserungsmaßnahmen als internen Nachweis des getesteten Ablaufs.
Praktische Checkliste für laufende Artikel-14-Prozesse:
Artikel 14 gilt seit dem 11. September 2026. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle werden über die ENISA SRP gemeldet: Frühwarnung binnen 24 Stunden, weitere Meldung binnen 72 Stunden. Der Abschlussbericht folgt je nach Fall spätestens 14 Tage nach verfügbarer Abhilfe oder innerhalb eines Monats nach der 72-Stunden-Meldung.
Die CRA-Meldung wird einmal über die SRP an das koordinierende CSIRT übermittelt und gleichzeitig ENISA bereitgestellt. Das ersetzt keine separaten Meldepflichten nach NIS2 oder anderen anwendbaren Vorschriften.
Ein verlässlicher Prozess braucht Vulnerability Monitoring, klare Zuständigkeiten und einen getesteten Ablauf. Regelmäßige Übungen und aktuelle Produkt- und Versionsdaten erleichtern eine fristgerechte Bewertung, wenn ein möglicher Meldefall eintritt.
Wie steht dein Unternehmen beim Thema Vulnerability Monitoring und Incident-Meldeprozess? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.
Weitere Artikel zu ähnlichen Themen.
