11. Juni 2026
Vorschriften zur Notifizierung der Konformitätsbewertungsstellen
Erst ab hier 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.
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.
Der CRA ist am 10. Dezember 2024 in Kraft getreten und wird über gestaffelte Termine wirksam. Der nächste ist der wichtigste, weil er einen Prozess verlangt, den man nicht am Stichtag erfindet.
11. Juni 2026
Vorschriften zur Notifizierung der Konformitätsbewertungsstellen
Erst ab hier 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
Die 24-Stunden-Frühwarnung ist faktisch ein Krisenprozess. Sie 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.
Der CRA verlangt Produkteigenschaften und Lebenszykluspflichten. Beide stehen in Anhang I, und beide werden in der Praxis unterschiedlich schlecht erfüllt.
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.
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.
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.
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.
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.
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.
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.
Wir liefern die fachliche Einordnung. Die rechtsverbindliche Feststellung, ob und wie der CRA ein bestimmtes Produkt trifft, bleibt einer Kanzlei vorbehalten.
Diese Seite ordnet ein. Die Herleitung mit Fundstellen steht in unserer Wissenssektion.
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.
Kostenloses BeratungsgesprächHersteller 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 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.
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.
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.
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.
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.
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.