Von Redaktion codAIx | Mai 2026

Die Konformitätsbewertung nach dem Cyber Resilience Act ist der Dreh- und Angelpunkt Ihrer Compliance-Strategie. Artikel 32 CRA verweist auf vier Module aus Anhang VIII — von der internen Kontrolle (Modul A) bis zur umfassenden Qualitätssicherung (Modul H). Die richtige Wahl entscheidet über Kosten, Zeit und Marktfähigkeit Ihres Produkts.

Quellenhierarchie für die Konformitätsbewertung: Der CRA-Verordnungstext (EU 2024/2847) und die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 (mit den technischen Beschreibungen für Anhang III/IV) sind unmittelbar EU-weit bindend. Die in Konsultation befindliche EU-Kommissions-Guidance (Draft Communication Ares(2026)2319816) ergänzt sie als nicht-bindende Auslegungshilfe. Harmonisierte EU-Normen (CEN/CENELEC, Normungsauftrag M/606) sollen ab Q3/Q4 2026 vorliegen und über Art. 27 CRA Konformitätsvermutung erzeugen. Die BSI TR-03183-H für Modul H ist eine nationale Konkretisierung des deutschen BSI: nicht EU-weit bindend, aber für Hersteller mit deutscher notifizierter Stelle oder deutscher Marktüberwachungsbehörde der praktische Bezugspunkt. Bei Konflikt zwischen EU- und nationaler Ebene gilt die EU-Vorgabe.

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:

  • (a) Modul A — Interne Fertigungskontrolle (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) — als gleichwertige Option zu den NLF-Modulen, sofern ein Schema verfügbar und anwendbar ist.

Die Module A, B, C und H sind in Anhang VIII der CRA-Verordnung beschrieben, die ihrerseits dem Beschluss Nr. 768/2008/EG (New Legislative Framework) entstammen. 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 bereits bestehendes Cybersicherheitszertifikat nutzt.

Die vier Konformitätsbewertungsmodule der CRA

Aus Sicht des Herstellers stehen damit 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 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 Eigenverantwortung reduziert externe Kosten, verlangt aber rigorose interne Dokumentation und Nachvollziehbarkeit.

Mindestens fünf Jahre Sicherheitsupdates als Modul-A-Pflicht: Auch ohne notifizierte Stelle ist der Unterstützungszeitraum keine Kür. Art. 13 Abs. 8 CRA verpflichtet Hersteller, Sicherheitsupdates für mindestens fünf Jahre nach Inverkehrbringen bereitzustellen; Erwägungsgrund 60 indiziert für langlebige Hardware ausdrücklich längere Zeiträume (Wiebe, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 6 Rn. 25–27). 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

Modul C ist der zweite Schritt nach Modul B: Der Hersteller stellt sicher und erklärt, dass jede produzierte Einheit dem in der EU-Baumusterprüfbescheinigung beschriebenen Baumuster entspricht und die grundlegenden Cybersicherheitsanforderungen weiter erfüllt. Die Kombination wird in der Praxis als „Modul B+C" bezeichnet; der Verordnungstext formuliert „auf der Grundlage von Modul B … und anschliessend … Modul C".

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 skalierbar

Modul H ist der einzige Pfad, der nicht auf einzelne Produkttypen, sondern auf die Prozesse des Herstellers abzielt. 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".

Die Schnittstelle zur KI-Verordnung: Art. 12 CRA

Wer Hochrisiko-KI-Systeme im Sinne der KI-Verordnung (EU) 2024/1689 in Verkehr bringt, muss bei der Modulwahl eine Sondervorschrift beachten — und die liegt nicht in Anhang VIII, sondern in Art. 12 CRA selbst:

  • Art. 12 Abs. 2 CRA — Standardfall Hochrisiko-KI: Erfüllt ein Hochrisiko-KI-Produkt die grundlegenden Cybersicherheitsanforderungen aus Anhang I CRA, gilt es insoweit als konform mit den Cybersicherheitsanforderungen der KI-VO. Konformitätsbewertet wird das Produkt jedoch nach Art. 43 KI-VO, nicht nach einem CRA-Modul. Notifizierte Stellen, die nach KI-VO benannt sind, dürfen die Bewertung übernehmen, sofern bei der Notifizierung auch die CRA-Anforderungen aus Art. 39 CRA mitgeprüft worden sind (Sörup, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 64–65).
  • Art. 12 Abs. 3 CRA — Hochrisiko-KI plus wichtig oder kritisch: Ist das Hochrisiko-KI-Produkt zugleich ein wichtiges Produkt der Klasse I oder II (Anhang III) oder ein kritisches Produkt (Anhang IV), greift die Sonderregel nicht mehr allein: Zusätzlich zu Art. 43 KI-VO ist das CRA-Konformitätsbewertungsverfahren nach Art. 32 CRA durchzuführen. In der Praxis entsteht damit ein kombiniertes Verfahren, das beide Regelwerke parallel erfüllen muss.

Diese Schnittstelle betrifft den Maschinen- und Anlagenbau direkt: Wer eine KI-Komponente — etwa ein Qualitätssicherungs-Vision-System mit Hochrisiko-Klassifizierung — in eine Werkzeugmaschine integriert, muss klären, ob die KI-Komponente unter Art. 12 Abs. 2 oder Abs. 3 CRA fällt, bevor das richtige Modul gewählt werden kann. Eine Modul-A-Selbstbewertung ohne diese Vorabprüfung ist nicht tragfähig.

Modul A in der Praxis: Die Wahl der meisten Softwarehersteller

Für die meisten Softwarehersteller ist Modul A das geeignete Verfahren, sofern ihre Produkte nicht als wichtig (Anhang III) oder kritisch (Anhang IV) eingestuft sind. Die 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

  • Cybersecurity-Anforderungen (Anhang I Teil I): Nachweis, dass das Produkt Authentifizierung, Verschlüsselung, Schwachstellenbehandlung, 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 Risiko­bewertung nach Art. 13 Abs. 2
  • Rückverfolgbarkeit: Alle Entscheidungen, Tests und Bewertungen müssen nachvollziehbar dokumentiert sein

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. Die Klassifizierung nach Anhang III bezieht sich auf das Endprodukt, nicht auf eingebettete Komponenten. Eine Standard-Werkzeugmaschine, eine Verpackungsanlage oder ein Roboterarm wird durch die Integration eines Anhang-III-Klasse-I-Bausteins (Router, Switch, eingebettetes Betriebssystem, Bootmanager, VPN-Komponente, Mikrocontroller mit sicherheitsrelevanter Funktion) 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 (Modul A unter harmonisierter Norm vs. Modul B+C/H) dokumentieren. Sicherheitsdokumentation, Patch-Praxis und Vulnerability-Disclosure-Policy des Lieferanten müssen vertraglich abgesichert sein. Die Draft Communication Ares(2026)2319816 konkretisiert in Rn. 151–157, welche Evidenz „angemessen" ist (vgl. Teil 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. Teil 7: SBOM für Softwarehersteller). Aktiv ausgenutzte Schwachstellen in der Komponente lösen eine eigene Meldepflicht des Integrators nach Art. 14 Abs. 1 aus, unabhängig davon, ob der Komponentenhersteller seinerseits gemeldet hat.

Die kritische Ausnahme — Art. 22 CRA (wesentliche Änderung): Wer die integrierte Komponente nicht nur einbaut, sondern wesentlich verändert (z. B. Bootmanager-Patch, eigene Kryptoroutinen im eingebetteten OS, gepflegter Firmware-Fork), gilt selbst als Hersteller dieser veränderten Komponente — mit allen Klasse-I-Pflichten und einer erneuten Konformitätsbewertung. Die Reichweite ist breiter, als sie klingt: Auch IT-Dienstleister können durch eine wesentliche Änderung in die Hersteller-Position rücken (Wiebe, in: Wiebe (Hrsg.), CRA-Kommentar, 2025, § 4 Rn. 29); praktisch gilt dasselbe für Systemintegratoren und Managed-Service-Anbieter. Wer also fremde Software konfiguriert, mit eigenem Code anreichert oder den Funktionsumfang substantiell erweitert, sollte die Schwelle der wesentlichen Änderung sauber dokumentieren. Reine Sicherheitspatches und routinemässige Updates lösen Art. 22 ausdrücklich nicht aus — sie sind im Gegenteil Teil der laufenden Herstellerpflicht. Wird Art. 22 ausgelöst, ist Modul A nur dann tragfähig, wenn die einschlägigen harmonisierten Normen vollständig angewendet werden oder ein europäisches Cybersicherheitszertifikat mindestens auf Stufe „mittel" nach Art. 27 vorliegt; sonst wird Modul B+C oder Modul H mit notifizierter Stelle erforderlich.

Maschinenbauer, deren Endprodukt zusätzlich der Maschinenverordnung (EU) 2023/1230 unterliegt (Geltungsbeginn 20. Januar 2027), 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 keine harmonisierten Normen vollständig angewendet werden können
  • Wichtige Produkte mit digitalen Elementen Klasse II (Anhang III)
  • Kritische Produkte mit digitalen Elementen (Anhang IV) — sofern kein europäisches Cybersicherheits­zertifizierungs­schema nach Art. 8 Abs. 1 zur Anwendung kommt

Anders als bei Modul A bewertet eine notifizierte Stelle nicht das einzelne Produkt, sondern Ihr Qualitätsmanagementsystem (QMS).

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?

Vorteil: Hat die notifizierte Stelle Ihr QMS genehmigt, können Sie alle künftigen Produkte oder Produktkategorien, die diesem Prozess folgen, unter demselben Zertifikat vermarkten. Das ist hochgradig skalierbar.

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 (Community Draft v1.0.0, Februar 2026; öffentliche Kommentierung am 31. März 2026 abgelaufen; bislang keine Folgefassung publiziert), wie Hersteller Modul H mithilfe eines ISO-27001-konformen Informationssicherheits-Managementsystems (ISMS) umsetzen können.

Kernidee: Wenn Ihr Unternehmen bereits ISO 27001 zertifiziert ist oder ein ISMS nach dem BSI-Grundschutz implementiert hat, müssen Sie diesen Prozess nicht von Grund auf neu entwickeln. Stattdessen erweitern Sie das ISMS um produktspezifische Elemente:

  • 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

Die TR-03183-H liegt als Community Draft v1.0.0, Februar 2026 vor (öffentliche Kommentierung am 31. März 2026 abgelaufen; bislang keine Folgefassung publiziert). Stand 12.05.2026 ist v1.0.0 weiterhin die einzige öffentlich verfügbare Fassung.

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. Wer im Mai 2026 eine Klassifizierung vornimmt, kommt an der Implementing Regulation 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.

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 Vertrauenswürdigkeitsstufe "mittel" nach Art. 27) vollständig angewendet werden. Andernfalls ist auch hier Modul B+C oder Modul H verpflichtend.

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 ein europäisches Cybersicherheits­zertifikat mindestens auf Vertrauenswürdigkeitsstufe "mittel" gemäss Verordnung (EU) 2019/881.

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 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

Für kritische Produkte schreibt Art. 32 Abs. 4 vor: vorrangig ein europäisches Cybersicherheits­zertifizierungs­schema gemäss Art. 8 Abs. 1; sind dessen Voraussetzungen nicht erfüllt, kommen die Verfahren aus Abs. 3 (Modul B+C, Modul H oder europäisches Cybersicherheitszertifikat mindestens der Stufe „mittel") zur Anwendung.

Die Implementing Regulation 2025/2392

Die Durchführungsverordnung (EU) 2025/2392 der Kommission vom 28. November 2025 konkretisiert die Anhänge III und IV durch technische Beschreibungen der Produktkategorien. Sie 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.

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 oder europäisches Cybersicherheitszertifikat (Art. 27 Abs. 9) | | Anhang III Klasse I — bei vollständiger Anwendung harmonisierter Normen / Spezifikationen / Cyber-Cert | Modul A bleibt möglich | | Anhang III Klasse I — sonst | Modul B+C oder Modul H | | Anhang III Klasse II | Modul B+C, Modul H oder europäisches Cybersicherheitszertifikat (mind. „mittel") | | Anhang IV (kritisch) | Vorrangig europäisches Cybersicherheitszertifizierungsschema nach Art. 8 Abs. 1; sonst Modul B+C, Modul H oder europäisches Cybersicherheitszertifikat mindestens der Stufe „mittel" (Art. 32 Abs. 3) | | 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 Anhang III oder IV | Art. 43 KI-VO plus CRA-Modul nach Art. 32 (Art. 12 Abs. 3 CRA) |

Bisher ist als europäisches Schema der EUCC (European Common Criteria-based Certification Scheme) nach der Durchführungsverordnung (EU) 2024/482 vollständig anwendbar; weitere Schemata befinden sich in Vorbereitung. 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 Rolle der notifizierten Stellen

Notifizierte Stellen sind unabhängige, akkreditierte Konformitätsbewertungsstellen, die nach Kapitel IV CRA (Notifizierungsvorschriften) 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; die Akkreditierung ist der Regelweg im Notifizierungsverfahren: Im Regelfall sind notifizierte Stellen durch die nationale Akkreditierungsstelle akkreditiert (in Deutschland: die DAkkS) — Art. 42 f. CRA; eine Notifizierung ohne Akkreditierungsurkunde ist mit Nachweisunterlagen möglich.

Die Europäische Kommission führt das zentrale Register notifizierter Stellen über die Datenbank NANDO. Kapitel IV der CRA (Notifizierungsvorschriften) — und damit die Notifizierung — gilt nach Art. 71 ab dem 11. Juni 2026. In der Praxis ist deshalb in den Monaten vor Geltungsbeginn der CRA mit knappen Kapazitäten zu rechnen.

EU-Konformitätserklärung und CE-Kennzeichnung

Nach erfolgreicher Konformitätsbewertung erstellt der Hersteller zwei zentrale Dokumentationen.

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 Cybersicherheits­zertifikate
  • 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. Für Deutschland ist daher in der Regel eine deutschsprachige Fassung erforderlich; Mehrsprachigkeit ist möglich. Eine vereinfachte Form steht über Anhang VI zur Verfügung.

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.

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
  • TR-03183-2: Software Bill of Materials (SBOM) — Anforderungen an Aufbau und Pflege einer SBOM (aktuelle Fassung Version 2.1.0 vom September 2025)
  • TR-03183-3: Vulnerability Reports and Notifications — Anforderungen an Schwachstellenmeldungen
  • TR-03183-H — umfassende Qualitätssicherung (Modul H) auf Basis eines ISO-27001-/Grundschutz-konformen ISMS (Community Draft v1.0.0, Februar 2026; öffentliche Kommentierung am 31. März 2026 abgelaufen; bislang keine Folgefassung publiziert)

Diese Richtlinien sind nicht bindend, werden aber von notifizierten Stellen und Aufsichtsbehörden als State-of-the-Art herangezogen. Eine Abweichung sollte gut begründet sein.

Warum Modulwahl und Konformitätsbewertung in der Praxis scheitern

In der Theorie klingt die Modulwahl überschaubar: Klassifikation prüfen, Modul wählen, Dokumentation erstellen, CE-Kennzeichen anbringen. In der Praxis begegnen uns immer wieder dieselben Stolpersteine. Hersteller unterschätzen die Klassifizierung nach Anhang III/IV und die Präzisierungen der Durchführungsverordnung (EU) 2025/2392 — der Unterschied zwischen "Produkt mit Browser-Funktion" und "Browser-Produkt" ist in der Praxis oft nicht trivial und entscheidet über die gesamte Bewertungstiefe. Häufig wird zu früh auf Modul A gesetzt, und später stellt sich heraus, dass eine einzelne Komponente das Produkt in Klasse II rutschen lässt — mit der Folge, dass die bis dahin erstellte Dokumentation für eine Drittprüfung nicht ausreicht und von Grund auf neu aufgebaut werden muss.

Hinzu kommt: Das Post-Market-Monitoring nach Art. 13 und Art. 14 wird selten mitgedacht, obwohl es auch für Modul A verpflichtend ist. SBOM-Dokumentation, Schwachstellen­management und EU-Konformitätserklärung sind an Release-Zyklen gekoppelt und altern mit jeder Codeänderung. Notifizierte Stellen haben begrenzte Kapazität; in unserer Erfahrung sind in der Vorlaufphase der CRA mehrmonatige Wartezeiten realistisch — wer zu spät anfragt, verpasst den Marktstart. Und die BSI TR-03183-H liegt weiterhin als Community Draft v1.0.0, Februar 2026 vor (öffentliche Kommentierung am 31. März 2026 abgelaufen; bislang keine Folgefassung publiziert): Die Anforderungen können sich noch verändern, und Dokumentation, die nicht kontinuierlich gepflegt wird, verliert ihren Bezug zur aktuellen Fassung. Das ist kein einmaliges Projekt, sondern ein kontinuierlicher Compliance-Prozess.

crAIready unterstützt Ihre Konformitätsbewertung

crAIready ist die KI-gestützte CRA-Compliance-Plattform, die Sie bei der CRA-Konformitätsbewertung entlastet:

  • CRA-Navigator (Modul 1): KI-gestützte Klassifizierung nach Anhang III (Klasse I/II) und Anhang IV gemäss DVO (EU) 2025/2392 und Empfehlung des passenden Konformitätsverfahrens (A / B+C / H). Die finale Klassifizierung ist eine Hersteller-Entscheidung.
  • Dokumentation & Konformität (Modul 4): Konformitätsbewertung nach Anhang VIII mit Lückenmatrix und Nachweisen, technische Dokumentation nach Anhang VII und EU-Konformitätserklärung als Entwurf (Anhang V) — vom Hersteller zu prüfen und zu unterzeichnen.
  • Behörden-Dossier (Modul 4): ein kombiniertes PDF für Marktüberwachungsbehörden und notifizierte Stellen.

Eine erste, kostenlose Orientierung — unabhängig von der Plattform — bietet der öffentliche CRA-Quick-Check: In wenigen Minuten erhalten Sie eine orientierende Einschätzung zur CRA-Klassifizierung Ihres Produkts und zur Frage, welches Konformitätsbewertungsverfahren in Betracht kommt.

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, 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
  • Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 (insbesondere die Kommentierung von Sörup zu Art. 12 CRA, § 4 Rn. 64–65, sowie von Wiebe zu Art. 22 CRA, § 4 Rn. 29, und zum Unterstützungszeitraum nach Art. 13 Abs. 8 CRA, § 6 Rn. 25–27)
  • Der BSI Technical Guideline TR-03183 (Teile 1 bis 3) sowie dem TR-03183-H Community Draft v1.0.0, Februar 2026 (öffentliche Kommentierung am 31. März 2026 abgelaufen; bislang keine Folgefassung publiziert)
  • Der Verordnung (EU) 2019/881 (Cybersecurity Act) und der Durchführungsverordnung (EU) 2024/482 (EUCC)
  • Der KI-Verordnung (EU) 2024/1689, insbesondere Art. 43
  • 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

Alle regulatorischen Angaben sind zum Stand 12.05.2026 aktuell.

Quellen

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

Commission Implementing Regulation (EU) 2025/2392 vom 28. November 2025 – EUR-Lex

Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025

BSI – Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products

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

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

Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates – KI-Verordnung – EUR-Lex

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

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

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. Veröffentlicht am: 01.05.2026. Zuletzt geprüft am: 03.07.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Die wesentliche Änderung — wann ein Software-Update ein bereits in Verkehr gebrachtes Produkt erneut konformitätspflichtig macht, wie die EU-Kommission Funktions- von Sicherheitsupdates abgrenzt und was die Einstufung als wesentliche Änderung für die Konformitätsbewertung und für Altprodukte bedeutet.