Von Redaktion codAIx | 8. Juni 2026

Viele Softwarehersteller starten mit der Annahme, sie könnten ihre CRA-Konformität selbst bewerten. Für Produkte der Standardkategorie stimmt das in aller Regel; Ausnahmen beim Verfahren gelten etwa für Hochrisiko-KI und EHR-Systeme (dazu unten). Bei wichtigen oder kritischen Produkten kann eine notifizierte Stelle jedoch zwingend werden — und dann verändern sich Kosten, Zeitplan und Dokumentation erheblich. Welcher Weg offensteht, hängt zunächst von der Klassifizierung des Produkts ab.

Quellenhierarchie für die Konformitätsbewertung (Stand: 11. Oktober 2026)

  • Verbindlich: der CRA (Verordnung (EU) 2024/2847)[1] und die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 mit den technischen Beschreibungen der Produktkategorien nach Anhang III und IV[2].
  • Auslegung, unverbindlich: die Kommissions-Guidance C(2026) 5252 vom 27.07.2026[3] und die FAQ der Kommissionsdienststellen v1.4[4]. Sie erläutern die verbindlichen Rechtsakte, können sie aber weder ergänzen noch ersetzen.
  • Harmonisierte Normen: Bis zum 11. Oktober 2026 war keine Fundstelle einer CRA-harmonisierten Norm im Amtsblatt veröffentlicht; erst die Veröffentlichung begründet die Konformitätsvermutung (Art. 27 Abs. 1 CRA). Zum Zeitplan siehe Abschnitt „Klassifizierung“.
  • Orientierungshilfen, unverbindlich: die BSI TR-03183-H für Modul H als nationale Konkretisierung[5] und das ENISA Secure by Design and Default Playbook[6].
  • Bei Widerspruch zwischen EU- und nationaler Ebene geht das EU-Recht vor.

Der Konformitätsbewertungsprozess nach Art. 32 CRA

Der Cyber Resilience Act schreibt vor, dass jedes Produkt mit digitalen Elementen einer Konformitätsbewertung unterzogen werden muss, bevor es auf dem EU-Markt vertrieben wird. Diese Bewertung soll nachweisen, dass Ihr Produkt die grundlegenden Cybersicherheitsanforderungen aus Anhang I erfüllt (vgl. Teil 3: Abgestufte CRA-Pflichten).

Artikel 32 Abs. 1 CRA nennt vier alternative Wege zur Konformitätsbewertung[1]:

  • (a) Modul A — Interne Kontrolle (Selbstbewertung)
  • (b) Modul B+C — EU-Baumusterprüfung kombiniert mit Konformität auf Basis interner Fertigungskontrolle
  • (c) Modul H — Umfassende Qualitätssicherung
  • (d) Europäisches Cybersicherheitszertifizierungsschema nach Art. 27 Abs. 9 CRA in Verbindung mit der Verordnung (EU) 2019/881 (Cybersecurity Act)[7] — als gleichwertige Option zu den NLF-Modulen, sofern ein Schema verfügbar und anwendbar ist. Verfügbar wird ein Schema erst, wenn die Kommission es durch einen delegierten Rechtsakt nach Art. 27 Abs. 9 CRA für den CRA ausweist; ein solcher Rechtsakt war bis zum 11. Oktober 2026 nicht erlassen (zur EUCC siehe Abschnitt „Artikel 32 im Überblick“). Die Schema-Option ist deshalb derzeit nicht verfügbar; wo sie im Folgenden genannt ist, gilt dieser Vorbehalt.

Die Module A, B, C und H sind in Anhang VIII des CRA beschrieben; sie entstammen ihrerseits dem Beschluss Nr. 768/2008/EG (New Legislative Framework)[8]. Die Module D, E, F und G sind in der CRA nicht vorgesehen. Die vier Wege unterscheiden sich grundlegend darin, ob der Hersteller die Bewertung selbst durchführt, eine notifizierte Stelle einbindet oder ein europäisches Cybersicherheitszertifizierungsschema nach Art. 27 Abs. 9 CRA nutzt.

Klassifizierung: Wann ist ein Produkt „wichtig“ oder „kritisch“?

Die Einteilung in Produktkategorien ist der entscheidende Schritt zur Bestimmung, welches Modul erforderlich ist. Massgeblich sind dafür Anhang III CRA (wichtige Produkte mit digitalen Elementen, Klassen I und II) und Anhang IV CRA (kritische Produkte mit digitalen Elementen) — konkretisiert durch die Durchführungsverordnung (EU) 2025/2392 der Kommission vom 28. November 2025, die für jede der dort gelisteten Kategorien eine technische Beschreibung liefert[2]. Wer heute eine Klassifizierung vornimmt, kommt an der Durchführungsverordnung (EU) 2025/2392 nicht vorbei: Sie ist die zentrale Auslegungsquelle für die Frage „Bin ich Klasse I, Klasse II oder kritisch?“

Anhang III CRA: Wichtige Produkte mit digitalen Elementen

Anhang III listet Produktkategorien auf, die für die Cybersicherheit von erhöhter Bedeutung sind. Die Liste ist in zwei Klassen unterteilt; die Verordnung selbst spricht von „Klasse I“ und „Klasse II“.

Klasse I: Beispielhaft (Auszug aus Anhang III) — Identitätsmanagementsysteme einschliesslich Software und Hardware für die Verwaltung privilegierter Zugänge, eigenständige und eingebettete Browser, Passwort-Manager, Software für die Suche, Entfernung und Quarantäne von Schadsoftware (Antivirus), Produkte mit VPN-Funktion, Netzmanagementsysteme, SIEM-Systeme, Bootmanager, Public-Key-Infrastrukturen, physische und virtuelle Netzschnittstellen, Betriebssysteme, Router, Modems und Switches sowie Mikroprozessoren und Mikrocontroller mit sicherheitsrelevanten Funktionen. Leicht übersehen werden im Consumer- und Gebäudetechnik-Umfeld die Nummern 16 bis 19 des Anhang III: virtuelle Assistenten für die intelligente häusliche Umgebung mit allgemeinem Zweck, Smart-Home-Produkte mit Sicherheitsfunktionen, etwa Türschlösser, Sicherheitskameras, Babyphone und Alarmanlagen, vernetztes Spielzeug mit Funktionen zur sozialen Interaktion oder Ortung sowie am Körper tragbare Produkte zur Gesundheitsüberwachung ausserhalb der Medizinprodukte-Verordnungen oder für Kinder.

Für Klasse-I-Produkte erlaubt Art. 32 Abs. 2 die Selbstbewertung über Modul A nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema mindestens der Vertrauenswürdigkeitsstufe „mittel“ nach Art. 27 Abs. 9 CRA vollständig angewendet werden. Andernfalls verengen sich die zulässigen Verfahren auf Modul B+C oder Modul H (so auch NK-CRA/Hessel Art. 32 Rn. 22)[9].

Genau hier wirkt sich der Normungszeitplan aus: Solange für die betreffende Produktkategorie keine einschlägige harmonisierte Norm im Amtsblatt veröffentlicht ist, lässt sich die Voraussetzung „vollständige Anwendung“ nicht erfüllen. Massgeblich ist, ob die angewandte Norm alle Risiken der Kernfunktion abdeckt (Guidance Rn. 149)[3]; die Konformitätsvermutung entsteht erst mit der Veröffentlichung der Fundstelle im Amtsblatt, nicht bereits mit der Verabschiedung durch die Normungsorganisationen (Art. 27 Abs. 1 CRA). Nach dem Normungsauftrag M/606 an CEN, CENELEC und ETSI sollten die horizontalen Normen zu Konzeption, Entwicklung und Herstellung sowie zur Schwachstellenbehandlung bis zum 30.08.2026 verabschiedet werden, die produktspezifischen (vertikalen) Normen für die Kategorien der Anhänge III und IV bis zum 30.10.2026 (FAQ Nr. 6.10)[4]. Ein noch nicht angenommener Entwurf zur Änderung des Normungsauftrags sieht eine Verschiebung auf den 31. Oktober 2026 für horizontale und den 31. Dezember 2026 für vertikale Normen vor (Einzelheiten in Teil 7 zur SBOM). Die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I ist erst bis zum 30.10.2027 geplant, also rund sechs Wochen vor Geltungsbeginn. Ob eine vertikale Norm ohne die horizontale Norm im Einzelfall genügt, hängt von ihrem Zuschnitt ab. Unberührt bleibt der Open-Source-Pfad nach Art. 32 Abs. 5 CRA (siehe Modul A).

Klasse II: Anhang III nennt hier abschliessend vier Nummern — (1) Hypervisoren und Container-Runtime-Systeme, (2) Firewalls/Intrusion-Detection-Systeme/Intrusion-Prevention-Systeme, (3) manipulationssichere Mikroprozessoren sowie (4) manipulationssichere Mikrocontroller.

Für Klasse-II-Produkte ist nach Art. 32 Abs. 3 immer eines der folgenden Verfahren erforderlich: Modul B+C, Modul H oder — sofern verfügbar und anwendbar — ein europäisches Cybersicherheitszertifizierungsschema nach Art. 27 Abs. 9 CRA mindestens auf Vertrauenswürdigkeitsstufe „mittel“ — es sei denn, es greift die Open-Source-Ausnahme des Art. 32 Abs. 5 CRA mit öffentlich zugänglicher technischer Dokumentation. Da die Schema-Option derzeit nicht verfügbar ist (siehe oben), verbleiben Modul B+C oder Modul H.

Anhang IV CRA: Kritische Produkte mit digitalen Elementen

Anhang IV ist deutlich kürzer und enthält besonders sicherheitskritische Produktkategorien:

  • Hardwaregeräte mit Sicherheitsboxen (Anhang IV Nr. 1; im englischen Wortlaut „hardware devices with security boxes“ — verwandt mit, aber nicht deckungsgleich mit Hardware-Sicherheitsmodulen i. e. S.)
  • Smart-Meter-Gateways in intelligenten Messsystemen sowie andere Geräte für fortgeschrittene Sicherheitszwecke einschliesslich der sicheren Kryptoverarbeitung
  • Chipkarten oder ähnliche Geräte einschliesslich Sicherheitselemente

Die BSI TR-03183-1 fasst diese Kategorie in Kap. 3.8.4 praxisnäher als Hardware-Sicherheitsmodule, Smart-Meter-Gateways, Smart Cards und Secure Elements zusammen[5] — eine hilfreiche Orientierung, die den Wortlaut des Anhang IV allerdings nicht ersetzt.

Für kritische Produkte kann die Kommission nach Art. 8 Abs. 1 CRA die Verwendung eines europäischen Cybersicherheitszertifizierungsschemas vorschreiben. Ein solcher delegierter Rechtsakt ist bislang nicht erlassen; bis dahin gelten nach Art. 8 Abs. 1 UAbs. 2 CRA die Verfahren des Art. 32 Abs. 3. Da auch die Schema-Option nach Art. 27 Abs. 9 nicht verfügbar ist (siehe oben), verbleiben derzeit Modul B+C oder Modul H.

Die Durchführungsverordnung (EU) 2025/2392

Die Durchführungsverordnung (EU) 2025/2392 definiert beispielsweise, wann eine Software als „Browser“ oder als „Passwort-Manager“ gilt — eine Unterscheidung, die für die Einordnung nach Art. 32 entscheidend ist.

Praktisch zu beachten: Die technische Beschreibung bezieht sich auf die Kernfunktionalität des Produkts, nicht auf Nebenfeatures. Eine Anwendung mit eingebettetem Browser ist darum nicht automatisch ein „Browser-Produkt“ unter der CRA, solange das nicht ihre Kernfunktion ist. Die veröffentlichte Guidance der EU-Kommission erläutert diesen Massstab in Kapitel 6.1 (Rn. 139–142)[3]: Massgeblich sind die Hauptmerkmale und technischen Fähigkeiten, ohne die das Produkt seinen bestimmungsgemässen Zweck nicht erfüllen könnte; zusätzliche (ancillary) Funktionen ändern die Einordnung nicht, solange sie die Kernfunktionalität nur ergänzen — ebenso wenig, wie ein Smartphone mit Betriebssystem dadurch zum „Betriebssystem-Produkt“ wird. Hessel zieht im NK-CRA dieselbe Linie und stützt sie auf die Erwägungsgründe 2 und 3 der Durchführungsverordnung (EU) 2025/2392: Massgeblich ist die Kernfunktion des Gesamtprodukts, und dem Verordnungsgeber war bewusst, dass Hersteller regelmässig Komponenten einbauen, die für sich genommen wichtige oder kritische Produkte sein können. Ein Produkt, das die Funktionen einer Anhang-III- oder Anhang-IV-Kategorie zwar ausüben kann, dessen Kernfunktionen davon aber abweichen, unterliegt den strengeren Voraussetzungen des Art. 32 Abs. 2 bis 5 CRA nicht (NK-CRA/Hessel Art. 32 Rn. 23–26)[9].

Die vier Konformitätsbewertungsmodule der CRA

Aus Sicht des Herstellers stehen folgende Modul-Optionen zur Verfügung (zusätzlich zur Schema-Option nach Art. 32 Abs. 1 lit. d CRA):

Modul A: Interne Kontrolle (Selbstbewertung)

Anwendung: Standardprodukte ohne Klassifizierung als wichtig oder kritisch; daneben Klasse I bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas nach Art. 27 Abs. 9 CRA mindestens der Stufe „mittel“ sowie freie und quelloffene Software der Klassen I und II mit öffentlicher technischer Dokumentation.

Externe Beteiligung: Keine

Aufwand: Mittel bis gering

Modul A ermöglicht es dem Hersteller, die Konformität in Eigenverantwortung zu bewerten. Anhang VIII Teil I beschreibt es als das Verfahren, mit dem der Hersteller „auf eigene Verantwortung erklärt, dass die Produkte mit digitalen Elementen allen grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I genügen und dass der Hersteller die grundlegenden Cybersicherheitsanforderungen in Anhang I Teil II erfüllt“.

Konkret dokumentiert der Hersteller:

  • die Umsetzung der produktbezogenen Cybersicherheitsanforderungen (Anhang I Teil I) in der Produktentwicklung
  • die Etablierung der organisatorischen Pflichten zur Schwachstellenbehandlung (Anhang I Teil II)
  • die durchgeführten Tests, Überprüfungen und Risikobewertungen
  • die technische Dokumentation gemäss Anhang VII

Praktische Bedeutung: Modul A ist das häufigste Verfahren für Softwarehersteller, deren Produkte nicht in Anhang III oder IV fallen. Die BSI TR-03183-1 beziffert diese Standardkategorie in Kap. 3.8.1 unter Verweis auf ein Briefing des Wissenschaftlichen Dienstes des Europäischen Parlaments auf eine Grössenordnung von rund 90 Prozent aller Produkte mit digitalen Elementen[5]. Die Eigenverantwortung reduziert externe Kosten, verlangt aber eine nachvollziehbare interne Dokumentation (dazu unten „Modul A in der Praxis“).

Der Open-Source-Pfad nach Art. 32 Abs. 5 CRA: Modul A ist nicht auf Standardprodukte und auf Klasse I unter vollständig angewandten harmonisierten Normen beschränkt. Nach Art. 32 Abs. 5 CRA können Hersteller von Produkten, die als freie und quelloffene Software gelten und in die Kategorien des Anhang III fallen, die Konformität über eines der Verfahren nach Art. 32 Abs. 1 — und damit auch über Modul A — nachweisen, sofern die technische Dokumentation nach Art. 31 zum Zeitpunkt des Inverkehrbringens öffentlich zugänglich gemacht wird. Die FAQ der Kommissionsdienststellen bestätigt dies in Nr. 6.1 ausdrücklich für wichtige Produkte der Klasse I und der Klasse II[4]; Nr. 6.6 hält die Kehrseite fest: Eine Veröffentlichungspflicht für die technische Dokumentation besteht sonst nicht — sie ist der Preis für die Selbstbewertung. Für einen Open-Source-Hersteller etwa eines Hypervisors, einer Container-Runtime, einer Firewall oder eines Angriffserkennungssystems (Klasse II) ist Modul B+C oder H daher nicht zwingend. Worin der eigentliche Vorteil dieses Pfades liegt, arbeitet Hessel im NK-CRA heraus: Der Hersteller kann jedes der in Art. 32 Abs. 1 CRA genannten Verfahren wählen, und zwar auch dann, wenn keine harmonisierten Normen oder gemeinsamen Spezifikationen angewandt werden — bei Klasse I ist gerade deren Anwendung sonst Voraussetzung für Modul A (NK-CRA/Hessel Art. 32 Rn. 35)[9].

Unterstützungszeitraum: auch bei Modul A keine Kür. Art. 13 Abs. 8 CRA verpflichtet Hersteller, einen Unterstützungszeitraum festzulegen, der die voraussichtliche Nutzungsdauer widerspiegelt. Er beträgt grundsätzlich mindestens fünf Jahre; beträgt die voraussichtliche Nutzungsdauer weniger als fünf Jahre, entspricht der Unterstützungszeitraum dieser kürzeren Dauer. Während dieses Zeitraums sind Schwachstellen nach Anhang I Teil II zu behandeln, insbesondere durch Sicherheitsaktualisierungen. Das Enddatum, mindestens Monat und Jahr, ist nach Art. 13 Abs. 19 CRA beim Kauf anzugeben (dazu ausführlich Artikel 3: Abgestufte CRA-Pflichten). Erwägungsgrund 60 und die Guidance, Rn. 125–127, stellen klar, dass für langlebige Hard- und Software sowie Industriesteuerungen längere Zeiträume erforderlich sein können[1][3]; zu Festlegung und Dokumentation des Unterstützungszeitraums Wiebe, § 6 Rn. 25–28[10]. Diese Verpflichtung verkettet sich unmittelbar mit der technischen Dokumentation nach Anhang VII: Wer den Unterstützungszeitraum in der Produktdokumentation ausweist, muss organisatorisch nachweisen, dass Build-Pipelines, Distributionskanäle und Schwachstellenmanagement diesen Zeitraum operativ tragen. Die Modul-A-Selbstbewertung greift zu kurz, wenn der Lifecycle-Plan diesen Punkt nur deklarativ adressiert.

Modul B: EU-Baumusterprüfung

Anwendung: Element eines kombinierten Verfahrens (B+C); allein nicht ausreichend

Externe Beteiligung: Notifizierte Stelle prüft das Baumuster und die Verfahren zur Schwachstellenbehandlung

Aufwand: Hoch

Bei Modul B prüft eine notifizierte Stelle die technische Konzeption und Entwicklung eines Produkts mit digitalen Elementen sowie die vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen. Sie bescheinigt anschliessend, dass das Baumuster den grundlegenden Cybersicherheitsanforderungen genügt und stellt eine EU-Baumusterprüfbescheinigung aus. Modul B ist nach Art. 32 CRA nicht eigenständig wählbar; es muss immer mit Modul C kombiniert werden.

Modul C: Konformität mit dem Baumuster auf Basis interner Fertigungskontrolle

Anwendung: Folgeschritt zu Modul B

Externe Beteiligung: Keine zusätzliche Bewertungsstelle für die Serienfertigung

Aufwand: Kontinuierlich, mittel

Auf die Baumusterprüfung nach Modul B folgt Modul C. Der Hersteller stellt dabei sicher und erklärt, dass jede produzierte Einheit dem in der EU-Baumusterprüfbescheinigung beschriebenen Baumuster entspricht und die grundlegenden Cybersicherheitsanforderungen weiter erfüllt. In der Praxis ist von „Modul B+C“ die Rede; der Verordnungstext formuliert „auf der Grundlage von Modul B … und anschliessend … Modul C“.

Was Modul B+C laufend bedeutet: Nach der FAQ der Kommissionsdienststellen (Nr. 6.2)[4] erfordert eine wesentliche Änderung des Produkts eine neue Bewertung durch dieselbe oder eine andere notifizierte Stelle und kann zur Revision der EU-Baumusterprüfbescheinigung führen; sonstige Änderungen ohne Auswirkung auf die CRA-Konformität lösen keine Neubewertung aus (zur Abgrenzung Artikel 11: Rolling Releases und wesentliche Änderungen). Nach Modul B Nr. 8 muss die notifizierte Stelle zudem periodische Audits durchführen, um die ordnungsgemässe Umsetzung der Schwachstellenbehandlungsprozesse sicherzustellen. Die Produktionsphase selbst wird von der notifizierten Stelle dagegen nicht bewertet — dafür trägt der Hersteller nach Modul C die alleinige Verantwortung.

Modul H: Umfassende Qualitätssicherung

Anwendung: Alternative für wichtige Produkte (Klasse I + II) und kritische Produkte; insbesondere sinnvoll für Hersteller mit grossem Produktportfolio

Externe Beteiligung: Notifizierte Stelle bewertet das gesamte Qualitätsmanagementsystem (QMS)

Aufwand: Sehr hoch initial, dann in Grenzen skalierbar

Bei Modul H steht nicht der einzelne Produkttyp im Mittelpunkt, sondern der Prozess des Herstellers. Anhang VIII Teil IV beschreibt es als das Verfahren, mit dem der Hersteller „auf eigene Verantwortung erklärt, dass die betreffenden Produkte mit digitalen Elementen oder Produktkategorien den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I und die vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen den grundlegenden Anforderungen in Anhang I Teil II genügen“.

Modul A in der Praxis: Die Wahl der meisten Softwarehersteller

Ist ein Softwareprodukt weder wichtig (Anhang III) noch kritisch (Anhang IV), ist Modul A für die meisten Hersteller der passende Weg. Dafür sprechen mehrere Gründe:

  • Kosten: Keine Gebühren für notifizierte Stellen, nur interne Ressourcen
  • Zeiteffizienz: Keine externen Freigabeprozesse
  • Unabhängigkeit: Vollständige Kontrolle über Timing und Dokumentation
  • Marktfähigkeit: Reicht für alle nicht-klassifizierten Produkte aus

Was Sie bei Modul A dokumentieren müssen

  • Cybersicherheitsanforderungen (Anhang I Teil I): Nachweis, dass das Produkt Authentifizierung, Verschlüsselung, eine Auslieferung ohne bekannte ausnutzbare Schwachstellen, Update-Mechanismen und die übrigen produktbezogenen Anforderungen umsetzt
  • Organisatorische Anforderungen zur Schwachstellenbehandlung (Anhang I Teil II): Dokumentation Ihres Security Development Lifecycle, Vulnerability-Disclosure-Policy und Schwachstellen-Bearbeitungsprozesses (vgl. Teil 8: Meldepflichten)
  • Technische Dokumentation nach Anhang VII, einschliesslich der Risikobewertung nach Art. 13 Abs. 2
  • Rückverfolgbarkeit: Alle Entscheidungen, Tests und Bewertungen müssen nachvollziehbar dokumentiert sein

Eine verwendbare Gliederung für den Selbstbewertungsbericht: Die BSI TR-03183-1 beschreibt in Kap. 4.8 einen Assessment Report, dessen Struktur sich an Anhang VII CRA und Art. 31 CRA anlehnt und der sich als Vorlage für die Modul-A-Dokumentation eignet[5]:

  • Datum der Bewertung
  • Produktidentifikation: Name und Modell, Beschreibung sowie Zweckbestimmung und vernünftigerweise vorhersehbare Verwendung, Hardware- und Softwareversion, Software-Stückliste (englisch software bill of materials, SBOM), soweit anwendbar (bei Hardware zusätzlich Abbildungen von äusseren Merkmalen, Kennzeichnung und innerem Aufbau)
  • Risikobewertung: identifizierte Assets und Bedrohungen, bewertete Risiken, akzeptierte Risiken
  • Design-Dokumentation: Architektur einschliesslich Netz- und physischer Schnittstellen, gewählte Controls mit jeweils gemindertem Risiko und Zuordnung zur einschlägigen Anforderung des Anhang I, nicht anwendbare Anforderungen mit Begründung, Beschreibung der Implementierung und der Verifikationsprozesse
  • Schwachstellenbehandlung: Beschreibung der Aktivitäten und deren Verifikation
  • Nutzerdokumentation

Ergänzend beschreibt die TR-03183-1 in Kap. 5 einen risikobasierten Ansatz in Anlehnung an ISO 31000 (Asset-Identifikation, Bedrohungsmodellierung, Risikoanalyse, -bewertung und -behandlung, Dokumentation und Aktualisierung), in Kap. 6 das Arbeiten mit „Adaptable Risk-based Controls“ und in Kap. 7 einen Control-Katalog im maschinenlesbaren OSCAL-Format, der über ein GitHub-Repository und auf Anfrage beim BSI zugänglich ist. Anhang B gibt Anhang I CRA mit stabilen Requirement-IDs wieder (Teil I: ER.0 bis ER.14; Teil II: VH.1 bis VH.8, wobei die SBOM als VH.1a geführt wird) — ein brauchbarer Anker für eigene Lückenmatrizen.

Modul A bleibt — auch wenn Sie eine Klasse-I-Komponente integrieren

Eines der häufigsten Missverständnisse im Maschinen- und Anlagenbau lautet: „Wir bauen einen Klasse-I-Router ein — sind wir damit selbst Klasse I?“ Die Antwort ist Nein: Nach Art. 7 Abs. 1 Satz 2 CRA führt die Integration eines Anhang-III-Produkts für sich genommen nicht dazu, dass das Endprodukt den strengeren Verfahren unterliegt. Massgeblich bleibt die Kernfunktion des Endprodukts (ebenso Guidance Rn. 141 und 152[3]; NK-CRA/Hessel Art. 32 Rn. 24–26[9]). Eine Standard-Werkzeugmaschine, eine Verpackungsanlage oder ein Roboterarm wird durch die Integration eines Anhang-III-Klasse-I-Bausteins nicht selbst zu einem Klasse-I-Produkt. Modul A bleibt damit der korrekte Konformitätsbewertungspfad — vorausgesetzt, die nachfolgenden Pflichten werden eingehalten:

  • Due Diligence nach Art. 13 Abs. 5 CRA: CE-Kennzeichen und EU-Konformitätserklärung der integrierten Komponente einsehen, in der eigenen technischen Dokumentation referenzieren und den Bewertungspfad des Komponentenherstellers dokumentieren. Die Guidance der Kommission nennt in Rn. 171 als angemessene Evidenz unter anderem technische Spezifikationen, Sicherheitsdokumentation und einschlägige Konformitäts- oder Assurance-Dokumentation des Komponentenherstellers, ergänzt um eigene Tests des Integrators, soweit angebracht[3]. Für Drittanbieter-Ferndienste, nicht für eingebaute Komponenten, nennt Rn. 207 zusätzlich wiederverwendbare Nachweise wie NIS-2-, DORA- und Cybersecurity-Act-Nachweise sowie ISO/IEC 27017:2015 und ISO/IEC 27001:2022 (vgl. Artikel 3: Abgestufte CRA-Pflichten).
  • Eigene Risikobewertung nach Art. 13 Abs. 2: Die Bewertung des Komponentenherstellers ersetzt die eigene nicht — bewertet werden die Angriffsflächen, die durch die Integration im eigenen Produktkontext entstehen.
  • Sichere Integration nach Anhang I Teil I: Default-Konfigurationen härten, Komponentenschnittstellen, die im Anwendungsfall überflüssig sind, deaktivieren, Patches der Komponente in den eigenen Update-Kanal einspeisen.
  • SBOM und Schwachstellenmanagement: Die integrierte Komponente gehört in die eigene SBOM (vgl. Artikel 7: SBOM für Softwarehersteller). Aktiv ausgenutzte Schwachstellen in der Komponente lösen eine eigene Meldepflicht des Integrators nach Art. 14 Abs. 1 CRA aus, wenn sie im eigenen Produkt aktiv ausgenutzt werden. Ist die Schwachstelle im eigenen Produkt nicht ausnutzbar oder wurde sie dort nicht ausgenutzt, besteht nach der Guidance keine Pflichtmeldung (Rn. 218; für den Fall fehlender Ausnutzbarkeit ebenso FAQ Nr. 5.4)[3][4]. Die freiwillige Meldung nach Art. 15, die Meldung nach Art. 13 Abs. 6 und die Schwachstellenbehandlung nach Anhang I Teil II bleiben unberührt.

Abgrenzung zur wesentlichen Änderung (Art. 22 CRA): Wer eine zugekaufte Komponente vor dem Einbau anpasst, etwa durch einen Bootmanager-Patch, eigene Kryptoroutinen oder einen gepflegten Firmware-Fork, und daraus ein eigenes Produkt baut, nimmt nach der Guidance keine wesentliche Änderung vor. Er ist Hersteller des neuen Gesamtprodukts und für dessen Konformität insgesamt verantwortlich (Guidance Rn. 120, Beispiel 51). Für eigene Änderungen trägt der Integrator volle Verantwortung; für die integrierte Drittkomponente bleibt Art. 13 Abs. 5 CRA risikobasiert relevant. Art. 22 greift erst, wenn ein bereits in Verkehr gebrachtes Produkt wesentlich verändert und wieder auf dem Markt bereitgestellt wird — etwa durch IT-Dienstleister (Wiebe, § 4 Rn. 29[10]; vertiefend Artikel 11).

Maschinenbauer, deren Endprodukt zusätzlich der Maschinenverordnung (EU) 2023/1230 unterliegt (Geltungsbeginn 20. Januar 2027)[11], führen die CRA-Komponentenintegration und die maschinenrechtliche Risikobeurteilung nach Anhang III Abschnitt 1.1.9 („Schutz gegen Korrumpierung“) und 1.2.1 zweckmässig in einer integrierten Dokumentation zusammen — eine getrennte Bearbeitung erzeugt regelmässig widersprüchliche Aussagen und doppelten Aufwand.

Modul H: Umfassende Qualitätssicherung und die BSI TR-03183-H

Modul H ist nach Art. 32 CRA als alternativer Pfad zugelassen für:

  • Wichtige Produkte mit digitalen Elementen Klasse I (Anhang III), wenn weder harmonisierte Normen oder gemeinsame Spezifikationen vollständig angewendet werden noch ein europäisches Cybersicherheitszertifizierungsschema mindestens der Vertrauenswürdigkeitsstufe „mittel“ nach Art. 27 Abs. 9 CRA greift
  • Wichtige Produkte mit digitalen Elementen Klasse II (Anhang III)
  • Kritische Produkte mit digitalen Elementen (Anhang IV) — mangels eines delegierten Rechtsakts nach Art. 8 Abs. 1 CRA derzeit nach Art. 32 Abs. 3 über Modul B+C oder Modul H

Die notifizierte Stelle bewertet hier — anders als bei Modul B+C — nicht in erster Linie das einzelne Baumuster, sondern Ihr Qualitätsmanagementsystem (QMS); hinzu kommt die Prüfung der technischen Dokumentation je eines Modells pro Produktkategorie (siehe unten).

Das Besondere an Modul H: Prozesse statt Produkte

Die notifizierte Stelle prüft:

  • Produktentwicklung: Wie integrieren Sie Sicherheit in den gesamten Entwicklungszyklus?
  • Risikomanagement: Wie identifizieren und bewerten Sie Risiken?
  • Dokumentation: Wie dokumentieren Sie Anforderungen, Design, Tests und Entscheidungen?
  • Schwachstellenbehandlung: Wie handhaben Sie Schwachstellen nach Markteinführung?
  • Qualitätskontrolle: Wie sichern Sie ab, dass jedes neue Produkt den QMS-Prozess befolgt?

Der Prüfumfang geht dabei über eine reine Systemprüfung hinaus. Die BSI TR-03183-H fasst die Anforderungen aus Anhang VIII Teil IV CRA in Anhang B.1 und B.2 wie folgt zusammen[5]:

  • Vor-Ort-Assessment: Das Audit umfasst einen Bewertungsbesuch in den Räumlichkeiten des Herstellers.
  • Qualifikation des Auditteams: Mindestens ein Mitglied muss als Assessor im betreffenden Produktfeld und in der betreffenden Produkttechnologie erfahren sein und die anwendbaren Anforderungen des Anhang I Teil I CRA kennen.
  • Review der technischen Dokumentation: je ein Modell pro Produktkategorie, mit mindestens den Elementen nach Anhang VII CRA.
  • Periodische Audits: Die notifizierte Stelle prüft laufend, ob das zertifizierte Qualitätssystem aufrechterhalten und angewendet wird.
  • Rezertifizierungszyklus: Für Managementsysteme ist üblicherweise ein vollständiges, mehrstufiges Audit alle drei Jahre plus jährliche Überwachungsaudits vorgesehen.

Grenzen der Skalierbarkeit: Ist das QMS genehmigt, lässt sich die Konformität für die davon erfassten Produktkategorien nachweisen, ohne dass jedes einzelne Produkt geprüft würde — das ist der zentrale Vorteil gegenüber Modul B+C. Ein Freibrief für beliebige Portfolio-Erweiterungen ist das aber nicht: Nach Anhang B.2 der TR-03183-H sind Änderungen am Qualitätssystem der notifizierten Stelle vorab anzuzeigen und können eine Neubewertung auslösen; das ist regelmässig der Fall, wenn der Geltungsbereich auf zusätzliche Produktkategorien erweitert wird. Hinzu kommt (Anhang B.4): Weil Modul H die Prüfung der technischen Dokumentation für ein Modell je Produktkategorie einschliesst, lässt es sich weder ohne detaillierte Stichprobe eines repräsentativen Produkts noch ohne produkttypspezifische Bewertung zertifizieren.

Und die Kehrseite: Weil die Zertifizierung am Qualitätssystem und nicht am Produkt hängt, lässt sich bei Verlust der Zertifizierung die Konformität für zwischenzeitlich produzierte Produkte in der Regel nicht nachträglich herstellen — insoweit ist das Risiko höher als bei Modul B+C (Anhang B.3). Umgekehrt relativiert die TR-03183-H in Anhang B.4 den Unterschied zwischen beiden Wegen: Auch Modul B+C ist keine statische Produktzertifizierung, weil es regelmässige Audits der Schwachstellenbehandlung nach Anhang I Teil II einschliesst. Die Differenz zwischen H und B+C ist unter dem CRA deshalb weniger ausgeprägt als in anderen Regulierungskontexten.

Die BSI TR-03183-H als Leitfaden

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit der Technical Guideline TR-03183-H einen praktischen Fahrplan veröffentlicht, wie Hersteller Modul H auf Basis eines ISO/IEC-27001-konformen Informationssicherheits-Managementsystems (ISMS) umsetzen können. Massgeblich ist die Version 1.1.0 vom 30. Mai 2026, die Deckblatt und Dokumenthistorie als Publikationsfassung ausweisen; die öffentliche Kommentierung der Vorfassung war am 31. März 2026 abgelaufen[5]. Die TR-03183-H ist eine nationale Konkretisierung des BSI und nicht EU-weit bindend, aber die derzeit detaillierteste deutsche behördliche Orientierung für Modul H; eine gefestigte Prüf- oder Vollzugspraxis besteht noch nicht.

Ein ISMS allein genügt nicht. Eine vorhandene ISO-27001-Zertifizierung wird gern als „halbe Miete“ für Modul H verstanden. In dieser Form stimmt das nicht. Die TR-03183-H stellt in Kap. 2 klar, dass zur Qualitätssicherung im Kontext von Modul H zusätzliche Anforderungen der ISO 9001 angewendet werden; ISO 9001:2015 steht neben ISO/IEC 27000, 27001, 27002 und der TR-03183-1 in den normativen Verweisen. In Anhang C erläutert das BSI den Grund: Ein QMS nach ISO 9001 ist nicht auf Cybersicherheit ausgelegt, ein ISMS nach ISO/IEC 27001 umgekehrt kein für Modul H erforderliches Qualitätssystem. Die TR-03183-H beschreibt deshalb ein integriertes Managementsystem aus ISMS, QMS und harmonisierten Normen, das als Ganzes durch eine für Managementsysteme notifizierte Stelle mit den Fähigkeiten nach ISO/IEC 27006 zertifiziert werden kann.

Konkret werden folgende ISO-9001-Anforderungen in das ISMS gezogen:

  • CRA 6.3: Änderungen am Managementsystem sind geplant durchzuführen nach ISO 9001 6.3
  • CRA 8.1.1 bis 8.1.5: Der Design-, Entwicklungs- und Produktionsprozess muss die Anforderungen der ISO 9001 8.3 (Entwicklung), 8.4 (extern bereitgestellte Prozesse, Produkte und Dienstleistungen), 8.5 (Produktion), 8.6 (Freigabe) und 8.7 (Steuerung nichtkonformer Ergebnisse) erfüllen

Wer ISO 27001 bereits betreibt, muss den Prozess also nicht von Grund auf neu entwickeln — aber er muss ihn substantiell erweitern, und zwar in zwei Richtungen: um produktbezogene Sicherheitsprozesse und um Qualitätssystem-Elemente. Zu den produktbezogenen Erweiterungen zählen:

  • Secure Software Development Lifecycle (SSDLC): Integration von Sicherheit in alle Phasen der Produktentwicklung
  • Supply Chain Security: Verwaltung von Open-Source-Abhängigkeiten und Drittanbieter-Komponenten (vgl. Teil 7: SBOM)
  • Post-Market Monitoring: Prozesse zur Erkennung und Behebung von Schwachstellen nach Markteinführung
  • Vulnerability Disclosure: Aufbau einer koordinierten Offenlegungspraxis für entdeckte Sicherheitsprobleme

Fünf weitere Festlegungen der TR-03183-H sind für die Praxis besonders relevant:

  • Geltungsbereich des ISMS (Kap. 2 und 5.4): Der Scope muss zwingend die Prozesse für das Inverkehrbringen des Produkts und die Bereitstellung der Datenfernverarbeitungslösungen (RDPS) umfassen — jeweils Design, Entwicklung, Produktion und Schwachstellenbehandlung über den definierten Unterstützungszeitraum. Wer RDPS aus dem Scope herausdefiniert, verfehlt Modul H (zur Abgrenzung der Datenfernverarbeitungslösungen vgl. Artikel 1, Artikel 2 und Artikel 4 dieser Serie).
  • Risikoakzeptanzkriterien (Kap. 5.6 und Anhang C.3.2): Sie müssen zwingend enthalten, dass eine Nichtkonformität mit dem CRA nicht akzeptabel ist; Risiken für betroffene Dritte sind nur akzeptabel, wenn ein angemessenes Sicherheitsniveau gewährleistet ist. Rein herstellereigene Risiken — Finanz- und Reputationsrisiken, entgangene Marktchancen — bleiben bei der Bewertung ausser Betracht.
  • Eingeschränkte Wahlfreiheit bei Controls (Kap. 5.7 und Kap. 6): Für bestimmte Controls wird die risikobasierte Wahlfreiheit der ISO/IEC 27001 eingeschränkt — sicherer Entwicklungslebenszyklus (8.25), Informationssicherheit im Projektmanagement (5.8), Sicherheitstests in Entwicklung und Abnahme (8.29), Änderungsmanagement (8.32) sowie Management technischer Schwachstellen (8.8) einschliesslich Threat Intelligence (5.7). Auslassungen im Statement of Applicability sind risikobasiert zu begründen.
  • Conformance Specifications (Kap. 5.2 und Anhang C.3.4): Als solche gelten harmonisierte europäische Normen oder gemeinsame Spezifikationen; sie sind zur Auslegung, Umsetzung und Bewertung der grundlegenden Anforderungen heranzuziehen, Abweichungen nur in begründeten Fällen. Die TR-03183-H enthält bewusst keine eigenen Detailanforderungen zu Anhang I, weil dies in die laufende europäische Normung fällt; die TR-03183-1 ist ausdrücklich keine Conformance Specification, sondern Guidance ohne Konformitätsanspruch (Anhang E). Praktische Folge: Die Detailanforderungen an Anhang I sind derzeit noch nicht abschliessend ableitbar — und zwar nicht, weil die TR unfertig wäre, sondern weil sie diese Frage bewusst der Normung überlässt.
  • Dokumentation (Kap. 5.10): Das ISMS muss dokumentierte Information nach Anhang VII CRA und nach Anhang VIII Teil IV Nr. 3.2 CRA enthalten; sie muss wahrheitsgemäss, korrekt, aktuell und hinreichend vollständig sein. Strukturierte, wiederverwendbare und automatisierbare Formate wie OSCAL werden empfohlen.

Die Schnittstelle zur KI-Verordnung: Art. 12 CRA

Für Hochrisiko-KI-Systeme im Sinne der KI-Verordnung (EU) 2024/1689[12] gilt bei der Modulwahl eine Sondervorschrift. Sie steht nicht in Anhang VIII, sondern unmittelbar in Art. 12 CRA:

  • Art. 12 Abs. 1 CRA — Konformitätsfiktion für Hochrisiko-KI: Erfüllt ein Hochrisiko-KI-Produkt die in Art. 12 Abs. 1 lit. a bis c genannten Bedingungen, gilt es insoweit als konform mit den Cybersicherheitsanforderungen aus Art. 15 KI-VO; die Anforderungen an Genauigkeit und Robustheit bleiben unberührt.
  • Art. 12 Abs. 2 CRA — Konformitätsbewertungsverfahren: Für die von Abs. 1 erfassten Produkte gilt grundsätzlich das Verfahren nach Art. 43 KI-VO. Notifizierte Stellen, die nach der KI-VO benannt sind, dürfen die CRA-Anforderungen mitbewerten, sofern im Notifizierungsverfahren auch ihre Eignung nach Art. 39 CRA geprüft wurde (Sörup, § 4 Rn. 64)[10].
  • Art. 12 Abs. 3 CRA — Hochrisiko-KI plus wichtig oder kritisch: Abweichend von Abs. 2 gilt für die Cybersicherheitsanforderungen das CRA-Verfahren nach Art. 32, wenn das Produkt ein wichtiges Produkt ist, das Art. 32 Abs. 2 lit. a oder b oder Abs. 3 unterliegt, oder ein kritisches Produkt ist. Zusätzliche Voraussetzung für beide Produktgruppen ist, dass für das KI-System nach der KI-VO das Verfahren der internen Kontrolle nach Anhang VI KI-VO gilt. Im Übrigen bleibt es beim Verfahren nach Art. 43 KI-VO.

Bei KI-Sicherheitsbauteilen in Maschinen ist zuerst ein Sonderweg zu beachten: Seit der Änderung der KI-Verordnung durch die Verordnung (EU) 2026/1744 (in Kraft seit 27.07.2026) ist die Maschinenverordnung in Anhang I Abschnitt B der KI-VO aufgeführt[13]. Für solche Produkte gelten Art. 15 und Art. 43 KI-VO nicht unmittelbar (Art. 2 Abs. 2 KI-VO n. F.)[12]. Die KI-Anforderungen sollen über delegierte Rechtsakte zur Maschinenverordnung umgesetzt werden, die ab dem 2. August 2028 gelten sollen (Erwägungsgrund 42 der Verordnung (EU) 2026/1744)[13]. Nach unserer Lesart läuft Art. 12 CRA, der an Art. 15 und Art. 43 KI-VO anknüpft, für diesen Weg deshalb weitgehend ins Leere. Relevant wird er erst, wenn das System auf anderem Weg als Hochrisiko-KI-System eingestuft ist, etwa nach Anhang III KI-VO. Erst dann ist zu prüfen, ob die Konformitätsfiktion des Art. 12 Abs. 1 CRA greift und welches Konformitätsbewertungsverfahren nach Abs. 2 oder 3 anzuwenden ist. Zur Konformitätsfiktion des Art. 12 Abs. 1 CRA siehe Teil 5 und Teil 6 dieser Serie.

Die Schnittstelle zum europäischen Gesundheitsdatenraum: Art. 32 Abs. 5a CRA

Eine zweite Sondervorschrift wird in der Praxis regelmässig übersehen, weil sie im ursprünglich verkündeten Verordnungstext nicht enthalten war: Art. 32 Abs. 5a CRA wurde nachträglich eingefügt, und zwar durch Art. 104 Nr. 3 der Verordnung (EU) 2025/327 über den europäischen Gesundheitsdatenraum (EHDS)[14]. Danach weisen Hersteller von Produkten mit digitalen Elementen, die nach der Verordnung (EU) 2025/327 als EHR-Systeme (Systeme für elektronische Gesundheitsaufzeichnungen) eingestuft sind, die Konformität mit den grundlegenden Anforderungen des Anhang I CRA nach, „indem sie das einschlägige Konformitätsbewertungsverfahren gemäss Kapitel III der Verordnung (EU) 2025/327 anwenden“.

Bei EHR-Systemen tritt das EHDS-Verfahren damit an die Stelle der Module aus Anhang VIII CRA. Die materiellen Anforderungen des Anhang I CRA bleiben unberührt; lediglich der Nachweisweg verschiebt sich. Dieselbe Änderungsverordnung passt zwei weitere Vorschriften an. Nach dem neu gefassten Art. 31 Abs. 3 CRA ist für Produkte nach Art. 12 und Art. 32 Abs. 5a CRA eine einzige technische Dokumentation zu erstellen, die die Angaben nach Anhang VII CRA und die nach dem anderen Unionsrechtsakt geforderten Angaben zusammenführt. Nach dem neu gefassten Art. 13 Abs. 4 CRA kann die Bewertung der Cybersicherheitsrisiken zugleich Teil der nach dem anderen Rechtsakt geforderten Risikobewertungen sein. Zwei parallele Dokumentationsstränge sind daher nicht nur unnötig, sondern regulatorisch nicht gewollt.

Zeitlich ist die Weiche noch nicht scharf gestellt: Die EHDS-Verordnung gilt grundsätzlich ab dem 26. März 2027; die Kernvorschriften für EHR-Systeme, insbesondere Art. 25 bis 27 EHDS-VO, gelten jedoch je nach den verarbeiteten prioritären Datenkategorien gestaffelt erst ab dem 26. März 2029 beziehungsweise 26. März 2031. Für EHR-Systeme, die nach Art. 26 Abs. 2 EHDS-VO in der Union in Betrieb genommen werden, gilt deren Kapitel III erst ab dem 26. März 2031. Wer ein EHR-System entwickelt, sollte die Modulwahl deshalb nicht isoliert nach dem CRA treffen, sondern gegen den EHDS-Zeitplan spiegeln.

Artikel 32 im Überblick: Wann wählen Sie zwischen Modulen, wann nicht?

| Produktkategorie | Wahlmöglichkeit nach Art. 32 | |---|---| | Nicht in Anhang III/IV | Modul A oder Modul B+C oder Modul H; zusätzlich ein europäisches Cybersicherheitszertifizierungsschema nach Art. 27 Abs. 9, sobald verfügbar und anwendbar (derzeit nicht verfügbar) | | Anhang III Klasse I — bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas nach Art. 27 Abs. 9 | Modul A bleibt möglich (Schema-Option derzeit nicht verfügbar) | | Anhang III Klasse I — sonst | Modul B+C oder Modul H | | Anhang III Klasse II | Derzeit Modul B+C oder Modul H; ein europäisches Cybersicherheitszertifizierungsschema nach Art. 27 Abs. 9 (mind. „mittel“) erst, sobald verfügbar und anwendbar | | Anhang III Klasse I oder II — freie und quelloffene Software mit zum Zeitpunkt des Inverkehrbringens öffentlich zugänglicher technischer Dokumentation | Modul A bleibt möglich (Art. 32 Abs. 5) | | Anhang IV (kritisch) | Derzeit nach Art. 32 Abs. 3 (kein delegierter Rechtsakt nach Art. 8 Abs. 1): Modul B+C oder Modul H; Schema-Option derzeit nicht verfügbar | | Hochrisiko-KI-Produkt (KI-VO) ohne Anhang III/IV-Status | Konformitätsbewertung nach Art. 43 KI-VO (Art. 12 Abs. 2 CRA) | | Hochrisiko-KI-Produkt zugleich wichtiges Produkt, das Art. 32 Abs. 2 lit. a oder b oder Abs. 3 unterliegt, oder kritisches Produkt | CRA-Verfahren nach Art. 32 für die Cybersicherheitsanforderungen, wenn KI-VO-seitig interne Kontrolle nach Anhang VI KI-VO gilt (Art. 12 Abs. 3 CRA); im Übrigen Art. 43 KI-VO | | EHR-System nach der Verordnung (EU) 2025/327 (EHDS) | Konformitätsbewertungsverfahren nach Kapitel III der Verordnung (EU) 2025/327 statt eines CRA-Moduls (Art. 32 Abs. 5a CRA) |

Die EUCC (European Common Criteria-based Cybersecurity Certification Scheme) nach der Durchführungsverordnung (EU) 2024/482 ist seit dem 27. Februar 2025 vollständig anwendbar und bislang das einzige europäische Zertifizierungsschema nach dem Cybersecurity Act[7][15]. Für die CRA-Konformitätsbewertung kann sie jedoch erst genutzt werden, wenn die Kommission sie durch einen delegierten Rechtsakt nach Art. 27 Abs. 9 CRA ausweist. Dieser delegierte Rechtsakt war nach der Umsetzungsübersicht der Kommission für das vierte Quartal 2026 angekündigt, bis zum 11. Oktober 2026 aber nicht erlassen[20]. Die Guidance hält die Mechanik fest: Erst die Ausweisung nach Art. 27 Abs. 9 CRA begründet die Konformitätsvermutung nach Art. 27 Abs. 8 (Rn. 148 mit Fn. 25, Rn. 153)[3]. Die im Markt häufig zitierte ETSI-Norm EN 303 645 ist ein Sicherheitsstandard für Consumer-IoT — sie kann als Grundlage für eine harmonisierte Norm oder ein künftiges Schema dienen, ist selbst aber kein Zertifizierungsschema im Sinne der Verordnung (EU) 2019/881. Die gemeinsame Analyse von JRC und ENISA („Cyber Resilience Act Requirements Standards Mapping“, EUR 31892 EN, 2024) kommt zu dem Ergebnis, dass bestehende Normen die CRA-Anforderungen nur teilweise abdecken und keine einzelne Norm alle Anforderungen des Anhang I erfüllt[16]. Zu EN 303 645 hält sie fest, dass sich die Norm wegen ihres IoT-Zuschnitts nicht automatisch auf andere Produktkategorien übertragen lässt. Die Analyse beruht noch auf dem Kommissionsvorschlag COM/2022/454 von 2022; ihre Nummerierung weicht von der geltenden Verordnung ab.

Die Rolle der notifizierten Stellen

Notifizierte Stellen sind unabhängige Konformitätsbewertungsstellen, die nach Kapitel IV CRA und auf Grundlage einer Notifizierung durch einen Mitgliedstaat tätig werden. Sie müssen nach Art. 39 unter anderem:

  • Unabhängig vom Hersteller und vom zu bewertenden Produkt sein
  • Technisch kompetent in Cybersicherheit sein
  • Ihre Tätigkeit mit höchster Integrität ausüben

Eine Akkreditierungspflicht enthält Art. 39 CRA nicht; im Regelfall sind notifizierte Stellen aber durch die nationale Akkreditierungsstelle akkreditiert (in Deutschland: die DAkkS) — Art. 42 f. CRA; eine Notifizierung ohne Akkreditierungsurkunde ist mit Nachweisunterlagen möglich.

Das zentrale Register notifizierter Stellen führt die Europäische Kommission in der Datenbank NANDO. Kapitel IV der CRA mit den Notifizierungsvorschriften — und damit die Notifizierung — gilt nach Art. 71 seit dem 11. Juni 2026. Die DAkkS nimmt seit dem 28. Juli 2026 Anträge auf Akkreditierung nach dem CRA entgegen, nach ISO/IEC 17065 für Modul B und ISO/IEC 17021-1 für Modul H[17]. Hersteller sollten den aktuellen NANDO-Stand und den Leistungsumfang der dort ausgewiesenen Stellen jeweils unmittelbar vor ihrer Verfahrensplanung prüfen.

Welche Behörde notifiziert, bestimmt der jeweilige Mitgliedstaat. In Deutschland soll diese Aufgabe das BSI übernehmen: Der Regierungsentwurf eines Gesetzes zur Durchführung der Cyberresilienz-Verordnung (BT-Drs. 21/6134 vom 26. Mai 2026; § 66 BSIG-E)[18] sieht das BSI als notifizierende Behörde nach Art. 36 Abs. 1 CRA vor — mit der Möglichkeit, im Ausnahmefall auch ohne Akkreditierung durch die Deutsche Akkreditierungsstelle (DAkkS) zu notifizieren. Nach der ersten Lesung im Juni billigte der Innenausschuss des Bundestages den Entwurf am 14. Oktober 2026 mit einer Änderung, die das Inkrafttreten einzelner Vorschriften betrifft; am 15. Oktober 2026 stimmte der Bundestag in dieser Fassung zu. Der zweite Durchgang im Bundesrat und die Verkündung standen danach noch aus[19]. Was das für Hersteller bedeutet, haben wir in Artikel 10 zum CRA-Durchführungsgesetz dargestellt.

EU-Konformitätserklärung und CE-Kennzeichnung

Ist die Konformitätsbewertung abgeschlossen, folgen zwei zentrale Schritte.

Art. 28 CRA: EU-Konformitätserklärung

Art. 28 verweist für Aufbau und Mindestinhalt auf das Muster in Anhang V und auf die im jeweiligen Modul nach Anhang VIII geforderten Elemente. Aus Anhang V ergeben sich insbesondere:

  • Name und Anschrift des Herstellers (und ggf. des Bevollmächtigten)
  • Identifikation des Produkts (Modell, Typ, Seriennummer/Charge, sofern zutreffend)
  • Erklärung, dass die EU-Konformitätserklärung in alleiniger Verantwortung des Herstellers ausgestellt wird
  • Gegenstand der Erklärung (Beschreibung, ggf. Foto)
  • Verweis auf die einschlägige Harmonisierungsrechtsvorschrift (CRA) und auf weitere angewandte Unionsrechtsakte
  • Angewandte harmonisierte Normen, gemeinsame Spezifikationen oder Cybersicherheitszertifikate
  • Bei Beteiligung einer notifizierten Stelle: deren Name, Kennnummer und ausgestellte Bescheinigung
  • Ort, Datum, Name und Unterschrift der bevollmächtigten Person

Die Erklärung ist in den Sprachen abzufassen, die der Mitgliedstaat vorschreibt, in dem das Produkt in Verkehr gebracht oder bereitgestellt wird. Eine solche Sprachvorgabe enthält das deutsche Durchführungsgesetz weder im Regierungsentwurf (BT-Drs. 21/6134)[18] noch in der vom Bundestag beschlossenen Fassung (BT-Drs. 21/8622)[21]; die Vorgaben des jeweiligen Zielmarkts sind gesondert zu prüfen. Für den deutschen Markt bleibt eine deutschsprachige Erklärung der sicherste Weg; Mehrsprachigkeit ist möglich. Dem Produkt kann statt der vollständigen Erklärung eine vereinfachte EU-Konformitätserklärung nach Anhang VI beigefügt werden; sie muss die Internetadresse nennen, unter der die vollständige Erklärung abrufbar ist (Art. 13 Abs. 20, Art. 28 Abs. 2 UAbs. 2 CRA)[1].

Art. 30 CRA: CE-Kennzeichnung

Art. 30 regelt die Anbringung der CE-Kennzeichnung wie folgt:

  • Sie ist gut sichtbar, leserlich und dauerhaft auf dem Produkt anzubringen.
  • Lässt die Art des Produkts dies nicht zu oder rechtfertigt es nicht, wird die CE-Kennzeichnung auf der Verpackung und der beigefügten EU-Konformitätserklärung angebracht.
  • Bei Produkten in Form von Software wird sie entweder auf der EU-Konformitätserklärung oder auf der das Softwareprodukt begleitenden Website angebracht. Im letzteren Fall muss der relevante Abschnitt der Website für Verbraucher leicht und direkt zugänglich sein.
  • Wurde eine notifizierte Stelle im Rahmen von Modul H beteiligt, folgt deren Kennnummer der CE-Kennzeichnung.

Eine „Gebrauchsanleitung“ ist im CRA-Wortlaut nicht als Anbringungsort vorgesehen — bei körperlosen Softwareprodukten ist die EU-Konformitätserklärung oder die Website massgeblich. Wie das eine CE-Zeichen bei Produkten wirkt, die zugleich anderen CE-Rechtsakten unterliegen, zeigt Teil 13 dieser Serie.

Die BSI TR-03183 als Kompass

Das BSI hat seine Technical Guideline TR-03183 als Orientierungshilfe für die CRA-Umsetzung veröffentlicht. Sie umfasst nach aktuellem Stand drei nummerierte Teile sowie einen ergänzenden Modul-H-Teil:

  • TR-03183-1: General Requirements — übergreifende Anforderungen an Hersteller, Version 1.0.0, ausdrücklich als „Living Document“ gekennzeichnet (Datumsangabe im Dokument uneinheitlich)
  • TR-03183-2: Software Bill of Materials (SBOM) — Anforderungen an Aufbau und Pflege einer SBOM, Version 2.1.0 vom 20. August 2025
  • TR-03183-3: Vulnerability Reports and Notifications — Version 1.0.0 vom 20. August 2025 (Vorfassung: Initial Draft 0.9.0 vom 20. September 2024); Regelungsschwerpunkt ist weniger die Meldung eigener Schwachstellen als die Entgegennahme von Schwachstellenmeldungen: Meldeinfrastruktur, koordinierte Offenlegung, Notifikationspflicht gegenüber dem nationalen CSIRT und eine 90-Tage-Offenlegungsfrist
  • TR-03183-H — umfassende Qualitätssicherung (Modul H) auf Basis eines ISO/IEC-27001-konformen ISMS, ergänzt um Qualitätssystem-Anforderungen der ISO 9001; Version 1.1.0 vom 30. Mai 2026

Verbindlich sind diese Richtlinien nicht — und das BSI formuliert das deutlicher, als es im Markt oft wiedergegeben wird: Die TR-03183-1 stellt in Kap. 2 ausdrücklich fest, dass das Dokument keine Herstellerpflichten begründet und keine Konformitätsvermutung erzeugt; es versteht sich als Vorbereitungshilfe und soll in seiner jetzigen Form abgelöst werden, sobald entsprechende Normungsdeliverables den Inhalt abdecken. Kap. 4.7 ergänzt für das Selbstbewertungsverfahren: Ein „PASS“ ist keine Aussage über CRA-Konformität — und ein „FAIL“ umgekehrt auch nicht, weil einzelne Anforderungen der Richtlinie für ein konkretes Produkt gar nicht einschlägig sein müssen. Wer die TR heranzieht, gewinnt Struktur und Prüfbarkeit, aber keinen Rechtsstatus[5].

Ebenfalls unverbindlich ist eine europäische Praxishilfe: Das ENISA Secure by Design and Default Playbook (Juli 2026, Version 1.0) beschreibt 22 Prinzipien mit Checklisten, Mindestnachweisen und Freigabekriterien und ordnet sie in Anhang C nach eigener Angabe als „indicative mapping“ den grundlegenden Anforderungen des Anhang I zu[6]. Es ist ausdrücklich keine Rechtsberatung und keine harmonisierte Norm und begründet keine Konformitätsvermutung; ENISA stellt selbst klar, dass die Befolgung der Prinzipien weder eine Zertifizierung nach Normen noch die Einhaltung regulatorischer Vorgaben sicherstellt.

Warum Modulwahl und Konformitätsbewertung in der Praxis scheitern

Klassifikation prüfen, Modul wählen, Dokumentation erstellen, CE-Kennzeichen anbringen: So geradlinig erscheint der Ablauf in der Theorie. Die Praxis ist fehleranfälliger. Besonders oft wird die Klassifizierung nach Anhang III/IV mitsamt den Präzisierungen der Durchführungsverordnung (EU) 2025/2392 unterschätzt. Der Unterschied zwischen einem „Produkt mit Browser-Funktion“ und einem „Browser-Produkt“ ist keineswegs trivial; von ihm kann die gesamte Bewertungstiefe abhängen. Wird vorschnell Modul A gewählt und erweist sich das Endprodukt später aufgrund seiner eigenen Kernfunktionalität als Klasse II, reicht die bisherige Dokumentation für eine Drittprüfung womöglich nicht aus. Sie muss dann von Grund auf neu aufgebaut werden.

Oft bleibt auch das Post-Market-Monitoring nach Art. 13 und Art. 14 ausser Betracht, obwohl es selbst bei Modul A verpflichtend ist. SBOM-Dokumentation, Schwachstellenmanagement und EU-Konformitätserklärung hängen an den Release-Zyklen; jede Codeänderung lässt sie altern. Wer eine notifizierte Stelle benötigt, sollte zudem mehrere Monate Vorlauf einplanen: Die Akkreditierung nach dem CRA ist in Deutschland erst Ende Juli 2026 angelaufen. Auch die inhaltliche Zielmarke steht noch nicht endgültig fest: Die BSI TR-03183-H verzichtet in ihrer Fassung 1.1.0 bewusst auf eigene Detailanforderungen zu Anhang I und verweist auf die laufende europäische Normung, deren zentrale Deliverables teils bis Ende 2026, teils erst bis Oktober 2027 vorliegen sollen. Konformitätsbewertung ist daher kein einmaliges Projekt, sondern ein fortlaufender Compliance-Prozess.

Das Wichtigste für Hersteller

  • Welche Module offenstehen, entscheidet zuerst die Klassifizierung nach Anhang III und IV CRA, konkretisiert durch die Durchführungsverordnung (EU) 2025/2392. Massgeblich ist die Kernfunktion des Produkts; eine integrierte Klasse-I-Komponente macht das Endprodukt nicht zum Klasse-I-Produkt.
  • Für Produkte der Standardkategorie bleibt Modul A, die Selbstbewertung, der Regelweg. Klasse-I-Produkte können Modul A nur nutzen, wenn eine im Amtsblatt veröffentlichte harmonisierte Norm (oder eine gemeinsame Spezifikation) vollständig angewandt wird; sonst bleiben Modul B+C oder H.
  • Klasse-II- und kritische Produkte brauchen derzeit eine notifizierte Stelle (Modul B+C oder H). Ausnahme: freie und quelloffene Software der Klassen I und II mit öffentlich zugänglicher technischer Dokumentation (Art. 32 Abs. 5 CRA).
  • Wer eine notifizierte Stelle braucht, sollte mehrere Monate Vorlauf einplanen. Für Modul H beschreibt die nicht bindende BSI TR-03183-H ein integriertes Managementsystem aus ISO/IEC 27001 und ISO 9001.
  • Konformitätsbewertung ist kein Einmalprojekt: Unterstützungszeitraum, Schwachstellenbehandlung und Dokumentation sind laufend zu pflegen; eine wesentliche Änderung erfordert eine neue Bewertung.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • Onboarding-Wizard und CRA-Wegweiser: erfassen Produkte und Rolle, unterstützen die Einordnung in die Produktklassen und führen je Produkt Schritt für Schritt durch die Pflichten – mit Kennzeichnung, welche bereits gelten und welche erst ab dem 11. Dezember 2027 verbindlich werden.
  • Dokumentation & Konformität: erstellt Entwürfe der technischen Dokumentation nach Anhang VII und der EU-Konformitätserklärung zur fachlichen Prüfung und Freigabe.

Für eine erste Einordnung steht der kostenlose CRA-Quick-Check bereit: Er liefert mit wenigen Fragen eine unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte. Die abschliessende Einordnung bleibt beim Hersteller.

Methodik dieser Recherche

Dieser Artikel basiert auf:

  • Der offiziellen Verordnung (EU) 2024/2847 (Text und Anhänge), insbesondere Art. 12, 13, 14, 22, 28, 30, 31, 32 und 71 sowie Anhang I, III, IV, V, VII und VIII
  • Der Durchführungsverordnung (EU) 2025/2392 der Kommission vom 28. November 2025 zur technischen Beschreibung der Produktkategorien
  • Der Europäischen Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026 und nicht verbindlich; insbesondere Kapitel 7.3 (Rn. 167–173) zur Due Diligence, Kapitel 6.1 (Rn. 139–142) zur Kernfunktionalität, Rn. 148 f. und 152 f. zu Klasse I und zur Schema-Option und Rn. 218 zu Schwachstellen in Drittkomponenten
  • Den „FAQs on the Cyber Resilience Act“ der Kommissionsdienststellen, Version 1.4 vom 04.09.2026, insbesondere Nr. 5.4 (Schwachstellen in Drittkomponenten), 6.1 (Modul A), 6.2 (Modul B+C), 6.6 (technische Dokumentation) und 6.10 (harmonisierte Normen); das Dokument ist ein „Living Document“ der Kommissionsdienststellen und gibt nach eigenem Hinweis keine offizielle Position der Europäischen Kommission wieder
  • Dem Kommentar Wiebe (Hrsg.), Das neue Recht der Cyberresilienz (Nomos, Stand Juni 2025): Sörup, § 4 Rn. 64 (zu Art. 12 CRA); Wiebe, § 4 Rn. 29 (zu Art. 22 CRA) und § 6 Rn. 25–28 (Unterstützungszeitraum nach Art. 13 Abs. 8 CRA)
  • Dem Kommentar Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung (NK-CRA): Kommentierung von Hessel zu Art. 32 CRA, insbesondere Rn. 22 (Voraussetzungen der Klasse I), Rn. 23–26 (Kernfunktionalität und integrierte Komponenten) und Rn. 35 (Konformitätsbewertung freier und quelloffener Software nach Art. 32 Abs. 5 CRA)
  • Der BSI Technical Guideline TR-03183: Teil 1 „General requirements“, Version 1.0.0 („Living Document“); Teil 2 „Software Bill of Materials (SBOM)“, Version 2.1.0 vom 20.08.2025; Teil 3 „Vulnerability Reports and Notifications“, Version 1.0.0 vom 20.08.2025; sowie TR-03183-H „Conformity based on full quality assurance (Module H)“, Version 1.1.0 vom 30.05.2026
  • Dem ENISA Secure by Design and Default Playbook, Juli 2026, Version 1.0 (unverbindliche Praxishilfe für KMU; keine harmonisierte Norm, keine Konformitätsvermutung)
  • Der gemeinsamen Analyse von JRC und ENISA, „Cyber Resilience Act Requirements Standards Mapping“, EUR 31892 EN, 2024 — mit dem Vorbehalt, dass sie auf dem Kommissionsvorschlag COM/2022/454 beruht und ihre Anforderungsnummerierung nicht der geltenden Verordnung entspricht
  • Der Verordnung (EU) 2019/881 (Cybersecurity Act) und der Durchführungsverordnung (EU) 2024/482 (EUCC), dort insbesondere Art. 50 (Geltung seit 27.02.2025)
  • Der Umsetzungsübersicht der Europäischen Kommission zum CRA, auf der der delegierte Rechtsakt nach Art. 27 Abs. 9 CRA am 11.10.2026 weiterhin für das vierte Quartal 2026 angekündigt, aber noch nicht als erlassen ausgewiesen war
  • Der DAkkS-Pressemitteilung vom 28. Juli 2026 zum Start des Akkreditierungsverfahrens nach dem CRA
  • Dem Regierungsentwurf eines Gesetzes zur Durchführung der Cyberresilienz-Verordnung, BT-Drs. 21/6134 vom 26. Mai 2026, sowie der amtlichen Dokumentation der ersten Beratung und Ausschussüberweisung und der Beschlussempfehlung des Innenausschusses, BT-Drs. 21/8622 vom 14. Oktober 2026
  • Der Verordnung (EU) 2025/327 über den europäischen Gesundheitsdatenraum (EHDS), insbesondere Art. 104 Nr. 1 bis 3 (Änderung der Verordnung (EU) 2024/2847: Neufassung von Art. 13 Abs. 4 und Art. 31 Abs. 3 CRA, Einfügung des Art. 32 Abs. 5a CRA) sowie Art. 105 (Geltungsbeginn)
  • Der KI-Verordnung (EU) 2024/1689 in der Fassung der Verordnung (EU) 2026/1744, insbesondere Art. 2 Abs. 2, Art. 15, Art. 43 und Anhang I Abschnitt B
  • Der Maschinenverordnung (EU) 2023/1230 (Geltungsbeginn 20. Januar 2027), insbesondere Anhang III Abschnitt 1.1.9 und 1.2.1
  • Dem Beschluss Nr. 768/2008/EG über das New Legislative Framework

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 7, 8, 12, 13, 22, 27, 28, 30, 31, 32 (einschliesslich Abs. 5a), 39, 42 f. und 71, Anhänge I, III bis VIII, Erwägungsgrund 60.

[2] Durchführungsverordnung (EU) 2025/2392 der Kommission vom 28. November 2025 – EUR-Lex

[3] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026 (Annex-Download: ec.europa.eu). Die Guidance ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sie ist nicht verbindlich; für die Konformitätsbewertung bleiben der CRA und die einschlägigen verbindlichen Rechtsakte massgeblich. Insbesondere Rn. 120, 125–127, 139–142, 148 f. (mit Fn. 25), 152 f., 167–173, 207 und 218.

[4] Europäische Kommission (Kommissionsdienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026. Living Document; nach eigenem Hinweis nicht als offizielle Position der Europäischen Kommission zu verstehen. Insbesondere Nr. 5.4, 6.1, 6.2, 6.6 und 6.10.

[5] BSI – Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products — Teil 1 „General requirements“, Version 1.0.0 (Living Document); Teil 2 „Software Bill of Materials (SBOM)“, Version 2.1.0 vom 20.08.2025; Teil 3 „Vulnerability Reports and Notifications“, Version 1.0.0 vom 20.08.2025; TR-03183-H „Conformity based on full quality assurance (Module H)“, Version 1.1.0 vom 30.05.2026.

[6] ENISA, „Secure by Design and Default Playbook — A Practical Guide to Secure by Design and Default Principles for SMEs“, Juli 2026, Version 1.0.

[7] Verordnung (EU) 2019/881 des Europäischen Parlaments und des Rates (Cybersecurity Act) – EUR-Lex

[8] Beschluss Nr. 768/2008/EG des Europäischen Parlaments und des Rates – EUR-Lex

[9] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Hessel, Art. 32 Rn. 22 (Voraussetzungen der Klasse I), Rn. 23–26 (Kernfunktionalität und integrierte Komponenten), Rn. 35 (freie und quelloffene Software nach Art. 32 Abs. 5 CRA).

[10] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Sörup, § 4 Rn. 64 (Art. 12 Abs. 2 CRA); Wiebe, § 4 Rn. 29 (wesentliche Änderung, Art. 22 CRA), § 6 Rn. 25–28 (Unterstützungszeitraum).

[11] Verordnung (EU) 2023/1230 des Europäischen Parlaments und des Rates – Maschinenverordnung – EUR-Lex

[12] Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates – KI-Verordnung – EUR-Lex — in der durch die Verordnung (EU) 2026/1744 geänderten Fassung; insbesondere Art. 2 Abs. 2, Art. 15, Art. 43, Anhang I Abschnitt B, Anhang III und Anhang VI.

[13] Verordnung (EU) 2026/1744 des Europäischen Parlaments und des Rates vom 8. Juli 2026 zur Änderung der Verordnungen (EU) 2024/1689, (EU) 2018/1139 und (EU) 2023/1230 – EUR-Lex — ABl. L vom 24.07.2026; insbesondere Art. 1 Nr. 2 und Erwägungsgrund 42.

[14] Verordnung (EU) 2025/327 des Europäischen Parlaments und des Rates vom 11. Februar 2025 über den europäischen Gesundheitsdatenraum sowie zur Änderung der Richtlinie 2011/24/EU und der Verordnung (EU) 2024/2847 – EUR-Lex — insbesondere Art. 104 Nr. 3 (Einfügung des Art. 32 Abs. 5a CRA) und Art. 105 (Geltungsbeginn).

[15] Durchführungsverordnung (EU) 2024/482 der Kommission – EUCC – EUR-Lex

[16] Hernandez Ramos, J. L. u. a., „Cyber Resilience Act Requirements Standards Mapping“, Joint Research Centre und ENISA, EUR 31892 EN, Publications Office of the European Union, 2024, JRC137340, doi:10.2760/905934. Stand-Vorbehalt: beruht auf dem Kommissionsvorschlag COM/2022/454.

[17] Deutsche Akkreditierungsstelle (DAkkS) — „DAkkS starts accreditation process under the Cyber Resilience Act“, 28. Juli 2026

[18] Deutscher Bundestag — BT-Drs. 21/6134 vom 26. Mai 2026, Entwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847

[19] Deutscher Bundestag — erste Beratung und Ausschussüberweisung am 11. Juni 2026; hib 822/2026 vom 14.10.2026 — Ausschuss billigt Gesetzentwurf zu Cyberresilienz-Verordnung; Deutscher Bundestag — Abschliessende Beratung am 15. Oktober 2026

[20] Europäische Kommission — „Cyber Resilience Act - Implementation“ — Umsetzungsübersicht der Kommission mit dem Zeitplan der Durchführungs- und delegierten Rechtsakte, darunter der delegierte Rechtsakt zur Konformitätsvermutung für ein europäisches Cybersicherheitszertifizierungsschema (Art. 27 Abs. 9 CRA).

[21] Deutscher Bundestag — BT-Drs. 21/8622 vom 14.10.2026, Beschlussempfehlung und Bericht des Innenausschusses zu dem Entwurf eines Gesetzes zur Durchführung der Verordnung (EU) 2024/2847 (Vorabfassung)

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 08.06.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: CRA-Durchführungsgesetz: Das BSI als Marktüberwachungsbehörde — welche Rolle der Regierungsentwurf dem BSI als Marktüberwachungs- und notifizierende Behörde zuweist, was Bitkom, TeleTrusT und OSBA am vorangegangenen Referentenentwurf kritisierten und was Hersteller für den nationalen Vollzug einplanen sollten.