CRA Technische Dokumentation: Leitfaden

Die technische Datei ist Ihr Nachweispaket für die CRA-Konformität. Marktüberwachungsbehörden können sie anfordern, und eine notifizierte Stelle prüft sie, wenn Ihr Konformitätsbewertungsverfahren eine solche Stelle einbezieht. Ohne vollständige technische Datei dürfen Sie Ihr Produkt nicht legal auf dem EU-Markt in Verkehr bringen.

Dieser Leitfaden geht die technische Datei Abschnitt für Abschnitt durch und erklärt, welche Nachweise jeder Bereich braucht und wie Sie ihn vorbereiten.

Was ist die technische Datei?

Die technische Datei (auch „technische Dokumentation" genannt) ist das vollständige Nachweispaket, das belegt, dass Ihr Produkt die grundlegenden Cybersicherheitsanforderungen erfüllt.

Sie ist nicht:

• Marketing-Material
• Nur Benutzerhandbücher
• Eine Pflichtübung zum Abhaken

Sie ist:

• Umfassender technischer Nachweis
• Lebende Dokumentation (über den gesamten Produktlebenszyklus aktualisiert)
• Ihre Verteidigung bei Marktüberwachungsuntersuchungen
• Voraussetzung für die Konformitätsbewertung

Was die technische Datei enthalten muss

Die technische Datei ist leichter prüfbar, wenn sie um acht Nachweisbereiche organisiert ist:

Abschnitt 1: Allgemeine Beschreibung

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

Erforderliche Inhalte

Beispiel

GENERAL DESCRIPTION

Product Name: SmartSense Pro Industrial Sensor
Model Number: SSP-3000
Hardware Version: Rev C (PCB v3.2)
Firmware Version: 2.4.1

INTENDED PURPOSE:
The SmartSense Pro is an industrial environmental sensor
designed for manufacturing facility monitoring. It measures
temperature, humidity, and air quality, transmitting data
via WiFi to cloud or local servers.

TARGET USERS:
- Facility managers
- Industrial automation integrators
- Environmental compliance officers

INTENDED ENVIRONMENT:
- Indoor industrial facilities
- Operating temperature: -10°C to +60°C
- Network: WiFi 802.11 b/g/n

NOT INTENDED FOR:
- Medical or life-safety applications
- Outdoor installation
- Explosive atmospheres
- Consumer/residential use

CRA CLASSIFICATION:
Default product. Not classified as important or critical.
Justification: General-purpose sensor without security
functions or critical infrastructure application.

EU MARKET PLACEMENT:
First placed on market: March 15, 2027
Target markets: All EU member states
Distribution: Direct sales and authorized distributors

Abschnitt 2: Konzeption, Entwicklung und Schwachstellenbehandlung

Zweck: Dokumentieren, wie das Produkt entworfen und entwickelt wurde, wie Schwachstellen nach der Veröffentlichung behandelt werden und wie Herstellungs- und Überwachungsprozesse validiert werden. Behandeln Sie diese Themen als einen Nachweisblock: Konzeption und Entwicklung, Verfahren zur Schwachstellenbehandlung sowie Herstellungs- und Überwachungskontrollen, die zeigen, dass Releases konsistent gebaut und überwacht werden.

Konzeption und Entwicklung: Erforderliche Inhalte

Wie „Secure by Design"-Dokumentation aussieht

SECURITY ARCHITECTURE OVERVIEW

1. TRUST BOUNDARIES
   +-----------------------------------------+
   |            Cloud Backend                 |
   |  (Authentication, Data Storage)          |
   \---------------+-------------------------+
                   | TLS 1.3
   +---------------+-------------------------+
   |         Device Firmware                  |
   |  +---------------------------------+    |
   |  |    Application Layer            |    |
   |  +---------------------------------+    |
   |  |    Security Services            |    |
   |  |  (Crypto, Auth, Secure Boot)    |    |
   |  +---------------------------------+    |
   |  |    Hardware Security            |    |
   |  |  (Secure Element, RNG)          |    |
   |  \---------------------------------+    |
   \-----------------------------------------+

2. AUTHENTICATION
   - Device-to-cloud: Mutual TLS with device certificates
   - User-to-device: Local API requires authentication token
   - Certificate provisioning: Factory-provisioned, unique per device

3. DATA PROTECTION
   - Data at rest: AES-256-GCM encryption
   - Data in transit: TLS 1.3 with certificate pinning
   - Sensitive data: Stored in secure element

4. UPDATE MECHANISM
   - Signed firmware updates (ECDSA P-256)
   - Signature verification before installation
   - Rollback protection via version counter
   - Automatic update checks (user-configurable)

Schwachstellenbehandlung: Erforderliche Inhalte

Dokumentation der Schwachstellenbehandlung

VULNERABILITY HANDLING PROCEDURES

1. CONTACT METHODS
   Primary: security@company.com
   Web Form: https://company.com/security/report
   security.txt: https://company.com/.well-known/security.txt
   CVD Policy: https://company.com/security/disclosure-policy

2. RESPONSE COMMITMENTS
   Acknowledgment: Within 3 business days
   Initial Assessment: Within 10 business days
   Status Updates: Every 14 days
   Resolution Target: 90 days (critical: 7 days)

3. INTERNAL PROCESS
   [Flowchart or process description]
   See: Process Document PD-VULN-003

4. PATCH DISTRIBUTION
   Mechanism: OTA updates via cloud infrastructure
   Notification: In-app notification + email to registered users
   Verification: Signed updates with rollback capability

5. ENISA REPORTING
   Trigger: Active exploitation detected
   Timeline: 24h early warning, 72h detailed report
   Responsible: Security Team Lead
   Process: See PD-ENISA-001

6. HISTORICAL RECORD
   Vulnerabilities handled (past 24 months): 3
   Average resolution time: 45 days
   ENISA reports filed: 0

Herstellung und Überwachung: Erforderliche Inhalte

Bei Softwareprodukten gibt es keine Fertigungsstraße. Herstellung und Überwachung beziehen 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.

Dokumentation Herstellung und Überwachung

PRODUCTION AND MONITORING PROCESSES

Product: Industrial Gateway IG-200
Build platform: GitHub Actions on ubuntu-22.04 runners
Provenance: SLSA Level 3 (signed in-toto attestations)
Signing: Cosign + Sigstore, offline KMS-backed root key

BUILD PIPELINE:
1. Source: 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) + essential requirements conformance suite (89 tests)
6. Sign: cosign sign-blob + attest --predicate slsa-provenance.json
7. Release: artifact + SBOM (CycloneDX 1.5) + DoC excerpt published

VALIDATION OF PROCESSES:
- Pipeline definition reviewed quarterly (Security Lead + Release Manager)
- Essential requirements conformance test suite reviewed when standards or risks change
- Annual reproducibility audit (independent rebuild from tagged source)
- Failure mode: any gate fails -> release blocked, incident logged

POST-DEPLOYMENT MONITORING:
- Dependency CVE feed: Trivy + Renovate, daily scan against current SBOM
- Threshold: Critical or High with KEV match -> patch within 7 days
- Threshold: Medium without KEV -> patch in next monthly release
- Customer notification: signed RSS feed + email for advisories
- Internal telemetry: failed update events, signature verification failures
- Review cadence: weekly triage, monthly trend review

Abschnitt 3: Cybersicherheits-Risikobewertung

Zweck: Identifizierte Risiken und ihre Behandlung dokumentieren.

Erforderliche Inhalte

Format der Risikobewertung

CYBERSECURITY RISK ASSESSMENT

Product: SmartSense Pro (SSP-3000)
Version: 2.4.1
Assessment Date: January 2027
Assessor: [Name, Security Team]

METHODOLOGY:
Based on ISO 27005 adapted for product security.
Risk = Likelihood × Impact
Scale: Low (1-4), Medium (5-9), High (10-16), Critical (17-25)

-------------------------------------------------------------
RISK ID: R-001
THREAT: Unauthorized firmware modification
VULNERABILITY: Unsigned firmware could be installed
IMPACT: High (5) - Device compromise, data breach
LIKELIHOOD: Medium (3) - Requires physical access
INHERENT RISK: 15 (High)

CONTROL: Firmware signature verification
IMPLEMENTATION: ECDSA P-256 signature checked before install
RESIDUAL RISK: 3 (Low) - Cryptographic attack unlikely

STATUS: Mitigated
-------------------------------------------------------------
RISK ID: R-002
THREAT: Man-in-the-middle attack on cloud communication
VULNERABILITY: Network traffic interception
IMPACT: High (4) - Data exposure, command injection
LIKELIHOOD: Medium (3) - Public networks possible
INHERENT RISK: 12 (High)

CONTROL: TLS 1.3 with certificate pinning
IMPLEMENTATION: Hardcoded CA certificate, no fallback
RESIDUAL RISK: 2 (Low) - Certificate compromise unlikely

STATUS: Mitigated
-------------------------------------------------------------
[Continue for all identified risks...]

RISK SUMMARY:
Total risks identified: 23
Critical: 0
High: 3 (all mitigated to Low/Medium)
Medium: 8 (all mitigated to Low)
Low: 12 (accepted or mitigated)

RESIDUAL RISK ACCEPTANCE:
All residual risks are within acceptable tolerance.
Signed: [Security Lead], [Date]

Abschnitt 4: Informationen zum Unterstützungszeitraum

Zweck: Die Begründung des gewählten Unterstützungszeitraums dokumentieren. Der Unterstützungszeitraum ist der Zeitraum, in dem sich der Hersteller verpflichtet, Sicherheitsupdates bereitzustellen. Die technische Datei muss die Informationen erfassen, die zu dieser Entscheidung geführt haben.

Erforderliche Inhalte

Wie eine gute Dokumentation aussieht

SUPPORT PERIOD DETERMINATION
Product: Industrial Gateway IG-200
Market placement: 2026-09-01
Declared support period: 2026-09-01 to 2034-09-01 (8 years)

Rationale:
1. Expected operational lifetime: 8-10 years (field deployment data,
   comparable to predecessor IG-150 still active in 2024 at 9 years).
2. Component support: Linux LTS kernel covers 6 years; we backport
   security patches for 2 additional years using vendor commitments.
3. Customer contracts: top 3 customers have 7-year service agreements;
   remainder typically renew on 5-year cycles.
4. Sector guidance: NIS2 covers operators of essential services using
   this gateway; assume update requirements through asset lifetime.
5. End-of-support communication: documented in user manual and EOL
   policy at https://example.com/security/eol.

Decision approved by: [Product Owner], [Security Lead], [Legal]
Date: 2026-08-15
Review trigger: any material change to component support timelines

Häufige Fallstricke

• Verankerung an der Fünfjahres-Mindestdauer ohne Begründung. Die 5 Jahre in der Unterstützungszeitraum-Regel sind eine Untergrenze, kein Standardwert. Produkte mit längerer erwarteter Lebensdauer benötigen einen längeren Zeitraum.
• Vergessen, dass die Untergrenze „oder Produktlebensdauer, falls kürzer" lautet. Ein 18 Monate lang verkauftes Verbrauchergerät 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 unveränderlich. Wenn sich Komponenten-Support-Zeitpläne ändern (z. B. wenn ein vorgelagertes Betriebssystem früher als erwartet sein EOL erreicht), muss die Entscheidung aktualisiert und die Support-Zusage neu kommuniziert werden.

Zuordnung der grundlegenden Anforderungen

Zweck: Nachweisen, wie jede grundlegende Cybersicherheitsanforderung erfüllt wird.

Teil I Anforderungen

Ordnen Sie jede Secure-by-Design-Anforderung Ihrer Implementierung zu:

ESSENTIAL REQUIREMENTS COMPLIANCE MATRIX

ANNEX I, PART I - SECURITY REQUIREMENTS
═══════════════════════════════════════════════════════════

1. DESIGNED WITHOUT KNOWN EXPLOITABLE VULNERABILITIES
   Status: COMPLIANT
   Evidence:
   - Vulnerability scan report (Trivy): 0 critical/high
   - Dependency analysis: All components at latest secure versions
   - Penetration test report: No exploitable vulnerabilities found
   Reference: Test Report TR-2027-001, pages 15-23

2. SECURE BY DEFAULT CONFIGURATION
   Status: COMPLIANT
   Evidence:
   - Default configuration review document
   - No default passwords (unique credentials required at setup)
   - Unnecessary services disabled by default
   - Secure protocols enabled by default (TLS, not HTTP)
   Reference: Design Document DD-004, Section 3.2

3. PROTECTION AGAINST UNAUTHORIZED ACCESS
   Status: COMPLIANT
   Evidence:
   - Authentication architecture document
   - Access control implementation
   - Session management design
   - Failed login lockout mechanism
   Reference: Security Architecture SA-001, Chapter 4

4. CONFIDENTIALITY OF DATA
   Status: COMPLIANT
   Evidence:
   - Encryption specifications (AES-256-GCM)
   - Key management procedures
   - Data classification and handling
   Reference: Design Document DD-005

5. INTEGRITY OF DATA AND COMMANDS
   Status: COMPLIANT
   Evidence:
   - Message authentication (HMAC)
   - Command validation logic
   - Input validation procedures
   Reference: Security Architecture SA-001, Chapter 5

6. DATA MINIMIZATION
   Status: COMPLIANT
   Evidence:
   - Data inventory document
   - Justification for each data type collected
   - Retention policy (automatic purge after 90 days)
   Reference: Privacy Impact Assessment PIA-001

[Continue for all essential requirements...]

Teil II Anforderungen

Ordnen Sie jede Schwachstellenbehandlungsanforderung Ihrer Implementierung zu:

ANNEX I, PART II - VULNERABILITY HANDLING
═══════════════════════════════════════════════════════════

1. IDENTIFY AND DOCUMENT VULNERABILITIES
   Status: COMPLIANT
   Evidence:
   - Vulnerability tracking system (JIRA project VULN)
   - CVE monitoring process document
   - SBOM-based dependency tracking
   Reference: Process Document PD-VULN-001

2. ADDRESS VULNERABILITIES WITHOUT DELAY
   Status: COMPLIANT
   Evidence:
   - Vulnerability response SLA document
   - Historical response time metrics
   - Patch development process
   Reference: Process Document PD-VULN-002

3. APPLY EFFECTIVE REGULAR TESTING
   Status: COMPLIANT
   Evidence:
   - Security testing schedule
   - Automated scan reports (weekly)
   - Annual penetration test reports
   Reference: Test Plan TP-SEC-001

[Continue for all Part II requirements...]

Abschnitt 5: Angewandte Normen

Zweck: Dokumentieren, welche Normen herangezogen wurden und wie.

Erforderliche Inhalte

Format der Normendokumentation

APPLIED STANDARDS

HARMONIZED STANDARDS (presumption of conformity):
-------------------------------------------------------------
Standard: EN 303 645 (when harmonized for CRA)
Title: Cybersecurity for Consumer IoT
Status: Applied in full
Publication: OJEU [reference when published]
Evidence: Standards Compliance Report SCR-001
-------------------------------------------------------------

OTHER STANDARDS APPLIED:
-------------------------------------------------------------
Standard: IEC 62443-4-1:2018
Title: Security for Industrial Automation - Secure Development
Status: Applied (selected requirements)
Clauses Applied: 5, 6, 7, 8, 10
Evidence: SDL Documentation SLD-001
-------------------------------------------------------------
Standard: ISO/IEC 27001:2022
Title: Information Security Management
Status: Organization certified (Certificate #12345)
Relevance: ISMS covers product development processes
-------------------------------------------------------------
Standard: NIST Cybersecurity Framework 2.0
Title: Framework for Improving Critical Infrastructure Cybersecurity
Status: Reference framework for risk assessment
Evidence: Risk Assessment methodology document
-------------------------------------------------------------

DEVIATIONS:
-------------------------------------------------------------
Standard: EN 303 645
Clause: 5.3-2 (Unique per device credentials)
Deviation: Credentials unique per device but not pre-provisioned
Justification: Device requires user setup; credentials created
              during first-time configuration
Alternative Measure: Strong password requirements enforced,
                    account lockout after failed attempts
Risk Assessment: Residual risk acceptable (see R-015)
-------------------------------------------------------------

Abschnitt 6: Prüfergebnisse

Zweck: Nachweise dafür liefern, dass die Anforderungen tatsächlich erfüllt sind.

Erforderliche Inhalte

Format der Prüfergebnisse

TEST RESULTS SUMMARY

Product: SmartSense Pro (SSP-3000) v2.4.1
Test Period: December 2026 - January 2027
Test Lead: [Name]

═══════════════════════════════════════════════════════════
TEST CAMPAIGN: TC-2027-001
═══════════════════════════════════════════════════════════

1. SECURITY FUNCTIONAL TESTING
   Scope: Authentication, authorization, encryption, secure boot
   Test Cases: 85
   Passed: 85
   Failed: 0
   Reference: Test Report TR-FUNC-001

2. VULNERABILITY SCANNING
   Tool: Trivy v0.48.0 + Nessus Professional
   Scope: Firmware, network services, web interface
   Findings:
     Critical: 0
     High: 0
     Medium: 2 (accepted with justification)
     Low: 5 (accepted)
   Reference: Scan Report SR-VULN-001

3. PENETRATION TESTING
   Provider: [Third-party firm name]
   Scope: Black-box testing of deployed device
   Duration: 5 days
   Findings:
     Critical: 0
     High: 0
     Medium: 1 (remediated before release)
     Low: 3 (accepted)
   Reference: Pentest Report PT-2027-001

4. FIRMWARE ANALYSIS
   Tool: EMBA v1.3
   Scope: Binary analysis, hardcoded credentials, crypto issues
   Findings:
     Critical: 0
     High: 0
     Informational: 4
   Reference: Firmware Analysis Report FA-001

5. CONFIGURATION REVIEW
   Scope: Default configuration security
   Findings: All defaults meet security requirements
   Reference: Configuration Review CR-001

═══════════════════════════════════════════════════════════
OVERALL ASSESSMENT: PASS
All critical and high findings remediated.
Medium/Low findings accepted with documented justification.
═══════════════════════════════════════════════════════════

Abschnitt 7: EU-Konformitätserklärung

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

Erforderliche Inhalte

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

Abschnitt 8: Software-Stückliste

Zweck: Komponententransparenz für die Schwachstellenverfolgung bereitstellen. Die SBOM gehört auf begründetes Verlangen einer Marktüberwachungsbehörde zur technischen Datei. In der Praxis erstellen und pflegen Hersteller sie zusammen mit dem Rest der Dokumentation.

Verwandte Leitfäden: Bewahren Sie bei Hardwareprodukten Nachweise zu Hardware-Komponenten dort auf, wo sie die Risikobewertung, die Nutzerinformationen oder die Schwachstellenanalyse stützen. BSI TR-03183 kann bei der SBOM-Qualität helfen, und VEX kann den Schwachstellenstatus einzelner Komponenten kommunizieren. Siehe den Leitfaden zu SBOM-Anforderungen für Formatentscheidungen, BSI TR-03183-Qualitätsstufen, HBOM-Umfang und VEX-Nutzung; sowie den Leitfaden zur Schwachstellenmeldung dazu, wie VEX die Pflicht zur Abwesenheit bekannter ausnutzbarer Schwachstellen unterstützt.

Erforderliche Inhalte

SBOM-Dokumentation

Wann muss die technische Datei aktualisiert werden?

Lebende Dokumentation

Die technische Datei ist nicht statisch:

Aufbewahrungspflichten

DOCUMENTATION RETENTION

Retention Period: at least 10 years from market placement, or the support period, whichever is longer

Example Timeline:
- Product first placed on market: March 2027
- Last unit placed on market: December 2030
- Documentation retention until: December 2040

Storage Requirements:
- Secure, accessible storage
- Backup procedures
- Integrity protection
- Available within [48 hours] of authority request

Häufige Fehler

Unvollständige Risikobewertung

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

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

Fehlende SBOM

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

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

Veraltete Dokumentation

Problem: Die technische Datei beschreibt Version 1.0, aber das Produkt ist bei Version 2.3.

Lösung: Dokumentation mit jedem Release aktualisieren. Versionen explizit nachhalten.

Keine Anforderungsrückverfolgbarkeit

Problem: Konformität wird behauptet, aber nicht gezeigt, wie jede Anforderung erfüllt wird.

Lösung: Explizite Zuordnung von jeder grundlegenden Anforderung auf Nachweise erstellen.

Tests ohne Nachweise

Problem: Tests werden behauptet, aber es liegen keine Berichte vor.

Lösung: Alle Prüfberichte aufbewahren. In die technische Datei aufnehmen oder eindeutig referenzieren.

Checkliste für die technische Datei