Documentation technique CRA : guide

Le dossier technique est votre dossier de preuves pour la conformité CRA. Les autorités de surveillance du marché peuvent le demander, et un organisme notifié l'examinera lorsque votre voie d'évaluation de la conformité en implique un. Sans dossier technique complet, vous ne pouvez pas légalement mettre votre produit sur le marché de l'UE.

Ce guide parcourt le dossier technique section par section, en expliquant les preuves attendues dans chaque domaine et comment les préparer.

Qu'est-ce que le dossier technique ?

Le dossier technique (aussi appelé « documentation technique ») est le dossier complet de preuves démontrant que votre produit respecte les exigences essentielles de cybersécurité.

Ce n'est pas :

• De la documentation marketing
• Uniquement des manuels utilisateur
• Un exercice de cases à cocher

C'est :

• Des preuves techniques complètes
• Une documentation vivante (mise à jour tout au long de la vie du produit)
• Votre défense lors des enquêtes de surveillance du marché
• Requis pour l'évaluation de la conformité

Important : Le dossier technique doit être préparé AVANT la mise sur le marché et conservé au moins 10 ans après la mise sur le marché du produit, ou pendant la période de support, si celle-ci est plus longue. Les autorités peuvent le demander à tout moment.

Ce que doit contenir le dossier technique

Le dossier technique est plus facile à examiner lorsqu'il est organisé autour de huit domaines de preuves :

Section 1 : description générale

Objectif : établir ce qu'est le produit et à quoi il sert.

Contenu requis

Exemple

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

Section 2 : conception, développement et gestion des vulnérabilités

Objectif : documenter la manière dont le produit a été conçu et construit, dont les vulnérabilités sont gérées après la mise sur le marché, et dont les processus de production et de suivi sont validés. Traitez ces éléments comme un seul bloc de preuves : dossiers de conception et de développement, processus de gestion des vulnérabilités, et contrôles de production et de suivi qui montrent que les releases sont construites et surveillées de manière cohérente.

Conception et développement : contenu requis

À quoi ressemble une documentation « sécurisé dès la conception »

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)

Gestion des vulnérabilités : contenu requis

Documentation de la gestion des vulnérabilités

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

Production et suivi : contenu requis

Pour les produits logiciels, il n'y a pas de chaîne d'assemblage. La production et le suivi correspondent au pipeline de build et de release qui produit les artefacts livrables, à la validation montrant que ces processus fonctionnent comme prévu, et au suivi post-déploiement qui détecte les régressions et les nouvelles vulnérabilités. Documentez chacun de ces volets afin qu'un auditeur puisse remonter d'une release à un build vérifié et reproductible.

Documentation production et suivi

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

Section 3 : évaluation des risques de cybersécurité

Objectif : documenter les risques identifiés et la manière dont ils sont traités.

Contenu requis

Format d'évaluation des risques

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]

Section 4 : informations sur la période de support

Objectif : documenter le raisonnement qui sous-tend la période de support retenue. La période de support est la durée pendant laquelle le fabricant s'engage à fournir des mises à jour de sécurité. Le dossier technique doit consigner les informations qui ont conduit à cette décision.

Contenu requis

À quoi ressemble une bonne documentation

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

Pièges courants

• Caler sur le minimum de cinq ans sans justification. Les cinq ans de la règle relative à la période de support sont un plancher, pas une valeur par défaut. Les produits dont la durée de vie attendue est plus longue doivent prévoir une période plus longue.
• Oublier que le plancher est « ou la durée de vie du produit, si elle est plus courte ». Un appareil grand public vendu pendant 18 mois doit toujours bénéficier de mises à jour de sécurité pour la période pendant laquelle il est raisonnablement utilisé.
• Ne pas consigner les éléments pris en compte. Les autorités de surveillance peuvent demander comment la période a été déterminée. « Nous avons choisi cinq ans » n'est pas une réponse.
• Considérer la décision comme figée. Si les calendriers de support des composants évoluent (par exemple, l'OS amont atteint sa fin de vie plus tôt que prévu), le registre de décision doit être mis à jour et l'engagement de support communiqué.

Cartographie des exigences essentielles

Objectif : démontrer comment chaque exigence essentielle de cybersécurité est satisfaite.

Exigences de la partie I

Rattachez chaque exigence de sécurité dès la conception à votre implémentation :

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...]

Exigences de la partie II

Rattachez chaque exigence de gestion des vulnérabilités à votre implémentation :

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...]

Section 5 : normes appliquées

Objectif : documenter quelles normes ont été utilisées et comment.

Contenu requis

Format de la documentation des normes

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)
-------------------------------------------------------------

Astuce : automatisez la génération de votre SBOM dans la CI/CD. La création manuelle de SBOM est sujette aux erreurs et ne passe pas à l'échelle d'une gamme de versions produit.

Section 6 : résultats des tests

Objectif : apporter la preuve que les exigences sont effectivement satisfaites.

Contenu requis

Format des résultats de tests

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.
═══════════════════════════════════════════════════════════

Section 7 : déclaration UE de conformité

Objectif : inclure la déclaration formelle ou une référence à celle-ci.

Contenu requis

Le dossier technique doit inclure une copie de la déclaration UE de conformité ou une référence vers l'endroit où elle peut être obtenue.

Section 8 : nomenclature des logiciels

Objectif : apporter la transparence des composants pour le suivi des vulnérabilités. Le SBOM fait partie du dossier technique sur demande motivée d'une autorité de surveillance du marché. En pratique, les fabricants le préparent et le maintiennent en même temps que le reste du dossier.

Guides connexes : pour les produits matériels, conservez les preuves relatives aux composants matériels lorsqu'elles appuient l'évaluation des risques, les informations destinées à l'utilisateur ou l'analyse des vulnérabilités. BSI TR-03183 peut aider à améliorer la qualité du SBOM, et VEX peut communiquer le statut de vulnérabilité des composants. Consultez le guide des exigences SBOM pour les choix de format, les niveaux de qualité BSI TR-03183, le périmètre HBOM et l'usage de VEX ; ainsi que le guide du signalement des vulnérabilités pour la manière dont VEX soutient l'obligation « aucune vulnérabilité exploitable connue ».

Contenu requis

Documentation SBOM

Quand le dossier technique doit-il être mis à jour ?

Documentation vivante

Le dossier technique n'est pas statique :

Exigences de conservation

Note : conservez le dossier technique pendant la durée la plus longue entre 10 ans à compter de la mise sur le marché et la période de support. Si vous vendez des produits jusqu'en 2030 avec une période de support de cinq ans, le délai de 10 ans l'emporte et la conservation court jusqu'en 2040. Si votre période de support s'étend au-delà de cette queue de 10 ans, la conservation suit alors la période de support. Prévoyez le stockage pour la plus longue des deux.

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

Erreurs courantes

Avertissement : un dossier technique qui ne décrit que la version 1.0 alors que votre produit est en version 2.3 est considéré comme non conforme. Mettez à jour la documentation à chaque release.

Évaluation des risques incomplète

Problème : une évaluation des risques qui ne couvre pas toutes les menaces ou qui manque de détails sur le traitement.

Correction : utilisez une méthodologie structurée. Rattachez chaque risque identifié à une mesure ou à une décision d'acceptation.

SBOM manquant

Problème : pas de SBOM, ou un SBOM qui n'inclut pas les dépendances transitives.

Correction : générez le SBOM avec un outillage adapté. Incluez l'arbre complet des dépendances.

Documentation obsolète

Problème : le dossier technique décrit la version 1.0, mais le produit est en version 2.3.

Correction : mettez à jour la documentation à chaque release. Suivez les versions de manière explicite.

Pas de traçabilité des exigences

Problème : la conformité est revendiquée mais le dossier ne montre pas comment chaque exigence est satisfaite.

Correction : créez une cartographie explicite depuis chaque exigence essentielle jusqu'aux preuves.

Tests sans preuves

Problème : des tests sont revendiqués mais aucun rapport n'est disponible.

Correction : conservez tous les rapports de tests. Incluez-les dans le dossier technique ou référencez-les clairement.

Liste de vérification du dossier technique