CRA technische Dokumentation: Welche Nachweise Hersteller wirklich brauchen

Die technische Dokumentation nach dem Cyber Resilience Act muss nachvollziehbar zeigen, wie ein Produkt mit digitalen Elementen und die dazugehörigen Herstellerprozesse die grundlegenden Cybersicherheitsanforderungen erfüllen. Sie ist vor dem Inverkehrbringen zu erstellen und während des Supportzeitraums bei Bedarf laufend zu aktualisieren. Annex VII nennt die Mindestinhalte: Produktbeschreibung, Entwicklungs- und Schwachstellenprozesse, Risikobewertung, angewandte Normen oder alternative Lösungen, Testberichte, EU-Konformitätserklärung und – soweit einschlägig – die SBOM.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Fristen & Umsetzung. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Im Nachweisregister sollten der Stand und die Abdeckung verwendeter CRA-Normen und harmonisierter Standards festgehalten sein. Beschreiben Sie außerdem die Umsetzung von Kryptografie und Schlüsselmanagement, soweit sie für das Produkt relevant ist.

Was verlangt der CRA bei der technischen Dokumentation?

Artikel 31 verlangt alle relevanten Daten und Angaben zu den Mitteln, mit denen der Hersteller sicherstellt, dass Produkt und Prozesse die Anforderungen aus Anhang I erfüllen. Mindestens müssen die Inhalte aus Anhang VII enthalten sein.

Die Dokumentation ist damit Beweis- und Arbeitsgrundlage zugleich. Sie soll eine Marktüberwachungsbehörde oder – je nach Konformitätspfad – eine benannte Stelle in die Lage versetzen, die Konformität nachvollziehen zu können.

Wann muss die Dokumentation fertig sein?

Sie muss vor dem Inverkehrbringen des Produkts erstellt sein. Spätestens zum Marktstart darf die Produktakte also nicht aus offenen Platzhaltern bestehen.

Der CRA verlangt außerdem, dass sie gegebenenfalls mindestens während des Supportzeitraums laufend aktualisiert wird. Neue Releases, geänderte Komponenten, neue Erkenntnisse aus Schwachstellen oder eine geänderte Risikobewertung können Aktualisierungen notwendig machen.

Welche acht Bereiche nennt Anhang VII?

Annex VII lässt sich in acht zentrale Nachweisbereiche gliedern. Nicht jeder Unterpunkt ist bei jedem Produkt gleich umfangreich, aber die Struktur ist für die Produktakte sehr hilfreich.

Was gehört in die allgemeine Produktbeschreibung?

Die Produktbeschreibung muss so präzise sein, dass klar ist, welches Produkt und welcher Stand bewertet wurden. Dazu gehören Zweckbestimmung und Softwareversionen, die die Erfüllung der Cybersicherheitsanforderungen beeinflussen.

Bei Hardware sind zusätzlich Fotografien oder Abbildungen zu äußeren Merkmalen, Kennzeichnungen und internem Aufbau vorgesehen. Außerdem gehören die Nutzerinformationen aus Anhang II in diesen Bereich.

Warum ist die Zweckbestimmung so wichtig?

Weil die Cybersicherheitsrisikobewertung auf Zweckbestimmung und vernünftigerweise vorhersehbarer Nutzung aufbaut. Eine vage Produktbeschreibung führt zu einer vagen Risikobewertung.

Ein Netzwerkgerät für private Heimnetze hat andere Einsatzbedingungen als dasselbe technische Grundgerät in einer industriellen Umgebung. Dokumentation und Risikomodell müssen zum tatsächlich vermarkteten Produkt passen.

Wie detailliert muss die Systemarchitektur beschrieben werden?

Die Dokumentation sollte verständlich machen, wie die wesentlichen Software- und Hardwarekomponenten zusammenarbeiten und in die Gesamtverarbeitung integriert sind. Wo relevant, gehören Zeichnungen, Schemata und Architekturinformationen dazu.

Das bedeutet nicht, dass jede Quellcodedatei dokumentiert werden muss. Entscheidend sind sicherheitsrelevante Strukturen: Vertrauensgrenzen, Schnittstellen, Authentifizierung, Updateweg, Datenspeicher, Remote-Komponenten, externe Abhängigkeiten und privilegierte Funktionen.

Welche Architekturdiagramme sind sinnvoll?

Für viele Produkte reichen wenige gezielte Darstellungen: Kontextdiagramm, Komponentenübersicht, Datenflussdiagramm und gegebenenfalls Deployment- oder Netzwerkübersicht. Sie sollten Versionsstand und Gültigkeitsbereich tragen.

Ein Diagramm ohne Bezug zum aktuellen Release kann im Audit sogar verwirren. Deshalb ist Versionsführung wichtiger als grafische Perfektion.

Was muss zu Schwachstellenprozessen dokumentiert werden?

Annex VII verlangt notwendige Informationen und Spezifikationen zu den Verfahren für die Behandlung von Schwachstellen. Dazu gehören unter anderem SBOM, Coordinated-Vulnerability-Disclosure-Policy, Kontaktadresse für Schwachstellenmeldungen und technische Lösungen für die sichere Verteilung von Updates.

Hier zeigt sich, warum die technische Dokumentation nicht nur das Produkt beschreibt. Auch Prozesse nach dem Release sind Teil des Nachweises.

Welche Rolle spielt die SBOM?

Die Software Bill of Materials dokumentiert Komponenten und Beziehungen innerhalb der Software. Sie unterstützt die Frage, welche Produktversionen von einer neu bekannt gewordenen Schwachstelle betroffen sein könnten.

Für die Produktakte sollte klar sein, welche SBOM zu welchem Release gehört, wo sie gespeichert ist und wie sie aktualisiert wird. Eine lose Liste ohne Build- oder Versionsbezug ist deutlich weniger wertvoll.

Wie wird die CRA-Risikobewertung eingebunden?

Die dokumentierte Cybersicherheitsrisikobewertung gehört ausdrücklich in die technische Dokumentation. Sie muss analysieren, welche Risiken aus Zweckbestimmung, vorhersehbarer Nutzung, Betriebsumgebung und zu schützenden Assets entstehen.

Außerdem muss sie erläutern, welche Anforderungen aus Anhang I anwendbar sind und wie diese umgesetzt werden. Nicht anwendbare Anforderungen sollten nicht einfach mit „n/a“ markiert werden; der Hersteller muss nachvollziehbar begründen, warum sie nicht einschlägig sind.

Wie sollte die Anforderungsmatrix aufgebaut sein?

Eine Anforderungsmatrix ist eine der praktisch nützlichsten Formen der CRA-Dokumentation. Für jede relevante Anforderung wird festgehalten, wie das Produkt sie erfüllt und welcher Nachweis existiert.

Die Tabelle ersetzt nicht die technischen Nachweise. Sie verbindet sie miteinander und macht die Produktakte navigierbar.

Welche Informationen gehören zum Supportzeitraum in die Produktakte?

Anhang VII verlangt relevante Informationen, die bei der Festlegung des Supportzeitraums berücksichtigt wurden. Die Dauer sollte deshalb nicht nur als Zahl erscheinen, sondern nachvollziehbar begründet sein.

Typische Faktoren sind erwartete Nutzungsdauer, Produktart, Nutzererwartung, Verfügbarkeit von Komponenten, Abhängigkeiten und die Fähigkeit des Herstellers, Sicherheitsupdates bereitzustellen.

Wie werden Normen dokumentiert?

Hersteller müssen auflisten, welche harmonisierten Normen, gemeinsamen Spezifikationen oder anwendbaren europäischen Cybersicherheitszertifizierungssysteme vollständig oder teilweise verwendet wurden. Bei Teilanwendung ist anzugeben, welche Teile angewandt wurden.

Wer keine entsprechende Norm nutzt, muss die technischen Lösungen beschreiben, mit denen die Anforderungen erfüllt werden. Dadurch bleibt die Dokumentationspflicht auch ohne harmonisierte Norm bestehen.

Welche Testberichte gehören in die technische Dokumentation?

Annex VII verlangt Berichte über Prüfungen, mit denen die Konformität des Produkts und der Schwachstellenprozesse verifiziert wurde. Die Art der Tests hängt vom Produkt und seiner Risikobewertung ab.

Das können funktionale Security-Tests, Authentifizierungsprüfungen, Fuzzing, Codeanalyse, Schwachstellenscans, Penetrationstests, Update- und Rollback-Tests oder Prüfungen sicherer Standardkonfigurationen sein. Entscheidend ist die Verbindung zur Anforderung.

Reicht ein Penetrationstest?

Nein. Ein Penetrationstest kann wertvolle Evidenz liefern, deckt aber nicht automatisch sämtliche CRA-Anforderungen ab. Er prüft einen bestimmten Umfang zu einem bestimmten Zeitpunkt.

Die Produktakte sollte deshalb mehrere Nachweisarten kombinieren: Designentscheidungen, automatisierte Tests, manuelle Sicherheitsprüfungen und Prozessnachweise.

Wie wird die EU-Konformitätserklärung eingebunden?

Eine Kopie der EU-Konformitätserklärung gehört in die technische Dokumentation. Sie ist das formale Ergebnis des Konformitätsprozesses und verweist auf den bewerteten Produkttyp und die angewandten Rechts- und Normgrundlagen.

Die Erklärung muss zum tatsächlichen Produktstand passen. Wird eine wesentliche Änderung vorgenommen, kann eine neue Bewertung und aktualisierte Erklärung erforderlich werden.

Wie hängen Dokumentation und CE-Kennzeichnung zusammen?

Die CE-Kennzeichnung steht am Ende eines Nachweisprozesses. Erst wenn der Hersteller die Konformität über das zulässige Verfahren bewertet hat, kann er die EU-Konformitätserklärung ausstellen und die CE-Kennzeichnung anbringen.

Die technische Dokumentation ist damit die Substanz hinter der Erklärung. Der Gesamtweg wird unter CRA-Konformitätsbewertung und CE erläutert.

Muss alles in einem einzigen PDF stehen?

Nein. Der CRA verlangt Inhalte und Nachweise, nicht zwingend eine einzige Datei. Für komplexe Produkte ist ein strukturiertes Dokumentationssystem meist sinnvoller.

Eine Masterakte kann auf freigegebene Artefakte verweisen: Risikobewertung, Architektur, Testberichte, SBOM, CVD-Policy, Release-Nachweise und Konformitätserklärung. Wichtig ist, dass Referenzen stabil, versioniert und langfristig verfügbar sind.

Kann vorhandene Dokumentation wiederverwendet werden?

Ja. Bestehende ISO-27001-Prozesse, Secure-Development-Dokumente, Produktsicherheitsakten, Testberichte oder andere EU-Produktdokumentationen können weiterverwendet werden, wenn sie die CRA-Anforderungen tatsächlich abdecken.

Artikel 31 sieht für Produkte, die zugleich anderen EU-Rechtsakten mit technischer Dokumentation unterliegen, ausdrücklich eine einzige gemeinsame Dokumentation vor. Doppelpflege ist also nicht das Ziel.

Wie sollte Versionierung funktionieren?

Jeder relevante Nachweis sollte einen Produkt- und Versionsbezug haben. Besonders bei Software muss klar sein, welche Releases von einer Risikobewertung oder einem Test erfasst werden.

Ein praktikables Schema verbindet Produkt-ID, Softwareversion, Dokumentversion, Freigabedatum und verantwortliche Person. Änderungen werden über einen Change-Prozess gesteuert. Bei einer wesentlichen Änderung muss geprüft werden, welche Teile der Produktakte neu bewertet werden.

Welche typischen Fehler schwächen die Dokumentation?

Dokumentation erst kurz vor Marktstart schreiben

Dann fehlen oft belastbare Nachweise, weil Designentscheidungen und Tests nicht strukturiert festgehalten wurden.

Dokumente ohne Versionsbezug

Ein Sicherheitsbericht ohne Produktversion ist später nur eingeschränkt verwertbar.

Normen nur nennen

Es muss klar sein, welche Teile angewandt wurden und welche Anforderungen damit abgedeckt werden.

SBOM und Risikobewertung getrennt halten

Komponenteninformationen sollten in die Schwachstellen- und Risikobewertung einfließen.

Supportprozesse nicht dokumentieren

CRA-Konformität endet nicht beim Release. Vulnerability Handling und Updateverteilung gehören dazu.

Wie baut ein KMU die Produktakte pragmatisch auf?

Ein KMU kann mit einer klaren Ordner- oder Repository-Struktur beginnen. Entscheidend ist nicht ein teures Tool, sondern Konsistenz.

1. Produktbeschreibung und Scope festlegen.
2. Risikobewertung erstellen.
3. Anhang-I-Matrix aufbauen.
4. Architektur und Komponenten dokumentieren.
5. SBOM pro Release erzeugen.
6. Vulnerability- und Updateprozess dokumentieren.
7. Tests der Anforderungen zuordnen.
8. Supportzeitraum begründen.
9. Konformitätsweg dokumentieren.
10. EU-Erklärung einbinden und Akte freigeben.

Wo stehen die Anforderungen im Original?

Die Anforderungen an die technische Dokumentation stehen in Artikel 31 und Anhang VII der Verordnung (EU) 2024/2847 bei EUR-Lex. Maßgeblich bleiben immer Produkt, Risikobewertung und der tatsächlich gewählte Konformitätspfad.