Cyber Resilience Act (CRA) : ce qui change pour les produits numériques

Le Cyber Resilience Act (CRA), ou règlement européen sur la cyberrésilience, impose des exigences de cybersécurité obligatoires à presque tous les produits matériels et logiciels connectés vendus dans l'Union européenne. Les fabricants doivent concevoir des produits sûrs, corriger leurs vulnérabilités pendant toute la durée de support et les signaler aux autorités. Depuis le 11 septembre 2026, ce signalement est obligatoire ; le 11 décembre 2027, le marquage CE dépendra du respect de l'ensemble du texte.

Le règlement (UE) 2024/2847 du 23 octobre 2024, connu sous son nom anglais de Cyber Resilience Act, est entré en vigueur le 10 décembre 2024. C'est la première législation européenne qui fixe un niveau de cybersécurité minimal pour les produits eux-mêmes, et non pour les organisations qui les utilisent. Son objet tient en une idée : un produit numérique ne doit plus être mis sur le marché avec des failles connues, ni abandonné par son fabricant dès la vente conclue.

Le texte part d'un constat que les RSSI connaissent bien : beaucoup de produits connectés sont livrés avec des mots de passe par défaut, des composants obsolètes et sans engagement de mise à jour, et l'utilisateur n'a aucun moyen de savoir combien de temps ils seront maintenus. Le CRA renverse la charge : c'est au fabricant de démontrer la sécurité de son produit, comme il démontre déjà sa sécurité électrique ou sa compatibilité électromagnétique.

Un règlement de type « nouveau cadre législatif »

Le CRA suit la logique des règlements européens sur la sécurité des produits : des exigences essentielles définies dans le texte (annexe I), des normes harmonisées qui permettent de présumer la conformité, une évaluation de la conformité proportionnée au risque, une déclaration UE de conformité et le marquage CE. Les autorités de surveillance du marché de chaque État membre contrôlent les produits et peuvent les faire retirer. Comme il s'agit d'un règlement, il s'applique directement en France, sans loi de transposition ; seules certaines mesures d'adaptation du droit national sont en cours d'élaboration selon l'ANSSI.

Le règlement vise les produits comportant des éléments numériques : tout produit matériel ou logiciel, et ses solutions de traitement de données à distance, dont l'usage prévu suppose une connexion directe ou indirecte à un appareil ou à un réseau. Le périmètre est donc très large : caméra connectée, routeur, montre, automate industriel, carte à puce, mais aussi logiciel vendu seul, application mobile, système d'exploitation ou jeu vidéo.

CRA et logiciel : ce qui entre et ce qui sort

Pour le logiciel, deux précisions comptent. D'abord, les services fournis entièrement en ligne (le SaaS) ne sont pas des produits au sens du CRA ; ils relèvent plutôt de NIS 2. Seule la partie « traitement de données à distance » sans laquelle un produit ne pourrait pas remplir une de ses fonctions est couverte, par exemple le service en ligne qui pilote une caméra. Ensuite, le logiciel libre développé ou distribué hors de toute activité commerciale n'est pas visé ; dès qu'un logiciel libre est monétisé, en revanche, son fabricant est soumis au CRA. Les lignes directrices de la Commission publiées le 27 juillet 2026 détaillent ces frontières à l'aide de nombreux exemples.

Les exclusions

Restent en dehors du CRA les produits déjà couverts par une réglementation sectorielle de cybersécurité équivalente, et quelques cas particuliers :

• les dispositifs médicaux et les dispositifs de diagnostic in vitro, qui relèvent des règlements européens 2017/745 et 2017/746 : un point important pour les établissements de santé, dont les équipements biomédicaux restent hors CRA, contrairement à leurs routeurs, postes et logiciels de gestion ;
• les véhicules à moteur, les équipements de l'aviation civile et les équipements marins ;
• les produits développés exclusivement pour la sécurité nationale ou la défense, ou pour traiter des informations classifiées ;
• les pièces détachées identiques fournies par le fabricant pour remplacer un composant d'un produit existant.

Produits par défaut, importants et critiques

Tous les produits doivent satisfaire aux mêmes exigences essentielles, mais la manière de le démontrer dépend de leur sensibilité. L'annexe III liste les produits importants (classes I et II) et l'annexe IV les produits critiques. Leur description technique précise a été fixée par le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025, entré en vigueur le 21 décembre 2025.

Le CRA répartit les obligations entre les acteurs de la chaîne, sur le modèle des autres règlements produits. L'essentiel pèse sur le fabricant.

• Le fabricant (article 13) conçoit le produit ou le fait concevoir et le commercialise sous son nom. Il réalise l'analyse des risques de cybersécurité, respecte les exigences essentielles, gère les vulnérabilités, rédige la documentation technique, mène l'évaluation de la conformité, appose le marquage CE et signale les vulnérabilités exploitées. Un fabricant établi hors de l'Union peut désigner un mandataire.
• L'importateur (article 19) ne met sur le marché que des produits conformes : il vérifie que l'évaluation a été faite, que la documentation existe, que le marquage CE est apposé et que le fabricant a prévu un point de contact pour les vulnérabilités.
• Le distributeur (article 20) vérifie le marquage CE et la présence des informations destinées à l'utilisateur, et cesse de vendre un produit qu'il sait non conforme.
• Le gestionnaire de logiciels libres (article 24), par exemple une fondation qui soutient durablement un projet utilisé commercialement, a un régime allégé : politique de cybersécurité documentée, coopération avec les autorités et certaines obligations de signalement. Il ne peut pas être sanctionné par une amende.

Attention à la requalification : un importateur ou un distributeur qui vend un produit sous son propre nom, ou toute personne qui apporte une modification substantielle à un produit déjà sur le marché, devient fabricant et en endosse toutes les obligations (articles 21 et 22). Une organisation qui modifie en profondeur un logiciel acheté puis le revend, ou le met à disposition d'autres entités dans le cadre d'une activité commerciale, doit se poser la question.

L'annexe I est le cœur technique du règlement. Elle comporte deux parties : les propriétés de sécurité du produit, et la gestion des vulnérabilités par le fabricant. Les deux s'apprécient à partir d'une analyse des risques de cybersécurité que le fabricant doit documenter et tenir à jour.

Partie I : un produit sûr dès sa conception

Le produit doit être conçu, développé et fabriqué de façon à garantir un niveau de cybersécurité adapté aux risques. Concrètement, il doit notamment :

• être mis sur le marché sans vulnérabilité exploitable connue ;
• être livré avec une configuration sécurisée par défaut, avec possibilité de revenir à l'état initial ;
• pouvoir recevoir des mises à jour de sécurité, automatiques par défaut lorsque c'est pertinent, avec possibilité pour l'utilisateur de les désactiver ;
• protéger contre les accès non autorisés (authentification, gestion des identités et des accès) et signaler les tentatives ;
• protéger la confidentialité des données (chiffrement au repos et en transit) et leur intégrité ;
• ne traiter que les données nécessaires à son usage prévu ;
• préserver ses fonctions essentielles, y compris face à une attaque par déni de service, et limiter son impact sur les autres appareils et réseaux ;
• réduire sa surface d'attaque, y compris les interfaces externes, et limiter les effets d'un incident ;
• journaliser les activités internes pertinentes pour la sécurité et permettre à l'utilisateur d'effacer ses données de façon sûre.

Partie II : gérer les vulnérabilités pendant toute la durée de support

Le fabricant doit aussi organiser un véritable processus de traitement des vulnérabilités :

• identifier et documenter les composants du produit, notamment en établissant une nomenclature logicielle (SBOM, pour Software Bill of Materials) couvrant au moins les dépendances de premier niveau ; nous y consacrons l'article SBOM : la nomenclature logicielle exigée par le CRA ;
• corriger les vulnérabilités sans délai, notamment par des mises à jour de sécurité séparées des évolutions fonctionnelles lorsque c'est possible ;
• tester et revoir régulièrement la sécurité du produit ;
• publier des informations sur les vulnérabilités corrigées, une fois le correctif disponible ;
• mettre en place une politique de divulgation coordonnée des vulnérabilités et une adresse de contact pour les signaler ;
• diffuser les correctifs de façon sécurisée, sans délai et gratuitement, accompagnés de conseils aux utilisateurs.

Pour un éditeur, cela revient à formaliser un cycle de développement sécurisé et un processus de réponse aux vulnérabilités (souvent appelé PSIRT, pour Product Security Incident Response Team) qui existaient de manière inégale. Les exigences s'appuient sur une analyse de risques : c'est elle qui justifie quelles mesures sont appliquées et comment.

Une durée de support d'au moins cinq ans

Le fabricant fixe une période de support qui reflète la durée pendant laquelle le produit est censé être utilisé. Elle ne peut pas être inférieure à cinq ans, sauf si la durée d'usage prévue est plus courte (article 13, paragraphe 8). Pendant cette période, il doit traiter les vulnérabilités, et chaque mise à jour de sécurité publiée doit rester disponible au moins dix ans ou jusqu'à la fin du support si celle-ci est plus tardive. La date de fin de support doit être indiquée clairement au moment de l'achat, au minimum le mois et l'année. Les lignes directrices de la Commission précisent qu'une simple correction mineure ne fait pas repartir un nouveau délai de cinq ans.

Documentation technique et information des utilisateurs

La documentation technique (annexe VII) décrit le produit, sa conception, l'analyse des risques de cybersécurité, les moyens retenus pour satisfaire aux exigences essentielles, la nomenclature logicielle et les rapports d'essais. Elle est conservée dix ans et remise aux autorités sur demande. L'utilisateur reçoit de son côté des informations listées à l'annexe II : point de contact pour signaler les vulnérabilités, usage prévu, risques connus, fin de la période de support, manière d'installer les mises à jour et de retirer le produit du service en sécurité.

CRA et marquage CE

Une fois l'évaluation de la conformité réalisée, le fabricant établit la déclaration UE de conformité et appose le marquage CE, visible et lisible, sur le produit ou, pour un logiciel, sur la déclaration ou le site qui l'accompagne. À compter du 11 décembre 2027, un produit comportant des éléments numériques sans marquage CE au titre du CRA ne pourra plus être mis sur le marché européen. Les normes harmonisées qui facilitent la démonstration sont en cours d'élaboration : le CEN, le CENELEC et l'ETSI ont accepté en 2025 la demande de normalisation de la Commission, qui porte sur une quarantaine de normes horizontales et verticales. Comme le rappelle l'ANSSI, leur usage reste volontaire et la mise en conformité ne doit pas attendre leur publication.

Le règlement s'applique par étapes, pour laisser aux fabricants le temps d'adapter leurs produits et aux États membres celui de désigner leurs autorités. Trois dates sont à retenir après l'entrée en vigueur, toutes fixées par l'article 71.

• 11 juin 2026 : les dispositions sur la notification des organismes d'évaluation de la conformité s'appliquent. En France, l'ANSSI, autorité notifiante, s'appuie sur l'accréditation du COFRAC ; elle indique que les premières notifications sont attendues vers la fin de 2026.
• 11 septembre 2026 : les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves. Cette obligation s'applique aussi aux produits mis sur le marché avant cette date.
• 11 décembre 2027 : toutes les autres obligations s'appliquent. Les produits mis sur le marché avant cette date n'y sont soumis que s'ils font ensuite l'objet d'une modification substantielle.

Ce qui est acquis et ce qui reste en cours au 23 septembre 2026

Le tableau ci-dessous fait le point sur les textes et outils d'application, avec la date de chaque information.

L'article 14 est la seule obligation de fond déjà en vigueur. Dès qu'il a connaissance d'une vulnérabilité activement exploitée dans l'un de ses produits, ou d'un incident grave ayant une incidence sur sa sécurité, le fabricant doit envoyer une alerte précoce dans les 24 heures, une notification dans les 72 heures, puis un rapport final. Le dépôt se fait sur la plateforme unique de signalement de l'ENISA ; pour un fabricant établi en France, le CSIRT coordinateur destinataire est le CERT-FR. Le fabricant doit aussi informer les utilisateurs concernés et leur indiquer les mesures à prendre.

Ce que recouvrent ces deux notions, les informations attendues à chaque étape, la comparaison avec NIS 2 et le RGPD et l'organisation interne à prévoir sont détaillés dans notre article CRA : signaler les vulnérabilités exploitées.

En France, la répartition des rôles a été confirmée par l'ANSSI, l'ANFR et la DGE lors d'une journée consacrée aux fabricants le 23 septembre 2026 :

• l'Agence nationale des fréquences (ANFR) est l'autorité de surveillance du marché : elle contrôle les produits, peut exiger une mise en conformité, restreindre ou interdire la mise sur le marché et ordonner un retrait ou un rappel ;
• l'ANSSI est l'autorité notifiante des organismes d'évaluation de la conformité et apporte son appui technique à la surveillance du marché ;
• le CERT-FR, rattaché à l'ANSSI, est le CSIRT coordinateur qui reçoit les signalements ;
• la DGE informe et sensibilise les entreprises, en particulier les PME.

L'article 64 fixe trois plafonds d'amendes administratives, le montant le plus élevé entre la somme fixe et le pourcentage du chiffre d'affaires annuel mondial étant retenu :

• 15 millions d'euros ou 2,5 % pour le non-respect des exigences essentielles de l'annexe I ou des obligations des articles 13 (fabricant) et 14 (signalement) ;
• 10 millions d'euros ou 2 % pour les autres obligations (importateurs, distributeurs, déclaration de conformité, marquage CE, documentation technique) ;
• 5 millions d'euros ou 1 % pour la fourniture d'informations inexactes, incomplètes ou trompeuses aux autorités.

Deux tempéraments : les micro et petites entreprises ne peuvent pas être sanctionnées pour avoir manqué le délai de 24 heures de l'alerte précoce, et les gestionnaires de logiciels libres ne peuvent pas recevoir d'amende. Pour situer ces montants parmi ceux des autres textes, voyez notre article sur les sanctions NIS 2.

Les trois textes se complètent plus qu'ils ne se recoupent. Le CRA s'adresse à ceux qui fabriquent et vendent des produits ; NIS 2 à ceux qui exploitent des services essentiels ou importants ; l'AI Act à ceux qui fournissent ou déploient des systèmes d'intelligence artificielle.

La plupart des organisations ne fabriquent pas de produits numériques, mais toutes en achètent. Pour elles, le CRA est d'abord une bonne nouvelle : il fixe un niveau minimal de sécurité et oblige les fabricants à communiquer des informations que les acheteurs réclamaient souvent sans succès. C'est aussi un outil pour la gestion des risques tiers : un fournisseur qui ne peut pas répondre à ces questions en 2026 aura du mal à mettre son produit sur le marché en décembre 2027.

Intégrer le CRA dans vos achats dès maintenant

• Dans les appels d'offres et les cahiers des charges : demandez la date de fin de support, la politique de divulgation coordonnée des vulnérabilités et le point de contact sécurité, l'engagement à fournir les mises à jour de sécurité gratuitement, et, pour les livraisons à partir de décembre 2027, la déclaration UE de conformité. Les acheteurs publics, nombreux parmi les clients des éditeurs de santé et des collectivités, peuvent inscrire ces critères dans leurs spécifications techniques.
• Dans vos questionnaires d'évaluation des fournisseurs : ajoutez des questions sur la préparation au CRA (catégorie du produit, procédure d'évaluation prévue, organisme notifié le cas échéant, organisation du signalement depuis septembre 2026, existence d'une nomenclature logicielle). Notre article sur le questionnaire de sécurité fournisseur explique comment proportionner ces questions à la criticité du tiers.
• Dans vos contrats : prévoyez la transmission sur demande de la nomenclature logicielle ou des informations de vulnérabilité pertinentes, le délai d'information en cas de vulnérabilité activement exploitée affectant le produit, et la durée de support minimale. Pour les prestations sensibles, ces clauses trouvent leur place dans le plan d'assurance sécurité.
• Dans votre inventaire : suivez la date de fin de support de chaque produit déployé. C'est une donnée simple qui permet d'anticiper les remplacements et de repérer les produits non maintenus, première porte d'entrée des attaques par la chaîne d'approvisionnement.

Ce que le CRA ne fait pas pour vous

Le marquage CE atteste qu'un produit respectait les exigences au moment de sa mise sur le marché ; il ne dit rien de la manière dont vous le configurez, l'intégrez et le maintenez. Les produits déjà déployés avant décembre 2027 ne seront pas mis en conformité rétroactivement. Et le CRA ne couvre pas les services SaaS, qui restent à évaluer par vos propres moyens. L'évaluation des fournisseurs et l'analyse de risques gardent donc toute leur place dans votre démarche de gouvernance, de gestion des risques et de conformité.

Phinasoft ne délivre pas de marquage CE et n'évalue pas vos produits à votre place. Sa plateforme vous aide en revanche à intégrer le Cyber Resilience Act dans vos processus de gestion des risques et des fournisseurs :

• avec le module de gestion des risques tiers, vous créez des questionnaires à partir de vos propres exigences, y compris celles que vous tirez du CRA, vous les soumettez à vos fournisseurs sur un portail dédié, vous leur faites vos retours (non-conformités acceptées ou non, demandes de compléments) et vous suivez les indicateurs ; chaque fournisseur garde l'historique de ses évaluations, et vous exportez les exigences à intégrer à vos plans d'assurance sécurité ;
• avec le module Risques & Conformité, vous conduisez vos analyses de risques selon EBIOS RM, ISO 27005 ou votre propre méthode, par exemple sur un projet qui intègre un produit connecté ;
• si vous êtes vous-même fabricant, les campagnes de conformité mesurent l'avancement de vos équipes, sites ou filiales face à une liste d'exigences que vous définissez, et pilotent les plans d'action qui en découlent.

Pour voir comment ces modules s'articulent sur votre cas, vous pouvez demander une démonstration.