Pendant des décennies, le marché européen a accueilli des produits numériques sans aucune exigence de sécurité minimale. Un objet connecté pouvait être vendu avec un mot de passe administrateur codé en dur, sans mécanisme de mise à jour, et abandonné par son fabricant le jour de sa commercialisation. Le résultat est connu : des parcs entiers de caméras, de routeurs et d’équipements industriels vulnérables, recrutés dans des réseaux de machines compromises et utilisés comme tremplins pour des attaques de grande ampleur.
Le Cyber Resilience Act, désigné par l’acronyme CRA et formellement le règlement (UE) 2024/2847, met fin à cette situation. Pour la première fois, l’Union européenne impose des obligations horizontales de cybersécurité à tous les produits comportant des éléments numériques mis sur son marché. Cet article décrit ce que le texte exige réellement, le calendrier d’application, et les actions concrètes que doivent engager les fabricants, les importateurs et les distributeurs.
Ce que couvre le CRA
Le périmètre du règlement est volontairement large. Il vise tout produit comportant des éléments numériques, expression qui recouvre à la fois le matériel et le logiciel dont l’usage prévu ou raisonnablement prévisible inclut une connexion de données, directe ou indirecte, à un appareil ou à un réseau.
Concrètement, entrent dans le champ d’application :
- les objets connectés grand public (caméras, assistants vocaux, électroménager intelligent, jouets connectés) ;
- les équipements professionnels et industriels disposant d’une interface réseau ;
- les logiciels vendus de manière autonome, qu’ils soient installés localement ou distribués sous forme de paquet ;
- les composants logiciels et matériels destinés à être intégrés dans d’autres produits.
Quelques catégories échappent au CRA parce qu’elles relèvent déjà d’une réglementation sectorielle spécifique : les dispositifs médicaux, les produits aéronautiques, les véhicules automobiles et certains équipements maritimes. Les services en nuage purs ne sont pas non plus visés par le CRA en tant que tels, car ils relèvent d’autres instruments. En revanche, un logiciel vendu comme produit, même s’il s’appuie sur des services distants, reste concerné.
Le texte distingue trois niveaux de criticité. La grande majorité des produits relève du régime par défaut, fondé sur l’auto-évaluation. Une catégorie de produits importants est répartie en deux classes selon leur sensibilité (gestionnaires de mots de passe, systèmes d’exploitation, routeurs, pare-feu, microcontrôleurs). Une catégorie de produits critiques fera l’objet d’exigences renforcées et, le cas échéant, d’une certification européenne obligatoire.
Cette classification n’est pas anecdotique : elle détermine la procédure d’évaluation de conformité applicable. Un produit du régime par défaut peut être déclaré conforme par le fabricant seul, sur la base de sa propre documentation. Un produit important de classe I peut suivre une auto-évaluation à condition d’appliquer des normes harmonisées ou un schéma de certification reconnu, faute de quoi l’intervention d’un tiers devient nécessaire. Un produit important de classe II et un produit critique relèvent de procédures plus lourdes, pouvant impliquer un organisme notifié. La Commission européenne précisera par actes délégués les listes exactes de produits relevant de chaque classe, ce qui rend la veille réglementaire indispensable pour les fabricants dont le catalogue se situe à la frontière entre deux régimes.
Les obligations du fabricant
Le fabricant porte l’essentiel des responsabilités. Le CRA lui impose une série d’obligations qui couvrent l’ensemble du cycle de vie du produit, de la conception au retrait du marché.
Sécurité dès la conception
Le produit doit être conçu, développé et fabriqué de manière à assurer un niveau de cybersécurité approprié au regard des risques. Cette exigence se traduit par des règles concrètes énumérées à l’annexe I du règlement : livraison sans vulnérabilité exploitable connue, configuration sécurisée par défaut, protection contre les accès non autorisés par des mécanismes d’authentification, protection de la confidentialité et de l’intégrité des données, minimisation de la surface d’attaque, et journalisation des activités pertinentes pour la sécurité.
Ces principes recoupent largement la logique d’une architecture de défense moderne. Une organisation qui a déjà engagé une démarche de durcissement, par exemple en suivant les principes d’une architecture Zero Trust, dispose d’une avance pratique sur la conformité au CRA.
Gestion des vulnérabilités et SBOM
Le fabricant doit mettre en place un processus documenté de traitement des vulnérabilités pendant toute la période de support. Ce processus comprend l’identification, la documentation, et la correction des failles, ainsi qu’une politique de divulgation coordonnée. Le règlement impose également la production d’une nomenclature logicielle, le SBOM (Software Bill of Materials), qui recense au minimum les composants de premier niveau du produit dans un format lisible par machine.
La mise en oeuvre de cette exigence rejoint directement les pratiques d’ingénierie sécurisée décrites dans notre guide DevSecOps et chaîne CI/CD : génération automatique du SBOM à chaque release, analyse de composition logicielle, et corrélation continue avec les bases de vulnérabilités. La structuration de ce travail s’appuie sur une gestion des vulnérabilités industrialisée, du référencement CVE jusqu’au déploiement du correctif.
Période de support
Le fabricant doit assurer la sécurité du produit pendant une période de support dont la durée reflète la durée d’utilisation attendue du produit. Le règlement fixe une durée minimale de référence de cinq ans, sauf si la durée d’utilisation prévue est plus courte. Pendant cette période, les correctifs de sécurité doivent être fournis sans délai et, lorsque cela est techniquement possible, séparément des mises à jour de fonctionnalités, afin que les utilisateurs puissent appliquer la sécurité sans changer le comportement du produit.
Cette obligation a une portée plus large qu’il n’y paraît. Elle interdit en pratique le modèle de l’obsolescence programmée par abandon du support : un fabricant ne peut plus cesser de corriger les failles d’un produit encore largement utilisé sous prétexte qu’il en commercialise une nouvelle version. Elle impose aussi de réfléchir, dès la conception, à la capacité du produit à recevoir des mises à jour pendant toute sa durée de vie, ce qui suppose des ressources matérielles suffisantes et un mécanisme de distribution des correctifs fiable et authentifié. La date de fin de support doit être communiquée clairement à l’acheteur, qui dispose ainsi d’une information jusqu’ici rarement disponible.
Documentation et marquage CE
Le fabricant doit constituer une documentation technique complète, conduire une évaluation de conformité, rédiger une déclaration UE de conformité, et apposer le marquage CE sur le produit. Pour les produits du régime par défaut, l’évaluation repose sur une auto-évaluation. Pour les produits importants et critiques, l’intervention d’un organisme notifié ou le recours à des normes harmonisées et à une certification peut devenir nécessaire.
Le régime de notification
Le CRA introduit un mécanisme de notification qui mérite une attention particulière, car il rapproche le secteur des produits du régime déjà connu des opérateurs de services essentiels.
Le fabricant doit notifier à l’ENISA, via une plateforme unique de notification, deux types d’événements :
- toute vulnérabilité activement exploitée présente dans le produit ;
- tout incident grave ayant un impact sur la sécurité du produit.
Le calendrier de notification est exigeant. Pour une vulnérabilité activement exploitée, un avertissement précoce doit être transmis dans les vingt-quatre heures suivant la prise de connaissance, suivi d’une notification complète dans les soixante-douze heures, puis d’un rapport final une fois la vulnérabilité corrigée. La plateforme de l’ENISA relaie l’information aux autorités nationales compétentes, dont l’ANSSI pour la France, selon un mécanisme de partage maîtrisé qui prévoit des garde-fous lorsque la diffusion immédiate pourrait aggraver le risque.
Ce délai de vingt-quatre heures aligne le secteur des produits sur la cadence imposée aux opérateurs par d’autres textes. Les entreprises déjà familières des obligations de notification de la directive NIS2 retrouveront une logique comparable, transposée du périmètre organisationnel vers le périmètre produit.
Le calendrier d’application
Le CRA est entré en vigueur le 10 décembre 2024, mais ses obligations s’appliquent de manière échelonnée. Trois jalons structurent le calendrier.
| Date | Obligations applicables |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement |
| 11 juin 2026 | Dispositions relatives à la notification et à la désignation des organismes d’évaluation de la conformité |
| 11 septembre 2026 | Obligations de notification des vulnérabilités exploitées et des incidents graves |
| 11 décembre 2027 | Application complète : exigences essentielles, évaluation de conformité, marquage CE |
Cet échelonnement laisse aux fabricants un délai de préparation, mais ce délai est trompeur. La mise en conformité d’une gamme de produits suppose des changements profonds dans les processus de développement, la documentation, et le support après-vente. Une organisation qui attendrait l’échéance de décembre 2027 pour engager le chantier découvrirait que dix-huit mois ne suffisent pas à reconstruire une chaîne de développement sécurisée et à requalifier l’ensemble d’un catalogue.
Fabricant, importateur, distributeur : qui fait quoi
Le CRA répartit les responsabilités le long de la chaîne d’approvisionnement, sur le modèle déjà connu du droit européen des produits.
Le fabricant assume la responsabilité principale : conception sécurisée, évaluation de conformité, documentation, marquage CE, gestion des vulnérabilités et notification. Lorsqu’un produit est commercialisé sous le nom d’une entreprise qui ne l’a pas conçu, cette entreprise est considérée comme fabricant et en assume toutes les obligations.
L’importateur ne peut mettre sur le marché que des produits conformes. Il doit vérifier que le fabricant a accompli l’évaluation de conformité, apposé le marquage CE et fourni la documentation. S’il a une raison de croire qu’un produit n’est pas conforme, il ne peut le mettre sur le marché.
Le distributeur doit agir avec la diligence requise : vérifier la présence du marquage CE et des instructions, et s’abstenir de distribuer un produit dont il sait ou devrait savoir qu’il n’est pas conforme.
Une modification substantielle d’un produit déjà sur le marché peut faire basculer celui qui l’opère dans le rôle de fabricant, avec l’obligation de procéder à une nouvelle évaluation de conformité. Cette règle a des conséquences directes pour les intégrateurs et pour les entreprises qui personnalisent des produits tiers.
Le CRA dans le paysage réglementaire
Le CRA ne s’ajoute pas isolément à l’arsenal européen. Il s’inscrit dans un ensemble cohérent dont les pièces se répondent.
NIS2 régit les organisations et leurs mesures de gestion du risque. DORA, le règlement sur la résilience opérationnelle numérique, encadre spécifiquement le secteur financier, y compris la sécurité des prestataires tiers de services informatiques. Le CRA, lui, sécurise les produits eux-mêmes. Une entreprise du secteur financier peut donc se trouver à l’intersection : soumise à DORA en tant qu’entité financière, à NIS2 en tant qu’opérateur, et au CRA pour les logiciels qu’elle développerait et mettrait sur le marché.
En France, la transposition et l’articulation de ces textes passent par la loi de résilience, qui décline NIS2, DORA et la directive sur la résilience des entités critiques dans le droit national. Le CRA, étant un règlement et non une directive, s’applique directement sans transposition, ce qui garantit une uniformité du périmètre produit dans toute l’Union.
Cette cohérence d’ensemble explique pourquoi les autorités, dont l’ANSSI, insistent sur une approche intégrée de la conformité. Traiter le CRA, NIS2 et DORA comme trois chantiers séparés conduit à des doublons et à des angles morts. Les mesures techniques de fond, gestion des actifs, durcissement, traitement des vulnérabilités, notification, servent les trois textes à la fois.
Préparer la conformité : feuille de route
La préparation au CRA se conduit comme un programme, pas comme une mise à jour ponctuelle. Quatre chantiers se dégagent.
Cartographier le catalogue. La première étape consiste à recenser tous les produits comportant des éléments numériques que l’organisation met sur le marché de l’Union, à les classer dans les catégories du CRA (par défaut, important, critique), et à identifier ceux qui relèvent d’une réglementation sectorielle excluante. Cette cartographie révèle souvent que le périmètre concerné est plus large que prévu, notamment lorsque des logiciels internes sont vendus à des tiers ou que des composants sont distribués.
Industrialiser le SBOM et la gestion des vulnérabilités. Le coeur technique de la conformité réside dans la capacité à savoir ce que contient chaque produit et à réagir vite quand une faille apparaît. Cela suppose une génération automatique du SBOM dans la chaîne de release, une veille continue sur les vulnérabilités des composants, et un processus documenté de correction. Ce socle profite immédiatement à la sécurité opérationnelle, indépendamment de l’échéance réglementaire.
Mettre en place la divulgation coordonnée et la notification. Le fabricant doit disposer d’un canal de réception des signalements de vulnérabilité, d’une politique de divulgation coordonnée, et d’une procédure interne capable de tenir le délai de vingt-quatre heures vers l’ENISA en cas d’exploitation active. Cette capacité opérationnelle se teste par des exercices, comme on teste un plan de réponse à incident.
Constituer la documentation et préparer l’évaluation. La documentation technique, la déclaration de conformité et la justification du marquage CE doivent être prêtes pour décembre 2027. Pour les produits importants et critiques, l’identification des normes harmonisées applicables et le dialogue éventuel avec un organisme notifié doivent être engagés bien en amont.
Les fabricants qui transfèrent une partie du risque résiduel vers une assurance cyber constateront que les assureurs intègrent désormais la maturité réglementaire dans leur évaluation. Démontrer une conformité CRA en cours de construction devient un argument lors de la souscription comme du règlement d’un sinistre.
Ce que le CRA change en profondeur
Au delà des obligations techniques, le CRA opère un déplacement de responsabilité. Jusqu’à présent, le coût de l’insécurité d’un produit reposait sur l’utilisateur final, contraint de protéger un objet mal conçu ou de le remplacer prématurément. Le règlement inverse cette logique : il fait porter au fabricant le coût de la sécurité, sur toute la durée de support, comme une composante normale du produit.
Ce déplacement aura des effets économiques. Certains produits à très faible marge et à durée de support courte deviendront non rentables. Les fabricants qui avaient construit leur modèle sur l’abandon rapide des produits devront le revoir. À l’inverse, les éditeurs et constructeurs qui investissaient déjà dans la sécurité disposeront d’un avantage concurrentiel rendu visible par le marquage CE.
Pour les directions des systèmes d’information qui achètent ces produits, le CRA apporte une garantie nouvelle : un produit portant le marquage CE au titre du CRA est réputé respecter un socle de sécurité et bénéficier d’un support de sécurité documenté. Cette information devient un critère d’achat exploitable, au même titre que les exigences contractuelles déjà imposées aux fournisseurs dans le cadre d’une démarche de conformité plus large.
Conclusion
Le Cyber Resilience Act referme une parenthèse de plusieurs décennies pendant laquelle un produit numérique pouvait être vendu en Europe sans aucune exigence de sécurité. À partir de décembre 2027, le marquage CE conditionnera l’accès au marché des produits comportant des éléments numériques, et la notification des vulnérabilités exploitées à l’ENISA s’imposera dès septembre 2026.
Pour les fabricants, l’enjeu n’est pas de cocher une case à la dernière minute, mais de reconstruire une chaîne de développement et de support qui intègre la sécurité comme une exigence permanente. Pour les acheteurs, le CRA fournit enfin un repère objectif. Et pour l’écosystème dans son ensemble, il pose le principe que la sécurité d’un produit numérique relève de celui qui le conçoit, et non de celui qui le subit.
Références
[1] Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 (Cyber Resilience Act), texte consolidé sur EUR-Lex. [2] Commission européenne, page de politique consacrée au Cyber Resilience Act. [3] ENISA, publications relatives à la coordination de la divulgation des vulnérabilités et à la plateforme de notification. [4] ANSSI, ressources sur l’articulation des cadres réglementaires de cybersécurité. [5] NIST, publications de référence sur le développement logiciel sécurisé et la nomenclature logicielle.
Sources primaires : EUR-Lex, Commission européenne, ENISA, ANSSI, NIST.