Documentation technique CRA : ce qu’il faut produire

Le Cyber Resilience Act (CRA – reglement (UE) 2024/2847) impose aux fabricants de produits comportant des elements numeriques de constituer une documentation technique demontrant la conformite de leurs produits aux exigences essentielles de cybersecurite. Cette documentation, definie a l’annexe VII du reglement, constitue le socle de l’evaluation de conformite et doit etre conservee a la disposition des autorites de surveillance du marche pendant au moins dix ans apres la mise sur le marche du produit.

Pour les fabricants qui connaissent deja les exigences du CRA dans son ensemble, la documentation technique constitue l’un des chantiers operationnels les plus lourds. Son elaboration requiert une collaboration etroite entre les equipes de developpement, de securite, de qualite et juridiques.

Le cadre legal de la documentation technique

L’obligation de l’article 31

L’article 31 du CRA impose au fabricant d’etablir la documentation technique avant la mise sur le marche du produit. Cette documentation doit demontrer que le produit satisfait aux exigences essentielles de cybersecurite definies a l’annexe I du reglement. Elle doit etre mise a jour tout au long du cycle de vie du produit, notamment en cas de modification significative.

Le lien avec l’evaluation de conformite

La documentation technique constitue la base de l’evaluation de conformite. Selon la categorie du produit (par defaut, important classe I ou II, critique), l’evaluation peut etre realisee en auto-evaluation ou par un organisme notifie. Dans les deux cas, la documentation technique doit etre complete et a jour.

Pour les produits soumis a une evaluation tierce, l’organisme notifie examine la documentation technique pour verifier la conformite du produit. Pour les produits en auto-evaluation, le fabricant doit etre en mesure de presenter la documentation aux autorites de surveillance du marche sur demande.

Le contenu obligatoire de la documentation technique

La description generale du produit

La documentation doit contenir une description generale du produit couvrant la finalite prevue du produit et ses fonctionnalites principales, l’architecture materielle et logicielle du produit, les interfaces et protocoles de communication, les composants logiciels et materiels, y compris les composants tiers et open source, et les interactions avec d’autres systemes et equipements.

Cette description doit etre suffisamment detaillee pour permettre a un evaluateur de comprendre le fonctionnement du produit et d’evaluer les risques de cybersecurite associes.

L’evaluation des risques de cybersecurite

La documentation doit inclure l’evaluation des risques de cybersecurite realisee par le fabricant, conformement a l’article 13 du CRA. Cette evaluation doit couvrir l’identification des menaces et vulnerabilites pertinentes, l’analyse des risques pour les utilisateurs et les tiers, les mesures de securite mises en oeuvre pour attenuer les risques identifies, et l’evaluation residuelle des risques apres application des mesures.

L’evaluation des risques doit etre proportionnee a la nature du produit et aux risques identifies. Pour les produits a faible criticite, une evaluation simplifiee peut suffire. Pour les produits importants ou critiques, une evaluation detaillee est requise.

La conformite aux exigences essentielles

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

Les exigences de securite du produit :

• Conception securisee (security by design) : le produit doit etre concu pour limiter les surfaces d’attaque ;
• Protection contre les acces non autorises : mecanismes d’authentification et de controle d’acces ;
• Protection de la confidentialite et de l’integrite des donnees : chiffrement, controles d’integrite ;
• Minimisation des donnees : le produit ne doit traiter que les donnees necessaires a son fonctionnement ;
• Disponibilite : resilience aux attaques par deni de service ;
• Configuration securisee par defaut : les parametres par defaut doivent correspondre au niveau de securite le plus eleve praticable.

Les exigences de gestion des vulnerabilites :

• Identification et documentation des vulnerabilites et des composants du produit, incluant le SBOM (Software Bill of Materials) ;
• Traitement rapide des vulnerabilites decouvertes (correctifs, mises a jour) ;
• Mise a disposition des correctifs de securite gratuitement pendant la duree de support ;
• Divulgation coordonnee des vulnerabilites ;
• Mecanisme de mise a jour securise.

Pour chaque exigence, la documentation doit decrire les mesures techniques et organisationnelles mises en oeuvre et les justifications de leur adequation.

Les resultats des tests

La documentation doit contenir les resultats des tests de securite realises pour verifier la conformite du produit. Ces tests incluent les tests fonctionnels de securite (verification du bon fonctionnement des mecanismes de securite), les tests de vulnerabilite (scans de vulnerabilites, tests de penetration), les tests de robustesse (fuzzing, tests de charge, tests de resilience), et les analyses de code (analyse statique, revue de code securite).

Le niveau de test attendu est proportionne a la categorie du produit. Les produits importants et critiques necessitent des tests plus approfondis, potentiellement realises par des tiers independants.

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 dependances (composants dont depend chaque composant), et les vulnerabilites connues au moment de la publication.

Le SBOM constitue un element essentiel de la gestion des vulnerabilites : il permet de tracer rapidement les composants affectes par une nouvelle vulnerabilite et de deployer les correctifs necessaires.

Les informations a l’utilisateur

La documentation doit inclure les informations destinees a l’utilisateur du produit, conformement a l’annexe II du CRA. Ces informations couvrent les instructions d’installation et de configuration securisee, les instructions de mise a jour, les fonctionnalites de securite et leur utilisation, les contacts pour le signalement de vulnerabilites, et la duree de support du produit (fourniture de mises a jour de securite).

Les specificites par categorie de produit

Produits par defaut

Pour les produits de la categorie par defaut (risque standard), la documentation technique peut etre constituee en interne par le fabricant. L’auto-evaluation ne necessite pas l’intervention d’un organisme notifie. La documentation doit neanmoins etre complete et disponible pour les autorites de surveillance du marche.

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 etre evalues par un organisme notifie, qui examinera la documentation en detail. La documentation doit donc etre plus exhaustive et plus formalisee.

Produits integrant de l’IA

Pour les produits comportant des elements d’intelligence artificielle, la documentation technique CRA doit etre articulee avec la documentation technique exigee par le AI Act. La double conformite CRA et AI Act impose de couvrir les exigences des deux reglementations de maniere integree, evitant les redondances tout en garantissant l’exhaustivite.

La conservation et la mise a jour

La duree de conservation

La documentation technique doit etre conservee pendant au moins dix ans apres la mise sur le marche du produit, ou apres la derniere mise a jour du produit si celle-ci est posterieure. Cette duree longue impose de mettre en place un systeme d’archivage fiable et accessible.

La mise a jour continue

La documentation doit etre mise a jour en cas de modification significative du produit (nouvelle version, ajout de fonctionnalites, correction de vulnerabilites majeures), de decouverte de nouvelles vulnerabilites affectant le produit, d’evolution des normes harmonisees applicables, et de changement dans l’evaluation des risques.

La gestion des vulnerabilites au long du cycle de vie du produit impose une mise a jour reguliere du SBOM et des resultats de tests.

L’articulation avec le RGPD

Pour les produits traitant des donnees personnelles, la documentation technique CRA doit etre articulee avec les exigences du RGPD en matiere de protection des donnees des la conception (privacy by design). L’intersection entre CRA et RGPD implique que la documentation couvre les mesures de protection des donnees integrees dans le produit, les mecanismes de minimisation des donnees, les fonctionnalites de portabilite et d’effacement, et les mesures de securite specifiques aux donnees personnelles.

Les autorites de surveillance du marche (ANSSI en France) et la CNIL peuvent toutes deux avoir acces a la documentation technique dans leurs domaines de competence respectifs.

FAQ

A partir de quand la documentation technique CRA doit-elle etre prete ?

La documentation technique doit etre etablie avant la mise sur le marche du produit. Le calendrier du CRA prevoit une application progressive : les obligations de notification des vulnerabilites s’appliquent depuis septembre 2026, et l’ensemble des obligations (y compris la documentation technique) seront pleinement applicables en decembre 2027. Les fabricants doivent anticiper la constitution de la documentation des maintenant, en integrant les exigences dans leurs processus de developpement.

Le SBOM doit-il etre rendu public ?

Le CRA n’impose pas la publication du SBOM au public. Le SBOM doit etre conserve dans la documentation technique et mis a la disposition des autorites de surveillance du marche sur demande. Il doit egalement etre communique aux clients professionnels dans le cadre de leurs obligations de gestion des risques (notamment les entites financieres soumises a DORA). La publication volontaire du SBOM est une bonne pratique de transparence, mais n’est pas une obligation reglementaire.

La documentation technique CRA est-elle differente du dossier technique marquage CE ?

La documentation technique CRA s’inscrit dans le cadre general du marquage CE mais comporte des specificites propres a la cybersecurite. Pour les produits deja soumis a d’autres directives ou reglements (directive Machines, directive RED, reglement dispositifs medicaux), la documentation technique CRA vient completer la documentation existante avec les elements specifiques a la cybersecurite (evaluation des risques cyber, SBOM, gestion des vulnerabilites, resultats des tests de securite). Le fabricant peut constituer un dossier technique unique couvrant l’ensemble des reglementations applicables, en veillant a l’exhaustivite des exigences.