CRA Technische Dokumentation: Leitfaden Anhang VII

Die Technische Dokumentation ist Ihr Nachweispaket für die CRA-Compliance. Marktüberwachungsbehörden werden sie anfordern. Notifizierte Stellen werden sie prüfen. Ohne vollständige Technische Dokumentation dürfen Sie Ihr Produkt nicht legal auf den EU-Markt bringen.

Dieser Leitfaden schlüsselt Anhang VII Abschnitt für Abschnitt auf und erklärt, was jeder erfordert und wie Sie ihn vorbereiten.

Was ist die Technische Dokumentation?

Die Technische Dokumentation ist das vollständige Nachweispaket, das demonstriert, dass Ihr Produkt die CRA-Anforderungen erfüllt.

Sie ist nicht:

• Marketing-Dokumentation
• Nur Benutzerhandbücher
• Eine Abhak-Übung

Sie ist:

• Umfassender technischer Nachweis
• Lebende Dokumentation (aktualisiert während des Produktlebenszyklus)
• Ihre Verteidigung bei Marktüberwachungsuntersuchungen
• Erforderlich für die Konformitätsbewertung

Anhang VII Strukturübersicht

Der CRA-Anhang VII spezifiziert die Anforderungen an die Technische Dokumentation:

STRUKTUR DER TECHNISCHEN DOKUMENTATION (Anhang VII)

1. ALLGEMEINE BESCHREIBUNG
   └── Produktidentifikation und Verwendungszweck

2. DESIGN, ENTWICKLUNG, SCHWACHSTELLENBEHANDLUNG UND PRODUKTION
   └── Sicherheit eingebaut, Schwachstellen behandelt, Produktion und Überwachung validiert

3. CYBERSICHERHEITS-RISIKOBEWERTUNG
   └── Identifizierte und behandelte Risiken

4. INFORMATIONEN ZUM UNTERSTÜTZUNGSZEITRAUM
   \-- Informationen zur Bestimmung des Unterstützungszeitraums (Artikel 13 Absatz 8)

5. ANGEWANDTE NORMEN
   \-- Verwendete Normen und Abweichungen

6. TESTERGEBNISSE
   \-- Verifizierungsnachweise

7. EU-KONFORMITÄTSERKLÄRUNG
   \-- Oder Kopie davon

8. SOFTWARE-STÜCKLISTE
   \-- Komponenten und Abhängigkeiten (auf begründeten Antrag)

Abschnitt 1: Allgemeine Beschreibung

Zweck: Festlegen, was das Produkt ist und wofür es gedacht ist.

Erforderlicher Inhalt

CHECKLISTE ALLGEMEINE BESCHREIBUNG

Produktidentifikation:
[ ] Produktname und Modellnummer
[ ] Hardware-Version(en)
[ ] Software-/Firmware-Version(en)
[ ] Seriennummernformat oder -bereich
[ ] Eindeutiger Produktidentifikator

Verwendungszweck:
[ ] Beschreibung der Hauptfunktion
[ ] Zielnutzer/-umgebung
[ ] Vorgesehene Anwendungsfälle
[ ] Nicht vorgesehene Verwendungen (Ausschlüsse)

Produktkategorie:
[ ] CRA-Klassifizierung (Standard/Wichtig/Kritisch)
[ ] Begründung der Klassifizierung
[ ] Verwandte Produktvorschriften (falls vorhanden)

Marktinformationen:
[ ] Datum des ersten EU-Inverkehrbringens
[ ] Ziel-Mitgliedstaaten
[ ] Vertriebskanäle

Beispiel

ALLGEMEINE BESCHREIBUNG

Produktname: SmartSense Pro Industriesensor
Modellnummer: SSP-3000
Hardware-Version: Rev C (PCB v3.2)
Firmware-Version: 2.4.1

VERWENDUNGSZWECK:
Der SmartSense Pro ist ein industrieller Umgebungssensor,
der für die Überwachung von Fertigungsanlagen konzipiert ist.
Er misst Temperatur, Luftfeuchtigkeit und Luftqualität und
überträgt Daten per WiFi an Cloud- oder lokale Server.

ZIELNUTZER:
- Facility Manager
- Industrieautomatisierungs-Integratoren
- Umwelt-Compliance-Beauftragte

VORGESEHENE UMGEBUNG:
- Industrielle Innenräume
- Betriebstemperatur: -10°C bis +60°C
- Netzwerk: WiFi 802.11 b/g/n

NICHT VORGESEHEN FÜR:
- Medizinische oder lebensrettende Anwendungen
- Außeninstallation
- Explosionsgefährdete Bereiche
- Verbraucher-/Wohnanwendungen

CRA-KLASSIFIZIERUNG:
Standardprodukt. Nicht in Anhang III oder IV gelistet.
Begründung: Allzwecksensor ohne Sicherheitsfunktionen
oder kritische Infrastrukturanwendung.

EU-INVERKEHRBRINGEN:
Erstmals auf den Markt gebracht: 15. März 2027
Zielmärkte: Alle EU-Mitgliedstaaten
Vertrieb: Direktverkauf und autorisierte Distributoren

Abschnitt 2: Design, Entwicklung und Schwachstellenbehandlung

Zweck: Dokumentieren, wie das Produkt entworfen und entwickelt wurde, wie Schwachstellen nach der Markteinführung behandelt werden und wie Produktions- und Überwachungsprozesse validiert werden. Anhang VII §2 behandelt diese als einen Block: Design und Entwicklung unter §2(a), Verfahren zur Schwachstellenbehandlung unter §2(b), Produktions- und Überwachungsprozesse unter §2(c).

Design und Entwicklung: erforderlicher Inhalt

CHECKLISTE DESIGN-DOKUMENTATION

Architektur:
[ ] Systemarchitekturdiagramm
[ ] Komponenteninteraktionsdiagramm
[ ] Datenflussdiagramm
[ ] Vertrauensgrenzen identifiziert

Sicherheitsdesign:
[ ] Beschreibung der Sicherheitsarchitektur
[ ] Kryptografische Implementierungen
[ ] Authentifizierungsmechanismen
[ ] Autorisierungsmodell
[ ] Sichere Kommunikationsprotokolle
[ ] Datenschutzmaßnahmen

Entwicklungsprozess:
[ ] Beschreibung des sicheren Entwicklungslebenszyklus
[ ] Rückverfolgbarkeit der Sicherheitsanforderungen
[ ] Code-Review-Verfahren
[ ] Sicherheitstests in der Entwicklung
[ ] Konfigurationsmanagement

Änderungsmanagement:
[ ] Versionskontrollverfahren
[ ] Änderungsauswirkungsbewertung
[ ] Sicherheitsüberprüfung bei Änderungen

Wie „Secure by Design“-Dokumentation aussieht

SICHERHEITSARCHITEKTUR-ÜBERSICHT

1. VERTRAUENSGRENZEN
   ┌─────────────────────────────────────────┐
   │            Cloud-Backend                 │
   │  (Authentifizierung, Datenspeicherung)  │
   └───────────────┬─────────────────────────┘
                   │ TLS 1.3
   ┌───────────────┴─────────────────────────┐
   │         Geräte-Firmware                  │
   │  ┌─────────────────────────────────┐    │
   │  │    Anwendungsschicht            │    │
   │  ├─────────────────────────────────┤    │
   │  │    Sicherheitsdienste           │    │
   │  │  (Krypto, Auth, Secure Boot)    │    │
   │  ├─────────────────────────────────┤    │
   │  │    Hardware-Sicherheit          │    │
   │  │  (Secure Element, RNG)          │    │
   │  └─────────────────────────────────┘    │
   └─────────────────────────────────────────┘

2. AUTHENTIFIZIERUNG
   - Gerät-zu-Cloud: Mutual TLS mit Gerätezertifikaten
   - Nutzer-zu-Gerät: Lokale API erfordert Auth-Token
   - Zertifikatbereitstellung: Werkseitig, einzigartig pro Gerät

3. DATENSCHUTZ
   - Ruhende Daten: AES-256-GCM-Verschlüsselung
   - Daten in Übertragung: TLS 1.3 mit Certificate Pinning
   - Sensible Daten: Im Secure Element gespeichert

4. UPDATE-MECHANISMUS
   - Signierte Firmware-Updates (ECDSA P-256)
   - Signaturverifizierung vor Installation
   - Rollback-Schutz über Versionszähler
   - Automatische Update-Prüfungen (nutzerkonfigurierbar)

Dokumentation der Schwachstellenbehandlung

VERFAHREN ZUR SCHWACHSTELLENBEHANDLUNG

1. KONTAKTMETHODEN
   Primär: security@firma.de
   Webformular: https://firma.de/security/melden
   security.txt: https://firma.de/.well-known/security.txt
   CVD-Richtlinie: https://firma.de/security/offenlegungsrichtlinie

2. ANTWORTVERPFLICHTUNGEN
   Bestätigung: Innerhalb von 3 Werktagen
   Erste Bewertung: Innerhalb von 10 Werktagen
   Statusupdates: Alle 14 Tage
   Lösungsziel: 90 Tage (kritisch: 7 Tage)

3. INTERNER PROZESS
   [Flussdiagramm oder Prozessbeschreibung]
   Siehe: Prozessdokument PD-VULN-003

4. PATCH-VERTEILUNG
   Mechanismus: OTA-Updates über Cloud-Infrastruktur
   Benachrichtigung: In-App-Benachrichtigung + E-Mail an registrierte Nutzer
   Verifizierung: Signierte Updates mit Rollback-Fähigkeit

5. ENISA-MELDUNG
   Auslöser: Aktive Ausnutzung erkannt
   Zeitplan: 24 h Frühwarnung, 72 h detaillierter Bericht
   Verantwortlich: Sicherheitsteamleiter
   Prozess: Siehe PD-ENISA-001

6. HISTORISCHE AUFZEICHNUNG
   Behandelte Schwachstellen (letzte 24 Monate): 3
   Durchschnittliche Lösungszeit: 45 Tage
   ENISA-Meldungen eingereicht: 0

Produktion und Überwachung: erforderlicher Inhalt

Bei Softwareprodukten gibt es keine Fertigungsstraße. Anhang VII Nummer 2 Buchstabe c bezieht sich auf die Build- und Release-Pipeline, die auslieferbare Artefakte erzeugt, auf den Nachweis, dass diese Prozesse wie vorgesehen funktionieren, und auf die Überwachung nach der Bereitstellung, mit der Regressionen und neue Schwachstellen erkannt werden. Dokumentieren Sie jeden Bereich so, dass eine prüfende Stelle ein Release bis zu einem verifizierten, reproduzierbaren Build zurückverfolgen kann.

CHECKLISTE PRODUKTION UND ÜBERWACHUNG

Build- und Release-Pipeline:
[ ] Quelle der Wahrheit benannt (Repository, Branch-Schutz)
[ ] Reproduzierbarer Build dokumentiert (Toolchain-Versionen festgepinnt)
[ ] Build-Provenienz erfasst (SLSA-Stufe, in-toto-Attestierungen)
[ ] Signierschlüssel und Schlüsselverwaltung dokumentiert
[ ] Integrität des Release-Artefakts (signierte Binaries, SBOM beim Release)

Validierung der Produktionsprozesse:
[ ] Sicherheits-Gates in CI dokumentiert (SAST, DAST, SCA, Bestehenskriterien)
[ ] Regressionssuite deckt mit Anhang I markierte Anforderungen ab
[ ] Release-Freigabe-Workflow dokumentiert
[ ] Rollback-Plan für fehlgeschlagene Releases
[ ] Turnus für Reproduzierbarkeitsaudits

Überwachung nach der Bereitstellung:
[ ] Turnus der Abhängigkeits-Schwachstellenüberwachung (täglich/wöchentlich)
[ ] SBOM-Diff-Prozess bei jedem Release
[ ] Einbindung von CVE-Feeds (NVD, GHSA, Hersteller-Advisories)
[ ] KEV-Abgleich auf aktive Ausnutzung
[ ] Telemetrie für sicherheitsrelevante Ereignisse (fehlgeschlagene Updates, Signaturfehler)
[ ] Auslöser für Kundenbenachrichtigungen dokumentiert

Dokumentation Produktion und Überwachung

PROZESSE FÜR PRODUKTION UND ÜBERWACHUNG

Produkt: Industrial Gateway IG-200
Build-Plattform: GitHub Actions auf ubuntu-22.04 runners
Provenienz: SLSA Level 3 (signed in-toto attestations)
Signierung: Cosign + Sigstore, offline KMS-backed root key

BUILD-PIPELINE:
1. Quelle: github.com/example/ig200-firmware (main branch protected,
   2-of-N review gate, signed commits required)
2. Build: reproducible cross-compile (rustc 1.78, locked Cargo.lock)
3. SAST: cargo-audit + clippy security lints (gate: 0 high+ findings)
4. SCA: trivy scan against built binary (gate: 0 known-exploitable CVEs)
5. Test: regression suite (1247 tests) + Annex-I conformance suite (89 tests)
6. Signieren: cosign sign-blob + attest --predicate slsa-provenance.json
7. Release: artifact + SBOM (CycloneDX 1.5) + DoC excerpt published

VALIDIERUNG DER PROZESSE:
- Pipeline-Definition vierteljährlich überprüft (Security Lead + Release Manager)
- Anhang-I-Konformitätstestsuite überprüft, wenn sich Normen oder Risiken ändern
- Jährliches Reproduzierbarkeitsaudit (unabhängiger Rebuild aus getaggter Quelle)
- Fehlerfall: schlägt ein Gate fehl -> Release blockiert, Vorfall protokolliert

ÜBERWACHUNG NACH DER BEREITSTELLUNG:
- Abhängigkeits-CVE-Feed: Trivy + Renovate, täglicher Scan gegen aktuelle SBOM
- Schwelle: Kritisch oder Hoch mit KEV-Treffer -> Patch innerhalb von 7 Tagen
- Schwelle: Mittel ohne KEV -> Patch im nächsten monatlichen Release
- Kundenbenachrichtigung: signierter RSS-Feed + E-Mail bei Advisories
- Interne Telemetrie: fehlgeschlagene Update-Ereignisse, Fehler bei Signaturprüfung
- Turnus: wöchentliche Triage, monatliche Trendüberprüfung

Abschnitt 3: Cybersicherheits-Risikobewertung

Zweck: Identifizierte Risiken und deren Behandlung dokumentieren.

Erforderlicher Inhalt

CHECKLISTE RISIKOBEWERTUNG

Methodik:
[ ] Risikobewertungsmethodik beschrieben
[ ] Scope-Definition
[ ] Asset-Identifikation
[ ] Ansatz zur Bedrohungsidentifikation

Risikoanalyse:
[ ] Bedrohungen aufgezählt
[ ] Schwachstellen berücksichtigt
[ ] Auswirkungsbewertung
[ ] Wahrscheinlichkeitsbewertung
[ ] Risikoeinstufungen

Risikobehandlung:
[ ] Behandlungsentscheidungen für jedes Risiko
[ ] Sicherheitskontrollen auf Risiken abgebildet
[ ] Restrisikobewertung
[ ] Risikoakzeptanzkriterien

Format der Risikobewertung

CYBERSICHERHEITS-RISIKOBEWERTUNG

Produkt: SmartSense Pro (SSP-3000)
Version: 2.4.1
Bewertungsdatum: Januar 2027
Bewerter: [Name, Sicherheitsteam]

METHODIK:
Basierend auf ISO 27005, angepasst für Produktsicherheit.
Risiko = Wahrscheinlichkeit × Auswirkung
Skala: Niedrig (1-4), Mittel (5-9), Hoch (10-16), Kritisch (17-25)

─────────────────────────────────────────────────────────────
RISIKO-ID: R-001
BEDROHUNG: Unbefugte Firmware-Modifikation
SCHWACHSTELLE: Unsignierte Firmware könnte installiert werden
AUSWIRKUNG: Hoch (5) - Gerätekompromittierung, Datenleck
WAHRSCHEINLICHKEIT: Mittel (3) - Erfordert physischen Zugang
INHÄRENTES RISIKO: 15 (Hoch)

KONTROLLE: Firmware-Signaturverifizierung
IMPLEMENTIERUNG: ECDSA P-256 Signatur vor Installation geprüft
RESTRISIKO: 3 (Niedrig) - Kryptografischer Angriff unwahrscheinlich

STATUS: Mitigiert
─────────────────────────────────────────────────────────────
RISIKO-ID: R-002
BEDROHUNG: Man-in-the-Middle-Angriff auf Cloud-Kommunikation
SCHWACHSTELLE: Abfangen von Netzwerkverkehr
AUSWIRKUNG: Hoch (4) - Datenexposition, Command Injection
WAHRSCHEINLICHKEIT: Mittel (3) - Öffentliche Netzwerke möglich
INHÄRENTES RISIKO: 12 (Hoch)

KONTROLLE: TLS 1.3 mit Certificate Pinning
IMPLEMENTIERUNG: Festcodiertes CA-Zertifikat, kein Fallback
RESTRISIKO: 2 (Niedrig) - Zertifikatskompromittierung unwahrscheinlich

STATUS: Mitigiert
─────────────────────────────────────────────────────────────
[Fortsetzung für alle identifizierten Risiken...]

RISIKOZUSAMMENFASSUNG:
Identifizierte Risiken gesamt: 23
Kritisch: 0
Hoch: 3 (alle auf Niedrig/Mittel mitigiert)
Mittel: 8 (alle auf Niedrig mitigiert)
Niedrig: 12 (akzeptiert oder mitigiert)

RESTRISIKO-AKZEPTANZ:
Alle Restrisiken liegen innerhalb akzeptabler Toleranz.
Unterzeichnet: [Sicherheitsleiter], [Datum]

Abschnitt 4: Informationen zum Unterstützungszeitraum

Zweck: Die Begründung für den gewählten Unterstützungszeitraum gemäß Artikel 13 Absatz 8 dokumentieren. Der Unterstützungszeitraum ist der Zeitraum, in dem sich der Hersteller verpflichtet, Sicherheitsupdates bereitzustellen. Anhang VII Nummer 4 verlangt, dass die Technische Dokumentation die Informationen erfasst, die zu dieser Entscheidung geführt haben.

Erforderlicher Inhalt

UNTERSTÜTZUNGSZEITRAUM-ENTSCHEIDUNG

Erklärter Unterstützungszeitraum: [Startdatum] bis [Enddatum]
Mindestdauer: 5 Jahre ab Inverkehrbringen (oder Produktlebensdauer, falls kürzer)

Berücksichtigte Eingaben (Artikel 13 Absatz 8):
[ ] Erwartete Nutzungsdauer des Produkts
[ ] Erwartungen von Nutzern und Kunden
[ ] Art und Verwendungszweck des Produkts
[ ] Einschlägiges Unionsrecht (sektorspezifische Mindestanforderungen)
[ ] Von der Kommission herausgegebene Leitlinien
[ ] Vernünftige Erwartungen von Verbrauchern und anderen Endnutzern

Dokumentierte Begründung:
[ ] Vergleichbare Produktlebensdauern auf dem Markt
[ ] Support-Zeitpläne der Komponentenhersteller (OS, Laufzeiten, Bibliotheken)
[ ] Kundenverträge oder SLAs, die Update-Fenster implizieren
[ ] EOL-Zeitpläne der Hardware (sofern relevant)

Wie eine gute Dokumentation aussieht

BESTIMMUNG DES UNTERSTÜTZUNGSZEITRAUMS
Produkt: Industrial Gateway IG-200
Inverkehrbringen: 01.09.2026
Erklärter Unterstützungszeitraum: 01.09.2026 bis 01.09.2034 (8 Jahre)

Begründung:
1. Erwartete Betriebsdauer: 8-10 Jahre (Felddaten,
   vergleichbar mit Vorgänger IG-150, der 2024 nach 9 Jahren noch im Einsatz ist).
2. Komponenten-Support: Linux LTS-Kernel deckt 6 Jahre ab; wir backporten
   Sicherheitspatches für 2 weitere Jahre auf Basis von Herstellerzusagen.
3. Kundenverträge: Die drei größten Kunden haben 7-jährige Servicevereinbarungen;
   die übrigen verlängern üblicherweise im 5-Jahres-Rhythmus.
4. Sektorale Vorgaben: NIS2 erfasst Betreiber wesentlicher Dienste, die
   dieses Gateway einsetzen; Update-Pflichten sind über die Asset-Lebensdauer angenommen.
5. Kommunikation des Support-Endes: dokumentiert im Benutzerhandbuch und in der
   EOL-Richtlinie unter https://example.com/security/eol.

Entscheidung freigegeben durch: [Product Owner], [Sicherheitsleitung], [Recht]
Datum: 15.08.2026
Auslöser für Überprüfung: jede wesentliche Änderung der Komponenten-Support-Zeitpläne

Häufige Fallstricke

• Verankerung an der 5-Jahres-Mindestdauer ohne Begründung. Die 5 Jahre in Artikel 13 Absatz 8 sind eine Untergrenze, kein Standardwert. Produkte mit längerer erwarteter Lebensdauer brauchen einen längeren Zeitraum.
• Vergessen, dass die Untergrenze "oder Produktlebensdauer, falls kürzer" lautet. Ein Verbrauchergerät, das 18 Monate lang verkauft wird, schuldet dennoch Update-Support für den Zeitraum, in dem das Produkt vernünftigerweise noch im Einsatz ist.
• Eingaben nicht erfasst. Marktüberwachungsbehörden können fragen, wie der Zeitraum bestimmt wurde. "Wir haben 5 Jahre gewählt" ist keine Antwort.
• Behandlung als endgültig festgelegt. Wenn sich Komponenten-Support-Zeitpläne ändern (z. B. wenn ein vorgelagertes OS früher als erwartet sein EOL erreicht), muss die Entscheidung aktualisiert und die Support-Zusage kommuniziert werden.

Zuordnung grundlegender Anforderungen (Anhang I)

Zweck: Nachweisen, wie jede Anhang I-Anforderung erfüllt wird.

Anhang I, Teil I Anforderungen

Ordnen Sie jede Anforderung Ihrer Implementierung zu:

COMPLIANCE-MATRIX GRUNDLEGENDE ANFORDERUNGEN

ANHANG I, TEIL I - SICHERHEITSANFORDERUNGEN
═══════════════════════════════════════════════════════════

1. OHNE BEKANNTE AUSNUTZBARE SCHWACHSTELLEN ENTWICKELT
   Status: KONFORM
   Nachweise:
   - Schwachstellen-Scanbericht (Trivy): 0 kritisch/hoch
   - Abhängigkeitsanalyse: Alle Komponenten auf aktuellen sicheren Versionen
   - Penetrationstestbericht: Keine ausnutzbaren Schwachstellen gefunden
   Referenz: Testbericht TR-2027-001, Seiten 15-23

2. STANDARDMÄSSIG SICHERE KONFIGURATION
   Status: KONFORM
   Nachweise:
   - Dokument zur Prüfung der Standardkonfiguration
   - Keine Standardpasswörter (eindeutige Credentials bei Setup erforderlich)
   - Unnötige Dienste standardmäßig deaktiviert
   - Sichere Protokolle standardmäßig aktiviert (TLS, nicht HTTP)
   Referenz: Designdokument DD-004, Abschnitt 3.2

3. SCHUTZ VOR UNBEFUGTEM ZUGRIFF
   Status: KONFORM
   Nachweise:
   - Dokument zur Authentifizierungsarchitektur
   - Implementierung der Zugriffskontrolle
   - Session-Management-Design
   - Mechanismus zur Sperrung bei fehlgeschlagener Anmeldung
   Referenz: Sicherheitsarchitektur SA-001, Kapitel 4

4. VERTRAULICHKEIT DER DATEN
   Status: KONFORM
   Nachweise:
   - Verschlüsselungsspezifikationen (AES-256-GCM)
   - Schlüsselverwaltungsverfahren
   - Datenklassifizierung und -handhabung
   Referenz: Designdokument DD-005

5. INTEGRITÄT VON DATEN UND BEFEHLEN
   Status: KONFORM
   Nachweise:
   - Nachrichtenauthentifizierung (HMAC)
   - Befehlsvalidierungslogik
   - Eingabevalidierungsverfahren
   Referenz: Sicherheitsarchitektur SA-001, Kapitel 5

6. DATENMINIMIERUNG
   Status: KONFORM
   Nachweise:
   - Dateninventardokument
   - Begründung für jeden erhobenen Datentyp
   - Aufbewahrungsrichtlinie (automatische Löschung nach 90 Tagen)
   Referenz: Datenschutz-Folgenabschätzung PIA-001

[Fortsetzung für alle Anhang I-Anforderungen...]

Abschnitt 5: Angewandte Normen

Zweck: Dokumentieren, welche Normen verwendet wurden und wie.

Format der Normendokumentation

ANGEWANDTE NORMEN

HARMONISIERTE NORMEN (Konformitätsvermutung):
─────────────────────────────────────────────────────────────
Norm: EN 303 645 (wenn für CRA harmonisiert)
Titel: Cybersicherheit für Verbraucher-IoT
Status: Vollständig angewandt
Veröffentlichung: ABl. EU [Referenz bei Veröffentlichung]
Nachweis: Normenkonformitätsbericht SCR-001
─────────────────────────────────────────────────────────────

WEITERE ANGEWANDTE NORMEN:
─────────────────────────────────────────────────────────────
Norm: IEC 62443-4-1:2018
Titel: Sicherheit für Industrieautomation - Sichere Entwicklung
Status: Angewandt (ausgewählte Anforderungen)
Angewandte Abschnitte: 5, 6, 7, 8, 10
Nachweis: SDL-Dokumentation SLD-001
─────────────────────────────────────────────────────────────
Norm: ISO/IEC 27001:2022
Titel: Informationssicherheitsmanagement
Status: Organisation zertifiziert (Zertifikat #12345)
Relevanz: ISMS deckt Produktentwicklungsprozesse ab
─────────────────────────────────────────────────────────────

ABWEICHUNGEN:
─────────────────────────────────────────────────────────────
Norm: EN 303 645
Abschnitt: 5.3-2 (Eindeutige Credentials pro Gerät)
Abweichung: Credentials eindeutig pro Gerät, aber nicht vorprovisioniert
Begründung: Gerät erfordert Nutzer-Setup; Credentials werden
            bei Erstkonfiguration erstellt
Alternative Maßnahme: Starke Passwortanforderungen durchgesetzt,
                     Kontosperrung bei fehlgeschlagenen Versuchen
Risikobewertung: Restrisiko akzeptabel (siehe R-015)
─────────────────────────────────────────────────────────────

Abschnitt 6: Testergebnisse

Zweck: Nachweis erbringen, dass Anforderungen tatsächlich erfüllt werden.

Format der Testergebnisse

ZUSAMMENFASSUNG TESTERGEBNISSE

Produkt: SmartSense Pro (SSP-3000) v2.4.1
Testperiode: Dezember 2026 - Januar 2027
Testleiter: [Name]

═══════════════════════════════════════════════════════════
TESTKAMPAGNE: TC-2027-001
═══════════════════════════════════════════════════════════

1. FUNKTIONALE SICHERHEITSTESTS
   Umfang: Authentifizierung, Autorisierung, Verschlüsselung, Secure Boot
   Testfälle: 85
   Bestanden: 85
   Fehlgeschlagen: 0
   Referenz: Testbericht TR-FUNC-001

2. SCHWACHSTELLEN-SCANNING
   Tool: Trivy v0.48.0 + Nessus Professional
   Umfang: Firmware, Netzwerkdienste, Web-Oberfläche
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Mittel: 2 (mit Begründung akzeptiert)
     Niedrig: 5 (akzeptiert)
   Referenz: Scan-Bericht SR-VULN-001

3. PENETRATIONSTESTS
   Anbieter: [Name der Drittfirma]
   Umfang: Black-Box-Tests des bereitgestellten Geräts
   Dauer: 5 Tage
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Mittel: 1 (vor Release behoben)
     Niedrig: 3 (akzeptiert)
   Referenz: Pentest-Bericht PT-2027-001

4. FIRMWARE-ANALYSE
   Tool: EMBA v1.3
   Umfang: Binäranalyse, hartcodierte Credentials, Krypto-Probleme
   Ergebnisse:
     Kritisch: 0
     Hoch: 0
     Informativ: 4
   Referenz: Firmware-Analysebericht FA-001

═══════════════════════════════════════════════════════════
GESAMTBEWERTUNG: BESTANDEN
Alle kritischen und hohen Befunde behoben.
Mittlere/niedrige Befunde mit dokumentierter Begründung akzeptiert.
═══════════════════════════════════════════════════════════

Abschnitt 7: EU-Konformitätserklärung

Zweck: Die formelle Erklärung oder einen Verweis darauf einschließen.

Erforderlicher Inhalt

Die Technische Dokumentation muss eine Kopie der EU-Konformitätserklärung oder einen Verweis enthalten, wo sie erhältlich ist.

EU-KONFORMITÄTSERKLÄRUNG

(Siehe separates DoC-Dokument oder Kopie in Technischer Dokumentation)

Referenz: DoC-SSP3000-2027-001
Datum: 1. März 2027
Ort: Technische Dokumentation, Anhang A

Die EU-Konformitätserklärung begleitet jedes Produkt
und ist zum Download verfügbar unter:
https://firma.de/support/ssp3000/doc

Abschnitt 8: Software-Stückliste

Zweck: Komponententransparenz für die Schwachstellenverfolgung bereitstellen. Anhang VII Nummer 8 macht die SBOM zum Bestandteil der Technischen Dokumentation auf begründeten Antrag einer Marktüberwachungsbehörde. In der Praxis erstellen und pflegen Hersteller sie zusammen mit dem Rest der Dokumentation.

Verwandte Leitfäden: Für Hardwareprodukte ist zusätzlich eine HBOM erforderlich, und die Qualität wird durch BSI TR-03183 geregelt. Der Schwachstellenstatus von SBOM-Komponenten wird per VEX kommuniziert. Siehe den Leitfaden zu SBOM-Anforderungen für CycloneDX vs. SPDX, BSI TR-03183-Qualitätsstufen, HBOM-Umfang und VEX-Verwendung; sowie den Leitfaden zur Schwachstellenmeldung dazu, wie VEX die Pflicht zur Abwesenheit bekannter ausnutzbarer Schwachstellen unterstützt.

SBOM-Dokumentation

SOFTWARE-STÜCKLISTE

Produkt: SmartSense Pro (SSP-3000)
Firmware-Version: 2.4.1
SBOM-Format: CycloneDX 1.5
Erstellt: 15.01.2027
Tool: Trivy + syft

SBOM-DATEI:
sbom-ssp3000-v2.4.1.json (angehängt)

KOMPONENTENZUSAMMENFASSUNG:
─────────────────────────────────────────────────────────────
Komponenten gesamt: 127
  Direkte Abhängigkeiten: 23
  Transitive Abhängigkeiten: 104

Nach Typ:
  Bibliotheken: 98
  Frameworks: 12
  Betriebssystem: 1 (FreeRTOS)
  Firmware-Module: 16

Nach Lizenz:
  MIT: 45
  Apache 2.0: 38
  BSD: 15
  LGPL: 8
  Proprietär: 21 (interne Komponenten)
─────────────────────────────────────────────────────────────

SCHWACHSTELLENSTATUS BEI BEWERTUNG:
─────────────────────────────────────────────────────────────
Scan-Datum: 15.01.2027
Scanner: Trivy v0.48.0

Kritisch: 0
Hoch: 0
Mittel: 2 (akzeptiert - siehe unten)
Niedrig: 5 (akzeptiert)

AKZEPTIERTE SCHWACHSTELLEN:
CVE-2026-XXXXX (Mittel): Komponente xyz v1.2.3
  Status: In unserer Konfiguration nicht ausnutzbar
  Begründung: Funktion nicht aktiviert, Codepfad nicht erreichbar
  Überprüfungsdatum: 15.04.2027
─────────────────────────────────────────────────────────────

SBOM-UPDATE-VERPFLICHTUNG:
SBOM wird mit jeder Firmware-Version aktualisiert und
Kunden auf Anfrage zur Verfügung gestellt.

Wann muss die Technische Dokumentation aktualisiert werden?

Lebende Dokumentation

Die Technische Dokumentation ist nicht statisch:

AUSLÖSER FÜR AKTUALISIERUNG DER TECHNISCHEN DOKUMENTATION

VERPFLICHTENDE UPDATES:
- Neue Firmware-/Software-Version
- Sicherheitspatch-Release
- Schwachstelle entdeckt und behandelt
- Designänderung, die Sicherheit betrifft
- Normenaktualisierung (wenn angewandte Normen sich ändern)
- SBOM-Änderungen (neue/aktualisierte Komponenten)

PERIODISCHE ÜBERPRÜFUNGEN:
- Vierteljährlich: SBOM und Schwachstellenstatus
- Jährlich: Vollständige Überprüfung der Technischen Dokumentation
- Vor Ende des Supportzeitraums: Endgültige Dokumentationsfestschreibung

VERSIONSKONTROLLE:
- Alle Dokumente versionskontrolliert
- Änderungshistorie gepflegt
- Frühere Versionen archiviert

Aufbewahrungsanforderungen

DOKUMENTATIONSAUFBEWAHRUNG

Aufbewahrungsfrist: 10 Jahre ab letzter auf den Markt gebrachter Einheit

Beispiel-Zeitachse:
- Produkt erstmals auf den Markt gebracht: März 2027
- Letzte Einheit auf den Markt gebracht: Dezember 2030
- Dokumentationsaufbewahrung bis: Dezember 2040

Speicheranforderungen:
- Sichere, zugängliche Speicherung
- Backup-Verfahren
- Integritätsschutz
- Verfügbar innerhalb von [48 Stunden] auf Behördenanfrage

Häufige Fehler

Unvollständige Risikobewertung

Problem: Risikobewertung, die nicht alle Bedrohungen abdeckt oder Behandlungsdetails fehlen.

Lösung: Strukturierte Methodik verwenden. Jedes identifizierte Risiko einer Kontrolle oder Akzeptanzentscheidung zuordnen.

Fehlende SBOM

Problem: Keine SBOM oder SBOM ohne transitive Abhängigkeiten.

Lösung: SBOM mit geeignetem Tooling erstellen. Vollständigen Abhängigkeitsbaum einschließen.

Veraltete Dokumentation

Problem: Technische Dokumentation beschreibt Version 1.0, aber Produkt ist bei Version 2.3.

Lösung: Dokumentation mit jeder Version aktualisieren. Versionen explizit verfolgen.

Keine Anforderungsrückverfolgbarkeit

Problem: Behauptet Compliance, zeigt aber nicht, wie jede Anforderung erfüllt wird.

Lösung: Explizite Zuordnung von jeder Anhang I-Anforderung zu Nachweisen erstellen.

Tests ohne Nachweise

Problem: Behauptet, Tests wurden durchgeführt, aber keine Berichte verfügbar.

Lösung: Alle Testberichte aufbewahren. In Technische Dokumentation einschließen oder klar referenzieren.

Checkliste für die technische Dokumentation

VOLLSTÄNDIGKEITS-CHECKLISTE TECHNISCHE DOKUMENTATION

ABSCHNITT 1 - ALLGEMEINE BESCHREIBUNG:
[ ] Produktidentifikation vollständig
[ ] Verwendungszweck dokumentiert
[ ] CRA-Klassifizierung mit Begründung angegeben
[ ] Inverkehrbringungs-Informationen

ABSCHNITT 2 - DESIGN, ENTWICKLUNG UND SCHWACHSTELLENBEHANDLUNG:
[ ] Architekturdiagramme
[ ] Sicherheitsdesign-Dokumentation
[ ] Entwicklungsprozess-Beschreibung
[ ] Änderungsmanagement-Verfahren
[ ] Kontaktmethoden für Schwachstellenmeldungen dokumentiert
[ ] CVD-Richtlinie (koordinierte Offenlegung) veröffentlicht
[ ] Schwachstellenbehandlungsprozess dokumentiert
[ ] ENISA-Meldeverfahren eingerichtet

ABSCHNITT 3 - RISIKOBEWERTUNG:
[ ] Methodik dokumentiert
[ ] Alle Risiken identifiziert
[ ] Behandlungsentscheidungen für jedes Risiko
[ ] Restrisikobewertung

ABSCHNITT 4 - INFORMATIONEN ZUM UNTERSTÜTZUNGSZEITRAUM:
[ ] Erklärter Unterstützungszeitraum (Start- und Enddatum)
[ ] Eingaben gemäß Artikel 13 Absatz 8 dokumentiert (Nutzungsdauer, Erwartungen, sektorspezifisches Recht)
[ ] Begründung erfasst (Komponenten-Support, Kundenverträge, Hardware-EOL)
[ ] Entscheidungsfreigabe dokumentiert (Produkt, Sicherheit, Recht)

ANHANG-I-ZUORDNUNG (unterstützt Abschnitte 5-7):
[ ] Anhang I Teil I Zuordnung vollständig
[ ] Anhang I Teil II Zuordnung vollständig
[ ] Nachweise für jede Anforderung referenziert

ABSCHNITT 5 - NORMEN:
[ ] Alle angewandten Normen aufgelistet
[ ] Anwendungsnachweise erbracht
[ ] Abweichungen dokumentiert und begründet

ABSCHNITT 6 - TESTERGEBNISSE:
[ ] Testplan dokumentiert
[ ] Testberichte angehängt
[ ] Alle Befunde behandelt

ABSCHNITT 7 - KONFORMITÄTSERKLÄRUNG:
[ ] Konformitätserklärung enthalten/referenziert

ABSCHNITT 8 - SBOM (auf begründeten Antrag):
[ ] Maschinenlesbare SBOM vorbereitet (CycloneDX oder SPDX)
[ ] Alle Komponenten enthalten (direkt + transitiv)
[ ] Schwachstellenstatus dokumentiert
[ ] Verfügbar auf Anfrage der Marktüberwachungsbehörde

WARTUNG:
[ ] Versionskontrolle eingerichtet
[ ] Update-Verfahren dokumentiert
[ ] Aufbewahrungsplan vorhanden