Cyber Resilience Act (CRA) : ce que le règlement change pour vous

L'idée en trois phrases

Le Cyber Resilience Act fait pour la cybersécurité ce que le marquage CE fait depuis trente ans pour la sécurité physique : il interdit de vendre en Europe un produit qui présente un risque connu et non traité. À partir du 11 décembre 2027, un objet connecté ou un logiciel ne pourra plus être mis sur le marché européen s'il est livré avec des failles de sécurité connues, sans mécanisme de mise à jour, ou sans personne à qui signaler un problème.

Trois phrases suffisent à retenir l'essentiel :

Le CRA s'applique aux produits, pas aux entreprises : c'est une réglementation produit, au même titre que le marquage CE mécanique ou électrique.
Il ne concerne pas seulement les fabricants. Les importateurs et les distributeurs (articles 19 et 20) portent leurs propres obligations, et certains d'entre eux basculent dans le statut de fabricant sans le savoir (article 21).
La conformité n'attend pas la publication des normes. L'ANSSI le formule sans détour : « la mise en conformité est une obligation réglementaire indépendante de la disponibilité des normes ».

Qu'est-ce qu'un « produit comportant des éléments numériques » ?

Le règlement définit un produit comportant des éléments numériques comme tout produit logiciel ou matériel, ainsi que ses solutions de traitement de données à distance, y compris les composants mis sur le marché séparément (article 3, point 1). Il entre dans le champ du CRA dès lors que son usage prévu ou raisonnablement prévisible comprend une connexion, directe ou indirecte, logique ou physique, à un dispositif ou à un réseau (article 2, paragraphe 1).

Dans le champ

Une caméra de surveillance connectée, un routeur, une serrure connectée, un jouet connecté
Un système d'exploitation, un navigateur, un gestionnaire de mots de passe
Une application mobile, une bibliothèque logicielle vendue à d'autres éditeurs, un firmware
Le backend cloud sans lequel l'objet vendu par son fabricant ne fonctionne plus

Hors champ

Un dispositif médical (règlement (UE) 2017/745 ou 2017/746)
Un véhicule ou un composant homologué pour véhicule (règlement (UE) 2019/2144)
Un aéronef certifié (règlement (UE) 2018/1139), un équipement marin (directive 2014/90/UE)
Un produit conçu exclusivement pour la défense, la sécurité nationale, ou traitant des informations classifiées
Une pièce de rechange identique, fabriquée selon les mêmes spécifications que le composant remplacé

Le SaaS pur est hors du champ du CRA. Le considérant 12 du règlement l'écrit noir sur blanc : les sites internet qui ne supportent pas la fonctionnalité d'un produit, et les services en nuage qui ne sont pas conçus et développés sous la responsabilité du fabricant d'un produit, ne relèvent pas du champ d'application. Le SaaS relève de NIS2, pas du CRA. La nuance à ne pas gommer : si votre service en nuage fait fonctionner un produit que vous vendez par ailleurs, il entre dans le champ avec ce produit, à l'image des fonctionnalités cloud d'un fabricant d'appareils domestiques intelligents qui permettent de le piloter à distance, ou de l'API et de la base de données sans lesquelles une application mobile ne peut pas fonctionner (considérant 11).

Les quatre rôles, et le piège de l'article 21

Le CRA distingue quatre rôles : fabricant, importateur, distributeur, et intendant de logiciel libre, chacun avec ses propres obligations (articles 13, 19, 20 et 24). Le piège est dans l'article 21 : un importateur ou un distributeur qui met un produit sur le marché sous sa propre marque, ou qui lui apporte une modification substantielle, devient fabricant à part entière, avec la totalité des obligations de l'article 13, signalement des 24 heures inclus.

Rôle	Qui	Ce qu'il doit faire
Fabricant (article 13)	Celui qui développe ou fait développer le produit et le met sur le marché sous son nom	Analyse de risque documentée, exigences essentielles de l'annexe I, période d'assistance, SBOM, documentation technique, déclaration UE, marquage CE, signalement
Importateur (article 19)	Celui qui met sur le marché de l'Union un produit d'un fabricant établi hors UE	Vérifier avant mise sur le marché que l'évaluation de conformité a été faite, que le marquage CE et la notice sont présents ; bloquer en cas de doute ; alerter le fabricant sans retard injustifié
Distributeur (article 20)	Celui qui revend un produit déjà mis sur le marché	Diligence requise, vérification du marquage CE et des mentions obligatoires, information du fabricant en cas de vulnérabilité, information immédiate des autorités en cas de risque important
Intendant de logiciel libre (article 24)	Personne morale, autre que le fabricant, qui apporte un soutien systématique et continu à un logiciel libre destiné à une activité commerciale	Régime allégé : politique de cybersécurité documentée, coopération avec les autorités, signalement. Pas de marquage CE, aucune amende administrative possible

Le piège de l'article 21. Un importateur ou un distributeur est considéré comme fabricant, et soumis aux articles 13 et 14, dans deux cas seulement : il met le produit sur le marché sous son propre nom ou sa propre marque, ou il lui apporte une modification substantielle. Traduction en clair : la PME française qui fait fabriquer un boîtier connecté à l'étranger et le revend sous sa marque n'est pas un simple revendeur au sens du CRA. C'est un fabricant, avec la totalité des obligations, y compris les 24 heures de l'article 14, et la plupart de ces entreprises l'ignorent. Une modification substantielle se définit comme une modification apportée après la mise sur le marché qui a une incidence sur la conformité aux exigences essentielles de l'annexe I, partie I, ou qui change l'usage prévu pour lequel le produit a été évalué (article 3, point 30).

Ce qui est déjà applicable depuis le 11 septembre 2026

Depuis le 11 septembre 2026, l'article 14 du CRA impose au fabricant de signaler toute vulnérabilité activement exploitée et tout incident grave affectant la sécurité de son produit, via la plateforme unique de signalement de l'ENISA. Cette obligation vaut pour les produits déjà en vente : elle n'attend pas le 11 décembre 2027 (article 69, paragraphe 3, à lire à la lumière de la FAQ de l'ENISA, la version française du règlement portant une divergence de traduction sur ce point précis).

Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des preuves fiables qu'elle a été exploitée par un acteur malveillant dans un système sans l'autorisation de son propriétaire (article 3, point 42). Un incident grave est un incident qui entache, ou est susceptible d'entacher, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles, ou qui a conduit ou est susceptible de conduire à l'exécution de code malveillant (article 14, paragraphe 5).

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	24 heures au plus tard, avec les États membres concernés	24 heures au plus tard, en indiquant au minimum si l'incident pourrait résulter d'actes illicites ou malveillants
Notification	72 heures au plus tard	72 heures au plus tard
Rapport final	14 jours au plus tard après la mise à disposition d'un correctif ou d'une mesure d'atténuation	1 mois à compter de la notification

Le destinataire du signalement est, simultanément, le CSIRT coordinateur et l'ENISA. Pour la France, le CSIRT coordinateur est le CERT-FR de l'ANSSI, et la plateforme unique de signalement de l'ENISA est en service depuis le 11 septembre 2026. Une obligation souvent oubliée : le fabricant doit aussi informer les utilisateurs concernés, au besoin dans un format structuré lisible par machine (article 14, paragraphe 8). S'il ne le fait pas en temps utile, le CSIRT peut le faire à sa place.

Un cas déjà obligatoire : les produits radio connectés (RED, EN 18031)

Pour les produits radio connectés à internet, une obligation de cybersécurité est déjà en vigueur depuis le 1er août 2025, indépendamment du calendrier du CRA. L'acte délégué (UE) 2022/30 de la directive RED (2014/53/UE) l'impose, et les normes harmonisées EN 18031 qui en détaillent le contenu technique ont été citées au Journal officiel de l'Union le 30 janvier 2025.

Concrètement, une PME qui vend aujourd'hui un objet connecté en wifi, Bluetooth, 4G, LoRa ou Zigbee est déjà soumise à cette obligation, et non à une échéance de décembre 2027. Les contrôles couverts par EN 18031 recoupent largement ceux de l'annexe I du CRA : l'analyse de risque menée au titre du RED alimente directement celle que le CRA exigera. Un seul dossier technique peut donc couvrir les deux réglementations, ce qui change la nature de la conversation : il ne s'agit plus de se préparer à une échéance qui arrive dans plus d'un an, mais de régulariser une obligation en vigueur depuis plus d'un an.

Si votre produit est de ce type, notre test de qualification vous le confirme en cinq questions, avec un signal dédié pour cette obligation RED.

Ce qui arrivera le 11 décembre 2027

Le 11 décembre 2027, les exigences essentielles de l'annexe I du CRA s'appliqueront à tous les produits dans le champ du règlement, en deux blocs : la sécurité du produit lui-même, et la gestion de ses vulnérabilités dans la durée. Le marquage CE, la déclaration UE de conformité et une documentation technique conservée dix ans deviendront obligatoires pour mettre un produit sur le marché européen (articles 28 et 30).

La partie I de l'annexe I porte sur le produit : pas de vulnérabilité exploitable connue à la mise sur le marché, configuration sécurisée par défaut, correction possible par mise à jour avec activation automatique par défaut, contrôle des accès, chiffrement des données au repos et en transit, minimisation des données, réduction de la surface d'attaque, journalisation des accès désactivable par l'utilisateur. La partie II porte sur la gestion des vulnérabilités dans la durée : recenser les composants et produire une nomenclature logicielle (SBOM) dans un format lisible par machine couvrant au moins les dépendances de premier niveau, corriger sans retard indu, tester régulièrement, publier l'information sur les vulnérabilités corrigées, et diffuser gratuitement les correctifs de sécurité.

Trois obligations pèsent directement sur le modèle économique du produit. D'abord, une période d'assistance d'au moins cinq ans, sauf durée d'utilisation prévue plus courte, et plus longue pour les produits qui durent plus longtemps comme les cartes mères ou les systèmes d'exploitation (article 13, paragraphe 8). Ensuite, chaque mise à jour de sécurité doit rester disponible dix ans après son émission, ou jusqu'à la fin de la période d'assistance si elle est plus longue (article 13, paragraphe 9). Enfin, la date de fin de la période d'assistance doit être affichée au moment de l'achat, au moins le mois et l'année (article 13, paragraphe 19).

Tous les produits ne sont pas au même régime

Le CRA fixe quatre niveaux de rigueur selon le type de produit : par défaut, important de classe I, important de classe II, et critique (annexes III et IV). Plus le niveau est élevé, plus la voie de l'auto-évaluation se ferme au profit de l'intervention d'un organisme notifié.

Niveau	Exemples	Ce que ça implique
Produit par défaut	La grande majorité des produits	Auto-évaluation possible (module A)
Important, classe I (annexe III)	Gestionnaires de mots de passe, navigateurs, VPN, antivirus, SIEM, systèmes d'exploitation, routeurs et modems, gestion des identités et des accès, assistants vocaux, produits domotiques de sécurité (serrures, caméras, babyphones, alarmes), jouets connectés interactifs ou géolocalisés	Auto-évaluation possible seulement en appliquant intégralement des normes harmonisées ou un schéma de certification européen de niveau substantiel au moins. À ce jour, aucune norme n'est citée au Journal officiel : examen UE de type ou assurance qualité complète avec un organisme notifié
Important, classe II (annexe III)	Hyperviseurs et moteurs de conteneurs, pare-feu, IDS et IPS, microprocesseurs et microcontrôleurs résistants aux manipulations	Évaluation par tierce partie obligatoire, sans échappatoire par les normes
Critique (annexe IV)	Dispositifs matériels avec boîtier de sécurité, passerelles de compteur intelligent, cartes à puce et éléments sécurisés	Certification européenne de cybersécurité si un acte délégué l'impose ; à défaut, régime de la classe II

À ce jour, aucune norme harmonisée CRA n'est citée au Journal officiel de l'Union. En l'état des textes publiés, la conséquence est directe et rarement dite : pour un produit de classe I, la voie de l'auto-évaluation est en pratique fermée, et l'intervention d'un organisme notifié devient le régime par défaut. C'est un argument de calendrier, pas une raison d'attendre : l'analyse de risque et le dossier technique se préparent indépendamment de la publication des normes.

Sanctions et qui contrôle le CRA en France

Le CRA prévoit trois plafonds de sanction selon la nature du manquement, jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial pour le manquement le plus grave (article 64). En France, la surveillance du marché revient à l'ANFR, avec l'appui technique de l'ANSSI, qui est par ailleurs autorité notifiante et, via le CERT-FR, CSIRT coordinateur pour les signalements.

Plafond	Manquement
15 M EUR ou 2,5 % du chiffre d'affaires mondial, le montant le plus élevé étant retenu	Manquement aux exigences essentielles de l'annexe I et aux obligations des articles 13 et 14
10 M EUR ou 2 % du chiffre d'affaires mondial	Manquement aux autres obligations : articles 18 à 23, déclaration UE, marquage CE, documentation technique, procédures d'évaluation
5 M EUR ou 1 % du chiffre d'affaires mondial	Informations inexactes, incomplètes ou trompeuses fournies aux organismes notifiés ou aux autorités de surveillance

Deux allègements réels protègent les petites structures. Les micro et petites entreprises ne peuvent pas être sanctionnées pour le seul dépassement du délai de 24 heures de l'alerte précoce, l'obligation reste mais l'amende tombe (article 64, paragraphe 10, point a). Elles peuvent aussi produire la documentation technique de l'annexe VII dans un format simplifié, que les organismes notifiés doivent accepter (article 33, paragraphe 5). La taille et la part de marché sont par ailleurs des critères de modulation de l'amende (article 64, paragraphe 5).

En l'état des textes publiés au 13 septembre 2026, la désignation française de l'ANFR et de l'ANSSI est annoncée par les autorités elles-mêmes, mais son support législatif national, porté par le projet de loi DDADUE, n'est pas encore adopté : il a été adopté par le Sénat le 18 février 2026 et reste en attente d'examen en séance à l'Assemblée nationale.

Et si je ne fabrique rien ? Vous allez quand même recevoir des alertes

Même sans fabriquer le moindre produit, une entreprise cliente va commencer à recevoir des alertes de sécurité de ses fournisseurs : depuis le 11 septembre 2026, tout fabricant qui découvre une vulnérabilité activement exploitée doit en informer ses utilisateurs (article 14, paragraphe 8). Sans processus pour recevoir, qualifier et traiter ces alertes, une entreprise se retrouve en difficulté au moment où elle en a le plus besoin.

Le sujet devient plus pressant encore pour une entité soumise à NIS2, qui porte des obligations explicites sur la sécurité de sa chaîne d'approvisionnement (article 21 de la directive (UE) 2022/2555). Notre page sur NIS2 détaille où se situe cette frontière. Deux bénéfices concrets pour l'acheteur : le CRA rehausse le niveau de sécurité de ce qui s'achète, et il offre un levier contractuel, la date de fin de période d'assistance et la nomenclature logicielle (SBOM) pouvant désormais être exigées avant achat. C'est exactement le type de point qu'un audit de maturité cybersécurité permet de sécuriser en amont.

Outil ou accompagnement

Il n'existe aujourd'hui aucun produit Dativo dédié au CRA : les normes harmonisées ne sont pas publiées, et un outil construit maintenant serait à refaire. Deux portes existent malgré tout, sans rien vendre de plus qu'elles ne livrent : le diagnostic sans frais, qui qualifie votre situation en cinq questions, et le conseil ponctuel, pour un avis argumenté sur un cas précis, sans engagement de durée.

Questions fréquentes

Le CRA, les questions qui reviennent

Mon SaaS est-il concerné par le CRA ?

Non, en règle générale. Le considérant 12 du règlement (UE) 2024/2847 l'écrit explicitement : les services en nuage qui ne sont pas conçus et développés sous la responsabilité du fabricant d'un produit ne relèvent pas du champ d'application du CRA, et le SaaS pur relève de NIS2. La nuance à connaître : si votre service en nuage fait fonctionner un produit matériel ou logiciel que vous vendez par ailleurs, comme l'API ou la base de données sans lesquelles une application mobile ne peut pas fonctionner, il entre dans le champ avec ce produit (considérant 11). Le test se fait donc au niveau du produit, pas de l'entreprise.

Je revends du matériel sous ma marque, suis-je fabricant ?

Oui. L'article 21 du règlement (UE) 2024/2847 est sans ambiguïté : un importateur ou un distributeur qui met un produit sur le marché sous son propre nom ou sa propre marque est considéré comme fabricant, et soumis à la totalité des obligations des articles 13 et 14. C'est le cas le plus fréquent chez les PME qui font fabriquer un produit à l'étranger et le vendent sous leur enseigne, et beaucoup d'entre elles l'ignorent encore. Cela inclut le signalement en 24 heures de l'article 14, pas seulement les obligations allégées d'un simple revendeur.

Le CRA s'applique-t-il aux produits déjà vendus ?

Oui, pour l'obligation de signalement. L'article 14 impose au fabricant de signaler toute vulnérabilité activement exploitée et tout incident grave depuis le 11 septembre 2026, y compris sur des produits déjà commercialisés. La version française de l'article 69, paragraphe 3, prête à confusion sur ce point : nous nous appuyons sur la FAQ de l'ENISA, qui confirme sans ambiguïté que l'obligation de signalement couvre les produits déjà sur le marché. Les exigences essentielles de l'annexe I, elles, ne s'appliqueront qu'aux produits mis sur le marché à partir du 11 décembre 2027.

Quelle est la différence entre le CRA et NIS2 ?

Le CRA est une réglementation produit : il porte sur ce que vous vendez, un objet connecté ou un logiciel (article 2, paragraphe 1). NIS2, la directive (UE) 2022/2555, est une réglementation d'organisation : elle porte sur la façon dont votre entreprise gère son propre risque cyber, quel que soit le produit qu'elle vend ou utilise. Les deux textes se rejoignent sur un point précis, la sécurité de la chaîne d'approvisionnement, que NIS2 impose à l'organisation (article 21 de la directive) quand le CRA l'impose au produit. Notre page dédiée à NIS2 détaille ce second texte.

Le CRA s'applique-t-il aux logiciels libres ?

Cela dépend de qui le maintient et comment. Une personne qui contribue du code à un projet dont elle n'a pas la responsabilité n'est en principe pas concernée. Celui qui apporte un soutien systématique et continu à un logiciel libre destiné à une activité commerciale relève du statut d'intendant de logiciel libre (article 24), avec un régime allégé : politique de cybersécurité documentée, coopération avec les autorités, signalement, mais aucun marquage CE et aucune amende administrative possible. Le critère de bascule est la monétisation : licence, support payant ou version professionnelle changent la qualification.

Faut-il attendre les normes harmonisées pour s'y mettre ?

Non. L'ANSSI le formule sans détour : la mise en conformité est une obligation réglementaire indépendante de la disponibilité des normes. À ce jour, aucune norme harmonisée CRA n'est citée au Journal officiel de l'Union, ce qui ferme en pratique la voie de l'auto-évaluation pour un produit important de classe I, mais l'analyse de risque et le dossier technique de l'annexe I se préparent indépendamment de cette publication. L'article 13, paragraphe 3, exige d'ailleurs que toute non-applicabilité d'une exigence soit documentée et justifiée au regard de l'analyse de risque, ce qui suppose que cette analyse existe déjà.

Qui contrôle le CRA en France ?

La surveillance du marché revient à l'ANFR, avec l'appui technique de l'ANSSI. L'ANSSI est par ailleurs l'autorité notifiante pour les organismes d'évaluation de la conformité, et elle assure, via le CERT-FR, le rôle de CSIRT coordinateur pour les signalements de l'article 14. En l'état des textes publiés au 13 septembre 2026, ces désignations sont annoncées par les autorités elles-mêmes, mais leur support législatif national, le projet de loi DDADUE, n'est pas encore adopté : il a été voté par le Sénat le 18 février 2026 et attend son examen en séance à l'Assemblée nationale.

Combien de temps dois-je maintenir mon produit ?

Au moins cinq ans à compter de la mise sur le marché, sauf si la durée d'utilisation prévue du produit est plus courte (article 13, paragraphe 8). Cette période doit être plus longue pour les produits dont l'usage attendu dépasse cinq ans, comme les cartes mères, les microprocesseurs, les routeurs ou les systèmes d'exploitation. Chaque mise à jour de sécurité émise doit par ailleurs rester disponible pendant dix ans après son émission, ou jusqu'à la fin de la période d'assistance si elle est plus longue (article 13, paragraphe 9). La date de fin de cette période doit être affichée au moment de l'achat, au moins le mois et l'année (article 13, paragraphe 19).

La SBOM doit-elle être publiée ?

Le règlement impose de la produire, pas nécessairement de la rendre publique. L'annexe I, partie II, exige que le fabricant recense les composants de son produit et établisse une nomenclature logicielle dans un format lisible par machine, couvrant au moins les dépendances de premier niveau. Ce qui doit être rendu public, distinctement, c'est l'information sur les vulnérabilités corrigées, une fois le correctif disponible. En l'état des textes publiés, rien n'impose la publication de la SBOM elle-même à l'ensemble du marché.

Que dois-je faire dans les 24 heures ?

Envoyer une alerte précoce au CSIRT coordinateur, le CERT-FR en France, et à l'ENISA, via la plateforme unique de signalement, dès que vous avez connaissance d'une vulnérabilité activement exploitée ou d'un incident grave affectant votre produit (article 14, paragraphes 3 et 5). Cette alerte n'a pas besoin d'être complète : elle doit au minimum indiquer si l'incident pourrait résulter d'actes illicites ou malveillants. Une notification plus détaillée suit sous 72 heures, puis un rapport final sous 14 jours après la disponibilité d'un correctif, ou sous un mois après la notification pour un incident grave. Le point à ne pas découvrir le jour J : il faut un compte déjà ouvert sur la plateforme de l'ENISA et une procédure interne écrite avant l'incident, pas pendant.

Sources

Deux minutes, une réponse

Vous ne savez pas où vous vous situez ?

Cinq questions suffisent pour savoir si le CRA vous concerne, et à quel titre.

Suis-je concerné : je me teste

Cyber Resilience Act : le CE de la cybersécurité