Le Cyber Resilience Act (CRA) – reglement (UE) 2024/2847 – est le premier texte europeen qui impose des exigences horizontales de cybersecurite a l’ensemble des produits comportant des elements numeriques. Adopte le 23 octobre 2024 et publie au Journal officiel de l’Union europeenne le 20 novembre 2024, ce reglement transforme en profondeur les obligations des fabricants, importateurs et distributeurs de produits connectes et de logiciels.

Pour les organisations qui traitent deja les sujets de securite dans le cadre du RGPD ou de la directive NIS2, le CRA constitue une couche supplementaire qu’il est indispensable de maitriser. Voyons cela en detail.

I. Pourquoi le Cyber Resilience Act ?

Le constat est sans appel : la multiplication des objets connectes et des logiciels a cree une surface d’attaque considerable en Europe. Selon les estimations de la Commission europeenne, le cout annuel de la cybercriminalite etait estime a 5 500 milliards d’euros au niveau mondial en 2021. Or, jusqu’au CRA, il n’existait aucune reglementation horizontale imposant un niveau minimum de securite pour les produits numeriques mis sur le marche europeen.

Trois problemes majeurs justifient ce texte :

1. Un faible niveau de cybersecurite des produits – de nombreux appareils IoT, logiciels et composants sont commercialises avec des vulnerabilites connues, des mots de passe par defaut, ou sans mecanisme de mise a jour.
2. L’asymetrie d’information – les acheteurs professionnels et les consommateurs n’ont aucun moyen fiable d’evaluer le niveau de securite d’un produit avant achat.
3. L’absence de suivi post-commercialisation – une fois le produit vendu, les fabricants n’avaient aucune obligation legale de corriger les vulnerabilites decouvertes.

Le CRA entend resoudre ces trois problemes de front. Il impose la securite des la conception, la transparence vis-a-vis du marche, et un suivi des vulnerabilites pendant toute la duree de vie du produit.

II. Champ d’application : quels produits sont concernes ?

A. La notion de “produit comportant des elements numeriques”

Le CRA s’applique a tout produit comportant des elements numeriques (“product with digital elements”), defini comme tout produit logiciel ou materiel et ses solutions de traitement de donnees a distance, y compris les composants logiciels et materiels mis sur le marche separement.

Concretement, cela couvre :

• les objets connectes (IoT) : cameras, thermostats, serrures connectees, appareils medicaux connectes ;
• les logiciels (applications, systemes d’exploitation, firmwares) ;
• les composants materiels (processeurs, cartes reseau, modules de communication) ;
• les solutions SaaS lorsqu’elles constituent le traitement de donnees a distance d’un produit.

B. Les exclusions

Le CRA ne s’applique pas a :

• les services cloud et SaaS purs (couverts par NIS2) ;
• les dispositifs medicaux deja couverts par les reglements (UE) 2017/745 et 2017/746 ;
• les vehicules a moteur couverts par le reglement (UE) 2019/2144 ;
• les produits developpes exclusivement a des fins de securite nationale ou de defense ;
• les logiciels libres et open source developpes dans un cadre non commercial (mais attention : des qu’un logiciel open source est integre dans un produit commercial, le fabricant de ce produit assume les obligations du CRA).

Ce dernier point merite une attention particuliere. L’ecosysteme open source a ete largement mobilise pendant les debats legislatifs. La version finale du texte prevoit un statut specifique pour les “intendants de logiciels libres” (open source software stewards), qui sont soumis a des obligations allegees.

C. La classification par niveaux de criticite

Le CRA etablit une classification des produits en trois categories, selon leur niveau de risque :

Categorie	Exemples	Evaluation de conformite
Produits par defaut	Disques durs, jeux video, logiciels de bureautique	Auto-evaluation par le fabricant
Produits importants (classe I)	Gestionnaires de mots de passe, VPN, routeurs domestiques, systemes domotiques, jouets connectes	Normes harmonisees ou evaluation tierce
Produits importants (classe II)	Pare-feu industriels, systemes de detection d’intrusion, microprocesseurs securises, systemes d’exploitation	Evaluation tierce obligatoire
Produits critiques	Cartes a puce, dispositifs de creation de signature electronique, passerelles de compteurs intelligents	Certification europeenne de cybersecurite

Cette classification determine la procedure d’evaluation de conformite applicable, allant de la simple auto-evaluation a la certification par un organisme tiers.

III. Qui est concerne ? Les acteurs de la chaine de valeur

Le CRA distribue les obligations entre trois categories d’operateurs economiques :

A. Les fabricants

Le fabricant est l’acteur qui supporte l’essentiel des obligations. Il s’agit de toute personne physique ou morale qui developpe ou fait developper un produit avec des elements numeriques et le commercialise sous son nom ou sa marque.

Ses obligations principales :

• Concevoir le produit selon le principe de securite par defaut et des la conception (security by design and by default) ;
• Realiser une evaluation des risques de cybersecurite avant la mise sur le marche ;
• Produire et maintenir un SBOM (Software Bill of Materials – nomenclature logicielle) ;
• Corriger les vulnerabilites sans delai et fournir des mises a jour de securite gratuites pendant toute la periode de support ;
• Signaler les vulnerabilites activement exploitees et les incidents graves a l’ENISA dans les 24 heures ;
• Apposer le marquage CE attestant de la conformite ;
• Rediger la documentation technique et la declaration de conformite UE.

B. Les importateurs

L’importateur met sur le marche de l’Union un produit provenant d’un fabricant etabli hors de l’UE. Avant la mise sur le marche, il doit verifier que :

• le fabricant a effectue l’evaluation de conformite appropriee ;
• la documentation technique est disponible ;
• le produit porte le marquage CE ;
• le fabricant a mis en place les procedures de gestion des vulnerabilites.

Si l’importateur a des raisons de croire que le produit n’est pas conforme, il ne doit pas le mettre sur le marche et doit en informer le fabricant et les autorites de surveillance.

C. Les distributeurs

Le distributeur met a disposition le produit sur le marche sans en modifier les caracteristiques. Ses obligations sont allegees mais reelles : il doit verifier que le produit porte le marquage CE et que l’importateur ou le fabricant a satisfait a ses obligations d’identification. En cas de risque identifie, il doit en informer le fabricant et les autorites competentes.

IV. Les obligations cles en detail

A. Securite par conception et par defaut (Security by Design)

Le CRA impose que la cybersecurite soit integree des la phase de conception du produit. L’annexe I du reglement enumere les exigences essentielles, parmi lesquelles :

• le produit doit etre mis sur le marche sans vulnerabilite exploitable connue ;
• la configuration par defaut doit etre securisee (pas de mots de passe generiques, acces restreints par defaut) ;
• les donnees stockees, transmises ou traitees doivent etre protegees (chiffrement, controle d’integrite) ;
• le produit doit minimiser sa surface d’attaque ;
• les mecanismes d’authentification doivent etre robustes ;
• la disponibilite des fonctions essentielles doit etre assuree, y compris en cas d’attaque (resilience) ;
• le produit doit generer des journaux d’audit pertinents.

Ces exigences ne sont pas nouvelles pour les praticiens de la securite. Elles rejoignent largement les obligations de securite des donnees au titre de l’article 32 du RGPD. La difference fondamentale est qu’elles s’appliquent desormais au produit lui-meme, et non au traitement de donnees.

B. Gestion des vulnerabilites

Le fabricant doit mettre en place un processus structure de gestion des vulnerabilites tout au long du cycle de vie du produit. Cela inclut :

• l’identification et la documentation de toutes les vulnerabilites et composants tiers contenus dans le produit ;
• la fourniture de mises a jour de securite gratuites et en temps utile ;
• la publication d’informations sur les vulnerabilites corrigees (advisories) ;
• la mise a disposition d’un mecanisme de signalement des vulnerabilites accessible au public (politique de divulgation coordonnee).

La duree de cette obligation couvre la duree de vie attendue du produit ou cinq ans apres la mise sur le marche, la periode la plus courte etant retenue. Ce point est crucial : un fabricant d’objets connectes doit anticiper la duree 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 integres dans un produit, incluant les bibliotheques tierces et les dependances open source.

Le fabricant doit :

• generer et maintenir un SBOM a jour ;
• le mettre a disposition des autorites de surveillance sur demande ;
• identifier les composants presentes dans le produit au minimum au niveau du package.

Le SBOM n’a pas vocation a etre rendu public (sa divulgation pourrait d’ailleurs faciliter certaines attaques). Mais il doit etre disponible pour les autorites et constitue un outil essentiel de tracabilite en cas de fuite de donnees ou de decouverte de vulnerabilite dans un composant tiers (l’affaire Log4Shell en est l’illustration parfaite).

D. Notification des incidents et des vulnerabilites

Le CRA impose un mecanisme de notification a deux etages :

1. Vulnerabilites activement exploitees : le fabricant doit notifier l’ENISA (Agence de l’Union europeenne pour la cybersecurite) dans les 24 heures suivant la decouverte, puis fournir un rapport complet dans les 72 heures, et un rapport final dans les 14 jours.
2. Incidents de securite graves ayant un impact sur la securite du produit : meme calendrier de notification.

Ces delais sont calques sur ceux de la directive NIS2, ce qui est logique. Les organisations deja soumises a NIS2 retrouveront un cadre familier. L’ENISA jouera le role de plateforme centralisee de signalement, puis redistribuera l’information aux CSIRT nationaux competents.

E. Le marquage CE

Le marquage CE, deja bien connu en matiere de securite des produits, est etendu a la cybersecurite. Un produit conforme au CRA devra porter le marquage CE, qui attestera du respect des exigences essentielles de cybersecurite.

Ce marquage implique :

• la redaction d’une declaration de conformite UE ;
• la constitution d’un dossier technique ;
• le passage par la procedure d’evaluation de conformite adaptee a la categorie du produit.

En pratique, le marquage CE deviendra un prerequis pour la mise sur le marche europeen. Les produits non conformes seront simplement interdits de commercialisation.

V. Articulation avec les autres reglementations

A. CRA et NIS2

Le CRA et la directive NIS2 sont complementaires :

• NIS2 porte sur la securite des reseaux et systemes d’information des entites essentielles et importantes (operateurs de services) ;
• Le CRA porte sur la securite des produits mis sur le marche.

En pratique, une organisation soumise a NIS2 qui fabrique egalement des produits connectes devra se conformer aux deux textes. Le CRA cree aussi un pont direct : les fabricants de produits critiques dont les vulnerabilites pourraient affecter des entites NIS2 devront prendre en compte cet impact dans leur evaluation des risques.

B. CRA et RGPD

Le CRA et le RGPD se rejoignent sur un point fondamental : la securite. L’article 32 du RGPD impose deja des mesures techniques et organisationnelles appropriees pour proteger les donnees personnelles. Le CRA ajoute une couche supplementaire en imposant la securite au niveau du produit lui-meme.

En pratique, un produit conforme au CRA contribuera mecaniquement au respect des obligations de securite du RGPD. Inversement, un produit non conforme au CRA utilise pour traiter des donnees personnelles constituera un facteur de risque aggravant en cas de controle ou de fuite de donnees.

Pour les DPO et les RSSI, le CRA impose de prendre en compte la conformite des produits acquis dans le cadre de leur audit de securite informatique.

C. CRA et reglement sur l’IA

Les systemes d’intelligence artificielle a haut risque couverts par le reglement IA (AI Act) sont egalement concernes par le CRA lorsqu’ils constituent des produits avec des elements numeriques. La conformite au CRA est alors une condition prealable a la conformite au reglement IA.

VI. Calendrier d’application

Le CRA est entre en vigueur le 10 decembre 2024 (20 jours apres sa publication). Mais son application est echelonnee :

Echeance	Evenement
10 decembre 2024	Entree en vigueur du reglement
11 juin 2026	Application des obligations relatives aux organismes d’evaluation de la conformite (organismes notifies)
11 septembre 2026	Application des obligations de notification (vulnerabilites activement exploitees et incidents)
11 decembre 2027	Application de l’ensemble des obligations du CRA

Les fabricants disposent donc de trois ans a compter de l’entree en vigueur pour se mettre en conformite, mais certaines obligations – notamment la notification des vulnerabilites – s’appliqueront des septembre 2026.

Ce calendrier est serre. Pour les organisations qui n’ont pas encore entame leur demarche, le temps presse.

VII. Sanctions

Le regime de sanctions du CRA est significatif et suit la logique desormais etablie par le RGPD et NIS2 :

Type d’infraction	Sanction maximale
Non-respect des exigences essentielles de cybersecurite (annexe I)	15 millions d’euros ou 2,5 % du CA annuel mondial
Non-respect des autres obligations du reglement	10 millions d’euros ou 2 % du CA annuel mondial
Fourniture d’informations inexactes ou incompletes aux autorites	5 millions d’euros ou 1 % du CA annuel mondial

Dans tous les cas, c’est le montant le plus eleve qui s’applique. Les autorites nationales de surveillance du marche seront competentes pour prononcer ces sanctions, et pourront egalement ordonner le retrait ou le rappel de produits non conformes.

Il faut noter que ces sanctions s’ajoutent aux sanctions deja applicables au titre du RGPD ou de NIS2. Un meme manquement de securite pourrait donc theoriquement donner lieu a des sanctions cumulatives au titre de plusieurs textes.

VIII. Impacts pratiques pour les entreprises

A. Pour les fabricants et editeurs de logiciels

L’impact est majeur. Il faut concretement :

• Revoir les processus de developpement pour integrer la securite par conception (DevSecOps, threat modeling, revue de code securite) ;
• Mettre en place la generation et la maintenance d’un SBOM pour chaque produit ;
• Formaliser un processus de gestion des vulnerabilites conforme aux exigences du CRA ;
• Preparer la documentation technique et la declaration de conformite ;
• Determiner la categorie de chaque produit et identifier la procedure d’evaluation de conformite applicable ;
• Budgeter les couts 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 numeriques doivent integrer les exigences du CRA dans leurs processus d’approvisionnement :

• Exiger la documentation de conformite CRA dans les appels d’offres ;
• Verifier la presence du marquage CE incluant la composante cybersecurite ;
• Integrer la duree de support securite comme critere de selection ;
• Demander les SBOM pour les produits critiques pour l’organisation.

C. Pour les DPO et les RSSI

Le CRA cree un nouveau levier pour ameliorer la securite globale :

• Integrer la conformite CRA dans les audits de securite et les analyses d’impact ;
• Documenter les produits utilises et leur statut de conformite CRA ;
• Anticiper les obligations de notification qui se cumulent avec celles du RGPD (72 heures pour les violations de donnees) et de NIS2.

Pour faciliter la gestion de ces obligations croisees, des outils de conformite automatisee comme Legiscope permettent de centraliser le suivi de la conformite RGPD, NIS2 et CRA au sein d’une meme plateforme.

IX. Que faire maintenant ?

Le CRA n’est pas un texte futur – il est deja en vigueur. Voici les etapes prioritaires :

1. Diagnostiquer votre exposition. Identifiez si votre organisation est fabricant, importateur ou distributeur de produits avec des elements numeriques. Si vous etes uniquement utilisateur, identifiez les produits critiques de votre parc.

2. Classifier vos produits. Pour les fabricants : determinez dans quelle categorie tombe chaque produit (par defaut, classe I, classe II, critique). Cela conditionnera la procedure d’evaluation de conformite et les investissements necessaires.

3. Mettre en place la gestion des vulnerabilites. C’est la premiere obligation qui s’appliquera (septembre 2026). Mettez en place un processus de detection, correction et notification des vulnerabilites conforme aux exigences du CRA.

4. Generer vos SBOM. Si ce n’est pas deja fait, integrez la generation automatique de SBOM dans votre pipeline de developpement. C’est un prerequis technique incontournable.

5. Adapter vos processus de developpement. Integrez les exigences de securite par conception dans vos pratiques de developpement. Pour les organisations matures, c’est souvent une evolution; pour les autres, c’est une transformation profonde.

6. Preparer la documentation de conformite. Dossier technique, declaration de conformite, procedures de gestion des vulnerabilites – 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 schemas de certification applicables. Les delais de certification peuvent etre longs.

8. Centraliser votre conformite. Le CRA s’ajoute au RGPD, a NIS2, et potentiellement au reglement IA. Un outil de suivi de conformite centralise tel que Legiscope devient rapidement indispensable pour eviter les doublons et les angles morts.

Le Cyber Resilience Act marque un tournant. Pour la premiere fois, la cybersecurite des produits numeriques n’est plus optionnelle – elle est une obligation legale, assortie de sanctions dissuasives. Les organisations qui anticipent seront celles qui transformeront cette contrainte reglementaire en avantage concurrentiel.

FAQ

Quels produits sont concernes par le Cyber Resilience Act ?

Le CRA s’applique a tout produit comportant des elements numeriques : objets connectes (cameras, thermostats, serrures), logiciels (applications, OS, firmwares), composants materiels et solutions SaaS liees a un produit. Les services cloud purs, les dispositifs medicaux et les vehicules deja couverts par des reglements specifiques sont exclus.

Le Cyber Resilience Act concerne-t-il les logiciels open source ?

Les logiciels open source developpes dans un cadre non commercial ne sont pas directement soumis au CRA. En revanche, des qu’un logiciel open source est integre dans un produit commercial, le fabricant de ce produit assume l’integralite des obligations du CRA. Les “intendants de logiciels libres” beneficient d’un regime d’obligations allegees.

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 integres dans un produit, y compris les bibliotheques tierces et les dependances open source. Le CRA l’impose pour permettre la tracabilite des vulnerabilites (comme l’affaire Log4Shell l’a illustre). Il n’est pas rendu public mais doit etre disponible pour les autorites.

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

Les deux textes sont complementaires : le CRA s’applique aux produits (securite by design, gestion des vulnerabilites), tandis que NIS2 s’applique aux organisations (securite operationnelle). Une entite soumise a NIS2 qui fabrique des produits connectes devra respecter les deux textes. Les delais 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 cybersecurite, 10 millions ou 2% pour les autres obligations, et 5 millions ou 1% pour la fourniture d’informations inexactes. Les autorites peuvent egalement ordonner le retrait ou le rappel de produits non conformes.