Cyber Resilience Act 2027 : le mur de conformité hardware que la plupart des équipes sous-estiment
Le Cyber Resilience Act de l'UE a été publié au Journal officiel en novembre 2024. Les premières obligations de déclaration entrent en vigueur en septembre 2026. La pleine application, incluant l'ensemble des exigences essentielles de cybersécurité, s'applique à partir du 11 décembre 2027. Tout produit comportant des éléments numériques vendu dans l'UE est concerné. Cela inclut les machines industrielles connectées, les dispositifs médicaux, la robotique, les systèmes de défense, et une longue traîne de matériel IoT que la plupart des entreprises n'ont pas encore classé.
Ce que le CRA exige réellement
Le CRA impose trois catégories d'obligations aux fabricants de matériel. Premièrement, la sécurité dès la conception sur tout le cycle de vie : chaque produit doit être conçu, développé et produit de manière à garantir un niveau de cybersécurité approprié en fonction des risques. Deuxièmement, la gestion des vulnérabilités : les fabricants doivent identifier, documenter et corriger les vulnérabilités pendant toute la durée de vie attendue du produit, avec déclaration obligatoire des vulnérabilités activement exploitées à l'ENISA sous 24 heures. Troisièmement, l'évaluation de conformité : chaque produit doit porter un marquage CE incluant des preuves de cybersécurité, avec l'intervention d'un organisme notifié pour les classes de produits importantes et critiques.
Les amendes en cas de non-conformité atteignent 15 M€ ou 2,5 % du chiffre d'affaires mondial, le montant le plus élevé étant retenu. Les autorités nationales de surveillance du marché peuvent retirer les produits non conformes du marché de l'UE.
Le point de douleur propre au hardware
Pour les éditeurs de logiciels, le CRA formalise surtout des pratiques que beaucoup ont déjà (suivi des CVE, correctifs de sécurité, SBOM). Pour les fabricants de matériel, il fait remonter un problème bien plus difficile : l'exigence de cycle de vie.
Les produits matériels restent souvent en service pendant 10, 15 ou 25 ans. Le CRA exige que le fabricant gère les vulnérabilités sur toute la durée de vie attendue du produit, définie comme n'étant pas inférieure à cinq ans et aussi longue que le produit est raisonnablement censé être utilisé. Pour un scanner CT dont la durée de vie est de 20 ans, cela représente deux décennies de suivi des vulnérabilités sur chaque composant connecté, chaque version de firmware et chaque bibliothèque tierce utilisée.
C'est impossible sans un système de gestion de configuration qui détient le dossier tel-que-construit complet par unité, indexé par numéro de série déployé. La plupart des entreprises hardware n'ont pas cela. Elles ont un BOM générique et une base de données de flotte qui a perdu le fil des révisions il y a trois ans.
Le mandat SBOM
Le CRA exige explicitement des fabricants de matériel qu'ils maintiennent un Software Bill of Materials pour chaque produit mis sur le marché, avec un suivi des vulnérabilités par rapport à ce SBOM tout au long du cycle de vie. Le projet de guide technique de l'ENISA, publié en février 2026, spécifie le format SPDX ou CycloneDX et exige que le SBOM soit lisible par machine et interrogeable.
L'industrie du matériel n'est globalement pas prête. Une enquête de la VDMA de mars 2026 a constaté que seuls 23 % des fabricants européens de machines industrielles maintiennent un SBOM formel pour leurs produits connectés, et seuls 9 % maintiennent des SBOM au niveau du numéro de série requis pour une réponse précise aux vulnérabilités.
L'architecture qui survit au CRA
Les fabricants qui passeront l'application du CRA partagent une architecture commune. Le graphe d'ingénierie détient l'exigence, la conception, le BOM et le SBOM comme des artefacts connectés. La base de données de flotte n'est pas un système séparé ; c'est une couche du même graphe, enregistrant le SBOM tel-que-construit par unité déployée. Quand une vulnérabilité est divulguée dans une bibliothèque tierce, une seule requête identifie chaque unité affectée, chaque client, et les obligations de déclaration réglementaire déclenchées.
Sans cette architecture, la réponse aux vulnérabilités est une investigation manuelle qui prend des jours. Avec elle, la réponse est une requête qui prend quelques secondes. La fenêtre de déclaration de 24 heures du CRA pour les vulnérabilités activement exploitées fait la différence entre la conformité et une amende de 15 M€.
Que faire avant septembre 2026
La première étape est l'évaluation du périmètre : tout produit comportant des éléments numériques vendu dans l'UE après décembre 2027 est concerné. La deuxième étape est la couverture SBOM : mettre en place un SBOM formel pour chaque produit, indexé aux dossiers tel-que-construit par numéro de série. La troisième étape est architecturale : choisir un backbone d'ingénierie qui détient le SBOM au sein du graphe de configuration, pas comme un artefact parallèle dans un outil de sécurité.
Koddex a été conçu pour cette convergence. Gestion de configuration, SBOM et suivi des vulnérabilités ne sont pas des systèmes séparés. Ce sont trois vues sur le même graphe. La conformité au CRA devient une requête, pas un exercice d'urgence trimestriel.
