CRA 5/5: Die Summe aller CRA-Notwendigkeiten: Was sind die technische Dokumentation und die EU-Konformitätserklärung?

„Trust before control” kann nur funktionieren, wenn die Selbsterklärung der Hersteller wirklich substanziell ist. Also unterlegt durch:

• technische Dokumentation,
• Risikobewertungen,
• Testberichte
• und, je nach Produktklasse, durch die Prüfung einer notifizierten Stelle (einer staatlich benannten, unabhängigen Prüforganisation).

Die Mechanismen dieses Nachweissystems — die drei Konformitätsbewertungsmodule, die Konformitätsvermutung, die technische Dokumentation nach Anhang VII und die CE-Kennzeichnung samt ihren Besonderheiten bei Software — gilt es daher genau zu verstehen.

Den Anfang macht die erste Weichenstellung: Wie streng geprüft wird, hängt von der Risikoklasse ab.

Die drei Konformitätsbewertungsmodule des Cyber Resilience Act

Der CRA kennt drei grundlegende Konformitätsbewertungsverfahren. Sie stammen nicht aus dem CRA selbst, sondern aus dem sogenannten New Legislative Framework, einem standardisierten Baukasten, den die EU seit Jahren für nahezu alle Produktverordnungen nutzt (von Maschinen bis Medizinprodukten).

Wer bereits CE-gekennzeichnete Produkte in Verkehr bringt, wird die Logik also wiedererkennen: Der CRA erfindet die Konformitätsbewertung nicht neu.

Welches Modul anzuwenden ist, hängt von der Produktklasse ab. Zur Erinnerung: Der CRA teilt Produkte in vier Kategorien — Standard, Wichtig (Klasse I und II) und Kritisch —, die wir im zweiten Artikel dieser Serie zur CRA-Cyberrisikobewertung eingeführt haben. In welche ein konkretes Produkt fällt, ergibt sich aus den Anhängen III und IV des CRA; die weit überwiegende Mehrheit landet in der Standardkategorie.

Modul A: Interne Kontrolle

Modul A ist die Selbstbewertung durch den Hersteller, das am wenigsten aufwändige Verfahren, ausreichend für:

• Default-Kategorie: Alle Produkte, die nicht explizit als wichtig oder kritisch eingestuft sind, können ausschließlich nach Modul A bewertet werden (s. Art. 32 Abs. 1).
• Important Class I mit harmonisierten Normen: Für wichtige Produkte der Klasse I gibt es eine Erleichterung: Wer anerkannte Standards vollständig anwendet, also harmonisierte Normen (im CRA-Kontext voraussichtlich die entstehende EN-40000-Reihe, die wir in den vorangegangenen Artikeln vorgestellt haben, sobald sie im EU-Amtsblatt zitiert ist), gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema (mindestens Stufe „mittel”), darf auch hier bei der Selbstbewertung nach Modul A bleiben, statt eine notifizierte Stelle einzuschalten (andersherum formuliert im CRA, s. Art. 32 Abs. 2).

Das wirft die berechtigte Frage auf, wie ein Hersteller belegt, dass er eine harmonisierte Norm tatsächlich vollständig anwendet.

Ein externes Audit ist dafür nicht nötig: Die vollständige Anwendung löst die Konformitätsvermutung nach Art. 27 aus, die Erfüllung der abgedeckten Anforderungen wird also vermutet, solange nichts Gegenteiliges vorliegt.

Belegt wird sie in der technischen Dokumentation (s. Art. 31 i. V. m. Anhang VII), in der die angewandten Normen aufzulisten und je zutreffender Anforderung nachzuweisen ist, wie das Produkt sie erfüllt. Diese Dokumentation kann die Marktüberwachungsbehörde jederzeit anfordern; erweist sich die Normanwendung als unvollständig, entfällt die Vermutung. Eine folgenlose Behauptung ist die Selbsterklärung damit nicht.

Im Rahmen von Modul A stellt der Hersteller sicher und erklärt auf eigene Verantwortung, dass Produkt und Prozesse die grundlegenden Cybersicherheitsanforderungen erfüllen.

Er erstellt die technische Dokumentation, führt die Konformitätsbewertung durch, stellt die EU-Konformitätserklärung aus und bringt die CE-Kennzeichnung an. Keine externe Prüfung. Aber: die gesamte Nachweislast liegt beim Hersteller.

Das ist weniger einfach, als es klingt.

Modul A bedeutet nicht, dass weniger zu tun ist. Letztlich erfolgt die Überprüfung nicht extern, sondern intern. Technische Dokumentation, Risikobewertung und Testberichte müssen genauso substanziell sein wie bei einer Drittprüfung. Der Unterschied liegt in der Verifikationsinstanz, nicht im Anforderungsniveau.

Eine wichtige Sonderregel: Hersteller wichtiger Produkte der Klasse I, die als freie und quelloffene Software gelten, können Modul A anwenden, sofern sie die technische Dokumentation öffentlich zugänglich machen (s. Art. 32 Abs. 5). Dies stellt eine Erleichterung für Open-Source-Hersteller dar, die die Transparenz ihrer Entwicklung als Vertrauensmechanismus nutzen.

Modul B+C: EU-Baumusterprüfung und Fertigungskontrolle

Reicht die Selbstbewertung nicht aus, kommt eine externe Prüfung ins Spiel, die sogenannte „Drittprüfung”.

Das heißt: Nicht der Hersteller selbst, sondern eine unabhängige, staatlich benannte Prüforganisation (die notifizierte Stelle) bestätigt die Konformität. Modul B+C ist einer von zwei zulässigen Wegen dafür (der andere ist Modul H).

Der Name beschreibt zwei aufeinanderfolgende Schritte:

• Modul B ist die EU-Baumusterprüfung — die notifizierte Stelle prüft technische Dokumentation, Produktdesign und Muster und stellt bei positivem Ergebnis eine Baumusterprüfbescheinigung aus.
• Modul C ist die anschließende Fertigungskontrolle, bei der der Hersteller sicherstellt, dass die tatsächlich produzierten Einheiten mit dem geprüften Baumuster übereinstimmen.

Kurz: erst wird der Prototyp geprüft, dann die Serie an ihn gebunden.

Wann Modul B+C (oder alternativ Modul H) greift:

• Wichtig, Klasse I ohne anerkannte Normen: Wer die einschlägigen Normen, Spezifikationen oder Zertifizierungsschemata nicht oder nur teilweise anwendet, verliert die Möglichkeit zur Selbstbewertung — dann ist eine externe Prüfung über Modul B+C oder alternativ Modul H fällig (s. Art. 32 Abs. 2).
• Wichtig, Klasse II: Hier führt kein Weg an der externen Prüfung vorbei — sie ist immer erforderlich, selbst bei vollständiger Normanwendung. Modul B+C ist einer der zulässigen Wege (s. Art. 32 Abs. 3).

Der Ablauf in der Praxis:

1. Der Hersteller reicht bei einer notifizierten Stelle seiner Wahl einen Antrag ein — mit technischer Dokumentation, einer Beschreibung des Produkts und seiner Zweckbestimmung sowie Mustern.
2. Die Stelle prüft die Unterlagen, führt Tests und Untersuchungen durch und stellt bei positivem Ergebnis die Baumusterprüfbescheinigung aus, die die Konformität des geprüften Baumusters mit den Essential Requirements des CRA bestätigt.
3. Diese Bescheinigung ist die Grundlage für die CE-Kennzeichnung.

Modul H: Umfassende Qualitätssicherung

Modul H ist die dritte Option. Sie setzt an einer ganz anderen Stelle an als Modul B+C. Statt ein einzelnes Produktmuster zu prüfen, wird hier der gesamte Herstellungsprozess zertifiziert.

Die Idee dahinter: Wenn nachweislich sichergestellt ist, dass ein Unternehmen strukturiert und sicher entwickelt und produziert, muss nicht jedes Produkt einzeln extern geprüft werden.

Konkret heißt das: Eine notifizierte Stelle bewertet einmalig das Qualitätsmanagementsystem (kurz QMS) des Herstellers und lässt es zu. Dieses System muss dann den gesamten Produktlebenszyklus abdecken: von der Konzeption über Entwicklung und Herstellung bis zur Schwachstellenbehandlung. Dabei garantiert das QMS, dass alle produzierten Einheiten die Essential Cybersecurity Requirements erfüllen.

Ist das System einmal zugelassen, kann der Hersteller seine Produkte ohne weitere Einzelprüfungen in Verkehr bringen, solange er das System aufrechterhält und die regelmäßigen Überwachungsaudits der notifizierten Stelle erfolgreich besteht. (Eine feste Frequenz schreibt der CRA dafür nicht vor; er verlangt regelmäßige Audits und erlaubt der notifizierten Stelle auch unangekündigte Überprüfungen.)

Wann sich das lohnt: vor allem für Hersteller, die ohnehin schon mit etablierten QM-Systemen arbeiten, etwa nach ISO 9001 oder ISO 27001, und viele oder häufig wechselnde Produkte im Portfolio haben.

Für sie ist es effizienter, einmal den Prozess zertifizieren zu lassen, als bei jedem neuen Produkt oder jeder Variante erneut eine Baumusterprüfung zu durchlaufen.

Ein Hersteller mit einem einzelnen, langlebigen Produkt fährt dagegen mit Modul B+C oft einfacher. Zulässig ist Modul H für dieselben Produktklassen wie Modul B+C (s. Art. 32 Abs. 2 und 3).

Kritische Produkte (CRA-Anhang IV): der Sonderfall staatlich geprüfter Zertifizierung

Ganz oben in der Risikopyramide steht eine kleine Gruppe kritischer Produkte, aufgeführt in Anhang IV. Dazu zählen etwa Hardware-Sicherheitsmodule, Smart-Meter-Gateways und Chipkarten beziehungsweise Sicherheitselemente, also Bauteile, deren ganzer Zweck der Schutz sicherheitskritischer Funktionen ist.

Bei diesen Produkten genügt die Selbstbewertung und auch die normale Drittprüfung nicht.

Verlangt wird eine förmliche Zertifizierung nach einem europäischen Cybersicherheitszertifizierungsschema, also nach einem staatlich festgelegten, einheitlichen Prüfstandard. Das derzeit wichtigste dieser Schemata ist das EUCC (European Common Criteria-based Cybersecurity Certification Scheme), das auf den international etablierten Common Criteria aufbaut.

Welche kritischen Produkte konkret unter diese Pflicht fallen und wie streng sie geprüft werden müssen, legt die EU-Kommission nach und nach fest. Solange das für ein bestimmtes Produkt noch nicht geschehen ist, gilt als Übergang die Prüfung nach den Regeln der höchsten regulären Stufe (Wichtig, Klasse II). Für die Praxis heißt das: Der Kreis wächst schrittweise, und bis dahin greift der bereits beschriebene Weg über die notifizierte Stelle.

Prüforganisationen und notifizierte Stellen für den CRA — Verfügbarkeit und praktische Relevanz

Wer sein Produkt nicht selbst prüfen darf, sondern eine externe Prüfung braucht (bei den Verfahren Modul B+C oder H), kommt an einer sogenannten notifizierten Stelle nicht vorbei. Das sind unabhängige Prüforganisationen (oft private Firmen wie TÜV oder DEKRA), die von einem EU-Mitgliedstaat offiziell dafür zugelassen und dann in einer zentralen EU-Datenbank gelistet werden, der NANDO (New Approach Notified and Designated Organisations ).

Nur wer dort steht, darf die Prüfung tatsächlich durchführen.

Damit es genug davon gibt, baut der CRA diese Prüf-Landschaft schrittweise auf. Erst seit dem 11. Juni 2026 gelten die Regeln, nach denen solche Stellen überhaupt erst zugelassen werden können. Und bis zum 11. Dezember 2026 sollen die Mitgliedstaaten für eine ausreichende Zahl sorgen, damit es beim Marktzugang nicht zum Stau kommt. Das „sollen” ist hier wörtlich zu nehmen: Es ist ein Ziel, zu dem sich die Länder bemühen müssen, keine feste Garantie, dass es rechtzeitig klappt.

Und genau da liegt das Problem für die Planung: Stand jetzt, Ende September 2026, ist die NANDO-Liste für den CRA praktisch leer, keine einzige zugelassene Stelle.

Das hat einen simplen Grund: Bis eine Stelle offiziell in der Datenbank auftaucht, greift eine mehrstufige Kette. Zunächst bewertet in der Regel die nationale Akkreditierungsstelle die fachliche Kompetenz der Prüforganisation, in Deutschland die Deutsche Akkreditierungsstelle (DAkkS). Auf dieser Grundlage notifiziert die zuständige notifizierende Behörde die Stelle offiziell bei der EU-Kommission, in Deutschland das Bundesamt für Sicherheit in der Informationstechnik (BSI). Erst danach erscheint der Eintrag in NANDO.

Diese Kette ist (Stand Ende September 2026) angelaufen, aber noch nicht durch: Das BSI-Verfahren startete pünktlich am 11. Juni 2026, die DAkkS nimmt Anträge für den Geltungsbereich CRA entgegen, und seit dem 25. September 2026 stellt das BSI der DAkkS eigene Fachbegutachter für die Akkreditierungsverfahren. Das nationale CRA-Durchführungsgesetz befindet sich dabei noch im Gesetzgebungsverfahren. Wer ein Produkt der höheren Risikoklassen plant, kann die Prüfung heute dennoch schlicht nicht abschließen: Die Stellen sind noch nicht benannt.

Der CRA und die Konformitätsvermutung: warum harmonisierte Normen den Nachweis so viel leichter machen

Hinter dem sperrigen Wort der Konformitätsvermutung steckt einer der praktisch wichtigsten Mechanismen des ganzen Systems rund um den Cyber Resilience Act.

Der Grundgedanke: Normalerweise müsste ein Hersteller für jede einzelne der Anforderungen aus Anhang I selbst belegen, dass und wie er sie erfüllt. Genau diesen Aufwand nimmt ihm die Konformitätsvermutung ab.

Sie funktioniert über sogenannte harmonisierte Normen. Das sind die in den vorangegangenen Artikeln dieser Serie immer wieder erwähnten technischen Standards, die im Auftrag der EU-Kommission speziell zu einer Verordnung entwickelt und anschließend im EU-Amtsblatt gelistet werden. Wendet ein Hersteller eine solche Norm vollständig an, so wird automatisch vermutet, dass er die davon abgedeckten CRA-Anforderungen erfüllt. Er muss dann nichts mehr Punkt für Punkt einzeln nachweisen. Die Erfüllung gilt als gegeben, solange niemand das Gegenteil belegt.

Diese Handhabe hat einen immensen Vorteil für die Dokumentation (und die mögliche Auseinandersetzung mit den Marktüberwachungsbehörden): Man kann sich auf einen anerkannten, überprüfbaren Standard stützen statt auf eine eigens entwickelte Begründung und Nachweiskette. Hinzu kommt, dass eine Norm im Arbeitsalltag deutlich handhabbarer ist als der Gesetzestext selbst: Sie übersetzt die abstrakten Vorgaben des CRA in konkrete, prüfbare Anforderungen und nimmt dem Hersteller so die Interpretationsarbeit ab, die er sonst für jede einzelne gesetzliche Anforderung leisten müsste. Und die Wirkung reicht über das einzelne Produkt hinaus: Die horizontale EN-40000-Reihe bildet den gemeinsamen Rahmen, auf dem die entstehenden vertikalen, produktspezifischen Normen aufsetzen. Wer sich früh an ihr orientiert, schafft damit zugleich die Grundlage, um später auf die passende vertikale Norm aufzubauen.

Zwei Dinge sind allerdings wichtig, damit dieser Vorteil nicht zur Falle wird:

1. Diese Vermutung hebt keine inhaltliche Pflicht auf. Wer sich auf eine Norm beruft, muss sie tatsächlich vollständig anwenden und nicht bloß formal auf sie verweisen. Der Verweis auf eine Norm, die im Produkt gar nicht umgesetzt ist, trägt nicht.
2. Die Vermutung deckt nicht automatisch alles ab. Die Prozesspflichten aus Anhang I Teil II, also das laufende CRA-Vulnerability-Handling aus dem vierten Artikel dieser Artikelserie, beschreiben keine Produkteigenschaften, sondern Herstellerprozesse, und werden von den Normen bislang nur teilweise erfasst. Für diesen Teil bleibt der eigene Nachweis nötig.

Genau hier liegt aktuell die praktische Einschränkung, wie bereits geschildert: Noch ist für den CRA keine harmonisierte Norm im EU-Amtsblatt gelistet. Die Konformitätsvermutung ist also bereits im Gesetz angelegt, greift in der Praxis aber erst, sobald die entsprechenden Normen, etwa aus der EN-40000-Reihe, offiziell referenziert sind.

Einige Experten raten daher gegenwärtig: Bis dahin führt für den Nachweis kein Weg an der einzelnen Begründung je Anforderung vorbei.

Der Blick nach vorn: Welche Normen und Hilfestellungen die CRA-Umsetzung künftig erleichtern

Dieser Einzelnachweis je Anforderung ist allerdings nur der heutige Zustand, kein Dauerzustand.

Es lohnt sich daher, die verfügbaren und kommenden Hilfestellungen geordnet in den Blick zu nehmen, und zwar nicht als flache Liste, sondern nach ihrer zeitlichen Reife: Was hilft heute schon, was wird mittelfristig zur verbindlichen Referenz, und worauf läuft es am Ende hinaus.

Eine wichtige Unterscheidung trägt dabei durch den ganzen Ausblick: Das Fertigstellungsdatum, an dem eine Norm technisch fertig ist, und die Zitierung im EU-Amtsblatt, an dem sie rechtlich wirksam wird, fallen auseinander. Erst Letzteres löst die Konformitätsvermutung aus.

Was schon heute gut für den CRA nutzbar ist, wenn auch ohne Konformitätsvermutung

Für den sofortigen Einstieg gibt es tragfähige Grundlagen. Die BSI TR-03183, die wir in dieser Artikelserie bereits mehrfach als Übergangs-Arbeitsgrundlage herangezogen haben, zeigt strukturiert, wie sich die CRA-Anforderungen inklusive SBOM methodisch adressieren lassen.

Sie wird laufend fortgeschrieben, begründet keine Konformitätsvermutung, ist als Orientierung aber breit akzeptiert.

Für den Umgang mit Schwachstellen kommen die etablierten internationalen Standards ISO/IEC 29147 (Vulnerability Disclosure) und ISO/IEC 30111 (Vulnerability Handling) hinzu, die direkt auf die Pflichten aus Anhang I Teil II einzahlen, insbesondere auf die in Artikel 4 beschriebene CVD-Policy. Ein kleiner, aber praktischer Baustein dazu ist RFC 9116, die security.txt-Konvention, die den Meldekanal für Schwachstellen auffindbar macht.

Am 27. Juli 2026 hat die EU-Kommission den Inhalt eines offiziellen Anwendungsleitfadens zum CRA genehmigt — die „Commission guidance on the application of the Cyber Resilience Act” (Dokument C(2026) 5252), gestützt auf Art. 26.

Auf über 80 Seiten beantwortet er die Fragen, die Herstellern am häufigsten unter den Nägeln brennen: Was fällt überhaupt unter den CRA, wann gilt ein Update als „wesentliche Veränderung”, wie lang muss der Unterstützungszeitraum sein, wie funktionieren die Meldepflichten — mit besonderem Blick auf kleine und mittlere Unternehmen.

Zwei Dinge sollte man dazu wissen: Der Leitfaden ist rechtlich unverbindlich (verbindlich auslegen kann den CRA nur der Europäische Gerichtshof), und die Kommission hat bislang nur den Inhalt freigegeben. Förmlich angenommen und damit anwendbar wird er erst später, sobald alle EU-Sprachfassungen vorliegen. Als Orientierungshilfe taugt er aber schon jetzt.

Der nächste Schritt: die besondere Relevanz der horizontalen Normenfamilie EN 40000 für den CRA

Das eigentliche Fundament für die Zukunft der CRA-Compliance ist die EN-40000-Reihe, die wir bereits im Artikel zur CRA-Risikobewertung und bei den CRA-Essential Cybersecurity Requirements vorgestellt haben. Sie gilt horizontal, also für alle Produkte mit digitalen Elementen, und wird unter dem EU-Normungsauftrag M/606 als Paket von rund 41 Normen entwickelt.

Für den Zeitplan relevant: Anfang Juli 2026 hat die Kommission die Fertigstellungsfristen für 2026 um zwei Monate nach hinten verschoben. An den Anwendungsdaten des Gesetzes selbst ändert das nichts.

Innerhalb der Reihe sind vier Teile zentral, und sie stehen unterschiedlich weit:

• EN 40000-1-1 (Vokabular) schafft eine einheitliche Terminologie und hat die öffentliche Umfrage bereits durchlaufen.
• EN 40000-1-2 (Prinzipien und Risikomanagement) ist der inhaltliche Kern für die Risikobewertung und die Anwendung der Essential Requirements aus Teil I, weit fortgeschritten und mit Fertigstellung im späteren Verlauf von 2026 erwartet.
• EN 40000-1-3 (Vulnerability Handling) übersetzt die acht Pflichten aus Teil II in prüfbare Anforderungen und ist voraussichtlich der Teil, der zuerst zitiert wird, was gut dazu passt, dass die Meldepflichten schon ab September 2026 greifen.
• Der vierte Teil, EN 40000-1-4 (generische Sicherheitsanforderungen), ist die größte offene Baustelle: Er soll die abstrakten Anforderungen auf einen Katalog konkreter Sicherheitskontrollen abbilden, befindet sich aber noch in der Erstellung ohne öffentlichen Entwurf, mit einem Lieferziel erst gegen Ende 2027.

Ergänzend liefert der technische Bericht TR 40000-1-5 (Threats and Security Objectives) ein strukturiertes Mapping von Bedrohungen auf Sicherheitsziele als Startpunkt für die Risikobewertung. Er ist kein normativer Standard, sondern eine unterstützende Orientierung.

Für wichtige und kritische Produkte: die produktspezifischen Normen zum CRA

Wer ein Produkt der höheren Risikoklassen baut, für den sind zusätzlich die vertikalen, also produktspezifischen Normen relevant. Sie bauen auf dem horizontalen EN-40000-Rahmen auf und konkretisieren ihn für einzelne Kategorien aus Anhang III und IV:

• Am weitesten fortgeschritten ist die ETSI-EN-304-6xx-Serie für IT- und Verbraucherprodukte sowie die meisten wichtigen Software- und vernetzten Produktkategorien, deren Entwürfe bereits öffentlich einsehbar sind.
• Für Operational-Technology-Produkte wie Firewalls, Router oder VPN-Lösungen entsteht die prEN-50770-Serie, die sich stark am etablierten IEC-62443-Framework orientiert.
• Für Halbleiter und sichere Elemente schließlich ist eine eigene Normengruppe in Arbeit, von der mehrere Teile die öffentliche Umfrage bereits abgeschlossen haben.

Für Hersteller solcher Produkte ist meist die passende vertikale Norm der relevantere Nachweispfad, nicht der horizontale Rahmen allein.

Der entscheidende Vorbehalt für die Planung

Bei all diesen Dokumenten gilt die bereits weiter oben skizzierte Unterscheidung: Fertigstellung ist nicht gleich Rechtswirkung.

Die ersten horizontalen Bausteine werden technisch ab dem späteren 2026 fertig, der Control-Katalog 1-4 erst gegen Ende 2027, die vertikalen Normen gestaffelt dazwischen.

Die erste Zitierung im Amtsblatt, und damit die tatsächlich nutzbare Konformitätsvermutung, wird jedoch nicht vor 2027 erwartet, teils erst nahe am vollen Anwendungsdatum Ende 2027.

Für den Fall, dass die Normen nicht rechtzeitig fertig werden, hat die EU-Kommission noch eine Ausweichmöglichkeit: Sie kann selbst eigene technische Vorgaben erlassen, sogenannte gemeinsame Spezifikationen. Diese hätten denselben Effekt wie eine harmonisierte Norm, wer sie anwendet, für den gilt die Konformität ebenfalls als vermutet. Ob und wann die Kommission davon Gebrauch macht, ist derzeit aber offen.

Als Faustregel für die Planung: Wer sich heute an EN 40000-1-2 und 1-3 sowie übergangsweise an der BSI TR-03183 orientiert, und bei wichtigen oder kritischen Produkten zusätzlich an der passenden vertikalen Norm, baut auf dem richtigen Fundament.

Einkalkulieren muss man aber, dass dieser bequeme Weg über die Normen erst 2027 tatsächlich nutzbar wird. Bis dahin gibt es die Abkürzung „ich wende die Norm an, damit gilt alles als erfüllt” noch nicht. So gilt: Der Hersteller muss Anforderung für Anforderung selbst durchgehen und für jede zutreffende Anhang-I-Anforderung dokumentieren, wie sein Produkt sie erfüllt. Genau diese Arbeit, Anforderung für Anforderung, hat der dritte Artikel dieser Serie im Detail beschrieben.

Die technische Dokumentation nach Anhang VII: das CRA-Beweisstück, auf das im Ernstfall alles hinausläuft

Die technische Dokumentation (Vgl. Artikel 31) ist das zentrale Nachweisdokument des gesamten CRA-Konformitätssystems. In ihr läuft alles zusammen, was diese Serie bisher beschrieben hat:

• die Risikobewertung aus dem zweiten Artikel,
• die Umsetzung der Essential Requirements aus dem dritten
• und die Vulnerability-Handling-Prozesse aus dem vierten.

Was ein Hersteller an Sicherheitsarbeit geleistet hat, existiert für die Behörden nur insoweit, wie es hier dokumentiert ist.

Anders gesagt: Nicht das sichere Produkt allein zählt, sondern der nachvollziehbare Beleg, dass es sicher ist.

Deshalb muss die technische Dokumentation bereits vor dem Inverkehrbringen vollständig vorliegen, nicht erst auf Nachfrage einer Behörde entstehen. Sie muss belegen, dass sowohl das Produkt als auch die dahinterstehenden Herstellerprozesse die Anforderungen aus Anhang I erfüllen. Sie ist damit die Grundlage, auf der die EU-Konformitätserklärung und die CE-Kennzeichnung überhaupt erst aufsetzen können, und im Prüffall das Erste, worauf eine Marktüberwachungsbehörde zugreift.

Die Mindestinhalte der technischen Dokumentation des Cyber Resilience Act (Vgl. Anhang VII) im Überblick:

Allgemeine Produktbeschreibung: Name, Typ und die Softwareversionen, die die Konformität beeinflussen, bei Hardware ergänzt um Fotografien oder Abbildungen, dazu die Informationen und Anleitungen für den Nutzer nach Anhang II. Genau diese Arbeit an der Nutzerdokumentation hatten wir schon als Bestandteil der Entwicklungsphase eingeordnet, also Sicherheitshinweise, Konfigurationsanleitungen und Angaben zum sicheren Betrieb (s. dritter Artikel dieser Serie). Hier fließt sie in die Dokumentation ein.

Beschreibung von Konzeption, Entwicklung und Herstellung: die Systemarchitektur, der Aufbau und das Zusammenspiel der Softwarekomponenten, die Kommunikationsschnittstellen und die Remote Data Processing Solutions (die herstellereigenen Cloud- oder Backend-Dienste, ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte, ausführlich behandelt bei der Frage nach den Produktgrenzen in unserem zweiten Artikel der Serie). Dazu kommen die Vulnerability-Handling-Prozesse mit SBOM, CVD-Policy, der Kontaktadresse für Schwachstellenmeldungen und der sicheren Update-Verteilung, also genau die acht Pflichten, die unser vierter Artikel im Detail beschrieben hat. Schließlich die Herstellungs- und Überwachungsprozesse und der Nachweis, dass sie funktionieren.

Cybersicherheits-Risikobewertung: die vollständige Risikobewertung mit identifizierten Assets und Bedrohungen, den bewerteten Risiken, den Risikoakzeptanzentscheidungen und den daraus abgeleiteten Maßnahmen, also das komplette Ergebnis der Methodik aus dem zweiten Artikel unserer Serie. Wichtig ist hier der Punkt, den wir bei der Anwendbarkeit schon betont haben: Für jede Anforderung aus Anhang I Teil I, die als nicht anwendbar eingestuft wurde, gehört eine klare Begründung in die Dokumentation (s. auch der dritte Artikel). Eine stillschweigend übergangene Anforderung akzeptiert die Behörde nicht.

Informationen zum Unterstützungszeitraum: die Überlegungen, die zur Festlegung der Support Period geführt haben, also die erwartete Nutzungsdauer, die Art des Produkts und einschlägige weitere Unionsrechtsvorschriften. Dass dieser Zeitraum mindestens fünf Jahre beträgt und eine Untergrenze ist, kein Standardwert, hatten wir im zweiten Artikel hergeleitet.

Angewandte Normen und Spezifikationen: eine Auflistung aller vollständig oder teilweise angewandten harmonisierten Normen, gemeinsamen Spezifikationen oder Zertifizierungsschemata. Solange noch keine solche Norm im Amtsblatt zitiert ist (der Stand, den wir im vorigen Abschnitt beschrieben haben), greift hier der zweite Fall: Dann muss beschrieben werden, mit welchen alternativen Lösungen die Essential Requirements stattdessen erfüllt werden. Das ist genau der Einzelnachweis, den der Hersteller bis zur Verfügbarkeit der Normen ohnehin führen muss.

Testberichte: die Berichte über alle durchgeführten Tests und Prüfungen, mit denen belegt wird, dass sowohl das Produkt die aus der Risikobewertung abgeleiteten Security-Maßnahmen erfolgreich umsetzt als auch die Vulnerability-Handling-Prozesse die Anforderungen aus Anhang I Teil I und Teil II erfüllen.

EU-Konformitätserklärung: ein Exemplar der EU-Konformitätserklärung, also der förmlichen Erklärung, mit der der Hersteller die Konformität selbst verbindlich zusichert. Was sie im Detail enthält, behandelt der nächste Abschnitt.

SBOM: die Software-Stückliste ist kein zwingender Standardbestandteil der Dokumentation, aber auf begründetes Verlangen der Marktüberwachungsbehörde vorzulegen. Das passt zu dem, was wir im vierten Artikel dieser Serie bereits festgehalten haben: Die SBOM muss nicht veröffentlicht werden, ist aber behördlich einsehbar.

Aufbewahrung und Zugänglichkeit: Technische Dokumentation und EU-Konformitätserklärung sind nach dem Inverkehrbringen mindestens zehn Jahre aufzubewahren, oder für die Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist. Da die Support Period bei vielen Produkten deutlich über fünf Jahre hinausgeht, kann die Aufbewahrungspflicht die zehn Jahre übersteigen. Auf begründetes Verlangen muss die Dokumentation den Marktüberwachungsbehörden zugänglich sein, in Papierform oder elektronisch und in einer für die Behörde leicht verständlichen Sprache. Sie ist ausdrücklich kein öffentliches Dokument, ihre Zugänglichkeit beschränkt sich auf die zuständigen Behörden. In der Praxis ergibt sich daraus eine Anforderung, die der CRA nicht eigens ausformuliert, die aber unmittelbar aus diesen Pflichten folgt: Die Dokumente sollten wie jedes prüfungsrelevante Material einem geordneten Dokumentenmanagement unterliegen, mit klarer Versionierung, dokumentierter Freigabe sowie Angaben zu Autor und Datum. Nur so lässt sich über einen Aufbewahrungszeitraum von zehn Jahren oder mehr belegen, welcher Stand wann galt und wer ihn verantwortet hat. Ebenso gehört die Dokumentation zentral und gesichert abgelegt, nicht lokal auf dem Rechner einzelner Mitarbeiter, damit sie im Prüffall vollständig, auffindbar und aktuell verfügbar ist.

Vereinfachtes Format für kleinere Unternehmen: Kleinst- und Kleinunternehmen dürfen alle genannten Elemente in einem vereinfachten Format vorlegen. Wer zählt als Kleinst- bzw. Kleinunternehmen? Das definiert der CRA nicht selbst, sondern greift auf die EU-Standarddefinition zurück (Empfehlung 2003/361/EC). Die Schwellen:

• Kleinstunternehmen (microenterprise): weniger als 10 Beschäftigte und Jahresumsatz und/oder Bilanzsumme höchstens 2 Mio. €.
• Kleinunternehmen (small enterprise): weniger als 50 Beschäftigte und Jahresumsatz und/oder Bilanzsumme höchstens 10 Mio. €.

Die EU-Kommission gibt dafür ein eigens auf kleine Hersteller zugeschnittenes Formular vor, und notifizierte Stellen müssen dieses Format für die Konformitätsbewertung akzeptieren. Wichtig dabei: Das senkt den Aufwand der Darstellung, nicht die inhaltlichen Anforderungen. Risikobewertung, Testberichte und die Beschreibung der Vulnerability-Handling-Prozesse müssen auch im vereinfachten Format substanziell sein.

Der letzte Schritt: vom Nachweis zum öffentlichen Versprechen mit CE-Kennzeichnung und EU‑Konformitätserklärung

Die EU-Konformitätserklärung bildet das rechtsverbindliche Herzstück des gesamten CRA-Compliance-Prozesses. Mit ihr erklärt der Hersteller, dass Produkt und Prozesse die grundlegenden Cybersicherheitsanforderungen erfüllen.

Sie wird vom Hersteller ausgestellt und trägt seine volle Verantwortung.

Mindestinhalte dafür, nach Anhang V:

• Name und Typ des Produkts sowie alle zur eindeutigen Identifizierung notwendigen Informationen;
• Name und Anschrift des Herstellers oder seines Bevollmächtigten;
• eine Erklärung, dass der Hersteller die alleinige Verantwortung für die Ausstellung trägt;
• ein Verweis auf die angewandten harmonisierten Normen,
• gemeinsamen Spezifikationen oder Cybersicherheitszertifizierungsschemata;
• gegebenenfalls Name und Kennnummer der beteiligten notifizierten Stelle;
• Ort und Datum der Ausstellung, Unterschrift.

Der CRA sieht auch eine vereinfachte EU-Konformitätserklärung vor (s. Art. 13 Abs. 20 und Anhang VI), die dem Produkt beigefügt werden kann. Sie enthält nur die wesentliche Erklärung und den Verweis auf die vollständige Erklärung über eine Internetadresse; die vollständige Erklärung muss online abrufbar und dauerhaft verfügbar sein.

Fällt ein Produkt unter mehrere EU-Rechtsvorschriften, die jeweils eine EU-Konformitätserklärung erfordern, wird eine einzige Erklärung für alle relevanten Rechtsvorschriften ausgestellt (s. Art. 28 Abs. 3). Das soll den Aufwand für Hersteller, deren Produkte gleichzeitig dem CRA, der Maschinenverordnung oder anderen EU-Rechtsakten unterliegen, reduzieren.

Die CE-Kennzeichnung beim Cyber Resilience Act: Wie wird sie angebracht?

Die CE-Kennzeichnung ist das sichtbare Zeichen dafür, dass ein Produkt die Anforderungen des CRA erfüllt. Für ihre Anbringung gelten bestimmte formale Regeln.

Mit ihr erklärt der Hersteller, dass das Produkt die Anforderungen aller anwendbaren EU-Harmonisierungsrechtsvorschriften erfüllt; sie ist Voraussetzung für den freien Marktzugang im Binnenmarkt.

Formale Anforderungen:

• gut sichtbar,
• lesbar
• und dauerhaft auf dem Produkt anzubringen
• oder, wenn die Art des Produkts das nicht zulässt, auf Verpackung und EU-Konformitätserklärung.

Die Mindesthöhe beträgt 5 mm, kann aber aus Gründen der Produktgröße kleiner sein, solange das Zeichen erkennbar bleibt; anzubringen ist sie vor dem Inverkehrbringen.

Bei Modul H folgt auf die CE-Kennzeichnung die Kennnummer der beteiligten notifizierten Stelle (s. Art. 30 Abs. 4).

Einen Sonderfall bildet Software, die ohne Hardware ausgeliefert wird. Die klassische CE-Kennzeichnung auf dem Produkt entfällt hier naturgemäß.

Bei Softwareprodukten stellt sich die Frage der CE-Anbringung anders als bei Hardware. Reine Software hat kein Gehäuse, keine Verpackung im klassischen Sinne. Der CRA adressiert das explizit: Bei Produkten mit digitalen Elementen in Form von Software wird die CE-Kennzeichnung entweder auf der EU-Konformitätserklärung selbst oder auf der das Softwareprodukt begleitenden Website angebracht (s. Art. 30 Abs. 1). Der relevante Abschnitt der Website muss für Verbraucher leicht und direkt zugänglich sein. Also nicht im Impressum vergraben, sondern als klarer Produktbestandteil auffindbar.

Die stetige Scope-Frage für Software im Cyber Resilience Act: PwDE oder nicht?

Ob ein Produkt überhaupt unter den CRA fällt, haben wir im ersten Teil dieser Serie geklärt. Für Software-Hersteller lohnt sich an dieser Stelle aber ein genauerer Blick, denn bevor die CE-Kennzeichnung überhaupt zum Thema wird, muss feststehen, ob das Software-Produkt ein Produkt mit digitalen Elementen (PwDE) ist.

Die Abgrenzung ist nicht immer eindeutig — vor allem dort, wo Software und Cloud ineinandergreifen:

• Klar im Scope: Software, die auf dem Gerät des Nutzers läuft: installierbare Programme, mobile Apps, Firmware, eingebettete Software. Sie braucht die CE-Kennzeichnung.
• Klar außerhalb: Reine Cloud-Dienste, die vollständig serverseitig laufen und nur über den Browser genutzt werden (klassisches SaaS/PaaS/IaaS). Sie fallen nicht unter den CRA, sondern ggf. unter NIS2.
• Grauzone – App mit Backend: Braucht eine App zwingend ein herstellereigenes Cloud-Backend, um die Kernfunktion zu erfüllen, gilt dieses Backend als Remote Data Processing Solution (RDPS) — und damit als Teil des PwDE, nicht als eigenständiger Cloud-Dienst. App und Backend werden dann als ein Produkt behandelt, die CE-Kennzeichnung gilt fürs Gesamtprodukt. Das Backend allein, ohne zugehörigen platzierten Client, fällt hingegen nicht unter den CRA.

Diese Abgrenzung ist einer der häufigsten Auslegungsstreitpunkte der CRA-Umsetzung.

Der Kommissionsleitfaden nach Art. 26 CRA (C(2026) 5252, Juli 2026) adressiert sie inzwischen ausführlich — mit Beispielen dazu, wann eine reine Browser-Anwendung, eine lokal installierte App oder ein Backend-Dienst als PwDE zählt. Wer unsicher ist, findet dort die konkreten Fallgruppen; im Zweifel lohnt zusätzlich rechtlicher Rat.

Der Kreis unserer CRA-Artikelserie schließt sich: von der ersten Risikobewertung bis zum CE-Zeichen

Dieser letzte Abschnitt zieht den Bogen über alle fünf Artikel unserer Serie. Dabei wird deutlich, dass die Themen, die wir nacheinander behandelt haben, in Wahrheit ein einziges zusammenhängendes System bilden.

Am Anfang stand die CRA-Meldepflicht, die seit September 2026 greift und deutlich macht, dass der CRA kein fernes Zukunftsthema ist (Artikel 1).

Ihr folgte die Cyber-Risikobewertung als methodischer Kern, die bestimmt, was für ein konkretes Produkt überhaupt und in welcher Tiefe zu tun ist (Artikel 2).

Darauf bauen die dreizehn Essential Requirements aus Anhang I Teil I auf, die technische Beschaffenheit des Produkts (Artikel 3), ergänzt um die acht Vulnerability-Handling-Pflichten aus Teil II, die diese Sicherheit über den gesamten Unterstützungszeitraum am Leben halten (Artikel 4).

Und all das mündet schließlich in den Nachweis: die technische Dokumentation, die Konformitätsbewertung und die CE-Kennzeichnung, mit der der Hersteller die Verantwortung sichtbar übernimmt (Artikel 5).

Keiner dieser Bausteine trägt für sich allein. Erst ihr Zusammenspiel ergibt das, was der CRA eigentlich will: nachweisbar sichere Produkte über ihren gesamten Lebenszyklus.

Fassen wir zusammen, wie jeder einzelne Baustein der Serie in den finalen Nachweis einfließt:

• Artikel 1, Meldepflichten: Der Hersteller braucht Prozesse, die sicherheitsrelevante Ereignisse strukturiert erkennen, klassifizieren und eskalieren. Diese Prozesse sind Teil der Vulnerability-Handling-Dokumentation und müssen damit in der technischen Dokumentation nach Anhang VII enthalten sein.
• Artikel 2, Cyber-Risikobewertung: Die Risikobewertung ist ausdrücklich Bestandteil der technischen Dokumentation, kein separates internes Papier. Asset-Identifikation, Bedrohungsanalyse, bewertete Risiken und die Dokumentation der umgesetzten Maßnahmen, also alles, was Artikel 2 methodisch beschrieben hat, fließt hier direkt ein.
• Artikel 3, Essential Requirements: Dass die dreizehn Anforderungen aus Anhang I Teil I umgesetzt sind, wird in der Dokumentation über die Beschreibung des Produktdesigns, der Entwicklungsprozesse und über die Testberichte belegt. Für jede als nicht anwendbar eingestufte Anforderung gehört eine Begründung dazu. Die Testberichte, also Penetrationstests, Scans und formale Reviews, sind dabei der konkrete Nachweis, dass die Anforderungen tatsächlich erfüllt sind, nicht nur behauptet.
• Artikel 4, Vulnerability Management und SBOM: Die Vulnerability-Handling-Prozesse mit SBOM, CVD-Policy, Patch-Prozess und Update-Verteilung sind ebenfalls Teil der technischen Dokumentation. Die SBOM ist auf begründetes Verlangen der Marktüberwachungsbehörde vorzulegen, und die CVD-Policy ist, wie in Artikel 4 gezeigt, das einzige Prozessdokument, das der CRA namentlich fordert und das öffentlich zugänglich sein muss. Auch die Testberichte zu diesen Prozessen gehören hinein.
• Artikel 5, Konformitätsbewertung: Die technische Dokumentation ist Ergebnis und Nachweis aller vorherigen Aktivitäten zugleich. Die EU-Konformitätserklärung ist ihre förmliche Zusammenfassung, und die CE-Kennzeichnung ist das sichtbare Signal nach außen, dass dieser gesamte Prozess vollständig durchlaufen wurde.

Das ist die eigentliche Botschaft dieses letzten Artikels: Die Konformitätsbewertung ist kein zusätzlicher Arbeitsschritt, der am Projektende noch abgehakt wird. Sie ist die strukturierte Zusammenfassung der Arbeit aus den vorangegangenen vier Artikeln. Wer eine saubere Risikobewertung durchgeführt hat, hat den Kern von Anhang VII bereits erarbeitet. Wer seine Vulnerability-Handling-Prozesse dokumentiert hat, hat die Prozessdokumentation bereits geschrieben. Und wer die dreizehn Anforderungen systematisch geprüft und ihre Umsetzung getestet hat, hat die Testberichte bereits erstellt.