Le Cyber Resilience Act est le règlement européen qui impose des exigences de cybersécurité obligatoires aux produits comportant des éléments numériques. Il s’applique à tout produit mis à disposition dans l’Union européenne. Il a été adopté sous la forme du règlement (UE) 2024/2847 et est entré en vigueur le 10 décembre 2024. Il oblige les fabricants, les importateurs et les distributeurs, et vise aussi bien le matériel que le logiciel, d’un routeur à une application mobile. Ses obligations arrivent par étapes. Les obligations de notification sont exigibles depuis le 11 septembre 2026. L’essentiel du règlement s’applique à partir du 11 décembre 2027. Le non-respect est sanctionné par jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.
Si vous avez besoin d’un conseil juridique pour vous mettre en conformité avec le Cyber Resilience Act, demandez une évaluation initiale gratuite.
Y entre tout produit logiciel ou matériel doté d’une connexion de données, logique ou physique, directe ou indirecte, à un appareil ou à un réseau. La définition inclut les solutions de traitement de données à distance associées au produit et les composants commercialisés séparément. Le critère est la connectivité, et non le secteur ou la taille de l’entreprise qui le fabrique.
Cette ampleur surprend de nombreuses entreprises qui ne se voient pas comme des fabricants de technologie. Une entreprise de machines industrielles qui vend des équipements dotés d’un écran tactile connecté est concernée. Un cabinet de conseil qui commercialise son propre logiciel de gestion est concerné. Un fabricant de jouets connectés à l’internet est concerné.
L’article 2 exclut sept cas, presque tous parce qu’ils disposent déjà de leur propre réglementation sectorielle de cybersécurité.
Est également exclu le logiciel libre développé sans finalité commerciale. Cette exclusion comporte une nuance. Lorsque le logiciel libre est destiné à un usage commercial apparaît une figure intermédiaire dotée d’obligations propres, présentée plus loin.
Le règlement vise quatre figures avec une intensité décroissante. Le fabricant supporte l’essentiel de la charge, y compris les exigences essentielles de l’annexe I et la notification de l’article 14. L’importateur vérifie que le produit qu’il introduit sur le marché européen est conforme. Le distributeur contrôle le marquage CE et vérifie que le fabricant et l’importateur ont fait leur part. Le mandataire agit pour le compte d’un fabricant sans établissement dans l’Union.
Le fabricant, au sens du règlement, n’est pas celui qui assemble physiquement. C’est celui qui développe un produit ou le fait développer et le commercialise sous son nom ou sa marque. Une entreprise qui fait développer son application et la publie sous sa marque est fabricant. Peu importe qu’elle n’ait pas écrit une ligne de code.
Lorsque le fabricant est situé hors de l’Union, la responsabilité suit une chaîne. Répond d’abord le mandataire. À défaut, l’importateur. Puis le distributeur. Et en dernier lieu, on retient l’État membre où se trouve le plus grand nombre d’utilisateurs.
Un importateur ou un distributeur est considéré comme fabricant dans deux cas prévus à l’article 21. Le premier est la mise sur le marché du produit sous son propre nom ou sa propre marque. Le second est l’apport d’une modification substantielle à un produit déjà commercialisé. Dans les deux cas, il est soumis aux articles 13 et 14. Il assume l’intégralité des obligations du fabricant et l’obligation de notifier les vulnérabilités en 24 heures.
C’est le piège juridique le plus discret du règlement, car il ne dépend pas de ce que fait l’entreprise, mais de la manière dont elle étiquette ce qu’elle vend. Le modèle de la marque blanche, courant dans l’électronique grand public et la distribution industrielle, fait du distributeur un fabricant sans qu’il s’en rende compte. Il en va de même pour l’intégrateur qui reconditionne un logiciel tiers sous sa propre marque.
La conséquence pratique est qu’un distributeur sans capacité technique de développement assume l’obligation de gérer les vulnérabilités d’un produit qu’il ne maîtrise pas. La seule issue raisonnable est contractuelle. Avant d’apposer sa propre marque sur le produit d’un autre, il convient de régler trois points avec le fournisseur d’origine. L’accès aux informations techniques, l’engagement de correction et des délais internes compatibles avec les 24 heures.
L’article 24 crée la figure du gestionnaire de logiciels libres et open source. C’est la personne morale qui apporte un soutien durable à un logiciel open source destiné à un usage commercial. Ce n’est pas un fabricant et il n’en supporte pas les obligations. Il doit adopter une politique de cybersécurité documentée, gérer efficacement les vulnérabilités et coopérer avec les autorités de surveillance du marché.
L’article 64 va plus loin et exclut totalement ces gestionnaires des amendes administratives. C’est l’une des rares exemptions liées à la qualité de l’opérateur. Elle répond au souci du législateur de ne pas étouffer l’écosystème open source européen.
La classification détermine comment démontrer la conformité, et non si le produit est visé. Il existe quatre niveaux. Les produits par défaut, c’est-à-dire tous ceux qui ne sont pas listés, permettent l’autoévaluation. Les produits importants de classe I et II figurent à l’annexe III. Les produits critiques figurent à l’annexe IV. Plus la fonction est sensible, plus l’intervention d’un tiers indépendant pèse.
| Catégorie | Où elle figure | Comment la conformité est évaluée | Exemples |
|---|---|---|---|
| Par défaut | Non listé | Autoévaluation par contrôle interne, dossier technique et déclaration UE de conformité | La plupart des logiciels de gestion et des objets connectés grand public |
| Importante de classe I | Annexe III | Autoévaluation si des normes harmonisées sont appliquées. À défaut, intervention d’un tiers | Navigateurs, gestionnaires de mots de passe, antivirus, VPN, systèmes d’exploitation, routeurs, domotique dotée de fonctions de sécurité, jouets connectés avec localisation |
| Importante de classe II | Annexe III | Évaluation par un organisme notifié | Pare-feu, hyperviseurs et environnements de conteneurs, systèmes de détection et de prévention des intrusions, microprocesseurs inviolables |
| Critique | Annexe IV | Une certification européenne de cybersécurité peut être exigée | Modules de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés |
La classification dépend de la fonctionnalité principale du produit, et non de ses fonctions accessoires. Un logiciel de comptabilité doté d’un gestionnaire de mots de passe pour son propre accès ne devient pas pour autant un produit important de classe I.
Pendant près d’un an, la classification a été source d’insécurité, car les annexes décrivaient les catégories en termes génériques. Le règlement d’exécution (UE) 2025/2392 du 28 novembre 2025 a publié les descriptions techniques de chaque catégorie de produits importants et critiques. Ce texte est aujourd’hui le point de départ de toute analyse de rattachement. Les 26 catégories et leurs descriptions techniques figurent dans notre guide sur la classification des produits du Cyber Resilience Act.
Le fabricant doit concevoir, développer et produire le produit conformément aux exigences essentielles de l’annexe I. Et il doit maintenir cette conformité pendant toute la période de support. Ce n’est pas une formalité de certification ponctuelle, c’est une obligation continue qui survit à la vente.
Les obligations se regroupent en cinq blocs.
La période de support est l’élément qui exige le plus de planification. L’article 13, paragraphe 8, fixe un minimum de cinq ans. Une période plus courte n’est admise que lorsque la durée d’utilisation prévue du produit est inférieure, comme pour une application conçue pour un événement précis. Le fabricant doit déterminer cette période, en informer l’utilisateur et la respecter, même si le produit n’est plus vendu.
Cinq ans d’engagement de correction imposent des décisions qui ne sont pas juridiques. Un fabricant qui intègre une bibliothèque tierce sans support à long terme assume une obligation qu’il ne pourra pas tenir par ses propres moyens.
Depuis le 11 septembre 2026, le fabricant notifie les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit. Le régime s’articule en trois communications successives sur le même fait. Les délais sont de 24 heures, 72 heures et 14 jours ou un mois selon le cas.
Les notifications sont présentées via la plateforme unique gérée par l’ENISA et adressées au CSIRT désigné comme coordinateur dans l’État membre de l’établissement principal. Depuis le 4 septembre 2026, l’Espagne achemine ses notifications via l’INCIBE-CERT.
Cette obligation est la seule du règlement qui s’applique déjà aux produits anciens. L’article 69, paragraphe 3, l’étend à tous les produits mis sur le marché avant le 11 décembre 2027, quelle que soit leur ancienneté. Les délais, les personnes visées et le contenu minimal de chaque communication figurent dans notre analyse de la notification des vulnérabilités du Cyber Resilience Act.
Le produit conforme porte le marquage CE et est accompagné d’une déclaration UE de conformité par laquelle le fabricant assume sa responsabilité. C’est le même mécanisme que celui qui s’applique déjà à la sécurité électrique ou à la compatibilité électromagnétique, désormais étendu à la cybersécurité. Sans marquage CE, le produit ne peut pas être mis à disposition dans l’Union à partir du 11 décembre 2027.
La voie vers ce marquage dépend de la catégorie. Un produit par défaut est évalué en interne selon le module A. Un produit important de classe I peut suivre la même voie si le fabricant applique des normes harmonisées couvrant les exigences applicables. S’il ne les applique pas, ou si le produit est de classe II, un organisme notifié intervient. Les produits critiques de l’annexe IV peuvent être soumis à un schéma européen de certification.
Les organismes notifiés sont la pièce qui rend tout cela possible. Les procédures relatives à leur notification s’appliquent depuis le 11 juin 2026. Le réseau devait exister avant que le marquage ne devienne exigible. La procédure complète, la documentation technique et la déclaration figurent dans notre guide du marquage CE du Cyber Resilience Act.
Le règlement n’entre pas en application d’un coup. Il répartit ses obligations sur quatre étapes en trois ans, et trois sont déjà passées.
| Date | Ce qui se passe | Situation |
|---|---|---|
| 10 décembre 2024 | Entrée en vigueur du règlement | Passée |
| 11 juin 2026 | Application des procédures de notification des organismes d’évaluation de la conformité | Passée |
| 11 septembre 2026 | Les obligations de notification de l’article 14 deviennent exigibles | Passée |
| 11 décembre 2027 | Application intégrale. Exigences essentielles, marquage CE et déclaration de conformité | À venir |
Quinze mois séparent septembre 2026 de décembre 2027. Pendant cette période, une obligation de notification pleinement exigible coexiste avec des exigences techniques encore inapplicables. Un fabricant peut être tenu de signaler une vulnérabilité d’un produit qui n’a pas encore à respecter l’annexe I.
Le 27 juillet 2026, la Commission a adopté la communication C(2026) 5252, qui contient les lignes directrices d’application du règlement prévues à son article 26. Elles s’adressent surtout aux microentreprises et aux PME et comprennent 67 exemples pratiques. Elles ne sont pas contraignantes, car l’interprétation authentique du règlement revient à la Cour de justice de l’Union européenne. Mais elles expriment la position officielle de la Commission et servent aussi à orienter les autorités de surveillance du marché et les organismes notifiés. Le texte est publié dans la bibliothèque de la Commission européenne (en anglais). Voici les précisions qui changent le plus le travail d’une entreprise.
De nombreux fabricants continueront de vendre après le 11 décembre 2027 des unités de modèles conçus auparavant. Les lignes directrices précisent que la conformité n’oblige pas nécessairement à les reconcevoir. Le fabricant doit réaliser l’évaluation des risques de l’article 13, paragraphe 2, et s’il démontre que le produit intègre déjà des mesures de sécurité adéquates, il peut s’appuyer sur elles.
Ce qui ne disparaît pas, c’est la procédure. Ces unités ont besoin de leur évaluation de la conformité, de leur déclaration UE de conformité et de leur marquage CE. Les lignes directrices allègent en revanche la charge documentaire. Il n’est pas nécessaire de reconstituer la documentation de conception ni les essais de la phase d’origine, et les essais nécessaires peuvent être regroupés par familles de produits.
Pour le règlement, seul est un logiciel libre celui qui dispose d’une licence libre accordant tous les droits d’utilisation, de modification et de redistribution et dont le code source est publié. Un logiciel sous licence libre dont seuls les clients payants reçoivent le code ne compte pas. Celui qui se contente de contribuer au code d’un projet tiers n’en répond pas non plus. La responsabilité incombe à celui qui publie le logiciel et décide de ses versions.
Les lignes directrices précisent quand le logiciel libre est fourni dans le cadre d’une activité commerciale et devient soumis au règlement.
En revanche, proposer séparément de la formation ou du conseil sur un logiciel que chacun peut télécharger gratuitement ne suffit pas. Accepter des dons non plus, sauf s’ils fonctionnent en pratique comme un prix parce qu’ils conditionnent l’accès au logiciel ou à ses mises à jour.
Les lignes directrices consacrent une section entière au logiciel mis à jour en continu. Le critère n’est pas l’ampleur du changement, mais le fait qu’il modifie le risque de cybersécurité et que ce risque n’ait pas déjà été pris en compte dans l’évaluation des risques du fabricant. Une nouvelle fonction qui change la destination du produit constituera normalement une modification substantielle. Une fonction prévue et évaluée dès la conception ne l’est pas. Une fonction en apparence mineure peut l’être. L’exemple des lignes directrices est l’option permettant de rester connecté, qui conserve les jetons d’authentification sur l’appareil.
Les mises à jour de sécurité ne sont pas, en règle générale, des modifications substantielles. Elles cessent d’être exemptées lorsqu’elles changent la destination du produit ou ajoutent des risques imprévus, par exemple des interfaces accessibles de l’extérieur ou des dépendances à des services tiers. Pour trancher, les lignes directrices proposent quatre questions.
La conséquence compte. Un produit modifié substantiellement est traité comme un nouveau produit mis sur le marché. Si une personne autre que le fabricant le modifie, elle devient fabricant, même si ses obligations peuvent se limiter à la partie modifiée lorsque le changement n’affecte pas la sécurité du produit dans son ensemble. La même proportionnalité vaut pour le fabricant d’origine qui modifie après décembre 2027 un produit mis sur le marché auparavant.
Les lignes directrices corrigent une lecture très répandue. Les cinq ans de l’article 13, paragraphe 8, sont un plancher. Un produit dont l’utilisation est prévue plus longtemps doit avoir une période de support plus longue. Le fabricant doit indiquer au moment de l’achat la date de fin du support, au moins en mois et en année. Et, lorsque c’est techniquement possible, avertir l’utilisateur de la fin du support.
Pour le logiciel à versions successives, chaque version modifiée substantiellement a besoin de sa propre période de support déclarée. L’article 13, paragraphe 10, permet de corriger les vulnérabilités uniquement dans la dernière version si les utilisateurs peuvent effectuer la mise à jour gratuitement et sans coûts supplémentaires. Selon les lignes directrices, ces coûts supplémentaires sont l’achat de nouveau matériel ou le remplacement d’infrastructures, et non le temps d’essai ou de configuration propre à toute mise à jour. Et une modification substantielle ne relance pas automatiquement la période de support, qui n’est recalculée que si la durée d’utilisation prévue du produit change.
Le règlement inclut dans le produit ses solutions de traitement de données à distance. Les lignes directrices précisent qu’une solution distante fait partie du produit lorsque deux conditions sont réunies à la fois.
Peu importe où elle s’exécute. Un serveur propre dans les locaux du fabricant compte autant qu’un cloud public. En sont exclus les systèmes internes de l’entreprise, comme les ressources humaines, le CRM ou les environnements d’intégration et de déploiement, la télémétrie à des fins purement statistiques et les sites web qui se contentent d’informer sur le produit. Une application SaaS d’un tiers ne fait pas non plus partie du produit, mais le fabricant doit la traiter comme un composant, en évaluer les risques et exercer une diligence raisonnable. Les lignes directrices suggèrent d’inclure des engagements de sécurité dans les accords de niveau de service avec ces prestataires.
Le délai court à partir du moment où le fabricant a connaissance du fait. Les lignes directrices le situent au moment où, après une première évaluation, il a un degré raisonnable de certitude qu’une vulnérabilité de son produit est activement exploitée ou qu’un incident grave en a compromis la sécurité. Cette évaluation doit être faite immédiatement.
Les lignes directrices ajoutent trois précisions. L’obligation n’est pas rétroactive : il n’y a pas à notifier les exploitations connues avant le 11 septembre 2026. La vulnérabilité d’un composant tiers qui ne peut pas être exploitée, ou ne l’a pas été, dans le produit lui-même n’est pas soumise à notification obligatoire, même si elle doit être signalée à celui qui maintient le composant. Et l’obligation de notification se poursuit après la fin de la période de support du produit.
L’Espagne n’a pas encore désigné formellement ses autorités au titre du règlement. Le projet de décret royal qui doit le faire confie la surveillance du marché au Secrétariat d’État aux Télécommunications et aux Infrastructures numériques. Il réserve le rôle d’autorité notifiante au Centre cryptologique national (CCN). L’autorité espagnole de la concurrence (CNMC) a rendu son rapport IPN/CNMC/007/26 (en espagnol) le 13 mai 2026 et le texte suit son cours.
Il convient de distinguer deux choses souvent confondues. Que l’INCIBE-CERT figure depuis le 4 septembre 2026 sur la liste de l’ENISA comme CSIRT coordinateur règle la question de savoir à qui l’on notifie. Cela ne règle pas celle de savoir qui surveille le marché ni qui instruit une procédure de sanction. Le canal européen est entré en service avant le bras exécutif national.
L’absence de désignation ne suspend aucune obligation. Le règlement est directement applicable et n’a pas besoin d’une norme nationale de mise en œuvre pour obliger. Ce qui reste en suspens, c’est l’appareil de sanction espagnol, et non l’existence de l’obligation. C’est le même schéma que celui observé dans le cadre réglementaire numérique européen avec d’autres textes récents.
L’article 64 fixe trois niveaux d’amende administrative. Dans chacun, s’applique le montant le plus élevé entre la somme fixe et le pourcentage du chiffre d’affaires annuel mondial de l’exercice précédent.
Deux exemptions, rarement mentionnées, changent le calcul du risque pour de nombreuses entreprises. Les microentreprises et les petites entreprises ne peuvent pas être sanctionnées pour non-respect du délai de 24 heures de l’alerte précoce. Les gestionnaires de logiciels libres et open source ne peuvent être sanctionnés pour aucune infraction au règlement.
L’exemption des PME est limitée et doit être bien lue. Elle couvre le délai de 24 heures, pas l’obligation de notifier. Une petite entreprise qui notifie en retard ne sera pas sanctionnée pour ce retard. Celle qui ne notifie pas du tout reste exposée au niveau le plus élevé. Quelle infraction relève de quel niveau et ce qui manque à l’Espagne pour sanctionner sont expliqués dans notre analyse des sanctions du Cyber Resilience Act.
Le CRA régit le produit. La directive NIS2 régit l’organisation qui fournit un service essentiel ou important. Une même entreprise peut relever des deux à des titres différents, et les obligations de notification ne se substituent pas l’une à l’autre. Un fabricant de logiciels qui exploite en outre une infrastructure critique notifie deux fois, par des voies différentes et avec ses propres délais.
Avec l’AI Act, la relation est cumulative. Un système d’IA à haut risque mis à disposition en tant que produit comportant des éléments numériques doit respecter les exigences de cybersécurité des deux textes. Les deux sont expressément liés : selon l’article 12 du CRA, un système d’IA à haut risque qui respecte les exigences essentielles du CRA est réputé conforme aux exigences de cybersécurité de l’AI Act.
Reste un troisième front dont presque personne ne parle. La directive (UE) 2024/2853 relative à la responsabilité du fait des produits défectueux inclut le logiciel dans la notion de produit. Et elle admet qu’un produit puisse être défectueux faute de mises à jour de sécurité. Le dossier technique que le CRA oblige à tenir sera la preuve de diligence dans une action civile en réparation. C’est la lecture qui apparaît le moins dans les analyses techniques et celle qui pèse le plus lorsqu’il y a un préjudice réel.
Une entreprise galicienne importe des caméras de vidéosurveillance d’un fabricant asiatique et les vend sous sa propre marque dans la grande distribution. Elle ne développe pas de micrologiciel et n’a pas de service technique. Elle se considère comme distributeur et suppose que ses obligations se limitent à contrôler le marquage CE.
L’article 21 dit autre chose. En commercialisant le produit sous son nom, cette entreprise est fabricant au sens du règlement. Lui incombent les exigences essentielles de l’annexe I, le dossier technique et la déclaration UE de conformité. Ainsi qu’une période de support d’au moins cinq ans et la notification en 24 heures de toute vulnérabilité exploitée.
L’annexe III range parmi les produits importants de classe I les produits domotiques dotés de fonctions de sécurité, et mentionne expressément les caméras de sécurité. Si le modèle est commercialisé pour un usage domestique, l’évaluation de la conformité cesse d’être une autoévaluation libre. La qualification n’est pas automatique et doit être analysée produit par produit. Les unités vendues en 2025 sont toujours sur le marché : l’obligation de notification la concerne donc déjà. Le marquage CE, en revanche, ne lui sera exigible qu’en décembre 2027.
La solution ne passe pas par l’arrêt des ventes. Elle passe par la renégociation du contrat avec le fabricant asiatique. Accès au SBOM, engagement de correction compatible avec les 24 heures et répartition du coût des mises à jour pendant la période de support. C’est un travail contractuel, pas technique.
Le règlement est entré en vigueur le 10 décembre 2024 et ses obligations arrivent par étapes. Depuis le 11 septembre 2026, il est obligatoire de notifier les vulnérabilités activement exploitées et les incidents graves. Le reste du règlement, y compris les exigences essentielles de l’annexe I et le marquage CE, s’applique à partir du 11 décembre 2027.
Oui. Le règlement ne distingue pas entre matériel et logiciel. Il vise tout produit doté d’une connexion de données directe ou indirecte à un appareil ou à un réseau, y compris les applications mobiles, les logiciels de gestion et les solutions de traitement de données à distance associées au produit. La plupart de ces logiciels relèvent de la catégorie par défaut, qui permet l’autoévaluation.
Oui. L’article 21 considère comme fabricant l’importateur ou le distributeur qui met un produit sur le marché sous son propre nom ou sa propre marque, ainsi que celui qui apporte une modification substantielle à un produit déjà commercialisé. Il est soumis aux articles 13 et 14, avec l’intégralité des obligations du fabricant et l’obligation de notifier en 24 heures.
Cela dépend de la catégorie du produit. Les produits par défaut font l’objet d’une autoévaluation par contrôle interne. Les produits importants de classe I de l’annexe III permettent l’autoévaluation si le fabricant applique des normes harmonisées couvrant les exigences applicables. Les produits importants de classe II exigent l’intervention d’un organisme notifié, et les produits critiques de l’annexe IV peuvent nécessiter une certification européenne de cybersécurité.
L’article 13, paragraphe 8, fixe une période de support d’au moins cinq ans. Une période plus courte n’est admise que lorsque la durée d’utilisation prévue du produit est inférieure à cinq ans. Le fabricant doit déterminer cette période, la communiquer à l’utilisateur et la maintenir même si le produit n’est plus vendu.
Le règlement est directement applicable et oblige sans norme nationale de mise en œuvre. Ce qui est en attente en Espagne, c’est la désignation formelle des autorités de surveillance du marché et de la procédure de sanction, et non l’existence de l’obligation. Un retard dans la désignation ne suspend pas l’obligation. La possibilité de sanctionner ensuite des manquements commis avant l’existence du régime de sanctions espagnol est une question ouverte, mais les mesures visant le produit et la responsabilité civile n’en dépendent pas.
Le Cyber Resilience Act redistribue la responsabilité tout au long de la chaîne d’approvisionnement, selon des critères qui ne correspondent pas à l’intuition commerciale des entreprises. Si vous vendez des produits connectés ou des logiciels, l’analyse de rattachement est à faire avant décembre 2027, pas après. Chez Innovatech, nous examinons la qualification de vos produits, la répartition contractuelle du risque avec vos fournisseurs et votre circuit interne de notification. Écrivez-nous et nous vous proposerons une évaluation initiale gratuite.
Marta Suárez-Mansilla est associée gérante d'Innovatech Legal et abogada inscrite à l'ICAM (Ilustre Colegio de la Abogacía de Madrid), active en droit des technologies. Elle a suivi le cours Copyright de la Harvard Law School et le programme Blockchain de BerkeleyX, et conseille des entreprises technologiques depuis plus de huit ans.