CRA Technische Dokumentation: Was muss rein?

Die technische Dokumentation nach dem Cyber Resilience Act ist kein optionales Beiwerk — sie ist der primäre Nachweis Ihrer gesamten CRA-Konformität. Anhang VII der Verordnung (EU) 2024/2847 listet neun Pflichtbestandteile auf, die jeder Hersteller eines Produkts mit digitalen Elementen zusammenstellen und zehn Jahre lang aufbewahren muss.

Was eine Marktaufsichtsbehörde als Erstes anfordert: diese Dokumentation. Wer sie nicht in 72 Stunden liefern kann, hat ein ernstes Problem.

Dieser Artikel geht jeden der neun Punkte durch: was genau hineingehört, welche Fehler Hersteller typischerweise machen und was in der Praxis funktioniert.

Warum die technische Dokumentation so kritisch ist

Marktaufsichtsbehörden — in Deutschland die Bundesnetzagentur und das BSI — dürfen nach Artikel 54 CRA jederzeit vollständige Dokumentation anfordern. Die Frist kann sehr kurz sein. Fehlt die Dokumentation oder ist sie unvollständig, drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes (Art. 64 Abs. 2 CRA).

Fertiggestellt sein muss die technische Dokumentation vor dem Inverkehrbringen — nicht danach. Wer sie rückwirkend erstellt, riskiert, dass die Marktaufsichtsbehörde die Konformitätserklärung als ungültig einstuft.

Was viele IoT-Startups und embedded-Software-Hersteller trotzdem tun: die Dokumentation als lästige Nacharbeit behandeln. Das ist der teuerste Fehler im gesamten CRA-Prozess.

Die 9 Pflichtbestandteile nach Anhang VII CRA

1. Allgemeine Produktbeschreibung

Was rein muss: Name, Modell, Versionsnummer, beabsichtigter Verwendungszweck, Zielgruppe (Verbraucher vs. professionelle Nutzer), Produktkategorie nach Anhang III oder IV CRA und eine technische Beschreibung der Hauptfunktionen inklusive vorhandener Netzwerkschnittstellen.

Typischer Fehler: Viele Hersteller übernehmen Text aus dem Marketing-Datenblatt. “Intuitive Benutzeroberfläche” hilft einer Behörde nicht. Gefragt sind präzise Angaben: Welche Schnittstellen existieren? Welche Daten werden verarbeitet? Funktioniert das Produkt als Standalone-Gerät oder als Teil eines Verbundsystems?

Praxishinweis: Eine Tabelle mit Kenndaten (Produktname, Version, Schnittstellentypen, Deployment-Modell, unterstützte Betriebssysteme) auf einer Seite ist besser lesbar als zwei Seiten Fließtext. Nehmen Sie sich maximal 30 Minuten für diesen Abschnitt — mehr Ausführlichkeit liefert hier keinen Mehrwert.

2. Beschreibung des Entwicklungsprozesses

Was rein muss: Überblick über den Software-Entwicklungslebenszyklus (SDLC) mit Fokus auf sicherheitsrelevante Prozesse: eingesetzte SAST/DAST-Tools, Code-Review-Verfahren für sicherheitskritische Änderungen, wie Sicherheitslücken im Entwicklungsprozess identifiziert und behoben werden, und wie Security Patches in den Releaseprozess integriert sind.

Typischer Fehler: Beschreibung der agilen Methodik statt der Sicherheitsprozesse. Scrum-Sprints interessieren die Behörde nicht. Sie will wissen: Gibt es eine Secure-Coding-Richtlinie? Prüft das Team Abhängigkeiten automatisch auf bekannte Schwachstellen? Wann im Entwicklungsprozess finden Security-Reviews statt?

Praxishinweis: Eine halbe Seite mit konkreten Maßnahmen schlägt drei Seiten allgemeine Prozess-Beschreibung. Benennen Sie konkrete Tools (z. B. Semgrep, CodeQL, Dependabot) und Zeitpunkte im Prozess. Selbst ein einfacher CI/CD-Scan auf CVEs ist dokumentierbar und zeigt Systematik.

3. Cybersicherheitsrisikobewertung

Was rein muss: Eine strukturierte Analyse der Cybersicherheitsrisiken über den gesamten Produktlebenszyklus. Dazu gehören identifizierte Bedrohungsszenarien, Angriffsvektoren, Risikobewertung nach Eintrittswahrscheinlichkeit und Auswirkung sowie die implementierten Gegenmaßnahmen. Restrisiken müssen explizit ausgewiesen und begründet sein.

Typischer Fehler: Eine generische Risikoliste ohne Produktbezug. “SQL-Injection ist ein Risiko” reicht nicht. Zu dokumentieren ist: Ist SQL-Injection für dieses Produkt relevant? Wenn ja, warum — und welche spezifischen Maßnahmen wurden implementiert? Wenn nein, warum nicht?

Praxishinweis: Verwenden Sie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) oder ein vergleichbares Framework wie OWASP Threat Dragon. Halten Sie für jeden Bedrohungsvektor fest: Risikostufe, Maßnahme, Restrisiko. Eine Tabelle mit 20 bis 40 Einträgen ist ein realistischer Ausgangspunkt für ein mittelkomplexes Produkt — etwa eine industrielle MQTT-Gateway-Firmware oder eine embedded Heizungssteuerung.

4. Auflistung angewandter Normen und Spezifikationen

Was rein muss: Eine Liste der angewandten harmonisierten Normen, gemeinsamen Spezifikationen oder sonstigen Standards, auf die sich der Hersteller bei der Konformitätsbewertung stützt — inklusive Angabe, welche Teile angewandt wurden und, falls nicht vollständig: warum bestimmte Teile ausgelassen wurden.

Typischer Fehler: Normen pauschal aufzählen ohne Angabe der angewandten Teile. Vollständige Konformitätsvermutung entsteht nur bei vollständiger Anwendung einer harmonisierten Norm. Wer nur einzelne Kapitel anwendet, muss das explizit dokumentieren.

Praxishinweis: Zum Stand 2026 befinden sich die harmonisierten CRA-Normen noch in der Entwicklung. ETSI EN 303 645 (Consumer IoT) und IEC 62443 (industrielle Systeme) sind die wichtigsten verfügbaren Referenzstandards. Dokumentieren Sie das Normen-zu-Anforderungen-Mapping in einer Tabelle: Welches Normkapitel deckt welche Anforderung aus Anhang I CRA ab?

5. EU-Konformitätserklärung oder Notified-Body-Bescheinigung

Was rein muss: Entweder die vollständige unterzeichnete EU-Konformitätserklärung nach Anhang V CRA (bei Selbstbewertung für Default-Produkte und Important Class I mit harmonisierten Normen) oder die Bescheinigung einer Notified Body (für Important Class I ohne harmonisierte Normen, Class II und Critical).

Typischer Fehler: Die Konformitätserklärung ausstellen, bevor die technische Dokumentation vollständig ist. Die Erklärung ist das Ergebnis der Bewertung — nicht ihr Ersatz. Außerdem: die falsche Produktklasse annehmen und damit das falsche Verfahren wählen. Ein Produkt der Klasse I, das als Default behandelt wird, hat eine fehlerhafte Dokumentation.

Was viele CRA-Berater nicht sagen: Die Produktklassifikation ist der kritischste Einzelschritt im gesamten Verfahren. Klassifizieren Hersteller falsch, ist nicht nur die Konformitätserklärung wertlos — der gesamte Dokumentationsaufwand muss neu aufgerollt werden.

Praxishinweis: Nutzen Sie den CRA RouteCheck, um Ihre Produktklassifikation zu verifizieren, bevor Sie das Verfahren festlegen. Die Konformitätserklärung muss mindestens enthalten: Herstelleridentifikation, Produktbeschreibung, Verweis auf die Verordnung, Konformitätsaussage, angewandte Standards, Datum und Unterschrift. Weitere Pflichten für Hersteller finden Sie im Artikel zu den CRA-Pflichten für Hersteller.

6. Beschreibung der Schnittstellen und Konnektivität

Was rein muss: Vollständige Auflistung aller Netzwerkschnittstellen, Protokolle, externen Dienste und Verbindungen, die das Produkt im Betrieb herstellt. Für jede Schnittstelle: Zweck, verwendetes Protokoll, Authentifizierungsmechanismus und ob die Verbindung verschlüsselt ist.

Typischer Fehler: Nur die offensichtlichen Schnittstellen dokumentieren (z. B. die REST-API), aber Update-Kanäle, Telemetrie-Verbindungen, Debugging-Schnittstellen und Drittanbieter-Integrationen vergessen. Marktaufsichtsbehörden haben ein Auge für undokumentierte Verbindungen — sie wirken wie ein Verbergungsversuch, auch wenn sie es nicht sind.

Konkret bedeutet das: Ein Hersteller von industriellen MQTT-Gateways — typisch im Maschinenbau und bei Industrie-4.0-Anbietern — muss hier nicht nur den MQTT-Broker-Endpunkt dokumentieren, sondern auch den OTA-Update-Kanal, etwaige SNMP-Schnittstellen und jeden Cloud-Backend-Call. Alles. Vollständig.

Praxishinweis: Erstellen Sie ein tabellarisches Schnittstellenregister: Schnittstelle, Protokoll, Richtung (eingehend/ausgehend), Authentifizierung, Verschlüsselung, Zweck. Dokumentieren Sie auch deaktivierte Schnittstellen (z. B. Debug-Ports) mit der Begründung, warum sie deaktiviert sind und ob sie im Feld reaktiviert werden können.

7. Software Bill of Materials (SBOM)

Was rein muss: Eine vollständige, maschinenlesbare Liste aller im Produkt enthaltenen Softwarekomponenten — inklusive Drittanbieter-Bibliotheken, Open-Source-Abhängigkeiten, deren Versionen und bekannter Schwachstellen. Empfohlene Formate: CycloneDX oder SPDX.

Typischer Fehler: SBOM nur auf direkten Abhängigkeiten basieren lassen und transitive Abhängigkeiten ignorieren. In einem typischen Node.js-Projekt können 50 direkte Abhängigkeiten 500 oder mehr transitive Abhängigkeiten erzeugen — Schwachstellen sitzen häufig mehrere Ebenen tief. Eine SBOM ohne transitive Dependencies ist für Vulnerability-Tracking nahezu wertlos.

Das ist der Punkt, den viele übersehen: Eine veraltete SBOM ist gefährlicher als gar keine — sie erzeugt falsche Sicherheit. Wer dem Release-Prozess keine automatische SBOM-Generierung vorschaltet, verliert die Kontrolle über seinen eigenen Software-Stack.

Praxishinweis: Integrieren Sie die SBOM-Generierung in die CI/CD-Pipeline — niemals manuell erstellen. Tools wie Syft, cdxgen oder CycloneDX-cli generieren vollständige, normkonforme SBOMs automatisch. Speichern Sie die SBOM als Release-Artefakt und verknüpfen Sie sie mit der Versionsnummer.

8. Sicherheitstests und Testergebnisse

Was rein muss: Dokumentation der durchgeführten Sicherheitstests: Penetrationstests, statische Code-Analyse (SAST), dynamische Analyse (DAST), Fuzzing oder andere Überprüfungen. Wichtig: nicht nur die Methoden beschreiben, sondern auch die Ergebnisse — und wie identifizierte Probleme behandelt wurden.

Typischer Fehler: Tests werden durchgeführt, aber nicht dokumentiert. Oder: Nur funktionale Tests sind dokumentiert, sicherheitsspezifische Tests fehlen. “Wir führen regelmäßige Pentests durch” ohne Berichte ist für eine Behörde kein Nachweis. Dokumentation heißt: Datum, Tool, Versionsnummer des getesteten Produkts, Scope, Findings, Behebung, Bestätigung.

Praxishinweis: Penetrationstest-Berichte externer Anbieter, Scan-Reports aus OWASP ZAP oder Burp Suite, SAST-Ergebnisse aus CodeQL oder Semgrep — all das gehört archiviert. Nicht perfekte Tests sind kein Problem. Fehlende oder undokumentierte Tests schon.

9. Angaben zu bekannten Schwachstellen und Vorfällen nach Inverkehrbringen

Was rein muss: Ein fortlaufendes Register aller nach Inverkehrbringen identifizierten Schwachstellen und Sicherheitsvorfälle: CVE-ID oder interne ID, Entdeckungsdatum, CVSS-Score, getroffene Maßnahmen (Patch, Mitigation, akzeptiertes Restrisiko mit Begründung) und Abschlussdatum.

Typischer Fehler: Diesen Punkt als Einmalaufgabe zu behandeln. Anhang VII Nr. 9 ist ein lebendiger Teil der Dokumentation, der über den gesamten Supportzeitraum gepflegt werden muss. Ein nicht gepflegtes Schwachstellenregister signalisiert einer Behörde, dass der Hersteller den Prozess nicht ernstnimmt.

Praxishinweis: Integrieren Sie dieses Register in Ihr Issue-Tracking-System oder CVE-Monitoring-Tool. Jede gemeldete oder entdeckte Schwachstelle erhält einen Eintrag, der durch den gesamten Prozess verfolgt wird: Bewertung, Entscheidung, Umsetzung, Veröffentlichung. Dieses Register ist gleichzeitig die operative Grundlage für die Meldepflicht nach Artikel 14 CRA — aktiv ausgenutzte Schwachstellen müssen ENISA innerhalb von 24 Stunden gemeldet werden.

Aufbewahrung: 10 Jahre ab Inverkehrbringen

Artikel 13 Absatz 3 CRA verpflichtet Hersteller, die technische Dokumentation mindestens 10 Jahre nach dem letzten Inverkehrbringen aufzubewahren — oder nach dem letzten Sicherheitsupdate, je nachdem was später eintritt. Bei Produkten mit kürzerer Lebensdauer als 5 Jahre gilt mindestens eine 5-Jahres-Frist.

Das klingt nach bürokratischem Aufwand. Ist es auch. Aber wer das System von Anfang an richtig aufsetzt, hat danach kaum Mehraufwand.

Praktische Implikationen:

• Versionieren Sie die Dokumentation pro Release — welche Version des Produkts deckt welche Dokumentationsversion ab?
• Speichern Sie in einem Format, das auch in 10 Jahren lesbar ist (kein proprietäres Format ohne Migrationsplan)
• Stellen Sie sicher, dass bei Unternehmensübernahmen oder Produkteinstellungen die Dokumentation zugänglich bleibt
• Mitarbeiterwechsel sind kein Grund für Dokumentationsverlust — externe Wissensdokumentation schützt das Unternehmen

Die häufigsten Lücken auf einen Blick

Wenn Sie wissen möchten, welche Pflichten speziell für Ihren Produkttyp gelten, lesen Sie unseren Überblick zu den CRA-Pflichten für Hersteller digitaler Produkte. Wie die Konformitätserklärung aufgebaut ist und was sie rechtlich bedeutet, erläutert der Artikel zur CRA-Konformitätserklärung.

Keine Rechtsberatung. Indikative Einschätzung auf Basis der Verordnung (EU) 2024/2847. Für verbindliche Aussagen zu Ihrem konkreten Produkt wenden Sie sich an einen spezialisierten Rechtsanwalt oder eine akkreditierte Zertifizierungsstelle.