Documentation technique CRA : ce qu'il faut produire

Le Cyber Résilience Act (CRA – règlement (UE) 2024/2847) impose aux fabricants de produits comportant des éléments numériques de constituer une documentation technique démontrant la conformité de leurs produits aux exigences essentielles de cybersécurité. Cette documentation, définie à l’annexe VII du règlement, constitue le socle de l’évaluation de conformité et doit être conservée à la disposition des autorités de surveillance du marché pendant au moins dix ans après la mise sur le marché du produit.

Pour les fabricants qui connaissent déjà les exigences du CRA dans son ensemble, la documentation technique constitue l’un des chantiers opérationnels les plus lourds. Son élaboration requiert une collaboration étroite entre les équipes de développement, de sécurité, de qualité et juridiques.

Le cadre légal de la documentation technique

L’obligation de l’article 31

L’article 31 du CRA impose au fabricant d’établir la documentation technique avant la mise sur le marché du produit. Cette documentation doit démontrer que le produit satisfait aux exigences essentielles de cybersécurité définies à l’annexe I du règlement. Elle doit être mise à jour tout au long du cycle de vie du produit, notamment en cas de modification significative.

Le lien avec l’évaluation de conformité

La documentation technique constitue la base de l’évaluation de conformité. Selon la catégorie du produit (par défaut, important classe I ou II, critique), l’évaluation peut être réalisée en auto-évaluation ou par un organisme notifie. Dans les deux cas, la documentation technique doit être complète et à jour.

Pour les produits soumis à une évaluation tierce, l’organisme notifie examiné la documentation technique pour vérifier la conformité du produit. Pour les produits en auto-évaluation, le fabricant doit être en mesure de présenter la documentation aux autorités de surveillance du marché sur demande.

Le contenu obligatoire de la documentation technique

La description générale du produit

La documentation doit contenir une description générale du produit couvrant la finalité prévue du produit et ses fonctionnalités principales, l’architecture matérielle et logicielle du produit, les interfaces et protocoles de communication, les composants logiciels et matériels, y compris les composants tiers et open source, et les interactions avec d’autres systèmes et équipements.

Cette description doit être suffisamment détaillée pour permettre à un évaluateur de comprendre le fonctionnement du produit et d’évaluer les risques de cybersécurité associés.

L’évaluation des risques de cybersécurité

La documentation doit inclure l’évaluation des risques de cybersécurité réalisée par le fabricant, conformément à l’article 13 du CRA. Cette évaluation doit couvrir l’identification des menaces et vulnérabilités pertinentes, l’analyse des risques pour les utilisateurs et les tiers, les mesures de sécurité mises en oeuvre pour atténuer les risques identifiés, et l’évaluation residuelle des risques après application des mesures.

L’évaluation des risques doit être proportionnée à la nature du produit et aux risques identifiés. Pour les produits a faible criticité, une évaluation simplifiée peut suffire. Pour les produits importants ou critiques, une évaluation détaillée est requise.

La conformité aux exigences essentielles

La documentation doit démontrer, pour chaque exigence essentielle de l’annexe I du CRA, comment le produit y satisfait. Les exigences essentielles couvrent deux volets :

Les exigences de sécurité du produit :

• Conception sécurisée (security by design) : le produit doit être conçu pour limiter les surfaces d’attaque ;
• Protection contre les accès non autorisés : mécanismes d’authentification et de contrôle d’accès ;
• Protection de la confidentialité et de l’intégrité des données : chiffrement, contrôles d’intégrité ;
• Minimisation des données : le produit ne doit traiter que les données nécessaires à son fonctionnement ;
• Disponibilite : résilience aux attaques par déni de service ;
• Configuration sécurisée par défaut : les paramètres par défaut doivent correspondre au niveau de sécurité le plus élevé praticable.

Les exigences de gestion des vulnérabilités :

• Identification et documentation des vulnérabilités et des composants du produit, incluant le SBOM (Software Bill of Materials) ;
• Traitement rapide des vulnérabilités decouvertes (correctifs, mises à jour) ;
• Mise à disposition des correctifs de sécurité gratuitement pendant la durée de support ;
• Divulgation coordonnée des vulnérabilités ;
• Mecanisme de mise à jour sécurisé.

Pour chaque exigence, la documentation doit décrire les mesures techniques et organisationnelles mises en oeuvre et les justifications de leur adéquation.

Les résultats des tests

La documentation doit contenir les résultats des tests de sécurité réalisés pour vérifier la conformité du produit. Ces tests incluent les tests fonctionnels de sécurité (vérification du bon fonctionnement des mécanismes de sécurité), les tests de vulnérabilité (scans de vulnérabilités, tests de pénétration), les tests de robustesse (fuzzing, tests de charge, tests de résilience), et les analysés de code (analyse statique, revue de code sécurité).

Le niveau de test attendu est proportionné à la catégorie du produit. Les produits importants et critiques nécessitent des tests plus approfondis, potentiellement réalisés par des tiers indépendants.

Le SBOM (Software Bill of Materials)

Le CRA impose la constitution d’un SBOM listant l’ensemble des composants logiciels du produit, y compris les bibliotheques tierces et les composants open source. Le SBOM doit inclure le nom et la version de chaque composant, la licence applicable, les dépendances (composants dont dépend chaque composant), et les vulnérabilités connues au moment de la publication.

Le SBOM constitue un élément essentiel de la gestion des vulnérabilités : il permet de tracer rapidement les composants affectés par une nouvelle vulnérabilité et de déployer les correctifs nécessaires.

Les informations à l’utilisateur

La documentation doit inclure les informations destinées à l’utilisateur du produit, conformément à l’annexe II du CRA. Ces informations couvrent les instructions d’installation et de configuration sécurisée, les instructions de mise à jour, les fonctionnalités de sécurité et leur utilisation, les contacts pour le signalement de vulnérabilités, et la durée de support du produit (fourniture de mises à jour de sécurité).

Les spécificités par catégorie de produit

Produits par défaut

Pour les produits de la catégorie par défaut (risque standard), la documentation technique peut être constituée en interne par le fabricant. L’auto-évaluation ne nécessité pas l’intervention d’un organisme notifie. La documentation doit néanmoins être complète et disponible pour les autorités de surveillance du marché.

Produits importants et critiques

Pour les produits importants (classe I et II) et critiques, la documentation technique fait l’objet d’un examen plus approfondi. Les produits importants de classe II et les produits critiques doivent être évalués par un organisme notifie, qui examinera la documentation en détail. La documentation doit donc être plus exhaustive et plus formalisée.

Produits intégrant de l’IA

Pour les produits comportant des éléments d’intelligence artificielle, la documentation technique CRA doit être articulee avec la documentation technique exigée par le AI Act. La double conformité CRA et AI Act impose de couvrir les exigences des deux réglementations de manière intégrée, évitant les redondances tout en garantissant l’exhaustivite.

La conservation et la mise à jour

La durée de conservation

La documentation technique doit être conservée pendant au moins dix ans après la mise sur le marché du produit, ou après la dernière mise à jour du produit si celle-ci est posterieure. Cette durée longue impose de mettre en place un système d’archivage fiable et accessible.

La mise à jour continue

La documentation doit être mise à jour en cas de modification significative du produit (nouvelle version, ajout de fonctionnalités, correction de vulnérabilités majeures), de découverte de nouvelles vulnérabilités affectant le produit, d’évolution des normes harmonisees applicables, et de changement dans l’évaluation des risques.

La gestion des vulnérabilités au long du cycle de vie du produit impose une mise à jour régulière du SBOM et des résultats de tests.

L’articulation avec le RGPD

Pour les produits traitant des données personnelles, la documentation technique CRA doit être articulee avec les exigences du RGPD en matière de protection des données des la conception (privacy by design). L’intersection entre CRA et RGPD implique que la documentation couvre les mesures de protection des données intégrées dans le produit, les mécanismes de minimisation des données, les fonctionnalités de portabilité et d’effacement, et les mesures de sécurité spécifiques aux données personnelles.

Les autorités de surveillance du marché (ANSSI en France) et la CNIL peuvent toutes deux avoir accès à la documentation technique dans leurs domaines de compétence respectifs.

FAQ

À partir de quand la documentation technique CRA doit-elle être prête ?

La documentation technique doit être établie avant la mise sur le marché du produit. Le calendrier du CRA prévoit une application progressive : les obligations de notification des vulnérabilités s’appliquent depuis septembre 2026, et l’ensemble des obligations (y compris la documentation technique) seront pleinement applicables en décembre 2027. Les fabricants doivent anticiper la constitution de la documentation des maintenant, en intégrant les exigences dans leurs processus de développement.

Le SBOM doit-il être rendu public ?

Le CRA n’impose pas la publication du SBOM au public. Le SBOM doit être conservé dans la documentation technique et mis à la disposition des autorités de surveillance du marché sur demande. Il doit également être communique aux clients professionnels dans le cadre de leurs obligations de gestion des risques (notamment les entités financières soumises à DORA). La publication volontaire du SBOM est une bonne pratique de transparence, mais n’est pas une obligation réglementaire.

La documentation technique CRA est-elle différente du dossier technique marquage CE ?

La documentation technique CRA s’inscrit dans le cadre général du marquage CE mais comporte des spécificités propres à la cybersécurité. Pour les produits déjà soumis à d’autres directives ou règlements (directive Machines, directive RED, règlement dispositifs médicaux), la documentation technique CRA vient compléter la documentation existante avec les éléments spécifiques à la cybersécurité (évaluation des risques cyber, SBOM, gestion des vulnérabilités, résultats des tests de sécurité). Le fabricant peut constituer un dossier technique unique couvrant l’ensemble des réglementations applicables, en veillant à l’exhaustivite des exigences.