Le Cyber Resilience Act est la norme européenne qui impose des exigences de cybersécurité obligatoires aux produits comportant des éléments numériques, d’une application mobile à une caméra connectée. Il a été adopté sous la forme du règlement (UE) 2024/2847 et est entré en vigueur le 10 décembre 2024, mais ses obligations arrivent par étapes. La première s’applique depuis le 11 septembre 2026. Depuis ce jour, tout fabricant qui met à disposition des produits numériques dans l’Union européenne doit notifier les vulnérabilités activement exploitées et les incidents graves, avec une première alerte dans les 24 heures. L’essentiel du règlement ne s’applique qu’à partir du 11 décembre 2027. Pendant quinze mois, une obligation de notification pleinement exigible coexistera avec des exigences techniques encore inapplicables. La portée complète du règlement, avec la classification des produits et le marquage CE, figure dans notre guide sur ce qu’est le Cyber Resilience Act et les entreprises qu’il vise.
Si vous avez besoin d’un conseil juridique pour vous mettre en conformité avec le Cyber Resilience Act, demandez une évaluation initiale gratuite.
L’article 14 impose deux obligations de notification distinctes. La première vise les vulnérabilités du produit qui sont activement exploitées. La seconde vise les incidents graves ayant un impact sur la sécurité du produit. Toutes deux se déclenchent dès que le fabricant a connaissance du fait, et non lorsqu’il le confirme ou le diagnostique.
La distinction compte, car les délais sont identiques mais le contenu des rapports ne l’est pas, et parce qu’un même événement peut relever des deux cas à la fois.
Une vulnérabilité est considérée comme activement exploitée lorsqu’il existe des preuves fiables qu’un tiers l’a exploitée dans un système sans l’autorisation de son propriétaire. La définition n’exige ni dommage consommé ni exfiltration de données. L’exécution de l’attaque suffit.
L’obligation couvre les vulnérabilités du produit dans son ensemble, y compris celles qui se trouvent dans des composants tiers intégrés. Un fabricant ne se libère pas en faisant valoir que la faille se trouve dans une bibliothèque open source qu’il n’a pas écrite. Si cette bibliothèque est embarquée dans son produit, la vulnérabilité est la sienne aux fins de la notification.
Outre l’avertissement à l’autorité, le fabricant doit informer sans retard injustifié les utilisateurs concernés du produit et, le cas échéant, leur indiquer les mesures correctives ou d’atténuation qu’ils peuvent appliquer.
Un incident est grave lorsqu’il nuit à la capacité du produit de protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données ou des fonctions qu’il traite. Il l’est aussi lorsqu’il entraîne, ou peut entraîner, l’introduction ou l’exécution de code malveillant dans le produit ou dans les réseaux et systèmes d’information de l’utilisateur.
Le seuil s’apprécie au niveau du produit, et non de l’organisation. Une intrusion dans les systèmes de l’entreprise du fabricant qui ne dégrade pas la sécurité du produit commercialisé échappe à l’article 14, même si elle peut déclencher d’autres règles comme la directive NIS2 ou l’obligation de notification des violations de données du RGPD.
Le régime s’articule en trois communications successives sur le même fait. Une alerte précoce dans les 24 heures, une notification complète dans les 72 heures et un rapport final dont le délai dépend de la nature du fait notifié, vulnérabilité ou incident. L’alerte précoce et la notification complète se comptent à partir du moment où le fabricant a eu connaissance du fait. Le rapport final a son propre point de départ, qui n’est pas la prise de connaissance.
| Délai | Communication | Contenu minimal |
|---|---|---|
| 24 heures | Alerte précoce | Indication qu’il existe une exploitation active ou un incident grave, et États membres où le produit est disponible |
| 72 heures | Notification complète | Données techniques, gravité et impact, et mesures correctives prises ou mises à la disposition des utilisateurs |
| 14 jours | Rapport final sur une vulnérabilité | Se compte à partir du moment où une mesure corrective est disponible. Description de la faille, gravité, impact et correctif appliqué |
| 1 mois | Rapport final sur un incident grave | Se compte à partir de la notification des 72 heures. Nature, cause probable et mesures d’atténuation |
L’horloge des 24 heures est le vrai point de friction. Elle démarre avec la prise de connaissance, et non avec le diagnostic. Une entreprise qui reçoit un signalement d’un chercheur externe un vendredi après-midi a jusqu’au samedi après-midi pour envoyer l’alerte précoce, même si son équipe technique n’a pas encore pu reproduire la faille.
L’obligation de notification pèse exclusivement sur le fabricant, c’est-à-dire celui qui développe le produit ou le fait développer et le commercialise sous son nom ou sa marque. Les importateurs et les distributeurs ne notifient pas l’autorité. Ils doivent informer le fabricant sans retard injustifié lorsqu’ils détectent une vulnérabilité, mais ne déclenchent pas l’horloge des 24 heures.
Le règlement place les gestionnaires de logiciels libres et open source dans une catégorie propre, avec une obligation plus limitée que celle du fabricant. Ils notifient les vulnérabilités activement exploitées des produits qu’ils développent, sans être soumis au reste du régime de conformité.
Être fabricant ne dépend pas du fait d’avoir une usine. Une entreprise de logiciels qui vend une application de gestion sous sa marque est fabricant au sens du règlement, même si le développement est sous-traité et que le produit ne comporte aucun composant physique.
L’obligation de notification vise tous les produits comportant des éléments numériques mis sur le marché avant le 11 décembre 2027, quelle que soit leur ancienneté. Un routeur vendu en 2019 ou une gamme abandonnée et sans support sont concernés. C’est la conséquence de l’article 69, paragraphe 3, qui exclut expressément l’article 14 du régime transitoire.
L’article 69, paragraphe 2, libère les produits antérieurs à cette date des exigences essentielles de l’annexe I tant qu’ils ne font pas l’objet d’une modification substantielle. Ce soulagement ne s’étend pas à la notification. Un fabricant peut ne pas être tenu de reconcevoir un produit ancien et être tenu de notifier dans les 24 heures une vulnérabilité exploitée de ce même produit.
L’obligation se déclenche avec la prise de connaissance, et non avec la date de vente. Comptent les vulnérabilités et les incidents dont le fabricant a connaissance à partir du 11 septembre 2026, et non ceux qu’il connaissait déjà avant. Cela ne rend pas le passé sans importance, car une vulnérabilité ancienne qui devient activement exploitée après cette date constitue bien un fait à notifier.
La plateforme unique de signalement (Single Reporting Platform) du Cyber Resilience Act est en service depuis le 11 septembre 2026, date à laquelle l’ENISA a déployé sa capacité opérationnelle initiale, et se trouve à l’adresse portal.cra-srp.enisa.europa.eu. C’est le canal par lequel les fabricants communiquent les vulnérabilités activement exploitées et les incidents graves, et elle fonctionne selon le principe d’une notification unique pour atteindre toutes les autorités compétentes.
La répartition est automatique. L’équipe de réponse aux incidents qui reçoit le signalement le partage sans retard avec les CSIRT des autres États membres sur le territoire desquels le produit est disponible, et l’ENISA le reçoit en parallèle. Le fabricant ne répète pas la démarche pays par pays, ce que l’article 14 voulait éviter.
Écrire par courriel au CSIRT national ne satisfait pas à l’obligation, même s’il existe une relation préalable avec cette équipe. La plateforme est le canal unique et la transmission aux autres États membres concernés se fait au sein du système.
L’accès à la plateforme exige une inscription préalable. Chaque entreprise désigne des représentants attitrés (Assigned Representatives), avec un rôle principal et des rôles secondaires, et l’ENISA publie un manuel propre à ce profil ainsi que les conditions générales du service (en anglais), en vigueur depuis le 10 septembre 2026.
L’ordre compte. L’horloge des 24 heures court à partir du moment où le fabricant a connaissance de la vulnérabilité exploitée, et non du moment où il parvient à se connecter au portail. Une entreprise qui commence son inscription le jour de l’incident consacre aux formalités les heures dont elle a besoin pour l’analyse technique.
Le démarrage est manuel. Aucune interface de programmation n’est disponible : l’intégration automatique avec les outils internes de gestion des vulnérabilités devra attendre. La version en service est la capacité opérationnelle initiale, et l’ENISA élargira les fonctionnalités dans les prochains mois à partir de l’expérience des utilisateurs.
Trois limites opérationnelles conditionnent le travail quotidien. Les comptes non encore validés peuvent présenter jusqu’à vingt notifications avant que la validation devienne obligatoire. La notification volontaire de l’article 15 n’a pas été incluse au lancement et arrivera dans une phase ultérieure, sans date annoncée. Et si la plateforme n’est pas opérationnelle, le fabricant peut s’adresser directement à son CSIRT, mais la notification devra ensuite passer par le système.
Le 4 septembre 2026, l’ENISA a publié la liste des CSIRT désignés comme coordinateurs (en anglais) dans les vingt-sept États membres. L’Espagne achemine ses notifications via l’INCIBE-CERT, avec deux voies distinctes, l’une pour les incidents et l’autre pour la coordination des vulnérabilités et l’attribution des CVE. Jusqu’à cette date, le destinataire espagnol était inconnu.
Les obligations de notification s’appliquent aux gestionnaires de logiciels libres et open source à partir du 11 décembre 2027, la même date que l’essentiel du règlement. D’ici là, l’article 14 lie les fabricants, comme l’indique la Commission européenne (en anglais) dans sa documentation sur la notification.
Lorsque le fabricant n’a pas d’établissement dans l’Union, la compétence suit une chaîne. D’abord le mandataire, puis l’importateur, ensuite le distributeur et, en dernier lieu, l’État membre où se trouve le plus grand nombre d’utilisateurs.
Que l’INCIBE-CERT figure sur la liste de l’ENISA comme CSIRT coordinateur pour l’Espagne règle la question de savoir à qui l’on notifie, pas celle de savoir qui surveille le marché ni qui sanctionne. Ce sont des fonctions distinctes et seule la première est réglée. Le canal européen est entré en service avant le bras exécutif national.
L’Espagne est arrivée au 11 septembre sans avoir désigné formellement ses autorités au titre du règlement, et en octobre 2026 elle ne l’a toujours pas fait. 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 et 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.
L’absence de désignation ne suspend rien. Le Cyber Resilience Act 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 qui instruit et qui sanctionne sur le territoire espagnol, et non l’existence de l’obligation.
C’est le même schéma que pour la transposition de NIS2, où le retard législatif national a coexisté avec des obligations européennes pleinement exigibles. Il ne faut pas confondre l’un et l’autre. L’examen complet de ce chevauchement figure dans notre guide du cadre réglementaire numérique en Espagne et dans l’Union européenne.
L’article 64 fixe trois niveaux d’amende administrative et, dans chacun, s’applique le montant le plus élevé entre la somme fixe et le pourcentage du chiffre d’affaires annuel mondial. Le manquement à l’obligation de notification relève du niveau le plus élevé.
Les amendes sont infligées par les autorités nationales de surveillance du marché, ce qui, en Espagne, renvoie de nouveau au décret royal en attente. Le risque pratique à court terme n’est pas tant l’amende immédiate que l’accumulation de manquements documentés qu’une autorité pourra examiner une fois constituée. Le régime complet, avec les exceptions et le retrait du produit, figure dans notre analyse des sanctions du Cyber Resilience Act.
La préparation est organisationnelle avant d’être technique. L’obligation s’applique déjà, et l’urgence n’est pas de reconcevoir le produit, mais de mettre en place le circuit qui permet de tenir un délai de 24 heures. Voici les sept points à avoir réglés.
Une entreprise de Valence, que nous appellerons Domotek, fabrique des thermostats connectés et les vend en Espagne, au Portugal et en France. Un chercheur indépendant lui écrit un vendredi à 18 heures avec des preuves qu’une faille du module d’appairage est utilisée pour accéder au réseau domestique de plusieurs clients.
L’horloge démarre le vendredi à 18 heures, et non le lundi lorsque l’équipe produit lira le courriel. Domotek a jusqu’au samedi 18 heures pour envoyer l’alerte précoce, en indiquant qu’il y a exploitation active et que le produit est commercialisé dans trois États membres. Elle a jusqu’au lundi 18 heures pour la notification complète, avec les données techniques et les mesures disponibles. La notification est présentée au CSIRT coordinateur espagnol, qui la transmet au Portugal et à la France sans que Domotek ait à faire trois envois.
En parallèle, et sans attendre le rapport final, elle doit avertir les utilisateurs concernés et leur dire ce qu’ils peuvent faire en attendant le correctif.
En matière de conformité en cybersécurité, le point de défaillance est rarement technique. Il relève de la gouvernance interne. La vulnérabilité est détectée à temps, mais personne n’a reçu par écrit le pouvoir de déclarer qu’il s’agit d’une exploitation active et de déclencher l’horloge. Il convient de fixer qui prend cette décision, qui la prend si cette personne est injoignable et à quel moment précis l’entreprise est réputée avoir eu connaissance du fait.
Oui. Le Cyber Resilience Act couvre les produits comportant des éléments numériques, catégorie qui inclut le logiciel mis sur le marché de manière autonome. Une application, un plugin ou un outil logiciel distribué comme produit est concerné. Le SaaS pur en est en général exclu, sauf le traitement de données à distance qui fait partie d’un produit. S’il est vendu sous votre marque, vous êtes le fabricant et c’est à vous de notifier.
Non. L’obligation de l’article 14 se limite aux vulnérabilités activement exploitées et aux incidents graves. Une vulnérabilité détectée lors d’un audit interne et corrigée avant que quiconque l’exploite n’est pas notifiée, même si elle doit être gérée conformément aux exigences qui s’appliqueront à partir de décembre 2027.
Le délai de 24 heures court de la même manière. Le règlement ne prévoit aucune suspension pour les week-ends ni les jours fériés. C’est pourquoi la procédure d’escalade doit désigner des personnes joignables en dehors des heures de bureau et préciser par écrit qui peut envoyer l’alerte précoce en l’absence du responsable principal.
Vous pouvez déléguer l’envoi matériel, mais pas la responsabilité. C’est le fabricant qui répond devant l’autorité. Si le prestataire ne respecte pas le délai, l’amende est infligée à l’entreprise qui commercialise le produit : le contrat doit donc prévoir des délais internes plus courts que ceux du règlement.
Oui. L’inscription comme représentant attitré est préalable et ne se règle pas le jour de l’incident. Le délai de 24 heures de l’alerte précoce commence à courir dès que l’entreprise a connaissance de la vulnérabilité exploitée, qu’elle ait ou non déjà accès au portail. Les entreprises dont des produits comportant des éléments numériques sont sur le marché de l’Union s’inscrivent maintenant, et non lorsque le problème survient.
Non. La notification est présentée une seule fois sur la plateforme unique et parvient à l’équipe de réponse aux incidents de l’État membre où l’entreprise a son établissement principal. Cette équipe la partage sans retard avec les CSIRT des autres territoires où le produit est disponible, et l’ENISA la reçoit en parallèle. Le fabricant ne répète pas la démarche.
Si vous mettez à disposition des produits comportant des éléments numériques dans l’Union européenne et que votre circuit de notification n’est pas en place, l’obligation vous concerne depuis le 11 septembre 2026. Chez Innovatech, nous aidons les fabricants et les éditeurs de logiciels à mettre en place la procédure, à réviser les contrats de la chaîne d’approvisionnement et à réagir lorsque l’horloge a déjà commencé à tourner. Parlez-nous de votre cas et nous l’examinerons.
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.