Regulatorik

Cyber Resilience Act umsetzen: Pflichten, Fristen, Nachweise

Der Cyber Resilience Act macht Cybersicherheit zur Bedingung für den Marktzugang. Er gilt als Verordnung unmittelbar, ohne nationales Umsetzungsgesetz, und er trifft nicht den Betreiber, sondern den Hersteller eines Produkts mit digitalen Elementen. Diese Seite ordnet die Pflichten, die Stichtage und die Abgrenzung zu NIS-2 und ISO 27001.

Person prüft mit einer Lupe ein Produkt, darüber ein grünes Prüfsiegel, daneben Platine und Klemmbrett

Die Stichtage, und was an ihnen fällig wird

Der CRA ist am 10. Dezember 2024 in Kraft getreten und wird über gestaffelte Termine wirksam. Seit dem 11. September 2026 gelten die Meldepflichten der Hersteller. Die Vollanwendung folgt am 11. Dezember 2027.

11. Juni 2026

Vorschriften zur Notifizierung der Konformitätsbewertungsstellen

Seitdem baut sich die Landschaft notifizierter Stellen auf. Wer eine Drittprüfung braucht, sollte die Verfügbarkeit früh klären statt kurz vor dem Marktstart.

11. September 2026

Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle

Seit diesem Tag ist die 24-Stunden-Frühwarnung Pflicht. Sie ist faktisch ein Krisenprozess und läuft auch nachts und am Wochenende. Wer Schwellen, Rollen und Freigabe erst im Vorfall klärt, reißt die Frist.

11. Dezember 2027

Vollanwendung mit Konformitätsbewertung und CE-Kennzeichnung

Ab hier entscheidet die Konformität über den rechtmäßigen Marktzugang. Sie entsteht aus Security-by-Design, laufender Schwachstellenbehandlung und mitwachsender technischer Dokumentation und lässt sich nicht nachholen.

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen grundsätzlich erst bei einer wesentlichen Änderung unter die vollen Pflichten. Die Meldepflichten wirken jedoch auch für bereits bereitgestellte Produkte.

Zwei Säulen, die oft verwechselt werden

Der CRA verlangt Produkteigenschaften und Lebenszykluspflichten. Beide stehen in Anhang I, und beide werden in der Praxis unterschiedlich schlecht erfüllt.

Produkteigenschaften (Anhang I, Teil I)

Auf Grundlage der Risikobewertung nach Artikel 13 Absatz 2: ohne bekannte ausnutzbare Schwachstellen und mit sicherer Standardkonfiguration bereitstellen, Schwachstellen über Sicherheitsaktualisierungen behebbar machen, unbefugten Zugriff kontrollieren und melden. Wo automatische Sicherheitsaktualisierungen vorgesehen sind, verlangt Anhang I Teil I Nummer 2 Buchstabe c, dass sie als Standardeinstellung installiert werden, einen klaren Opt-out haben und von den Nutzern vorübergehend verschoben werden können. Das ist Engineering-Arbeit am Produkt.

Schwachstellenbehandlung (Anhang I, Teil II)

Komponenten und Schwachstellen identifizieren und dokumentieren, unter anderem durch eine SBOM in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Unverzüglich beheben, regelmäßig testen, eine CVD-Policy führen und Updates über den festgelegten Unterstützungszeitraum bereitstellen. Sicherheitsupdates sind unverzüglich und grundsätzlich kostenlos zu verbreiten; abweichende Vereinbarungen sind auf maßgeschneiderte Produkte für Geschäftsnutzer beschränkt. Behobene Schwachstellen sind grundsätzlich öffentlich zu beschreiben, wobei die Offenlegung aufgeschoben werden darf, bis die Nutzer den Patch anwenden konnten. Das ist eine Dauerpflicht, kein Projekt.

Der Unterstützungszeitraum ist keine Empfehlung und kein Richtwert. Nach Artikel 13 Absatz 8 Unterabsatz 3 beträgt er mindestens fünf Jahre; nur eine kürzere voraussichtliche Nutzungsdauer tritt an die Stelle dieses Minimums. Die Festlegung ist zudem gebunden: Unterabsatz 2 verlangt, dass sie die voraussichtliche Nutzung widerspiegelt und dabei den Erwartungen der Nutzer und der Art des Produkts Rechnung trägt. Bereitgestellte Sicherheitsupdates bleiben nach Artikel 13 Absatz 9 mindestens zehn Jahre oder für den verbleibenden Unterstützungszeitraum verfügbar, je nachdem, was länger ist. Technische Dokumentation und EU-Konformitätserklärung sind nach Artikel 13 Absatz 13 mindestens zehn Jahre oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, welcher Zeitraum länger ist. Und er ist keine interne Größe: Nach Artikel 13 Absatz 19 muss das Enddatum zum Zeitpunkt des Kaufs leicht zugänglich, klar und verständlich angegeben werden, mindestens mit Monat und Jahr. Soweit technisch machbar, ist den Nutzern zusätzlich anzuzeigen, dass das Ende erreicht ist.

Davon zu trennen ist die Meldepflicht. Schwachstellenbehandlung ist eine Dauerpflicht, die Meldung eine Ereignispflicht. Beide sollten dieselbe PSIRT-Funktion bedienen, aber sie sind verschiedene Prozesse.

SBOM: was verlangt wird, und was nicht

Die Software-Stückliste ist unter dem CRA keine gute Praxis mehr, sondern Teil der Schwachstellenbehandlung nach Anhang I Teil II. Sie ist die Datengrundlage für die Frage, die im Ernstfall in Minuten zu beantworten ist: Steckt die gemeldete Komponente in einem unserer Produkte, und in welcher Version.

Zu unterscheiden sind drei Dinge, die oft in einen Topf geraten. Erstellen ist Pflicht: nach Anhang I Teil II Nummer 1 in einem gängigen maschinenlesbaren Format, mindestens über die obersten Abhängigkeiten. Dokumentieren ebenfalls: Anhang VII Nummer 2 Buchstabe b führt die SBOM in der technischen Dokumentation, und Nummer 8 verlangt sie zusätzlich auf begründetes Verlangen der Marktüberwachungsbehörde, soweit diese sie zur Prüfung der grundlegenden Anforderungen braucht. Veröffentlichen ist dagegen keine Pflicht: Erwägungsgrund 77 stellt ausdrücklich fest, dass Hersteller nicht verpflichtet sein sollten, die SBOM zu veröffentlichen. Wer sie Kunden freiwillig zugänglich macht, muss nach Anhang II Nummer 9 nur angeben, wo sie zu finden ist.

Praktisch trägt nur eine SBOM, die aus der Build-Pipeline entsteht und versioniert mitläuft. Eine einmal erstellte Liste ist am Tag der nächsten Auslieferung falsch. Als nationale Orientierungshilfe kann die BSI TR-03183 dienen, Teil 2 behandelt die SBOM. Sie ist frei zugänglich, aber nicht rechtsverbindlich und begründet keine Konformitätsvermutung.

Die Meldekette, mit den Fristen aus Artikel 14

Gemeldet wird GLEICHZEITIG an das als Koordinator benannte CSIRT und an die ENISA, über die einheitliche Meldeplattform nach Artikel 16. Nicht an eine Stelle, die die andere weiterreicht. Zwei Auslöser: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts betreffen.

24 StundenFrühwarnung, unverzüglich und in jedem Fall innerhalb von 24 Stunden, nachdem der Hersteller Kenntnis erlangt hat. Knapp, aber nicht inhaltsleer: bei Schwachstellen sind die Mitgliedstaaten anzugeben, in deren Hoheitsgebiet das Produkt seiner Kenntnis nach bereitgestellt wurde, bei Vorfällen zumindest, ob der Verdacht auf eine rechtswidrige oder böswillige Handlung besteht, und gegebenenfalls ebenfalls diese Mitgliedstaaten.
72 StundenMeldung, unverzüglich und in jedem Fall innerhalb von 72 Stunden nach Kenntnis, mit Angaben zum betroffenen Produkt, zur Art der Ausnutzung oder des Vorfalls und zu ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
14 TageAbschlussbericht bei einer aktiv ausgenutzten Schwachstelle, spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht.
ein MonatAbschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Neben der Meldung an die Behörden verlangt Artikel 14 Absatz 8, die betroffenen Nutzer und gegebenenfalls alle Nutzer über den Vorfall oder die Schwachstelle zu informieren, erforderlichenfalls samt Risikominderungs- und Korrekturmaßnahmen, die sie selbst ergreifen können, und gegebenenfalls in einem strukturierten, maschinenlesbaren Format. Die Meldung an das CSIRT ersetzt diese Information nicht. Bleibt sie aus, dürfen die als Koordinatoren benannten CSIRTs die Nutzer selbst unterrichten.

Ein Unternehmen kann gleichzeitig Hersteller nach CRA und Betreiber nach NIS-2 sein, im Finanzsektor zusätzlich unter DORA fallen. Die Pflichten überlagern sich, sie ersetzen einander nicht. Ohne klare Abgrenzung entsteht entweder eine Doppelmeldung mit widersprüchlichen Inhalten oder eine Meldelücke, weil sich alle Beteiligten auf das jeweils andere Regime verlassen.

Deckt unser ISO-27001-Zertifikat den CRA ab?

Nein, und die Trennlinie ist klar zu ziehen: zwischen Prozess und Produkt, zwischen Managementsystem und Produktrecht. Die Rahmen verzahnen sich, statt sich zu ersetzen.

Frage	CRA	NIS-2	ISO 27001
Wen verpflichtet es?	Den Hersteller eines Produkts mit digitalen Elementen	Den Betreiber, als besonders wichtige oder wichtige Einrichtung	Die Organisation, die sich zertifizieren lässt
Was ist der Gegenstand?	Die Eigenschaften und Lebenszykluspflichten eines Produkts	Das Risikomanagement einer Organisation	Das Managementsystem der Informationssicherheit
Wie gilt es?	Verordnung, unmittelbar in allen Mitgliedstaaten	Richtlinie, national umgesetzt (in Deutschland im BSIG)	Freiwillige Norm, wirksam über Zertifikat und Vertrag
Wie wird die Erfüllung nachgewiesen?	Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung, gestuft nach Produktklasse	Gegenüber der Aufsichtsbehörde, national geregelt	Zertifikat einer Zertifizierungsstelle, mit wiederkehrenden Audits

Was prozessual erprobt ist, trägt die produktrechtlichen Pflichten des CRA. Es ersetzt sie nicht. Neu am CRA sind vor allem die Bindung an das Inverkehrbringen, die Konformitätsbewertung mit EU-Konformitätserklärung und CE-Kennzeichnung, ein definierter Unterstützungszeitraum, die verpflichtende SBOM und gesetzliche Meldefristen für Produkt-Schwachstellen.

Die Produktklasse steuert die Prüfstrenge

Wie streng geprüft wird, hängt nicht vom Risiko im Allgemeinen ab, sondern von der Klasse, in die ein Produkt fällt. Wer sie zu spät bestimmt, riskiert, dass eine verpflichtende Drittprüfung den Marktstart blockiert.

Standardprodukt
In der Regel Selbstbewertung über die interne Kontrolle (Modul A).
Wichtiges Produkt, Klasse I (Anhang III)
Betriebssysteme zählen dazu. Selbstbewertung ist nur zulässig, wenn einschlägige harmonisierte Normen, gemeinsame Spezifikationen oder ein nach Artikel 27 Absatz 9 ausgewiesenes europäisches Zertifizierungsschema mit einem Zertifikat mindestens der Vertrauenswürdigkeitsstufe „mittel" vollständig angewendet werden. Sonst ist eine Drittprüfung durch eine notifizierte Stelle nötig.
Wichtiges Produkt, Klasse II (Anhang III)
Firewalls sowie Intrusion-Detection- und Intrusion-Prevention-Systeme zählen dazu. Die Drittprüfung ist verpflichtend, soweit nicht ein solches Zertifizierungsschema verfügbar und anwendbar ist. Eine Ausnahme kennt Artikel 32 Absatz 5: Hersteller von Produkten aus Anhang III, die als freie und quelloffene Software gelten, dürfen auch das Verfahren nach Absatz 1 nutzen, wenn die technische Dokumentation beim Inverkehrbringen öffentlich zugänglich ist.
Kritisches Produkt (Anhang IV)
Eigene, strengere Anforderungen an den Nachweis.

Klassifiziert wird seit dem 28. November 2025 anhand der Anhänge III und IV des CRA IN VERBINDUNG MIT der Durchführungsverordnung (EU) 2025/2392, die deren Kategorien verbindlich anhand ihrer Kernfunktion beschreibt. Die Durchführungsverordnung klassifiziert keine einzelnen Produkte; welche Klasse ein konkretes Produkt trifft, ist im Einzelfall an beiden Rechtsakten zu prüfen.

Was OdySecure dazu beiträgt, und was nicht

Was die Plattform trägt

Das Managementsystem, in dem die CRA-Pflichten als Anforderungen geführt werden: Verantwortliche, Fristen, Wiedervorlagen und der Nachweis, wer wann was entschieden hat.
Die Gap-Analyse gegen die wesentlichen Anforderungen aus Anhang I, im Assessment-Modul gegen einen hinterlegten Katalog statt gegen eine Tabelle.
Die Nachweisführung für die technische Dokumentation: Belege an der Anforderung, mit Quelle und Stand, exportierbar für die Konformitätsbewertung.
Die Verzahnung mit NIS-2 und ISO 27001 auf einer Datenbasis, damit dieselbe Maßnahme nicht dreimal dokumentiert wird.

Was die Plattform ausdrücklich nicht ist

Kein SBOM-Generator. Die Stückliste entsteht in Ihrer Build-Pipeline, nicht in einem Managementsystem.
Kein PSIRT und kein Schwachstellenscanner. Die Analyse einer gemeldeten Schwachstelle bleibt bei Ihrem Produktteam.
Kein Ersatz für die Konformitätsbewertung. Ob eine Drittprüfung nötig ist, entscheidet die Produktklasse, nicht ein Werkzeug.

Wir liefern die fachliche Einordnung. Die rechtsverbindliche Feststellung, ob und wie der CRA ein bestimmtes Produkt trifft, bleibt einer Kanzlei vorbehalten.

Das ISMS-Modul ansehen Standards und Regulatorik im Katalog

Die Grundlagen im Detail

Diese Seite ordnet ein. Die Herleitung mit Fundstellen steht in unserer Wissenssektion.

Wo stehen Ihre Produkte?

Im Beratungsgespräch ordnen wir Ihren Anwendungsbereich fachlich ein: welche Produkte betroffen sind, in welche Klasse sie fallen und welche Lücken zwischen dem heutigen Stand und dem rechtmäßigen Marktzugang liegen. Ohne eigenen CISO organisiert ein vCISO Ihre Meldekette und führt die Nachweise in OdySecure. Die Plattform ist im Mandat enthalten, ab 3.600 €/Monat.

Kostenloses Beratungsgespräch

Häufige Fragen

Wen trifft der Cyber Resilience Act?

Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden, dazu Importeure und Händler mit eigenen Pflichten. Wer ein Produkt wesentlich verändert, kann selbst als Hersteller gelten. Anders als NIS-2 knüpft der CRA nicht an Sektor und Unternehmensgröße an, sondern an das Produkt.

Ab wann gelten die CRA-Meldepflichten?

Seit dem 11. September 2026. Zu melden sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts betreffen, gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA. Die Frühwarnung ist unverzüglich und in jedem Fall innerhalb von 24 Stunden nach Kenntnis fällig. Daneben sind nach Artikel 14 Absatz 8 die betroffenen Nutzer und gegebenenfalls alle Nutzer zu informieren.

Ist eine SBOM Pflicht, und muss sie veröffentlicht werden?

Erstellen ja: Anhang I Teil II Nummer 1 verlangt eine SBOM in einem gängigen maschinenlesbaren Format, mindestens über die obersten Abhängigkeiten. Sie gehört nach Anhang VII in die technische Dokumentation und ist der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen, soweit diese sie zur Prüfung braucht. Eine Pflicht zur Veröffentlichung folgt daraus nicht.

Deckt ein ISO-27001-Zertifikat den CRA ab?

Nein. ISO 27001 beschreibt das Managementsystem einer Organisation, der CRA regelt Eigenschaften und Lebenszykluspflichten eines Produkts. Ein erprobtes Managementsystem trägt die CRA-Pflichten, es ersetzt sie nicht. Neu sind vor allem Konformitätsbewertung, CE-Kennzeichnung, Unterstützungszeitraum, SBOM und gesetzliche Meldefristen.

Ist Open-Source vom CRA ausgenommen?

Nicht pauschal, und die verbreitete Kurzfassung ist falsch: Wer Open-Source-Komponenten einbaut, wird dadurch nicht zum Hersteller der Komponente. Hersteller ist, wer ein Produkt entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet. Für das Gesamtprodukt trägt dieser Hersteller die Pflichten, einschließlich der Sorgfaltspflicht für integrierte Drittkomponenten. Bei nicht monetarisierter freier Software liegt in der Regel keine Geschäftstätigkeit vor. Daneben kennt der CRA die eigene Rolle des Open-Source-Verwalters mit eigenen Pflichten.

Ist die CE-Kennzeichnung beim CRA nur eine Formalität?

Nein. Sie ist eine rechtsverbindliche Herstellererklärung, dass das Produkt die wesentlichen Anforderungen erfüllt. Die Nachweisform ist gestuft: Sie hängt von der Produktklasse ab und davon, ob harmonisierte Normen angewendet werden. Eine pauschale Zertifizierung gibt es nicht.

Wann sollte ein Hersteller mit der Umsetzung beginnen?

Jetzt, und zwar mit Inventar und Klassifizierung. Konformität entsteht aus Security-by-Design, laufender Schwachstellenbehandlung und mitwachsender Dokumentation. Das ist kein Projekt mit Abgabetermin, sondern ein Regelkreis je Produktlinie, und er lässt sich vor dem Stichtag nicht nachholen.