Règlement sur la cyberrésilience : Ce que les fabricants doivent faire dès maintenant

7 min de lecture

Le Règlement européen sur la cyberrésilience (CRA) est entré en vigueur en décembre 2024 et concerne tout fabricant mettant sur le marché européen des produits comportant des éléments numériques. À compter de septembre 2026, les premières obligations de déclaration entreront en vigueur ; à partir de décembre 2027, tous les produits devront satisfaire aux nouvelles exigences en matière de cybersécurité. Pour les entreprises industrielles du moyen secteur, cela signifie que chaque capteur connecté, chaque système de commande de machine et chaque composant logiciel relève de ce règlement. Le temps d’agir devient court.

L’essentiel en bref

Ce que le CRA réglemente et qui il concerne

Le Règlement sur la cyberrésilience constitue le premier texte réglementaire de l’Union européenne à introduire des exigences contraignantes en matière de cybersécurité pour tous les produits comportant des éléments numériques. Son champ d’application est délibérément large : il englobe aussi bien le matériel connecté (routeurs, appareils domestiques intelligents, capteurs industriels IoT) que les logiciels purs, y compris les applications, les systèmes d’exploitation et les pare-feu.

Pour les entreprises industrielles du moyen secteur, cela a des conséquences considérables. Chaque système de commande de machine doté d’une connexion réseau, chaque capteur disposant d’une fonction de mise à jour du micrologiciel (firmware) et chaque système embarqué intégré dans une installation de production relève de ce règlement.

Particulièrement pertinent pour le moyen secteur : les importateurs et distributeurs qui mettent des produits sur le marché de l’UE assument également des obligations propres. Celui qui importe un module IoT chinois et le commercialise sous sa propre marque est considéré comme « fabricant » et doit prouver la conformité complète au CRA. Cela concerne un grand nombre de constructeurs de machines et d’intégrateurs de systèmes qui intègrent des composants provenant de pays tiers dans leurs solutions.

Même ceux qui ne fabriquent pas eux-mêmes ces produits, mais les intègrent dans leurs propres solutions, supportent, en tant qu’intégrateurs, des obligations de conformité.

Seules quelques catégories sont expressément exclues : les dispositifs médicaux (déjà réglementés par le Règlement sur les dispositifs médicaux, MDR), les véhicules automobiles (réglementation UNECE), les équipements aéronautiques et certains produits nationaux liés à la sécurité. Les logiciels open source ne sont concernés que lorsqu’ils sont commercialisés à des fins commerciales.

« Le CRA garantit que les produits matériels et logiciels arrivent sur le marché avec moins de vulnérabilités et que les fabricants prennent au sérieux la sécurité tout au long du cycle de vie d’un produit. »
– Commission européenne, communiqué de presse sur le CRA, septembre 2022

Les trois échéances : ce qui entre en vigueur et quand

Le CRA est entré en vigueur le 10 décembre 2024 et sera appliqué progressivement en trois étapes. La première échéance arrive plus tôt que beaucoup d’entreprises ne l’attendent.

11 juin 2026 : l’habilitation des organismes d’évaluation de la conformité devient effective. À compter de cette date, les autorités nationales doivent avoir désigné les organismes habilités à évaluer les produits à haut risque (catégories I et II).

11 septembre 2026 : les obligations de déclaration relatives aux vulnérabilités et aux incidents de sécurité entrent en vigueur. Les fabricants doivent signaler à l’ENISA, dans les 24 heures, toute vulnérabilité activement exploitée. Pour les incidents de sécurité graves, le délai de déclaration est de 72 heures. Cette obligation entre en vigueur six mois avant l’application complète du règlement et constitue, pour de nombreuses entreprises, la première échéance contraignante.

11 décembre 2027 : application intégrale de toutes les exigences. À compter de cette date, seuls les produits conformes au CRA portant le marquage CE seront autorisés à être commercialisés sur le marché de l’UE. Les produits déjà présents sur le marché avant cette date et non substantiellement modifiés bénéficient d’une protection du statu quo.

Catégories de produits : standard, important, critique

Le CRA classe les produits en trois niveaux de risque, déterminant ainsi la procédure d’évaluation de la conformité. Cette classification a des répercussions directes sur les coûts et les efforts requis.

Produits standard (environ 90 % de tous les produits) : capteurs IoT simples, appareils domestiques intelligents sans fonction de sécurité, logiciels grand public et équipements de bureau. Les fabricants peuvent attester leur conformité par auto-évaluation. Aucun organisme tiers n’est requis.

Produits importants (catégorie I) : systèmes d’exploitation, pare-feu, routeurs, logiciels VPN, systèmes de gestion réseau. Une évaluation selon des normes harmonisées ou une vérification par un tiers est requise.

Produits critiques (catégorie II) : modules matériels de sécurité, passerelles de compteurs intelligents, systèmes de commande industrielle et infrastructures à clé publique (PKI). Une évaluation de la conformité par un organisme tiers désigné est impérativement obligatoire.

Ce que les fabricants doivent concrètement mettre en œuvre

Les exigences du CRA se répartissent en trois domaines : développement sécurisé, gestion des vulnérabilités et documentation.

Sécurité par conception (Security by Design) : les produits doivent être développés dès la phase de conception selon le principe du « sécurisé par défaut ». Cela implique une surface d’attaque minimale, des communications chiffrées, l’absence de mots de passe codés en dur et des mécanismes de mise à jour sécurisés. Les fabricants doivent démontrer que la sécurité n’a pas été ajoutée a posteriori, mais intégrée dès le départ.

Gestion des vulnérabilités : les fabricants doivent fournir des mises à jour de sécurité pendant toute la durée du cycle de vie du produit, et au minimum pendant cinq ans après sa mise sur le marché. Toute vulnérabilité activement exploitée doit être signalée à l’ENISA dans les 24 heures. Cela exige la mise en place d’un processus PSIRT fonctionnel (équipe de réponse aux incidents de sécurité des produits).

Documentation technique : pour chaque produit, une documentation exhaustive doit être disponible : analyse des risques, description de l’architecture de sécurité, rapports de tests, SBOM (liste des composants logiciels) et déclaration UE de conformité.

Un point souvent sous-estimé : l’obligation de fournir gratuitement des mises à jour de sécurité pendant au moins cinq ans. Pour les fabricants de composants industriels dont le cycle de vie s’étend sur dix à vingt ans, cela représente un engagement à long terme substantiel. Celui qui lance aujourd’hui un module de commande connecté doit garantir qu’il pourra encore être correctement mis à jour en 2032. Cela exige une architecture logicielle durable et une infrastructure de mise à jour opérationnelle allant bien au-delà du cycle de vie typique d’un produit.

Dans la pratique, cela signifie également que les fabricants doivent repenser leurs relations avec leurs fournisseurs. Si une bibliothèque open source intégrée dans un produit n’est plus maintenue, le fabricant doit soit développer lui-même les correctifs, soit remplacer la composante. La SBOM devient ici un système d’alerte précoce : elle identifie les dépendances existantes et les risques latents.

La SBOM est particulièrement pertinente, car elle doit lister exhaustivement tous les composants logiciels, y compris les bibliothèques open source.

SBOM : pourquoi la liste des composants logiciels devient un facteur décisif

La Software Bill of Materials (SBOM) constitue l’un des nouveaux instruments centraux du CRA. Dans la pratique, elle est comparable à la liste des ingrédients figurant sur un emballage alimentaire : elle recense chaque composant logiciel intégré dans un produit. Pour de nombreux acteurs du moyen secteur, cela représente un défi, car les dépendances dans les piles logicielles modernes sont complexes.

Un système embarqué typique dans une commande de machine comprend un système d’exploitation temps réel, des bibliothèques de communication, des modules cryptographiques et des dizaines d’autres composants, souvent intégrés sous forme open source. Chacun de ces composants peut contenir des vulnérabilités que le fabricant doit connaître et maîtriser.

La bonne nouvelle : des normes et outils éprouvés existent. CycloneDX et SPDX sont les deux formats SBOM dominants. Des outils de construction comme Syft ou Grype génèrent automatiquement des SBOM à partir du référentiel de code. Pour les entreprises utilisant déjà des pipelines CI/CD, la génération de SBOM peut être intégrée dans le processus de construction existant, sans perturber le flux de développement.

Pour les entreprises ne développant pas elles-mêmes de logiciels, mais achetant des composants auprès de fournisseurs, la règle est la suivante : exigez une SBOM de vos fournisseurs. Le CRA déplace la responsabilité le long de la chaîne d’approvisionnement. Celui qui intègre des composants dépourvus de SBOM dans ses propres produits assume lui-même la responsabilité des vulnérabilités inconnues.

Coût concret du CRA pour le moyen secteur

Les coûts de conformité dépendent fortement de la catégorie de produit et du niveau de maturité des processus de sécurité existants. Pour les produits standard faisant l’objet d’une auto-évaluation, les experts sectoriels estiment les coûts ponctuels à 20 000 à 50 000 euros par gamme de produits, principalement destinés à la documentation, à l’analyse des risques et à la création de la SBOM.

Pour les produits des catégories I et II, nécessitant une évaluation externe, les coûts augmentent à 80 000 à 200 000 euros. S’y ajoutent des coûts récurrents liés à la gestion des vulnérabilités : un processus PSIRT dédié, incluant surveillance, développement de correctifs et déclarations à l’ENISA, nécessite au minimum une demi-équivalent temps plein, voire davantage en pratique.

L’autre face de la médaille : selon le BSI (Office fédéral de la sécurité informatique), le coût moyen d’un incident de cybersécurité dans le moyen secteur s’élève à 500 000 euros. Un seul incident grave dépasse les coûts de conformité sur plusieurs années. S’y ajoute l’avantage concurrentiel lié à l’accès au marché : celui qui est conforme au CRA peut commercialiser ses produits partout en Europe sans restriction, tandis que les concurrents non conformes sont exclus du marché.

CRA, NIS2 et Règlement IA : la triade réglementaire

Le CRA n’existe pas isolément. Avec le NIS2 (sécurité des réseaux et des systèmes d’information) et le Règlement IA, il forme une triade réglementaire qui touche simultanément les entreprises européennes. Pour le moyen secteur, cela signifie : identifier les chevauchements et exploiter les synergies.

Le NIS2 oblige les opérateurs d’infrastructures critiques et importantes à mettre en place une gestion des risques et à déclarer les incidents. Le CRA, quant à lui, oblige les fabricants des produits utilisés par ces opérateurs. Ainsi, celui qui fabrique des capteurs IoT pour les fournisseurs d’énergie ou des logiciels de commande pour les usines d’eau doit respecter à la fois les exigences du CRA pour ses produits et celles du NIS2 applicables à ses clients.

La bonne nouvelle : de nombreuses exigences se recoupent. Celui qui dispose déjà d’un système de management de la sécurité de l’information conforme à la norme ISO/IEC 27001 couvre déjà une grande partie des exigences organisationnelles. L’exigence de SBOM du CRA complète les obligations de transparence du Règlement IA concernant les composants d’intelligence artificielle intégrés dans les produits.

Check-liste : cinq étapes vers la conformité au CRA

Décembre 2027 semble lointain, mais les obligations de déclaration à compter de septembre 2026 interviennent dans six mois. Voici une feuille de route pragmatique.

1. Établir un inventaire des produits. Quels produits comportant des éléments numériques l’entreprise commercialise-t-elle ? Lesquels disposent d’une connexion réseau, d’un micrologiciel ou de composants logiciels ? Ce recensement constitue la base de la classification des risques.

2. Déterminer la classe de risque. Pour chaque produit, vérifier s’il relève de la catégorie « standard », « catégorie I » ou « catégorie II ». Cette classification détermine si une auto-évaluation suffit ou si un organisme tiers est requis.

3. Mettre en place un processus PSIRT. À compter de septembre 2026, les vulnérabilités doivent être déclarées dans les 24 heures. Cela exige un processus de réponse aux incidents fonctionnel, avec des responsabilités clairement définies, des coordonnées de contact de l’ENISA et une procédure de déclaration documentée.

4. Créer une SBOM. Pour chaque produit, établir une Software Bill of Materials recensant tous les composants logiciels, y compris leurs versions et licences. Des outils comme CycloneDX ou SPDX automatisent ce processus.

5. Mettre en œuvre un cycle de développement sécurisé (Secure Development Lifecycle). Le principe « Security by Design » doit être intégré au processus de développement. Cela comprend la modélisation des menaces, les revues de code, les tests d’intrusion (penetration tests) et des mécanismes de mise à jour sécurisés.

Exemple pratique : un acteur du moyen secteur sur la voie de la conformité au CRA

Un fabricant de capteurs basé en Souabe, comptant 80 employés, produit des capteurs de température et d’humidité destinés à l’industrie agroalimentaire. Ces capteurs disposent d’une connexion Wi-Fi, transmettent les données de mesure à une plateforme cloud et reçoivent des mises à jour du firmware par voie aérienne (over-the-air). Jusqu’à présent, il n’existait ni processus structuré de gestion des vulnérabilités, ni SBOM.

Étape 1 : inventaire des produits. L’entreprise identifie trois gammes de produits comportant des éléments numériques, toutes classées à risque standard (auto-évaluation possible).

Étape 2 : création de la SBOM. Un prestataire externe analyse le code du firmware et établit une SBOM au format CycloneDX. Résultat : 47 composants logiciels, dont 12 bibliothèques open source, dont trois n’ayant pas été mises à jour depuis plus d’un an. Ces trois composants doivent être remplacés ou corrigés en interne.

Étape 3 : mise en place du PSIRT. Le responsable du développement logiciel assume la fonction de responsable sécurité. Un processus simple est défini : surveillance des vulnérabilités via la National Vulnerability Database (NVD), évaluation dans les 48 heures, déclaration à l’ENISA dans les 24 heures en cas d’exploitation active.

Étape 4 : documentation. Analyse des risques, architecture de sécurité et rapports de tests sont rédigés. Charge de travail totale : environ 35 000 euros et une durée de projet de trois mois.

Conclusion

Le Règlement sur la cyberrésilience transformera durablement le développement de produits en Europe. Pour les entreprises industrielles du moyen secteur, il ne s’agit pas d’une recommandation facultative, mais d’une condition obligatoire d’accès au marché. Celui qui souhaite vendre des produits connectés dans l’UE doit être conforme au CRA à compter de décembre 2027.

Mais la première échéance contraignante n’est pas décembre 2027, mais septembre 2026 : à compter de cette date, les vulnérabilités doivent être déclarées. Six mois ne constituent pas beaucoup de temps pour mettre en place un processus PSIRT, si aucun n’existe encore. Celui qui commence dès maintenant y parviendra. Celui qui attend aura à rattraper son retard sous pression temporelle. L’investissement dans la conformité au CRA n’est pas une simple charge. C’est un investissement dans la qualité des produits, la sécurité des clients et l’accès durable au marché européen, où la cybersécurité devient une condition fondamentale.

Questions fréquentes

Lectures complémentaires

Le Règlement IA à compter d’août 2026 : l’IA à haut risque dans le moyen secteur

L’attaque de la chaîne d’approvisionnement GlassWorm : plus de 400 outils compromis – SecurityToday

Sécurité de la chaîne d’approvisionnement des conteneurs : Docker et SBOM – cloudmagazin

Source de l’image : Anete Lusina / Pexels