Règlement cyberrésilience : Fabricants, agissez sans délai

7 min. de lecture

Le Règlement EU Cyber Resilience Act (CRA) est en vigueur depuis décembre 2024 et touche tous les fabricants qui introduisent des produits avec des éléments numériques sur le marché européen. À partir de septembre 2026, les premières obligations de déclaration s’appliquent, et à partir de décembre 2027, tous les produits doivent satisfaire aux nouvelles exigences de cybersécurité. Pour les entreprises de taille intermédiaire, cela signifie que tout capteur connecté, tout contrôleur de machine et chaque composant logiciel sont soumis à la réglementation. Le temps d’action est limité.

Les points clés en bref

Qu’applique le CRA et à qui s’applique-t-il

Le Règlement Cyber Resilience est la première réglementation de l’UE à introduire des exigences de cybersécurité contraignantes pour tous les produits avec des éléments numériques. Le champ d’application est consciencieusement large : il englobe des composants matériels connectés tels que les routeurs, les appareils Smart Accueil et les capteurs IoT industriels, ainsi que du logiciel pur, y compris les applications, les systèmes d’exploitation et les pare-feux.

Pour les entreprises de taille intermédiaire, les conséquences sont profondes. Tout contrôleur de machine avec connexion réseau, tout capteur avec fonctionnalité de mise à jour de firmware et chaque système embarqué dans une installation de production sont soumis à la réglementation.

Particulièrement pertinent pour les entreprises de taille intermédiaire : Les importateurs et distributeurs qui mettent en circulation des produits dans l’UE ont également des responsabilités. Celui qui importe un module IoT chinois et le vend sous son propre label est considéré comme un fabricant et doit prouver la conformité complète au CRA. Cela touche de nombreux fabricants d’outillage et des intégrateurs de systèmes qui intègrent des composants d’États tiers dans leurs solutions.

Les exceptions sont limitées : les produits médicaux (régulés par la MDR), les véhicules automobiles (réglementation UNECE), la technologie aéronautique et certaines produits de sécurité nationaux. Le logiciel open-source n’est concerné que si il est commercialisé.

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

Les trois délais: Quand et comment

Le CRA est entré en vigueur le 10 décembre 2024 et sera applicable en trois étapes. La première date limite arrive plus rapidement que ce que de nombreux entreprises attendent.

11 juin 2026: La notification des centres d’évaluation de conformité sera effective. À partir de cette date, les autorités nationales doivent avoir nommé les centres d’évaluation autorisés pour évaluer les produits à haut risque (catégories I et II).

11 septembre 2026: La responsabilité de signaler les faiblesses et les incidents de sécurité commencera. Les fabricants doivent signaler les faiblesses activement utilisées dans les 24 heures à l’ENISA. Pour les incidents de sécurité graves, la période de signalement est de 72 heures. Cette obligation prend effet six mois avant l’application complète et est pour de nombreux entreprises la première date limite sérieuse.

11 décembre 2027: Application complète de toutes les exigences. À partir de cette date, seuls les produits CRA-conformes avec la marque CE pourront être commercialisés sur le marché EU. Les produits qui étaient already sur le marché avant cette date et n’ont pas été significativement modifiés bénéficient d’un protection temporaire.

Catégories de produits: Standard, Important, Critique

Le CRA divise les produits en trois classes de risque qui déterminent la façon dont l’évaluation de la conformité doit être effectuée. L’attribution de ces classes a des implications directes sur les coûts et les efforts nécessaires.

Produits standard (environ 90 pour cent des produits): Il s’agit de capteurs IoT simples, appareils Smart Accueil sans fonctionnalités de sécurité, logiciels de consommation et appareils de bureau. Les fabricants peuvent prouver la conformité par une auto-évaluation. Aucun examinateur externe n’est nécessaire.

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

Produits critiques (catégorie II): Modules de sécurité matériels, passerelles Smart Meter, systèmes de contrôle industriels et infrastructure de clé publique. Une vérification de conformité par un tiers effectuée par une autorité nommée est obligatoire.

Qu’ils doivent concrètement mettre en œuvre, les fabricants

Les exigences CRA peuvent être divisées en trois domaines : développement sécurisé, gestion des faiblesses et documentation.

Security by Design : Les produits doivent être conçus en fonction du principe « Secure by Default ». Cela signifie : faible surface d’attaque, communication chiffrée, pas de mots de passe codés en dur et mécanismes de mise à jour sécurisés. Les fabricants doivent pouvoir démontrer que la sécurité n’est pas ajoutée de manière postérieure, mais est intégrée dès le début du processus de conception.

Gestion des faiblesses : Les fabricants doivent fournir des mises à jour de sécurité tout au long du cycle de vie du produit, au moins pendant les cinq années suivant leur introduction sur le marché. Les faiblesses activement exploitées doivent être signalées à l’ENISA dans les 24 heures. Cela nécessite un processus PSIRT (Product Security Incident Response Team) efficace.

Documentation technique : Pour chaque produit, une documentation complète est nécessaire : analyse des risques, description de l’architecture de sécurité, rapports de test, SBOM (Software Bill of Materials) et déclaration de conformité européenne. Un aspect souvent négligé est la responsabilité de fournir des mises à jour de sécurité gratuites pendant au moins cinq ans. Pour les fabricants de composants industriels avec des cycles de vie de dix à vingt ans, cela représente une obligation à long terme importante. Qui livre un module de contrôle connecté aujourd’hui, doit garantir qu’il puisse être sécurisé par des mises à jour jusqu’en 2032. Cela nécessite une architecture logicielle durable et une infrastructure de mise à jour fonctionnelle qui dépasse le cycle de vie de l’article standard.

En pratique, cela signifie également que les fabricants doivent revoir leurs relations avec leurs fournisseurs. Si une bibliothèque open source utilisée dans un produit n’est plus maintenue, le fabricant doit développer des correctifs soi-même ou remplacer la composante. L’SBOM devient un système de préavis : il montre les dépendances existantes et où les risques se cachent.

L’SBOM est particulièrement pertinent car elle doit inclure toutes les composantes logicielle, y compris les bibliothèques open source.

SBOM : Pourquoi la liste de composition logicielle devient un changement de paradigme

La Software Bill of Materials est l’un des nouveaux instruments centraux du CRA. En pratique, elle est comparable à une liste des ingrédients sur un aliment : elle énumère chaque composante logicielle utilisée dans un produit. Pour de nombreux petits et moyens entreprises, cela représente un défi, car les dépendances dans les piles de logiciels modernes sont complexes.

Un système embarqué typique dans une commande de machine comprend un système d’exploitation en temps réel, des bibliothèques de communication, des modules de cryptographie et des dizaines de composantes supplémentaires, souvent intégrées en tant qu’open source. Chaque composante de ces dernières peut contenir des faiblesses dont le fabricant doit être conscient et maîtriser.

La bonne nouvelle : des normes et des outils établis existent. CycloneDX et SPDX sont les deux formats SBOM les plus couramment utilisés. Les outils de build tels que Syft ou Grype génèrent automatiquement des SBOM à partir du dépôt de code. Pour les entreprises qui utilisent already CI/CD pipelines, l’intégration de la création de SBOM dans le processus de build existant est possible sans perturber le workflow de développement.

Pour les entreprises qui ne développent pas leur propre logiciel, mais qui acquièrent des composantes de fournisseurs, il est recommandé de demander à leurs fournisseurs une SBOM. Le CRA transfère la responsabilité le long de la chaîne de fournisseurs. Qui intègre des composantes sans SBOM dans ses produits, assume la responsabilité des faiblesses inconnues.

Quelles sont les coûts concrets du CRA pour les entreprises de taille intermédiaire

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 avec auto-évaluation, les experts du secteur prévoient des dépenses uniques de 20 000 à 50 000 euros par ligne de produits, principalement pour la documentation, l’analyse des risques et la création de la SBOM.

Pour les produits de catégorie I et II qui nécessitent une vérification externe, les coûts augmentent à 80 000 à 200 000 euros. En outre, des coûts de fonctionnement pour la gestion des faiblesses sont à prendre en compte : un processus PSIRT (Product Security Incident Response Team) dédié avec suivi, développement de correctifs et notifications ENISA nécessite au moins une demi-véritable, en pratique souvent plus.

Le rapport coût-bénéfice : les coûts moyens d’un incident de cybersécurité sont, selon le BSI, de 500 000 euros pour les entreprises de taille intermédiaire. Un seul incident majeur dépasse les coûts de conformité sur plusieurs années. En outre, il y a un avantage de marché : celui qui est CRA-conform peut commercialiser sans restrictions à l’échelle européenne, tandis que les concurrents non conformes sont exclus du marché.

CRA, NIS2 et AI Act : La triade réglementaire

Le CRA ne fonctionne pas isolément. Ensemble avec NIS2 (Sécurité des réseaux et des informations) et le AI Act, il constitue une triade réglementaire qui frappe les entreprises européennes simultanément. Pour les entreprises de taille intermédiaire, cela signifie : repérer les chevauchements et utiliser les synergies.

NIS2 exige que les exploitants d’infrastructures critiques et importantes gèrent les risques et signalent les incidents. Le CRA exige que les fabricants des produits utilisés par ces exploitants s’y conformer. Par exemple, si une entreprise fabrique des capteurs IoT pour fournisseurs d’énergie ou des logiciels de contrôle pour des usines d’eau, elle doit respecter le CRA pour ses produits et également satisfaire aux exigences de NIS2 de ses clients.

La bonne nouvelle : de nombreuses exigences se chevauchent. Qui plus est, si une entreprise exploite already un système de gestion de la sécurité des informations conforme à l’ISO 27001, elle a déjà couvert la majeure partie des exigences organisationnelles. La demande de SBOM du CRA s’ajoute aux obligations de transparence de l’AI Act pour les composants d’IA dans les produits.

Checkliste : Cinq étapes vers la conformité CRA

Le décembre 2027 semble lointain, mais les obligations de signalement à partir de septembre 2026 sont à six mois. Une feuille de route pragmatique.

1. Inventaire des produits créer. Quels produits avec des éléments numériques vendent l’entreprise ? Quels d’entre eux ont une connexion réseau, du firmware ou des composants logiciels ? L’inventaire est la base pour la classification des risques.

2. Catégorie de risque déterminer. Pour chaque produit, vérifier : standard, catégorie I ou catégorie II ? L’évaluation détermine si une auto-évaluation suffit ou si un vérificateur externe est nécessaire.

3. Processus PSIRT mettre en place. À partir de septembre 2026, les faiblesses doivent être signalées dans les 24 heures. Pour cela, un processus de réponse aux incidents fonctionnant avec des responsabilités claires, des coordonnées ENISA et un mécanisme de signalement documenté est nécessaire.

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

5. Développement sécurisé intégrer. La sécurité par conception doit être intégrée dans le processus de développement. Cela comprend la modélisation des menaces, les révisions de code, les tests d’intrusion et des mécanismes de mise à jour sécurisés.

Exemple de pratique : Un entreprise artisanale sur la voie de la CRA-compliance

Un fabricant de capteurs de la Suisse, avec 80 employés, produit des capteurs de température et de humidité pour l’industrie alimentaire. Ces capteurs sont équipés d’une connexion Wi-Fi, envoyent les données de mesure à une plateforme cloud et recevront des mises à jour de firmware en ligne. Jusqu’à présent, il n’y avait pas de gestion structurée des faiblesses et aucune liste de composants logiciels (SBOM).

Étape 1 : Inventaire des produits. L’entreprise identifie trois lignes de produits avec des éléments numériques, tous avec un risque standard (auto-évaluation possible). Étape 2 : Création de l’SBOM. Un fournisseur externe analyse le code de la firmware et génère une SBOM CycloneDX. Résultat : 47 composants logiciels, dont 12 bibliothèques open source, dont trois ne sont plus maintenus depuis plus d’un an. Ces trois doivent être remplacés ou correctés manuellement.

Étape 3 : Mise en place d’un PSIRT. Le responsable de développement logiciel assume le rôle de responsable de sécurité. Un processus simple est défini : surveillance des faiblesses via la base de données nationale des vulnérabilités (NVD), évaluation dans les 48 heures, signalement à ENISA dans les 24 heures en cas d’exploitation active. Étape 4 : Documentation. Une analyse des risques, une architecture de sécurité et des rapports de tests sont rédigés. Coût total : environ 35 000 euros et trois mois de durée du projet.

Conclusion

Le Cyber Resilience Act changera durablement la conception de produits en Europe. Pour les entreprises artisanales productrices, il n’est pas une recommandation optionnelle, mais une condition obligatoire pour l’accès au marché. Quiconque souhaite vendre des produits connectés dans l’UE doit être CRA-compliant d’ici décembre 2027.

La première deadline sévère n’est pas décembre 2027, mais septembre 2026 : à partir de cette date, les faiblesses doivent être signalées. Six mois ne sont pas beaucoup de temps pour mettre en place un processus PSIRT si celui-ci n’existe pas encore. Celui qui commence maintenant réussit. Celui qui attend se verra contraint de travailler sous pression. L’investissement dans la CRA-compliance n’est pas seulement une dépense, c’est une investment dans la qualité des produits, la sécurité des clients et l’accès à long terme au marché dans un Europe où la cybersécurité est devenue une condition préalable.

Foire aux questions

Lectures complémentaires

AI Act à partir d’août 2026 : KI à haut risque dans le mittelstand

Attaque de Supply Chain GlassWorm : 400+ outils compromis – SecurityToday

Sécurité du cycle de supply chain des conteneurs : Docker et SBOM – cloudmagazin

Source de l’illustration de tête de page : Anete Lusina / Pexels