Cyber Résilience Act (CRA) : guide complet du règlement européen

Le Cyber Résilience Act (CRA) – règlement (UE) 2024/2847 – est le premier texte européen qui impose des exigences horizontales de cybersécurité à l’ensemble des produits comportant des éléments numériques. Adopte le 23 octobre 2024 et publié au Journal officiel de l’Union européenne le 20 novembre 2024, ce règlement transformé en profondeur les obligations des fabricants, importateurs et distributeurs de produits connectés et de logiciels.

Pour les organisations qui traitent déjà les sujets de sécurité dans le cadre du RGPD ou de la directive NIS2, le CRA constitue une couche supplémentaire qu’il est indispensable de maîtriser. Voyons cela en détail.

I. Pourquoi le Cyber Résilience Act ?

Le constat est sans appel : la multiplication des objets connectés et des logiciels a créé une surface d’attaque considérable en Europe. Selon les estimations de la Commission européenne, le coût annuel de la cybercriminalité était estimé à 5 500 milliards d’euros au niveau mondial en 2021. Or, jusqu’au CRA, il n’existait aucune réglementation horizontale imposant un niveau minimum de sécurité pour les produits numériques mis sur le marché européen.

Trois problèmes majeurs justifient ce texte :

1. Un faible niveau de cybersécurité des produits – de nombreux appareils IoT, logiciels et composants sont commercialises avec des vulnérabilités connues, des mots de passe par défaut, ou sans mécanisme de mise à jour.
2. L’asymetrie d’information – les acheteurs professionnels et les consommateurs n’ont aucun moyen fiable d’évaluer le niveau de sécurité d’un produit avant achat.
3. L’absence de suivi post-commercialisation – une fois le produit vendu, les fabricants n’avaient aucune obligation légale de corriger les vulnérabilités decouvertes.

Le CRA entend résoudre ces trois problèmes de front. Il impose la sécurité des la conception, la transparence vis-à-vis du marché, et un suivi des vulnérabilités pendant toute la durée de vie du produit.

II. Champ d’application : quels produits sont concernés ?

A. La notion de “produit comportant des éléments numériques”

Le CRA s’applique à tout produit comportant des éléments numériques (“product with digital éléments”), défini comme tout produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels et matériels mis sur le marché séparément.

Concrètement, cela couvre :

• les objets connectés (IoT) : caméras, thermostats, serrures connectées, appareils médicaux connectés ;
• les logiciels (applications, systèmes d’exploitation, firmwares) ;
• les composants matériels (processeurs, cartes réseau, modules de communication) ;
• les solutions SaaS lorsqu’elles constituent le traitement de données à distance d’un produit (voir notre analyse des obligations CRA pour les éditeurs SaaS).

B. Les exclusions

Le CRA ne s’applique pas a :

• les services cloud et SaaS purs (couverts par NIS2) ;
• les dispositifs médicaux déjà couverts par les règlements (UE) 2017/745 et 2017/746 ;
• les véhicules a moteur couverts par le règlement (UE) 2019/2144 ;
• les produits développés exclusivement à des fins de sécurité nationale ou de défense ;
• les logiciels libres et open source développés dans un cadre non commercial (mais attention : des qu’un logiciel open source est intègre dans un produit commercial, le fabricant de ce produit assumé les obligations du CRA).

Ce dernier point mérite une attention particulière. L’écosystème open source a été largement mobilise pendant les débats législatifs. La version finale du texte prévoit un statut spécifique pour les “intendants de logiciels libres” (open source software stewards), qui sont soumis à des obligations allégées.

C. La classification par niveaux de criticité

Le CRA établit une classification des produits en trois catégories, selon leur niveau de risque :

Catégorie	Exemples	Évaluation de conformité
Produits par défaut	Disques durs, jeux vidéo, logiciels de bureautique	Auto-évaluation par le fabricant
Produits importants (classe I)	Gestionnaires de mots de passe, VPN, routeurs domestiques, systèmes domotiques, jouets connectés	Normes harmonisees ou évaluation tierce
Produits importants (classe II)	Pare-feu industriels, systèmes de détection d’intrusion, microprocesseurs sécurisés, systèmes d’exploitation	Évaluation tierce obligatoire
Produits critiques	Cartes a puce, dispositifs de création de signature électronique, passerelles de compteurs intelligents	Certification européenne de cybersécurité

Cette classification déterminé la procédure d’évaluation de conformité applicable, allant de la simple auto-évaluation à la certification par un organisme tiers.

III. Qui est concerné ? Les acteurs de la chaîne de valeur

Le CRA distribue les obligations entre trois catégories d’opérateurs économiques :

A. Les fabricants

Le fabricant est l’acteur qui supporté l’essentiel des obligations. Il s’agit de toute personne physique ou morale qui développé ou fait développer un produit avec des éléments numériques et le commercialise sous son nom ou sa marque.

Ses obligations principales :

• Concevoir le produit selon le principe de sécurité par défaut et des la conception (security by design and by default) ;
• Réaliser une évaluation des risques de cybersécurité avant la mise sur le marché ;
• Produire et maintenir un SBOM (Software Bill of Materials – nomenclature logicielle) ;
• Corriger les vulnérabilités sans délai et fournir des mises à jour de sécurité gratuites pendant toute la période de support ;
• Signaler les vulnérabilités activement exploitées et les incidents gravés à l’ENISA dans les 24 heures ;
• Apposer le marquage CE attestant de la conformité ;
• Rédiger la documentation technique et la déclaration de conformité UE.

B. Les importateurs

L’importateur met sur le marché de l’Union un produit provenant d’un fabricant établi hors de l’UE. Les obligations spécifiques des importateurs et distributeurs sont détaillées dans notre article dédié. Avant la mise sur le marché, il doit vérifier que :

• le fabricant a effectué l’évaluation de conformité appropriée ;
• la documentation technique est disponible ;
• le produit porte le marquage CE ;
• le fabricant a mis en place les procédures de gestion des vulnérabilités.

Si l’importateur à des raisons de croire que le produit n’est pas conforme, il ne doit pas le mettre sur le marché et doit en informer le fabricant et les autorités de surveillance.

C. Les distributeurs

Le distributeur met à disposition le produit sur le marché sans en modifier les caractéristiques. Ses obligations sont allégées mais réelles : il doit vérifier que le produit porte le marquage CE et que l’importateur ou le fabricant a satisfait à ses obligations d’identification. En cas de risque identifie, il doit en informer le fabricant et les autorités compétentes.

IV. Les obligations clés en détail

A. Sécurité par conception et par défaut (Security by Design)

Le CRA impose que la cybersécurité soit intégrée des la phase de conception du produit. L’annexe I du règlement énumère les exigences essentielles, parmi lesquelles :

• le produit doit être mis sur le marché sans vulnérabilité exploitable connue ;
• la configuration par défaut doit être sécurisée (pas de mots de passe generiques, accès restreints par défaut) ;
• les données stockées, transmises ou traitées doivent être protégées (chiffrement, contrôle d’intégrité) ;
• le produit doit minimiser sa surface d’attaque ;
• les mécanismes d’authentification doivent être robustes ;
• la disponibilité des fonctions essentielles doit être assurée, y compris en cas d’attaque (résilience) ;
• le produit doit générer des journaux d’audit pertinents.

Ces exigences ne sont pas nouvelles pour les praticiens de la sécurité. Elles rejoignent largement les obligations de sécurité des données au titre de l’article 32 du RGPD. La différence fondamentale est qu’elles s’appliquent désormais au produit lui-même, et non au traitement de données.

B. Gestion des vulnérabilités

Le fabricant doit mettre en place un processus structuré de gestion des vulnérabilités tout au long du cycle de vie du produit. Cela inclut :

• l’identification et la documentation de toutes les vulnérabilités et composants tiers contenus dans le produit ;
• la fourniture de mises à jour de sécurité gratuites et en temps utile ;
• la publication d’informations sur les vulnérabilités corrigées (advisories) ;
• la mise à disposition d’un mécanisme de signalement des vulnérabilités accessible au public (politique de divulgation coordonnée).

La durée de cette obligation couvre la durée de vie attendue du produit ou cinq ans après la mise sur le marché, la période la plus courte étant retenue. Ce point est crucial : un fabricant d’objets connectés doit anticiper la durée de support des son choix de conception.

C. Le SBOM (Software Bill of Materials)

Le SBOM est l’une des innovations les plus structurantes du CRA. Il s’agit d’un inventaire exhaustif de tous les composants logiciels intégrés dans un produit, incluant les bibliotheques tierces et les dépendances open source.

Le fabricant doit :

• générer et maintenir un SBOM à jour ;
• le mettre à disposition des autorités de surveillance sur demande ;
• identifier les composants présentes dans le produit au minimum au niveau du package.

Le SBOM n’a pas vocation a être rendu public (sa divulgation pourrait d’ailleurs faciliter certaines attaques). Mais il doit être disponible pour les autorités et constitue un outil essentiel de traçabilité en cas de fuite de données ou de découverte de vulnérabilité dans un composant tiers (l’affaire Log4Shell en est l’illustration parfaite).

D. Notification des incidents et des vulnérabilités

Le CRA impose un mécanisme de notification a deux etages :

1. Vulnerabilites activement exploitées : le fabricant doit notifier l’ENISA (Agence de l’Union européenne pour la cybersécurité) dans les 24 heures suivant la découverte, puis fournir un rapport complet dans les 72 heures, et un rapport final dans les 14 jours.
2. Incidents de sécurité gravés ayant un impact sur la sécurité du produit : même calendrier de notification.

Ces délais sont calques sur ceux de la directive NIS2, ce qui est logique. Les organisations déjà soumises à NIS2 retrouveront un cadre familier. L’ENISA jouera le rôle de plateforme centralisée de signalement, puis redistribuera l’information aux CSIRT nationaux compétents.

E. Le marquage CE

Le marquage CE, déjà bien connu en matière de sécurité des produits, est étendu à la cybersécurité. Un produit conforme au CRA devra porter le marquage CE, qui attestera du respect des exigences essentielles de cybersécurité.

Ce marquage implique :

• la rédaction d’une déclaration de conformité UE ;
• la constitution d’un dossier technique ;
• le passage par la procédure d’évaluation de conformité adaptée à la catégorie du produit.

En pratique, le marquage CE deviendra un prérequis pour la mise sur le marché européen. Les produits non conformes seront simplement interdits de commercialisation.

V. Articulation avec les autres réglementations

A. CRA et NIS2

Le CRA et la directive NIS2 sont complémentaires :

• NIS2 porte sur la sécurité des réseaux et systèmes d’information des entités essentielles et importantes (opérateurs de services) ;
• Le CRA porte sur la sécurité des produits mis sur le marché.

En pratique, une organisation soumise à NIS2 qui fabrique également des produits connectés devra se conformer aux deux textes. Le CRA créé aussi un pont direct : les fabricants de produits critiques dont les vulnérabilités pourraient affecter des entités NIS2 devront prendre en compte cet impact dans leur évaluation des risques.

B. CRA et RGPD

Le CRA et le RGPD se rejoignent sur un point fondamental : la sécurité. L’article 32 du RGPD impose déjà des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Le CRA ajouté une couche supplémentaire en imposant la sécurité au niveau du produit lui-même.

En pratique, un produit conforme au CRA contribuera mécaniquement au respect des obligations de sécurité du RGPD. Inversement, un produit non conforme au CRA utilise pour traiter des données personnelles constituera un facteur de risque aggravant en cas de contrôle ou de fuite de données.

Pour les DPO et les RSSI, le CRA impose de prendre en compte la conformité des produits acquis dans le cadre de leur audit de sécurité informatique.

C. CRA et règlement sur l’IA

Les systèmes d’intelligence artificielle a haut risque couverts par le règlement IA (AI Act) sont également concernés par le CRA lorsqu’ils constituent des produits avec des éléments numériques. La conformité au CRA est alors une condition préalable à la conformité au règlement IA.

VI. Calendrier d’application

Le CRA est entre en vigueur le 10 décembre 2024 (20 jours après sa publication). Mais son application est échelonnée :

Echeance	Évènement
10 décembre 2024	Entree en vigueur du règlement
11 juin 2026	Application des obligations relatives aux organismes d’évaluation de la conformité (organismes notifies)
11 septembre 2026	Application des obligations de notification (vulnérabilités activement exploitées et incidents)
11 décembre 2027	Application de l’ensemble des obligations du CRA

Les fabricants disposent donc de trois ans à compter de l’entrée en vigueur pour se mettre en conformité, mais certaines obligations – notamment la notification des vulnérabilités – s’appliqueront des septembre 2026.

Ce calendrier est serre. Pour les organisations qui n’ont pas encore entamé leur démarche, le temps presse.

VII. Sanctions

Le régime de sanctions du CRA est significatif et suit la logique désormais établie par le RGPD et NIS2 :

Type d’infraction	Sanction maximale
Non-respect des exigences essentielles de cybersécurité (annexe I)	15 millions d’euros ou 2,5 % du CA annuel mondial
Non-respect des autres obligations du règlement	10 millions d’euros ou 2 % du CA annuel mondial
Fourniture d’informations inexactes ou incomplètes aux autorités	5 millions d’euros ou 1 % du CA annuel mondial

Dans tous les cas, c’est le montant le plus élevé qui s’applique. Les autorités nationales de surveillance du marché seront compétentes pour prononcer ces sanctions, et pourront également ordonner le retrait ou le rappel de produits non conformes.

Il faut noter que ces sanctions s’ajoutent aux sanctions déjà applicables au titre du RGPD ou de NIS2. Un même manquement de sécurité pourrait donc théoriquement donner lieu à des sanctions cumulatives au titre de plusieurs textes.

VIII. Impacts pratiques pour les entreprises

A. Pour les fabricants et éditeurs de logiciels

L’impact est majeur. Il faut concrètement :

• Revoir les processus de développement pour intégrer la sécurité par conception (DevSecOps, threat modeling, revue de code sécurité) ;
• Mettre en place la génération et la maintenance d’un SBOM pour chaque produit ;
• Formaliser un processus de gestion des vulnérabilités conforme aux exigences du CRA ;
• Préparer la documentation technique et la déclaration de conformité ;
• Déterminer la catégorie de chaque produit et identifier la procédure d’évaluation de conformité applicable ;
• Budgeter les coûts de certification pour les produits de classe II et les produits critiques.

B. Pour les acheteurs et utilisateurs professionnels

Les organisations qui achetent des produits numériques doivent intégrer les exigences du CRA dans leurs processus d’approvisionnement :

• Exiger la documentation de conformité CRA dans les appels d’offres ;
• Vérifier la présence du marquage CE incluant la composante cybersécurité ;
• Intégrer la durée de support sécurité comme critère de sélection ;
• Demander les SBOM pour les produits critiques pour l’organisation.

C. Pour les DPO et les RSSI

Le CRA créé un nouveau levier pour améliorer la sécurité globale :

• Intégrer la conformité CRA dans les audits de sécurité et les analysés d’impact ;
• Documenter les produits utilisés et leur statut de conformité CRA ;
• Anticiper les obligations de notification qui se cumulent avec celles du RGPD (72 heures pour les violations de données) et de NIS2.

Pour faciliter la gestion de ces obligations croisées, des outils de conformité automatisée comme Legiscope permettent de centraliser le suivi de la conformité RGPD, NIS2 et CRA au sein d’une même plateforme.

IX. Que faire maintenant ?

Le CRA n’est pas un texte futur – il est déjà en vigueur. Voici les étapes prioritaires :

1. Diagnostiquer votre exposition. Identifiez si votre organisation est fabricant, importateur ou distributeur de produits avec des éléments numériques. Si vous êtes uniquement utilisateur, identifiez les produits critiques de votre parc.

2. Classifier vos produits. Pour les fabricants : déterminez dans quelle catégorie tombe chaque produit (par défaut, classe I, classe II, critique). Cela conditionnera la procédure d’évaluation de conformité et les investissements nécessaires.

3. Mettre en place la gestion des vulnérabilités. C’est la première obligation qui s’appliquera (septembre 2026). Mettez en place un processus de détection, correction et notification des vulnérabilités conforme aux exigences du CRA.

4. Générer vos SBOM. Si ce n’est pas déjà fait, integrez la génération automatique de SBOM dans votre pipeline de développement. C’est un prérequis technique incontournable.

5. Adapter vos processus de développement. Integrez les exigences de sécurité par conception dans vos pratiques de développement. Pour les organisations matures, c’est souvent une évolution; pour les autres, c’est une transformation profonde.

6. Préparer la documentation de conformité. Dossier technique, déclaration de conformité, procédures de gestion des vulnérabilités – la charge documentaire est significative. Commencez tot.

7. Anticiper la certification. Pour les produits de classe II et les produits critiques, identifiez des maintenant les organismes notifies et les schémas de certification applicables. Les délais de certification peuvent être longs.

8. Centraliser votre conformité. Le CRA s’ajouté au RGPD, a NIS2, et potentiellement au règlement IA. Un outil de suivi de conformité centralisé tel que Legiscope devient rapidement indispensable pour éviter les doublons et les angles morts.

Le Cyber Résilience Act marque un tournant. Pour la première fois, la cybersécurité des produits numériques n’est plus optionnelle – elle est une obligation légale, assortie de sanctions dissuasives. Les organisations qui anticipent seront celles qui transformeront cette contrainte réglementaire en avantage concurrentiel.

FAQ

Quels produits sont concernés par le Cyber Résilience Act ?

Le CRA s’applique à tout produit comportant des éléments numériques : objets connectés (caméras, thermostats, serrures), logiciels (applications, OS, firmwares), composants matériels et solutions SaaS liées à un produit. Les services cloud purs, les dispositifs médicaux et les véhicules déjà couverts par des règlements spécifiques sont exclus.

Le Cyber Résilience Act concerné-t-il les logiciels open source ?

Les logiciels open source développés dans un cadre non commercial ne sont pas directement soumis au CRA. En revanche, des qu’un logiciel open source est intègre dans un produit commercial, le fabricant de ce produit assumé l’intégralité des obligations du CRA. Les “intendants de logiciels libres” bénéficient d’un régime d’obligations allégées.

Qu’est-ce qu’un SBOM et pourquoi est-il obligatoire ?

Le SBOM (Software Bill of Materials) est un inventaire exhaustif de tous les composants logiciels intégrés dans un produit, y compris les bibliotheques tierces et les dépendances open source. Le CRA l’impose pour permettre la traçabilité des vulnérabilités (comme l’affaire Log4Shell l’a illustré). Il n’est pas rendu public mais doit être disponible pour les autorités.

Quel est le lien entre le CRA et la directive NIS2 ?

Les deux textes sont complémentaires : le CRA s’applique aux produits (sécurité by design, gestion des vulnérabilités), tandis que NIS2 s’applique aux organisations (sécurité opérationnelle). Une entité soumise à NIS2 qui fabrique des produits connectés devra respecter les deux textes. Les délais de notification (24h/72h) sont identiques.

Quelles sont les sanctions du CRA ?

Les sanctions maximales atteignent 15 millions d’euros ou 2,5% du CA mondial pour le non-respect des exigences essentielles de cybersécurité, 10 millions ou 2% pour les autres obligations, et 5 millions ou 1% pour la fourniture d’informations inexactes. Les autorités peuvent également ordonner le retrait ou le rappel de produits non conformes.