In diesem Beitrag
Seit dem 11. September 2026 ist Artikel 14 des Cyber Resilience Act anwendbar. Viele Hersteller hatten diesen Termin nicht auf dem Schirm, weil sie sich auf den 11. Dezember 2027 eingestellt hatten, das Datum, ab dem der CRA im Übrigen gilt.
Der frühere Termin ist der unangenehmere. Er betrifft nämlich nicht nur die Produkte, die Sie künftig entwickeln, sondern alles, was heute beim Kunden läuft. Eine Steuerung von 2011 fällt genauso darunter wie eine Maschine, die nächste Woche ausgeliefert wird.
Rechtsstand: 10. September 2026. Grundlage sind die Verordnung (EU) 2024/2847, die FAQ der Europäischen Kommission zum Cyber Resilience Act in der Fassung 1.4 vom 4. September 2026, die FAQ der ENISA zur Single Reporting Platform (Stand 8. September 2026) sowie die Leitlinien C(2026) 5252 vom 27. Juli 2026. Die Kommissions-FAQ ist eine Auslegungshilfe und rechtlich nicht bindend; maßgeblich bleibt der Verordnungstext.
Der Irrtum, mit dem fast jedes Projekt anfängt
„Unsere Bestandsprodukte fallen nicht unter den CRA.“ Diesen Satz höre ich in fast jedem Erstgespräch. Er stimmt — für den größten Teil der Verordnung. Für die Meldepflicht stimmt er nicht.
Artikel 69 Absatz 2 regelt den Grundsatz:
„Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Anforderungen dieser Verordnung nur dann, wenn sie ab diesem Zeitpunkt wesentlich geändert werden.“
Absatz 3 nimmt die Meldepflicht davon ausdrücklich aus:
„Abweichend von Absatz 2 gelten die in Artikel 14 festgelegten Pflichten für alle Produkte mit digitalen Elementen, die in den Anwendungsbereich dieser Verordnung fallen und vor dem 11. Dezember 2027 in Verkehr gebracht wurden.“
Ohne Stichtag, ohne Altersgrenze, ohne Bindung an einen laufenden Supportvertrag. Die einzige Voraussetzung ist, dass das Produkt überhaupt ein Produkt mit digitalen Elementen im Sinne der Verordnung ist.
Was ab wann gilt
| Datum | Was anwendbar wird |
|---|---|
| 11. Juni 2026 | Artikel 35 bis 51: Notifizierung der Konformitätsbewertungsstellen |
| 11. September 2026 | Artikel 14 vollständig: Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle — für den gesamten Altbestand |
| 11. Dezember 2027 | Alle übrigen Pflichten: Anhang I, Artikel 13, CE-Kennzeichnung, Konformitätsbewertung, Marktüberwachung — für ab diesem Datum in Verkehr gebrachte Produkte |
| 11. Juni 2028 | Auslaufen der EU-Baumusterprüfbescheinigungen nach Artikel 69 Absatz 1 |
Melden ja. Patchen nein.
An dieser Stelle löst sich die meiste Aufregung wieder auf. In FAQ 5.3 (S. 53–54) trennt die Kommission beides ausdrücklich: Für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, gilt Artikel 14 — die Pflichten zum Vulnerability Handling nach Anhang I Teil II gelten nicht.
Die Begründung dafür liest sich wie eine Bestandsaufnahme aus jedem Maschinenbauunternehmen: Werkzeuge zum Scannen alter Softwarestände existieren nicht mehr, Build-Umgebungen für alten Code lassen sich nicht rekonstruieren, Abhängigkeiten sind nicht mehr verfügbar oder inkompatibel, und die Kollegen, die den Code kannten, sind längst woanders.
Diese Aufzählung ist die Ratio der Ausnahme, nicht ihre Bedingung. Sie müssen nicht nachweisen, dass eine Untersuchung unmöglich ist. Die Ausnahme folgt aus Artikel 69 Absätze 2 und 3, nicht aus technischer Machbarkeit. Wo eine Untersuchung oder eine Abhilfe möglich ist, ist sie gute Praxis und häufig vertraglich geschuldet — eine CRA-Pflicht nach Anhang I ist sie für ein nicht wesentlich geändertes Altprodukt nicht.
Zwei Einschränkungen gehören dazu:
Artikel 14 Absatz 8 bleibt. Die Pflicht, betroffene Nutzer zu informieren und ihnen — soweit erforderlich — Risikominderungs- und Abhilfemaßnahmen zu nennen, ist Teil von Artikel 14 und damit von der Ausnahme in Absatz 3 mitumfasst. Sie gilt für den Altbestand.
Keine Rückwirkung. Die Meldepflicht knüpft an die Kenntniserlangung ab dem 11. September 2026 an. Eine aktiv ausgenutzte Schwachstelle, von der Sie vorher schon wussten, müssen Sie nicht nachmelden. Erlangen Sie ab dem Stichtag Kenntnis, greift die Pflicht — auch wenn die Schwachstelle selbst zehn Jahre alt ist.
Was die Pflicht auslöst
Zwei Ereignisse, mit jeweils eigenem Test.
Aktiv ausgenutzte Schwachstelle. Artikel 3 Nummer 42 definiert sie als Schwachstelle, „bei der es zuverlässige Hinweise darauf gibt, dass ein böswilliger Akteur sie in einem System ohne Erlaubnis des Systemeigentümers ausgenutzt hat“. Der Zusatz ist entscheidend: Ein Zero Day ohne Patch ist nur dann meldepflichtig, wenn zuverlässige Hinweise auf eine Ausnutzung vorliegen. Ein Fund aus dem eigenen Bug-Bounty-Programm oder aus einem beauftragten Pentest ist es nicht (FAQ 5.2, S. 53).
Schwerwiegender Sicherheitsvorfall. Artikel 14 Absatz 5 definiert die Schwelle abschließend: Der Vorfall beeinträchtigt oder kann die Fähigkeit des Produkts beeinträchtigen, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen — oder er hat zur Einschleusung oder Ausführung von Schadcode im Produkt oder in den Netz- und Informationssystemen eines Nutzers geführt beziehungsweise kann dazu führen. Nicht jeder sicherheitsrelevante Vorfall ist meldepflichtig.
Eine Überwachungspflicht folgt daraus nicht. FAQ 5.1 stellt klar, dass der CRA nicht regelt, wie ein Hersteller Kenntnis erlangt, und dass die dort genannten Kanäle keine Pflicht zum Monitoring begründen. Was daraus folgt, ist trotzdem operativ: Sobald irgendjemand im Unternehmen Kenntnis hat, läuft die Frist. Der Servicetechniker im Feld ist der Anfang der Kette, nicht der Meldeverantwortliche — und die interne Eskalation muss so schnell laufen, dass von den 24 Stunden noch etwas übrig ist.
Die Fristen
Aktiv ausgenutzte Schwachstelle (Artikel 14 Absatz 2):
- Frühwarnung innerhalb von 24 Stunden ab Kenntnis, mit Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde
- Schwachstellenmeldung innerhalb von 72 Stunden: betroffenes Produkt, Art des Exploits, Art der Schwachstelle, ergriffene und für Nutzer verfügbare Abhilfemaßnahmen
- Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Abhilfe- oder Risikominderungsmaßnahme
Schwerwiegender Vorfall (Artikel 14 Absatz 4):
- Frühwarnung innerhalb von 24 Stunden, mit Angabe, ob ein rechtswidriger oder böswilliger Akt vermutet wird
- Vorfallsmeldung innerhalb von 72 Stunden mit Ersteinschätzung und Maßnahmen
- Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung
Beim Abschlussbericht für eine Schwachstelle lohnt der genaue Blick auf den Wortlaut: Die 14 Tage laufen ab Verfügbarkeit einer Maßnahme, nicht ab Kenntnis. Stellen Sie für ein Altprodukt keine Maßnahme bereit, beginnt die Frist nach dem Wortlaut nicht zu laufen. Die ENISA-SRP-FAQ 26 beschreibt den fehlenden Abschlussbericht-Zähler allgemeiner für aktiv ausgenutzte Schwachstellen, nicht speziell für Altprodukte ohne Maßnahme. Der technische 72-Stunden-Zähler läuft laut FAQ vorübergehend 48 Stunden ab Einreichung der Frühwarnung. Für die gesetzliche 72-Stunden-Frist bleibt dagegen die Kenntnis des Herstellers maßgeblich; der Portalzähler darf sie nicht ersetzen. Das ist keine Erledigung der Pflicht. Dokumentieren Sie die Entscheidung und halten Sie den Status gegenüber dem CSIRT aktiv.
Wohin gemeldet wird — und was Sie vorher einrichten müssen
Gemeldet wird über die Single Reporting Platform nach Artikel 16, erreichbar unter https://portal.cra-srp.enisa.europa.eu. Die Pflicht gilt seit dem 11. September 2026.
Der richtige Meldeweg. Nach Artikel 14 Absatz 7 melden Sie über den elektronischen Endpunkt des CSIRT, das im Mitgliedstaat Ihrer Hauptniederlassung als Koordinator benannt ist; die Meldung ist gleichzeitig für die ENISA zugänglich. Hauptniederlassung ist der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit Ihrer Produkte überwiegend getroffen werden. Für Hersteller mit Hauptniederlassung in Deutschland ist das CERT-Bund beim BSI, so gelistet von der ENISA am 4. September 2026. Die Wahl des falschen CSIRT kann die Meldung unwirksam machen.
Haben Sie keine Niederlassung in der Union, greift die Reihenfolge des Artikels 14 Absatz 7: der Bevollmächtigte mit den meisten Produkten, dann der Einführer mit den meisten Produkten, dann der Händler, dann der Mitgliedstaat mit den meisten Nutzern.
Nur eine Meldung. Für eine bestimmte aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall ist genau eine Meldung erforderlich — auch bei mehreren Standorten in der Union oder einer Muttergesellschaft außerhalb (SRP-FAQ 8). Ebenso wenig wird pro Kunde gemeldet: Gegenstand der Meldung ist die Schwachstelle beziehungsweise der Vorfall, nicht der Einzelfall beim Anwender.
Registrierung und EU Login. Meldeberechtigte authentifizieren sich mit einem persönlichen EU-Login-Konto mit Multi-Faktor-Authentifizierung. Die ENISA empfiehlt ausdrücklich, sich auf der Plattform erst dann zu registrieren, wenn eine Meldung abzugeben ist — eine Vorratsregistrierung ist nicht vorgesehen. Praktisch heißt das: Das EU-Login-Konto mit MFA muss vorher eingerichtet und die Zugangsdaten müssen außerhalb der Bürozeiten verfügbar sein, die Registrierung auf der Plattform selbst erfolgt im Ereignisfall.
Die Validierung des Meldeberechtigten durch das CSIRT ist keine Voraussetzung für die Abgabe. Die FAQ vom 3. Oktober 2026 unterscheidet Primary und Secondary Representatives und erläutert die Vertretungsrollen. Ein noch nicht validierter Vertreter kann derzeit bis zu 20 Meldungen für einen Hersteller einreichen (SRP-FAQ 9). Zuständigkeit und Vertretung sollten vor einem Vorfall organisatorisch geklärt sein. Ist die Plattform vorübergehend nicht erreichbar, warten Sie und reichen die Meldung nach der Wiederherstellung ein; ein direkter Kontakt zum CSIRT ersetzt die Meldung über die Plattform nicht (SRP-FAQ 25).
Freiwillige Meldungen nach Artikel 15 sind zum Start nicht über die Plattform möglich. Bis diese Funktion verfügbar ist, sollen entsprechende Informationen auf anderem Weg an das zuständige CSIRT gehen (SRP-FAQ 4 und 27).
Wen Sie informieren müssen
Artikel 14 Absatz 8 verlangt, dass Sie nach Kenntniserlangung „die betroffenen Nutzer des Produkts mit digitalen Elementen und gegebenenfalls alle Nutzer“ über die Schwachstelle oder den Vorfall informieren — und, soweit erforderlich, über Maßnahmen, die diese ergreifen können.
Der Verordnungstext verlangt Information, nicht Veröffentlichung. Anhang I Teil II Nummer 4 verwendet für die öffentliche Bereitstellung von Informationen über behobene Schwachstellen ein anderes Verb; Artikel 14 Absatz 8 tut das nicht. Die Leitlinien C(2026) 5252 lesen die Vorschrift in den Punkten 81 und 82 so, dass betroffene Nutzer bei bestehender direkter Beziehung unmittelbar zu informieren sind und, wo angemessen, zusätzlich alle Nutzer über eine allgemeine Bekanntmachung. Eine Veröffentlichung auf der Website allein erfüllt die Pflicht gegenüber bekannten betroffenen Kunden nicht.
Für den Altbestand zerfällt der Adressatenkreis praktisch in drei Gruppen:
- Identifizierbare Nutzer der betroffenen Firmware- und Hardwarestände. Direkt informieren, über den etablierten Kanal, dokumentiert: wer, wann, welcher Stand, was zu tun ist. Ein laufender Servicevertrag stellt den Kunden fast immer in diese Gruppe.
- Identifizierbare Nutzer anderer Stände derselben Baureihe, die nicht betroffen sind. Die Verordnung verlangt das nicht. In der Praxis teilen Sie es trotzdem mit, sonst läuft die Hotline voll.
- Nutzer, die sich aus den vorhandenen Unterlagen nicht mehr ermitteln lassen. Wo eine allgemeine Bekanntmachung angemessen ist, kann ein öffentliches Security Advisory den direkten Kontakt ergänzen. Auch noch erreichbare Händler können bei der Verteilung helfen.
Bekannter Betreiber heißt zunächst: aus den Unterlagen ermittelbar, die heute tatsächlich vorhanden und mit vertretbarem Aufwand auswertbar sind — etwa aktive Serviceverträge, offene Tickets, Rechnungen und Lieferungen, Serien- und Typenschildregister, CRM oder ERP, Händler- und OEM-Listen, Lizenzschlüssel oder Inbetriebnahmeprotokolle. Artikel 14 Absatz 8 schreibt weder bestimmte Suchsysteme noch eine feste Recherchetiefe vor. Welche Nachforschungen im Einzelfall angemessen sind, sollte deshalb anhand des Produktrisikos, der verfügbaren Daten und des Aufwands entschieden und dokumentiert werden.
Halten Sie fest, welche Quellen Sie geprüft haben, wen Sie direkt erreicht haben und für welche Typen oder Stände keine Kundendaten mehr existieren. Bei Produkten, die 15 bis 30 Jahre im Feld stehen, sind solche Lücken nicht ungewöhnlich. Die Dokumentation macht die Abwägung nachvollziehbar; sie ersetzt aber nicht die direkte Information bekannter betroffener Nutzer. Eine allgemeine Bekanntmachung kommt ergänzend hinzu, wenn sie nach Reichweite und Risiko angemessen ist.
Die stille Falle: Weiterbau des Altdesigns
Diese Stelle wird im Altbestand am häufigsten übersehen, und sie hat mit Meldepflichten nichts zu tun.
Der CRA gilt für einzelne Produkte, nicht für Produkttypen. FAQ 7.2 (S. 64) ist unmissverständlich: Nur einzelne Exemplare, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, sind ausgenommen. Produkte, die nach einem nicht CRA-konformen Typ gefertigt werden, dürfen ab dem 11. Dezember 2027 nicht in Verkehr gebracht werden — auch dann nicht, wenn das erste Exemplar dieses Typs vorher auf dem Markt war.
Konkret:
- Einheiten, die bereits im Markt sind, bleiben unberührt. Händler dürfen sie weiter bereitstellen (FAQ 7.5, S. 66).
- Jede weitere vollständige Einheit desselben Altdesigns, die Sie ab dem 11. Dezember 2027 in Verkehr bringen, ist ein neues Produkt im Anwendungsbereich — einschließlich Austauschgeräten, die als komplette Einheit verkauft werden.
- Ersatzteile bleiben außen vor, soweit sie identische Komponenten ersetzen und nach denselben Spezifikationen gefertigt sind (Artikel 2 Absatz 6).
Daraus folgt eine kaufmännische Entscheidung, keine technische: ein End-of-Sale-Datum für Neueinheiten des Altdesigns — oder das Design bis dahin auf Anhang-I-Niveau bringen.
Fremdkomponenten: keiner meldet für Sie
Die Meldepflicht wird nicht durchgereicht. Enthält Ihr Produkt eine aktiv ausgenutzte Schwachstelle, die aus einer integrierten Komponente stammt, melden Sie — und der Hersteller der Komponente meldet ebenfalls, sofern die Komponente selbst in Verkehr gebracht wurde (FAQ 5.4, S. 54–55). Dass Ihr Lieferant gemeldet hat, entlastet Sie nicht.
Der einzige legitime Filter gegen unbegrenztes Meldevolumen aus der Lieferkette ist die Bewertung der Ausnutzbarkeit im integrierten Produkt: Ist die Schwachstelle in Ihrem Produkt nicht ausnutzbar, ist sie nicht aktiv ausgenutzt und damit nicht meldepflichtig. Eine freiwillige Meldung nach Artikel 15 bleibt möglich.
Diese Bewertung setzt voraus, dass Sie wissen, welche Komponenten in welchem Produkt stecken — also eine SBOM, auch für Altprodukte, für die die Verordnung selbst keine verlangt. Die Meldepflicht ohne diese Kenntnis zu erfüllen, ist Raten.
Die Pflicht, die Schwachstelle an den Hersteller oder Verwalter der Komponente zu melden (Artikel 13 Absatz 6), ist eine Herstellerpflicht aus Artikel 13. Für ein vor dem 11. Dezember 2027 in Verkehr gebrachtes und nicht wesentlich geändertes Produkt gilt Artikel 13 nicht (Artikel 69 Absatz 2). Artikel 14 gilt trotzdem.
Was jetzt zu tun ist
| # | Maßnahme | Verantwortung |
|---|---|---|
| 1 | Meldeverfahren nach Artikel 14 dokumentiert: 24-Stunden- und 72-Stunden-Schritt, 14-Tage-Abschlussbericht für Schwachstellen, Ein-Monats-Abschlussbericht für Vorfälle | Security, Recht |
| 2 | Interne Eskalation vom Servicetechniker zum Meldeverantwortlichen, inklusive Rufbereitschaft außerhalb der Bürozeiten | Serviceleitung |
| 3 | EU Login mit MFA eingerichtet, koordinierendes CSIRT nach Artikel 14 Absatz 7 bestimmt, Registrierung auf der Plattform im Meldefall vorbereitet | Meldeverantwortlicher |
| 4 | Schriftliches Kriterium für „aktiv ausgenutzt“, das Bug-Bounty- und Testfunde abgrenzt | Security |
| 5 | Prozess zur Nutzerinformation nach Artikel 14 Absatz 8, mit Advisory-Vorlage und Verteilerliste | Service, Marketing |
| 6 | Bestandsdaten zusammengetragen, soweit vorhanden, mit dokumentierten Lücken | Service |
| 7 | Ausnutzbarkeitsbewertung für Komponentenschwachstellen als definierter Prozessschritt | Entwicklung |
Die drei Sätze, die in Projekten am häufigsten fallen und am zuverlässigsten falsch sind:
„Altbestand ist außerhalb des CRA.“ Für Artikel 14 unzutreffend, für alles andere zutreffend.
„Wenn wir melden müssen, müssen wir auch patchen.“ Für vor dem 11. Dezember 2027 in Verkehr gebrachte Produkte unzutreffend; die Kommission trennt beides in FAQ 5.3 ausdrücklich.
„Unser Lieferant hat gemeldet, also sind wir abgedeckt.“ Unzutreffend; jeder integrierende Hersteller meldet im eigenen Namen.
Sie wollen Ihren Altbestand vor dem Ernstfall sortiert haben? Ich prüfe mit Ihnen, welche Produkte im Anwendungsbereich liegen, wie Ihre Eskalationskette die 24 Stunden hält und wie die Nutzerinformation nach Artikel 14 Absatz 8 aussehen muss. Nehmen Sie Kontakt auf — TPC Security, Leipheim, für Maschinenbau und Industrieautomation in Ulm, Günzburg, Augsburg und bundesweit.
Weitere Einordnung finden Sie auf meiner Leistungsseite zu CRA und Maschinenverordnung sowie in den Beiträgen zum Cyber Resilience Act und zur DIN EN 40000 für CRA-Hersteller.