Von Redaktion codAIx | 8. Juni 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. Der Annex zu C(2026) 5252 final enthält den von der Kommission am 27.07.2026 inhaltlich gebilligten Guidance-Entwurf und ersetzt für die Auswertung den bisherigen Entwurf Ares(2026)2319816 vom 03.03.2026. Die förmliche Annahme soll erfolgen, sobald alle Sprachfassungen vorliegen. Erst dann soll die Guidance als offizielle Auslegungshilfe der Kommission verwendet werden. Für die Konformitätsbewertung sind der CRA und die einschlägigen verbindlichen Rechtsakte massgeblich; die Guidance kann diese 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

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

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

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

Für EHR-Systeme tritt das EHDS-Verfahren damit an die Stelle der Module aus Anhang VIII CRA. Die materiellen Anforderungen des Anhang I CRA bleiben unberührt — nur 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 also 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

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

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. Der im Annex zu C(2026) 5252 final veröffentlichte Guidance-Entwurf 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 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?

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. Die verbreitete Erwartung, eine bestehende ISO-27001-Zertifizierung sei bereits die halbe Miete für Modul H, trifft in dieser Form nicht zu. 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 begründet das BSI dies ausführlich: Ein QMS nach ISO 9001 ist nicht auf Cybersicherheit ausgelegt, ein ISMS nach ISO/IEC 27001 ist 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 Cybersicherheits­zertifikat 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 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. Der veröffentlichte Guidance-Entwurf 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?

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

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.

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

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

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 das Endprodukt aufgrund seiner eigenen Kernfunktionalität als Klasse II einzustufen ist — 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 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. Dokumentation, die nicht kontinuierlich gepflegt wird, verliert damit zwangsläufig ihren Bezug zum jeweils aktuellen Stand. 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, 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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026 und im Annex als aktuelle Auswertungsgrundlage nach dem Entwurf Ares(2026)2319816 vom 03.03.2026 veröffentlicht; die förmliche Annahme soll nach Vorliegen aller Sprachfassungen erfolgen. Erst danach soll die Guidance als offizielle, weiterhin unverbindliche Auslegungshilfe der Kommission verwendet werden; 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

Versionshinweis (v24, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 08.06.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Versionshinweis (v23, 12.08.2026): Der Verfahrensstatus des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs wurde im Kasten zur Quellenhierarchie, im Fliesstext, in der Methodik und im Quellenverzeichnis präzisiert. Die Bezeichnungen „inhaltlich final“ und „finale Guidance“ wurden im aktuellen Artikeltext korrigiert. Verbindliche Rechtsakte und die nur erläuternde Funktion der Guidance werden klar getrennt. Die historischen Versionshinweise bleiben unverändert.

Alle regulatorischen Angaben sind zum Stand 06.08.2026 aktuell (v22: Ergänzung der EHDS-Weiche — Art. 32 Abs. 5a CRA, eingefügt durch Art. 104 Nr. 3 der Verordnung (EU) 2025/327, mit eigenem Abschnitt, neuer Zeile in der Übersicht der Konformitätsbewertungspfade, den Folgeänderungen in Art. 13 Abs. 4 und Art. 31 Abs. 3 CRA und dem EHDS-Zeitplan; zeitliche Einordnung des EUCC-Schemas nach Art. 50 der Durchführungsverordnung (EU) 2024/482 (Geltung seit 27.02.2025); Hinweis auf das BSI als vorgesehene notifizierende Behörde nach Art. 36 Abs. 1 CRA mit Querverweis auf Teil 10 der Serie; Korrektur der Vorschau am Artikelende auf den tatsächlich folgenden Teil 10; Aufnahme der Verordnung (EU) 2025/327 in Methodik und Quellenverzeichnis. v21: Ergänzungen aus dem juristischen Kommentar Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Aufl. 2026, Nomos (NK-CRA), Kommentierung des Art. 32 CRA durch Hessel — Klarstellung, dass der Modul-A-Pfad für freie und quelloffene Software nach Art. 32 Abs. 5 CRA auch ohne Anwendung harmonisierter Normen oder gemeinsamer Spezifikationen offensteht (Rn. 35); Präzisierung der Klasse-I-Voraussetzungen um das europäische Zertifizierungsschema mindestens der Vertrauenswürdigkeitsstufe „mittel“ (Rn. 22); zusätzlicher Beleg zur Kernfunktionalität und zu integrierten Komponenten einschliesslich der Klarstellung, dass abweichende Kernfunktionen die strengeren Voraussetzungen des Art. 32 Abs. 2 bis 5 CRA nicht auslösen (Rn. 23–26); Aufnahme des Kommentars in Methodik und Quellenverzeichnis. v20: Aktualisierung der BSI TR-03183-H auf die publizierte Version 1.1.0 vom 30.05.2026 und Streichung der Draft-Hinweise; Ergänzung der ISO-9001-Anforderungen und des integrierten Managementsystems als Kernaussage zu Modul H; Entfernung des nicht belegten Grundschutz-Bezugs; Präzisierung von Prüfumfang, Auditzyklus und Skalierbarkeitsgrenzen des Moduls H; Ergänzung des Open-Source-Pfads nach Art. 32 Abs. 5 CRA einschliesslich neuer Tabellenzeile; Aktualisierung des Normungszeitplans nach FAQ 6.10; Ergänzung von Modul B+C um FAQ 6.2; Präzisierung der Meldepflicht bei Komponentenschwachstellen nach FAQ 5.4 und Guidance Rn. 218; Korrektur und Ergänzung der Versionsangaben zu TR-03183 Teil 1 bis 3; Ersetzung der Pauschalaussage zur Verbindlichkeit der BSI-Richtlinien durch die belegte Selbstbeschreibung der TR-03183-1; Aufnahme des ENISA Secure by Design and Default Playbook und der JRC/ENISA-Normen-Mapping-Analyse. v19: Aktualisierung auf die am 27.07.2026 inhaltlich final vorliegende EU-Kommissions-Guidance C(2026) 5252 final, Annex, welche den bisherigen Entwurf Ares(2026)2319816 vom 03.03.2026 ersetzt; Anpassung der Rn.-Verweise zur Due Diligence auf Kapitel 7.3, Rn. 167–173, Ergänzung der Nachweis-Artefakte aus Kapitel 8.2, Rn. 207, sowie Referenzierung von Kapitel 6.1, Rn. 139–142, zur Kernfunktionalität. Hinweis zur Versionshistorie: Bei der Erstellung der Version v19 wurde die vorherige Datei v18 versehentlich mit dem Inhalt von v19 überschrieben; ihr ursprünglicher Stand mit den alten Draft-Zitaten war auf diesem Weg nicht mehr rekonstruierbar und wurde entfernt. Die letzte bekannte, unveränderte Vorversion ist v17, archiviert unter „Alte Versionen (Stand 2026-07-06)“).

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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026. Der Annex ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Für die Konformitätsbewertung sind der CRA und die einschlägigen verbindlichen Rechtsakte massgeblich; die Guidance kann diese erläutern, aber weder ergänzen noch ersetzen (Stand 12.08.2026). 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. Zuletzt geprüft am: 13.08.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.

Stand: 13.08.2026 (v25 — freigegebene Schlusskorrektur: Vermutungswirkung Art. 12 Abs. 1 und Verfahrensregel Art. 12 Abs. 2 getrennt; automatische Höherstufung des Endprodukts durch eine integrierte Komponente korrigiert; Markdown-Fehler behoben. Vorherige Fassung: v24; zeitabhängige Formulierungen unverändert.)