TL;DR
Le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), est entré en vigueur le 10 décembre 2024. Il introduit pour la première fois au monde un cadre horizontal obligatoire de cybersécurité pour tous les produits comportant des éléments numériques mis sur le marché européen.
La première obligation contraignante s’applique dès le 11 septembre 2026, y compris pour les produits déjà sur le marché. Les sanctions peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. L’ensemble des obligations entre en vigueur le 11 décembre 2027. Le délai semble long. Il ne l’est pas.
Depuis des décennies, les produits numériques ont pu être commercialisés dans l’Union européenne sans que leur niveau de sécurité soit soumis à une exigence réglementaire minimale définie par le droit européen. Un équipement connecté, un logiciel, un système embarqué pouvait être mis sur le marché avec des vulnérabilités connues non corrigées, sans que cela ne constitue en soi une infraction réglementaire.
Le Cyber Resilience Act change cette règle fondamentale. Il ne crée pas un label ou une certification facultative. Il établit des obligations légales de sécurité, dont la violation expose à des amendes substantielles et au retrait du marché. Et il s’applique, avec quelques nuances, à quiconque fabrique, importe ou distribue un produit comportant des éléments numériques destiné au marché européen, qu’il soit établi dans l’Union ou en dehors.
Présentation du règlement
Le règlement (UE) 2024/2847 a été formellement adopté par le Parlement européen le 10 octobre 2024 et publié au Journal officiel de l’Union européenne le 20 novembre 2024. Il est entré en vigueur le 10 décembre 2024. C’est un règlement, pas une directive : il s’applique directement et uniformément dans tous les États membres, sans transposition nationale.
Le CRA complète l’architecture réglementaire européenne existante. Il coexiste avec la directive NIS 2, avec DORA, et avec les réglementations sectorielles existantes (dispositifs médicaux, aviation civile, véhicules). Une clause d’exclusion évite le double régime : lorsqu’un produit est déjà couvert par une réglementation sectorielle européenne imposant des exigences de cybersécurité équivalentes, les exigences CRA correspondantes ne s’appliquent pas. Pour les organisations soumises à NIS 2 sur les systèmes industriels, notre article sur la directive NIS 2 et la sécurité industrielle détaille cette articulation.
La page officielle de la Commission européenne sur le Cyber Resilience Act et les publications de l’ ENISA constituent les sources de référence les plus à jour pour suivre les précisions réglementaires au fil de leur publication.
Qui est concerné : une portée bien plus large qu’on ne le croit
La définition centrale du CRA est celle de "produit comportant des éléments numériques". Elle englobe tout produit matériel ou logiciel dont une fonction inclut une connexion directe ou indirecte à un autre appareil ou à un réseau. Concrètement : smartphones, ordinateurs, tablettes, équipements réseau, objets connectés grand public, systèmes d’exploitation, logiciels commerciaux, navigateurs, suites bureautiques, solutions de cybersécurité, équipements industriels connectés, et composants logiciels vendus séparément.
Trois rôles sont distingués : le fabricant, qui porte l’essentiel des obligations ; l’importateur, qui met un produit d’un fabricant hors UE sur le marché européen ; et le distributeur, qui met à disposition un produit sans le modifier substantiellement.
Le cas des PME et micro-entreprises. Le règlement prévoit des dispositions allégées pour les micro-entreprises (moins de 10 salariés, moins de 2 millions d’euros de chiffre d’affaires), notamment en matière de documentation technique. Mais les obligations de sécurité essentielles et les obligations de signalement des vulnérabilités s’appliquent à toutes les tailles d’entreprises.
Le cas des éditeurs SaaS. Les logiciels accessibles uniquement à distance, sans composant installé chez le client, se situent dans une zone d’interprétation en cours de précision. La distinction pertinente que la Commission trace est celle entre produit mis "sur le marché" (avec transfert de propriété ou licence) et service pur. Les éditeurs qui distribuent des composants installés sont clairement dans le périmètre. Par ailleurs, les applications SaaS utilisées sans validation IT, relevant du Shadow IT, créent un risque de conformité supplémentaire : un éditeur peut être exposé à des obligations CRA sans que son client en soit informé.
Le cas de l’open source. Les logiciels open source développés et distribués sans activité commerciale sont explicitement exclus. En revanche, un produit commercial qui intègre des composants open source est pleinement dans le périmètre. La responsabilité du niveau de sécurité des composants intégrés appartient au fabricant du produit final.
Les exigences concrètes
Les exigences essentielles de cybersécurité (Annexe I)
Le coeur du règlement est une liste d’exigences essentielles organisées en deux volets.
Volet 1 : propriétés de sécurité du produit. Le produit doit être conçu de manière à ce que sa surface d’attaque soit limitée (sécurité minimale par défaut, exposition des interfaces réduite au minimum nécessaire). Il doit être livré sans vulnérabilités exploitables connues. Les mécanismes d’authentification, de chiffrement, de contrôle d’accès et d’intégrité des données doivent être appropriés au niveau de risque. Les configurations par défaut doivent être sécurisées.
Volet 2 : gestion des vulnérabilités. Le fabricant doit identifier et corriger les vulnérabilités de son produit, les communiquer, et maintenir cette activité pendant toute la "période d’assistance" du produit (5 ans minimum en règle générale). Il doit établir et publier une politique de divulgation coordonnée des vulnérabilités, mettre à disposition des mises à jour de sécurité sans frais supplémentaires, et établir un SBOM (Software Bill of Materials, nomenclature logicielle) listant les composants de premier niveau intégrés dans le produit.
Le calendrier en trois jalons
11 septembre 2026 : les obligations de signalement s’appliquent. Dès cette date, toute vulnérabilité activement exploitée ou tout incident grave détecté doit faire l’objet d’une alerte précoce sous 24 heures à l’ENISA et au CSIRT national. Une notification complète doit suivre sous 72 heures. Un rapport final doit être transmis dans les 14 jours suivant la remédiation. Ces obligations s’appliquent aux produits déjà sur le marché, pas seulement aux nouveaux.
11 décembre 2027 : application intégrale. À cette date, l’ensemble des obligations entre en vigueur : exigences de sécurité essentielles, documentation technique, SBOM, déclaration UE de conformité, marquage CE. Seuls les produits conformes aux exigences CRA pourront légalement être mis sur le marché de l’UE.
Les catégories de produits et les modalités d’évaluation
Le CRA distingue trois niveaux de criticité. Les produits par défaut (grande majorité) peuvent faire l’objet d’une autévaluation par le fabricant. Les produits importants de classe I (gestionnaires de mots de passe, navigateurs, VPN grand public, systèmes de contrôle industriel de certains types) nécessitent en principe une évaluation par un organisme tiers ou l’application de normes harmonisées. Les produits importants de classe II (systèmes d’exploitation critiques, microprocesseurs de sécurité, cartes à puce, routeurs industriels) sont soumis à une évaluation par un organisme notifié ou à une certification de type.
Le piège le plus sous-estimé : le 11 septembre 2026 concerne les produits déjà sur le marché
C’est l’angle mort que beaucoup d’éditeurs de logiciels n’ont pas encore intégré. La logique habituelle des réglementations produit est que les produits déjà commercialisés avant la date d’application bénéficient d’une période de grâce. Le CRA rompt avec cette logique sur le volet signalement.
À partir du 11 septembre 2026, un éditeur dont le produit est commercialisé depuis plusieurs années doit disposer d’un processus opérationnel de détection et de signalement des vulnérabilités sous 24 heures. La hotline sécurité, le circuit de tri interne, le contact ENISA/CSIRT, la documentation du processus : ces éléments doivent être en place avant cette date, pour les produits actuels.
Nombre d’éditeurs de logiciels n’ont pas aujourd’hui de programme de divulgation des vulnérabilités formalisé, ni de processus de gestion des incidents de sécurité documenté. La mise en conformité avec cette seule obligation représente un travail organisationnel non trivial. L’ANSSI publie sur cyber.gouv.fr des ressources sur la gestion des vulnérabilités qui constituent un point de départ utile pour structurer ce processus.
Comment un audit PIIRATES s’articule avec une démarche CRA
Le CRA impose que les produits soient livrés "sans vulnérabilités exploitables connues". Cette formulation n’impose pas que le produit soit sans vulnérabilités, mais que celles qui sont connues soient documentées et traitées avant mise sur le marché, ou que leur traitement soit planifié. Un test d’intrusion sur l’application web ou mobile permet d’identifier ces vulnérabilités dans le produit avant son lancement ou une mise à jour significative, et de produire la preuve documentaire que cette évaluation a été réalisée. C’est la base d’un dossier de conformité CRA convaincant pour un évaluateur extérieur ou un donneur d’ordre.
L’exigence de sécurité par défaut et par conception, coeur des exigences essentielles du CRA, est précisément ce qu’enseigne notre formation à la sécurité applicative pour développeurs, certifiée Qualiopi. Plutôt que de corriger des vulnérabilités après coup, elle permet aux équipes de développement de comprendre et d’éviter les patterns de code qui en sont la source.
L’obligation de SBOM, qui exige de cartographier tous les composants de premier niveau intégrés dans le produit, est directement liée à la gestion des risques de supply chain logicielle. Un composant tiers vulnérable intégré sans le savoir dans un produit peut compromettre la conformité CRA du produit final. La surveillance des alertes de sécurité sur les composants utilisés est une pratique complémentaire indispensable pour répondre à l’obligation de signalement sous 24 heures.
La valeur au-delà de la conformité
Le CRA va forcer des milliers d’éditeurs de logiciels et de fabricants à mettre en place deux pratiques que les entreprises de sécurité mature considèrent depuis longtemps comme des fondamentaux.
Un programme de gestion des vulnérabilités sérieux. Avoir un SBOM à jour, un canal de signalement des vulnérabilités, un processus de triage et de remédiation priorisé, des mises à jour de sécurité publiées régulièrement : ces pratiques existent dans les grandes entreprises technologiques depuis les années 2000. Elles sont encore rarissimes chez les éditeurs de logiciels de taille moyenne. Le CRA va les normaliser.
La transparence sur les composants. Le SBOM n’est pas seulement un document de conformité : c’est une base de données qui permet à l’éditeur de répondre rapidement à la question "ce composant tiers vulnérable est-il présent dans mes produits, et dans quelles versions ?". Sans SBOM, cette question prend des semaines à répondre. Avec un SBOM maintenu, elle prend des heures. Un éditeur qui sait ce que contient son produit, qui peut corriger rapidement et communiquer avec transparence sur les vulnérabilités, est un éditeur dont la réputation résiste bien mieux à un incident.
Votre produit est-il conforme aux exigences essentielles du CRA avant le 11 décembre 2027 ?
Ce que nous ne faisons pas
(Liste non exhaustive)
Piratage de boite mail
Piratage comptes réseaux sociaux
Espionnage
Exfiltration de sms
Récupération de Cryptomonnaies
Prise en main à distance de véhicules
Suivi GPS de véhicule
Envoyez nous un ping
Le CRA s’applique principalement aux produits mis "sur le marché" (avec transfert de propriété ou licence). Les services SaaS purs, accessibles uniquement à distance sans composant installé chez le client, se situent dans une zone d’interprétation que la Commission européenne est en train de préciser via ses orientations officielles. (Page officielle CRA, Commission européenne). La distinction entre produit et service reste à suivre au fur et à mesure des précisions réglementaires.
Un SBOM (Software Bill of Materials, ou nomenclature logicielle) est une liste formalisée des composants de premier niveau intégrés dans un produit : bibliothèques tierces, frameworks, modules open source, avec leurs versions et licences. Le CRA l’impose pour permettre la traçabilité des composants vulnérables. C’est directement lié à la gestion des risques de supply chain logicielle : si une vulnérabilité est découverte dans un composant tiers, le fabricant doit pouvoir identifier quels produits l’intègrent en quelques heures, pas en quelques semaines.
ISO 27001 certifie qu’une organisation a mis en place un système de management de la sécurité de l’information (SMSI) conforme à un référentiel. Le CRA impose des exigences de sécurité sur le produit lui-même : ses caractéristiques de sécurité intrinsèques, son processus de mise à jour, sa gestion des vulnérabilités sur toute la durée de vie. Les deux sont complémentaires : ISO 27001 porte sur l’organisation, le CRA porte sur le produit.
Oui. C’est le point le plus important. Les obligations de déclaration des vulnérabilités activement exploitées (alerte sous 24 heures à l’ENISA et au CSIRT national) et des incidents graves s’appliquent à partir du 11 septembre 2026 à tous les produits, y compris ceux commercialisés avant l’entrée en vigueur du règlement. Les fabricants doivent avoir leurs processus opérationnels en place avant cette date.
Oui, s’il commercialise des produits sur le marché européen. Le CRA s’applique à toute entité qui met des produits avec éléments numériques à disposition sur le marché de l’UE, quelle que soit sa localisation. Un fabricant américain, asiatique ou australien qui vend ses produits en Europe est soumis aux mêmes exigences qu’un fabricant européen. Le texte intégral est consultable sur EUR-Lex.
Les sanctions prévues atteignent jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu, pour les manquements aux exigences essentielles. Des sanctions inférieures s’appliquent pour des manquements moins graves. Au-delà des amendes, les autorités de surveillance nationales peuvent imposer le retrait du marché des produits non conformes. Un audit de sécurité applicatif réalisé avant la date cible constitue une preuve documentaire de due diligence en cas de contrôle.
Le CRA impose dès le 11 septembre 2026 le signalement des vulnérabilités sous 24h, y compris pour les produits déjà sur le marché. Ce que les éditeurs de logiciels doivent avoir en place, et ce que 2027 change fondamentalement.
