tanaonte - stock.adobe.com

Actualites

Top départ pour le Cyber Resilience Act

Adopté par le Parlement européen en 2024, le Cyber Resilience Act commence à entrer en application cette année. Le texte vise à rendre plus sûrs tous les produits numériques commercialisés dans l’Union, y compris les produits physiques intégrant du logiciel.

Alain Clapaud
par
Publié le: 06 août 2026

Contrairement à NIS 2, le Cyber Resilience Act est un règlement européen ; il ne nécessite donc pas de transposition en droit national et son calendrier s’applique à tous les pays européens. Comme le rappelle Maître Haas, son objectif est de définir des règles de cybersécurité minimum pour tous les produits commercialisés dans l’Union embarquant du numérique : « l’enjeu principal du CRA est de renforcer la capacité de résistance des entreprises européennes. Celles-ci ont du mal à se protéger avec de multiples applications et équipements qui présentent des vulnérabilités qui peuvent être exploitées par les attaquants ».

L’avocat estime qu'avec le montant des sanctions, jusqu’à 15 M€ d’amende ou 2,5% du chiffre d’affaires mondial en cas de récidive, l’Europe cherche clairement à contraindre les fournisseurs à réellement sécuriser leurs produits : « l’autre point est que le CRA et cette notion de résilience est directement liée à la protection des données personnelles. 80% des sanctions liées au CRA pourraient aussi inclure un manquement au RGPD ». 

Le texte européen a été inspiré par les échanges avec plusieurs organisations professionnelles, dont le Cesin en France. Alain Bouillé, son directeur général, souligne : « les RSSI sont aujourd’hui complètement submergés par des vulnérabilités qu'ils doivent traiter maintenant quasiment de manière industrielle. Ceux-ci doivent mettre en œuvre des outils pour trier, prioriser, planifier. C’est devenu une importante source de dépenses inutiles car si les outils étaient correctement sécurisés, nous n’aurions pas à en arriver là. Nous avons fait part aux parlementaires européens de nos réflexions sur le sujet et de l’urgence à faire quelque chose ».

Le texte veut contraindre toutes les entreprises qui veulent commercialiser à entrer dans la logique du Secure-by-Design, c'est-à-dire embarquer la sécurité dès la phase de conception du produit. L’objectif est de protéger les utilisateurs d’applications et de produits commercialisés dans l’union contre d’éventuelles attaques informatiques causées par les vulnérabilités qu’ils pourraient présenter. 

Le texte défini plusieurs dates butoirs. Il doit s’exercer dans sa totalité 36 mois après son vote, c'est-à-dire en 2027, le 11 décembre 2027 pour être précis. Cependant, dès le 11 septembre 2026, l’obligation de signalement des incidents graves et des vulnérabilités sera effective. Par contre, le texte ne sera pas rétroactif : les produits commercialisés avant le 11 décembre 2027 n’y seront pas soumis, sauf évolution significative. On peut imaginer que ce ne sera qu’au passage à un nouveau numéro de version majeur qu’un logiciel tombera sous la coupe du CRA.

Des produits classés en 4 catégories

La gamme de produits et services concernés est extrêmement large puisque le texte porte sur tous les logiciels, ainsi que les équipements et les produits embarquant du logiciel commercialisés dans l’Union. Cette définition inclut notamment les dispositifs IoT, industriels de type SCADA, les objets connectés grand publics. Le texte prévoit quelques exemptions, notamment les dispositifs médicaux, l’automobile, les dispositifs déjà certifiés par l’aviation civile, les équipements marins et des produits dédiés à la sécurité nationale et à la défense.

Une très large gamme de produits et logiciels seront donc concernés par ce texte, mais ceux-ci vont être classés en 4 catégories, avec des critères d’évaluation plus ou moins drastiques. A la base figurent les produits classés « par défaut ». Ce sont les produits grand public, les smartphones, les ordinateurs. Les constructeurs pourront réaliser eux-mêmes l’évaluation du produit avant sa commercialisation.

Les produits considérés comme « Importants » ont été scindés en 2 classes. La classe I regroupe 19 catégories de produits, depuis des solutions IT comme les gestionnaires de mots de passe, le SIEM, les solutions comme les routeurs, OS et navigateurs et enfin des produits sectoriels comme les jouets.

La classe II regroupe 4 types de produits : les hyperviseurs, les firewall/IDS/IPS, les microprocesseurs et les microcontrôleurs. Enfin, la catégorie des produits critiques correspond aux dispositifs de sécurité comme les équipements hardware de type HSM, les cartes à puce, les passerelles des compteurs intelligents.

Pour être commercialisés, les produits, mais aussi les procédures de contrôles qualité, devront être auto-évalués et évalués par des organismes agréés, avec un niveau de sévérité croissant entre les produits classés « par défaut », « Importants » de catégories I et II et « Critiques ». 

Des exigences avant et après la commercialisation

Pour pouvoir être commercialisé, le produit doit satisfaire à 13 exigences de base :

  1. Ne pas être affligé d’une vulnérabilité exploitable connue,
  2. Etre proposé dans une configuration sécurisée par défaut, 
  3. Assurer une correction des vulnérabilités par des mises à jour de sécurité,
  4. Disposer de mécanisme de contrôle pour se protéger des accès non autorisés,
  5. Assurer une protection de la confidentialité des données,
  6. Protéger l’intégrité des données,
  7. Limiter les données collectées au strict nécessaire,
  8. Protéger la disponibilité des fonctions essentielles et basiques,
  9. Minimiser l’impact négatif du produit sur la disponibilité des services fournis par d’autres dispositifs et des réseaux,
  10. Limiter les surfaces d’attaque par conception,
  11. Réduire l’impact d’un incident,
  12. Enregistrer et/ou surveiller l’activité interne,
  13. Donner la possibilité aux utilisateurs de supprimer de manière sûre, simple et permanente toutes les données et tous les paramètres.

Outre la phase de commercialisation, les éditeurs de logiciels et fabricants de produits vont devoir se plier à plusieurs exigences : identifier les composants logiciels du produit et les vulnérabilités, fournir des mises à jour de sécurité gratuitement et sans délai, mener des test d'intrusion réguliers, partager les informations sur les vulnérabilités corrigées, et mettre en place une politique de divulgation coordonnée des vulnérabilités.

    Toute vulnérabilité activement exploitée ou tout incident de sécurité grave doit être signalé dans un délai de 24 heures seulement et donner des informations plus détaillées sur l’incident doit être fait dans les 72 heures. Cela recouvre notamment le détail des mesures correctives qui ont été prises, celles que les utilisateurs doivent prendre et indiquer le niveau de sensibilité de l’incident. Le rapport final devra quant à lui être livré sous deux semaines. Il est à noter que l’éditeur va devoir fournir des mises à jour de sécurité pendant un minimum de 5 ans.

    En 2026 et en 2027, le CRA va être le grand chantier réglementaire pour de nombreux éditeurs de services, notamment tous les petits, qui sont moins bien équipés et moins rodés aux contraintes réglementaires et normatives que les géants du logiciel et du Cloud.

    A l’inverse, les industriels sont plus habitués à naviguer dans les normes, mais ils vont certainement devoir faire rapidement monter en maturité leurs équipes logicielles pour tenir ces nouvelles contraintes réglementaires. On se souvient que, suite à l’attaque Stuxnet sur les installations nucléaires iraniennes en 2010, Siemens avait du faire un énorme effort pour aller vers ce concept du « Secure by Design ».

    C’est désormais à tous les industriels européens de faire ce même effort. Et cela tout en surfant sur la vague du Vibe Coding...

    Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)