Viele Softwarehersteller starten mit der Annahme, sie könnten ihre CRA-Konformität selbst bewerten. Für Standardprodukte stimmt das häufig. Bei wichtigen oder kritischen Produkten kann eine notifizierte Stelle jedoch zwingend werden — und dann verändern sich Kosten, Zeitplan und Dokumentation erheblich. Art. 32 CRA verweist dafür auf vier Module aus Anhang VIII: die interne Kontrolle (Modul A), die Baumusterprüfung mit anschliessender Konformität zum Baumuster (Module B+C) und die umfassende Qualitätssicherung (Modul H). Welcher Weg offensteht, hängt zunächst von der Klassifizierung des Produkts ab.

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 Kommission veröffentlichte ihre nicht verbindliche Guidance am 27.07.2026 mit Communication C(2026) 5252 final. Sie ersetzt für diese Auswertung den bisherigen Entwurf Ares(2026)2319816 vom 03.03.2026 und kann die verbindlichen Rechtsakte erläutern, aber weder ergänzen noch ersetzen. Harmonisierte EU-Normen (CEN/CENELEC/ETSI, Normungsauftrag M/606) entstehen gestaffelt: Nach der FAQ der Kommissionsdienststellen (Abschnitt 6.10) sollen die horizontalen Normen zu Design, Entwicklung und Herstellung sowie zur Schwachstellenbehandlung bis zum 30.08.2026 von den europäischen Normungsorganisationen verabschiedet werden, die 26 vertikalen Normen (31 Deliverables) bis zum 30.10.2026 — die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I aber erst bis zum 30.10.2027, also rund sechs Wochen vor Geltungsbeginn. Die Konformitätsvermutung nach Art. 27 CRA entsteht zudem erst mit der Veröffentlichung der Fundstelle im Amtsblatt, nicht bereits mit der Verabschiedung durch die Normungsorganisationen. 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. Als vierte Kategorie kommen unverbindliche technische Praxishilfen hinzu: 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 — es ist ausdrücklich keine Rechtsberatung, 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. 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; daneben Klasse I bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Zertifizierungsschemas 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. Die Eigenverantwortung reduziert externe Kosten, verlangt aber rigorose interne Dokumentation und Nachvollziehbarkeit.

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 Abschnitt 6.1 ausdrücklich für wichtige Produkte der Klasse I und der Klasse II; Abschnitt 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 der juristische Kommentar zum 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. Einzige Bedingung bleibt die Veröffentlichung der technischen Dokumentation nach Art. 31 CRA zum Zeitpunkt des Inverkehrbringens (NK-CRA/Hessel, 1. Aufl. 2026, CRA Art. 32 Rn. 35).

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 bereitzustellen — kürzer nur, wenn die voraussichtliche Nutzungsdauer erkennbar darunter liegt. Festzulegen ist dabei kein Zeitraum, sondern ein Enddatum, das nach Art. 13 Abs. 19 CRA anzugeben ist (dazu ausführlich Teil 3: Abgestufte CRA-Pflichten). 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

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 (Abschnitt 6.2) 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. 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“.

Die Schnittstelle zur KI-Verordnung: Art. 12 CRA

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

  • Art. 12 Abs. 1 CRA — Vermutungswirkung für Hochrisiko-KI: Erfüllt ein Hochrisiko-KI-Produkt die in Art. 12 Abs. 1 Buchst. 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, 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 zunächst prüfen, ob die Vermutungswirkung des Art. 12 Abs. 1 CRA greift und welches Konformitätsbewertungsverfahren nach Abs. 2 oder 3 anzuwenden ist. Eine Modul-A-Selbstbewertung ohne diese Vorabprüfung ist nicht tragfähig.

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). 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; 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.

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

  • Datum der Bewertung
  • Produktidentifikation: Name und Modell, Beschreibung sowie Zweckbestimmung und vernünftigerweise vorhersehbare Verwendung, Hardware- und Softwareversion, 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. Die Klassifizierung nach Anhang III bezieht sich auf das Endprodukt, nicht auf eingebettete Komponenten; der juristische Kommentar zum CRA bestätigt das und hält zugleich fest, dass der Hersteller die Sicherheit des Gesamtprodukts unter Berücksichtigung der integrierten Komponenten bewerten muss (NK-CRA/Hessel, 1. Aufl. 2026, CRA Art. 32 Rn. 25). 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 mit Communication C(2026) 5252 final veröffentlichte Guidance der EU-Kommission konkretisiert in Kapitel 7.3 (Rn. 167–173), welche Evidenz „angemessen“ ist: Nach Rn. 171 kann dies Dokumentation des Komponentenherstellers umfassen — etwa technische Spezifikationen, Sicherheitsdokumentation oder einschlägige Konformitäts- bzw. Assurance-Dokumentation —, ergänzt um eigene Tests des Integrators, soweit angebracht. Als wiederverwendbare Nachweis-Artefakte nennt die Guidance in Kapitel 8.2 (Rn. 207) u. a. Nachweise nach der NIS-2-Durchführungsverordnung (EU) 2024/2690, DORA-Nachweise, Zertifizierungen nach dem Cybersecurity Act sowie ISO/IEC 27017:2015 und ISO/IEC 27001:2022 (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. Diese Meldepflicht hat allerdings eine Grenze: Ist dem Hersteller bekannt, dass die integrierte Komponente eine Schwachstelle enthält, die in seinem Produkt nicht ausnutzbar ist (etwa weil der verwundbare Code nicht erreichbar ist) oder dort nicht ausgenutzt wurde, gilt sie nach der FAQ der Kommissionsdienststellen (Abschnitt 5.4) und der EU-Kommissions-Guidance (Rn. 218) nicht als aktiv ausgenutzte Schwachstelle seines Produkts und unterliegt keiner Meldepflicht — die freiwillige Meldung nach Art. 15 CRA, die Meldung an den Komponentenhersteller nach Art. 13 Abs. 6 CRA und die Pflichten zur Schwachstellenbehandlung nach Anhang I Teil II bleiben unberührt.

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 weder harmonisierte Normen oder gemeinsame Spezifikationen vollständig angewendet werden noch ein europäisches Schema für die Cybersicherheitszertifizierung mindestens der Vertrauenswürdigkeitsstufe „mittel“ nach Art. 27 CRA greift
  • Wichtige Produkte mit digitalen Elementen Klasse II (Anhang III)
  • Kritische Produkte mit digitalen Elementen (Anhang IV) — sofern kein europäisches Cybersicherheitszertifizierungsschema nach Art. 8 Abs. 1 zur Anwendung kommt

Die notifizierte Stelle bewertet hier — anders als bei Modul A — 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?

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:

  • 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): Modul H ist unter dem CRA nicht nur eine Qualitätssystem-Zertifizierung, sondern schliesst die Prüfung der technischen Dokumentation für ein Modell je Produktkategorie ein. Modul H lässt sich daher weder ohne detaillierte Stichprobe eines repräsentativen Produkts erreichen 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.

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. Teil 1, 2 und 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 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.

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. Die BSI TR-03183-1 nennt in Kap. 3.8.2 zusätzlich ausdrücklich Smart-Home-Produkte mit Sicherheitsfunktion, mit dem Internet verbundene Spielzeuge und persönliche tragbare Geräte — Kategorien, die im Consumer- und Gebäudetechnik-Umfeld leicht übersehen werden.

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 verengen sich die zulässigen Verfahren auf Modul B+C oder Modul H (so auch NK-CRA/Hessel, 1. Aufl. 2026, CRA Art. 32 Rn. 22; die dritte Alternative — ein europäisches Schema für die Cybersicherheitszertifizierung mit mindestens der Vertrauenswürdigkeitsstufe „mittel“ — wird in der Praxis häufig übersehen). Genau hier wirkt sich der Normungszeitplan aus: Solange die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I aussteht (geplante Verabschiedung 30.10.2027) und die Fundstellen noch nicht im Amtsblatt veröffentlicht sind, lässt sich die Voraussetzung „vollständige Anwendung“ für Klasse-I-Produkte praktisch kaum belegen. Unberührt bleibt der Open-Source-Pfad nach Art. 32 Abs. 5 CRA.

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 Cybersicherheitszertifikat mindestens auf Vertrauenswürdigkeitsstufe „mittel“ gemäss Verordnung (EU) 2019/881 — es sei denn, es greift die Open-Source-Ausnahme des Art. 32 Abs. 5 CRA mit öffentlich zugänglicher technischer Dokumentation.

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

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 — eine hilfreiche Orientierung, die den Wortlaut des Anhang IV allerdings nicht ersetzt.

Für kritische Produkte schreibt Art. 32 Abs. 4 vor: vorrangig ein europäisches Cybersicherheitszertifizierungsschema 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. Die veröffentlichte Guidance der EU-Kommission erläutert diesen Massstab in Kapitel 6.1 (Rn. 139–142): 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. Der juristische Kommentar zum CRA zieht 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, 1. Aufl. 2026, CRA Art. 32 Rn. 23–26).

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

Wahlmöglichkeit nach Art. 32 CRA je Produktkategorie:

  • 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, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas (mindestens Stufe „mittel“): 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 (mindestens Stufe „mittel“)
  • 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): 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)
  • 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)

Bisher ist als europäisches Schema der EUCC (European Common Criteria-based Certification Scheme) nach der Durchführungsverordnung (EU) 2024/482 vollständig anwendbar. Massgeblich ist deren Art. 50: Die Durchführungsverordnung gilt seit dem 27. Februar 2025; lediglich Kapitel IV und Anhang V waren bereits ab ihrem Inkrafttreten 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 gemeinsame Analyse von JRC und ENISA, „Cyber Resilience Act Requirements Standards Mapping“ (EUR 31892 EN, 2024), kommt zu dem Ergebnis, dass die bestehenden Normen die CRA-Anforderungen zwar zumindest teilweise abdecken, es aber keine einzelne Norm gibt, die alle Anforderungen des Anhang I allein erfüllt, und hält zu EN 303 645 ausdrücklich fest, dass eine automatische Übertragbarkeit auf alle Produktkategorien nicht angenommen werden kann, weil die Norm auf IoT-Systeme zugeschnitten ist; zu beachten ist dabei, dass diese Analyse noch auf dem Kommissionsvorschlag COM/2022/454 von 2022 beruht und ihre Anforderungsnummerierung daher nicht der geltenden Verordnung entspricht.

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.

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. In den Monaten vor Geltungsbeginn des CRA ist deshalb mit knappen Kapazitäten zu rechnen.

Welche Behörde notifiziert, bestimmt der jeweilige Mitgliedstaat. In Deutschland soll diese Aufgabe das BSI übernehmen: Das Cyberresilienz-Durchführungsgesetz weist dem BSI die Rolle der notifizierenden Behörde nach Art. 36 Abs. 1 CRA zu — mit der umstrittenen Möglichkeit, im Ausnahmefall auch ohne Akkreditierung durch die Deutsche Akkreditierungsstelle (DAkkS) zu notifizieren. Was das für Hersteller bedeutet, haben wir in Teil 10: Das BSI als CRA-Marktüberwachung dargestellt.

EU-Konformitätserklärung und CE-Kennzeichnung

Ist die Konformitätsbewertung abgeschlossen, 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 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. 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, Version 1.0.0, ausdrücklich als „Living Document“ gekennzeichnet (Datierungshinweis: Deckblatt und Changelog des Dokuments widersprechen einander — 31.07.2026 gegenüber 31.07.2025; eine eindeutige Zuordnung ist nicht möglich, weshalb hier auf eine Datumsangabe verzichtet wird)
  • 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 (öffentliche Kommentierung der Vorfassung am 31. März 2026 abgelaufen)

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.

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. Zugleich sind die Kapazitäten notifizierter Stellen begrenzt. Nach unserer Erfahrung sind in der CRA-Vorlaufphase Wartezeiten von mehreren Monaten realistisch — eine späte Anfrage kann den Marktstart gefährden. 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 teilweise erst für 2026 und 2027 vorgesehen sind. Ohne kontinuierliche Pflege verliert die Dokumentation zwangsläufig den Bezug zum jeweils aktuellen Stand. Konformitätsbewertung ist daher kein einmaliges Projekt, sondern ein fortlaufender Compliance-Prozess.

crAIready unterstützt Ihre Konformitätsbewertung

crAIready bündelt die für eine CRA-Konformitätsbewertung benötigten Arbeitsschritte:

  • Der Onboarding-Wizard: Der KI-gestützte Onboarding-Wizard führt Sie von den Angaben zu Ihrem Produkt und seiner Kernfunktion bis zu einer konkreten Empfehlung. Berücksichtigt werden die einschlägigen Produktkategorien aus Anhang III (wichtige Produkte der Klassen I und II) sowie Anhang IV CRA (kritische Produkte) und deren technische Beschreibungen nach der Durchführungsverordnung (EU) 2025/2392. Die abschliessende rechtliche Einordnung bleibt Aufgabe und Verantwortung des Herstellers.
  • Dokumentation & Konformität: crAIready erstellt auf Grundlage Ihrer Angaben einen strukturierten Entwurf der technischen Dokumentation nach Anhang VII und einen Entwurf der EU-Konformitätserklärung nach Art. 28 in Verbindung mit Anhang V CRA. Prüfung, Ergänzung, Freigabe und Unterzeichnung bleiben beim Hersteller. Ergänzend werden Benutzerinformationen nach Anhang II und Nachweise für das anwendbare Konformitätsbewertungsverfahren strukturiert vorbereitet.

Für eine erste Einordnung können Sie unabhängig von der Plattform den öffentlichen CRA-Quick-Check nutzen. Er unterstützt mit wenigen Fragen eine kostenlose und unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte. Die vertiefte Produktklassifizierung und die Empfehlung eines möglichen Konformitätsbewertungsverfahrens erfolgen im Onboarding-Wizard; die abschliessende Einordnung bleibt beim Hersteller. Keine Rechtsberatung im Sinne des RDG.

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 und Rn. 218 zu Schwachstellen in Drittkomponenten
  • Den „FAQs on the Cyber Resilience Act“ der Kommissionsdienststellen, Version 1.3 vom 01.07.2026, insbesondere Abschnitte 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
  • 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)
  • Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter), artikelweiser Kommentar zur Verordnung (EU) 2024/2847; herangezogen wurde die 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 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, 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

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

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. 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. Kapitel 7.3 (Rn. 167–173) zur Due Diligence, Kapitel 6.1 (Rn. 139–142) zur Kernfunktionalität, Rn. 218 zu Schwachstellen in Drittkomponenten. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation (Annex-Download: https://ec.europa.eu/newsroom/dae/redirection/document/131456).

Europäische Kommission (Kommissionsdienststellen), „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.2026. Living Document; nach eigenem Hinweis nicht als offizielle Position der Europäischen Kommission zu verstehen.

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

Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 32 kommentiert von Hessel.

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.

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

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.

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

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: 08.06.2026. Fachlich geprüft am: 13.08.2026. Produktbeschreibung aktualisiert am: 06.09.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Das BSI als CRA-Marktüberwachung — warum das Cyberresilienz-Durchführungsgesetz das BSI zur zentralen Marktüberwachungs- und notifizierenden Behörde macht, was Bitkom, TeleTrusT und OSBA daran kritisieren und was Hersteller für den nationalen Vollzug einplanen sollten.