MDP Data Protection accompagne les éditeurs de logiciels dans la mise en conformité aux obligations de signalement du Cyber Resilience Act
Depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants de produits numériques de signaler toute vulnérabilité activement exploitée sous vingt-quatre heures. Cette obligation s’applique même aux produits commercialisés depuis plusieurs années. Voici ce qui doit être signalé, dans quel délai, sur quelle plateforme, et ce qu’un éditeur de logiciels doit mettre en place dès maintenant pour être en mesure de le faire.
👉 Pour une présentation générale du règlement, son calendrier complet et son champ d’application, consultez notre article Cyber Resilience Act : définition, objectifs et calendrier d’application.
Ce qui est exigible depuis le 11 septembre 2026
Une seule disposition du Cyber Resilience Act est entrée en application à cette date : l’article 14, celui du signalement. Tout fabricant qui prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave affectant l’un de ses produits doit le déclarer, y compris pour des produits mis sur le marché avant le 11 septembre 2026.
La distinction entre ces deux notions est le point de vigilance principal :
- Vulnérabilité activement exploitée : il existe des preuves fiables qu’un acteur malveillant l’a exploitée sans autorisation. Une preuve de concept publiée, un rapport de chercheur ou un test autorisé ne suffisent pas — il faut une exploitation constatée.
- Incident grave : un événement qui affecte, ou est susceptible d’affecter, la disponibilité, l’authenticité, l’intégrité ou la confidentialité du produit, ou qui a conduit à l’exécution de code malveillant.
Un identifiant CVE publié sur une vulnérabilité ne constitue pas, à lui seul, une notification au sens de l’article 14. C’est un acte distinct, qui doit être déposé sur la plateforme dédiée.
Le calendrier de signalement : 24 heures, 72 heures, puis un rapport final
| Étape | Délai | Contenu |
|---|---|---|
| Alerte précoce | 24 heures après la prise de connaissance | Signalement sommaire, sans exiger une analyse complète |
| Notification | 72 heures | Évaluation de la gravité et de l’impact, mesures correctives ou d’atténuation |
| Rapport final | 14 jours après une mesure corrective (vulnérabilité) ou 1 mois après la notification (incident grave) | Description complète, causes, mesures prises |
Le point de départ de ces délais est la prise de connaissance : le moment où l’entreprise dispose d’éléments suffisants pour caractériser l’événement. Ce moment se documente, c’est souvent le premier élément qu’une autorité examine en cas de contrôle.
Où et comment signaler : la plateforme unique de l’ENISA
Le signalement se fait exclusivement sur la plateforme unique de signalement (Single Reporting Platform), en ligne depuis le 11 septembre 2026 à l’adresse : portal.cra-srp.enisa.europa.eu.
Le fabricant s’y connecte avec un compte EU Login à authentification multifacteur, sous le rôle de représentant désigné (« Assigned Representative »). Un seul dépôt suffit : la plateforme transmet automatiquement l’information au CSIRT coordinateur compétent et à l’ENISA.
En France : CERT-FR et ANFR, deux rôles distincts
Pour un fabricant dont l’établissement principal est en France, le CSIRT coordinateur destinataire des signalements est le CERT-FR, rattaché à l’ANSSI.
Le contrôle et la sanction relèvent en revanche d’une autre autorité : l’ANFR (Agence nationale des fréquences), désignée autorité de surveillance du marché pour les produits numériques, avec l’appui technique de l’ANSSI.
L’ANSSI conserve pour sa part le rôle d’autorité notifiante, chargée de désigner les organismes qui évalueront la conformité des produits (accrédités par le COFRAC).
Qui est concerné : le point de vigilance sur le périmètre
Le champ n’est pas automatique pour un éditeur. Notre article sur la définition et le champ d’application du Cyber Resilience Act détaille les exclusions générales. Pour un éditeur de logiciels, trois situations concrètes font basculer un produit dans le champ :
- une brique est téléchargée ou installée chez le client (application mobile, extension, client lourd), un SaaS accessible uniquement par navigateur n’y suffit pas ;
- un traitement de données à distance côté éditeur est indispensable au fonctionnement d’un autre produit ;
- le développement est réalisé sur mesure pour un client unique, ou commercialisé en marque blanche.
Ce point mérite d’être tranché produit par produit, avec un conseil qualifié, la qualification d’une offre SaaS ne se déduit pas d’un modèle générique.
Ce qu’un éditeur doit mettre en place dès maintenant
Être en capacité de signaler dans les 24 heures suppose plusieurs prérequis, à vérifier avant tout événement :
- identifier son CSIRT coordinateur (le CERT-FR pour un établissement principal en France) ;
- désigner un représentant sur la plateforme, avec un compte EU Login et un suppléant distinct, la fenêtre de 24 heures ne s’accommode pas d’une absence ;
- tenir un registre recensant les produits, leurs versions maintenues et leur date de mise sur le marché, pour répondre en quelques minutes à la question « ce produit est-il dans le champ ? » ;
- disposer d’un canal de réception des signalements externes, et d’une liste de diffusion permettant de joindre les utilisateurs par produit et par version.
👉 Pour savoir ce que vous pouvez exiger de vos fournisseurs de logiciels, consultez notre article sur le sujet.
Un doute sur votre exposition, ou besoin d’aide pour mettre ces prérequis en place ? Un doute sur votre obligation de signalement ? Parlons-en
Quelles sanctions en cas de manquement ?
Les montants sont détaillés dans notre article sur le calendrier et les sanctions du Cyber Resilience Act. Pour le seul manquement à l’obligation de signalement, l’amende peut atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial annuel.
FAQ – Obligations de signalement du Cyber Resilience Act
Une vulnérabilité corrigée avant d’avoir été exploitée doit-elle être signalée ?
Non. Le critère déclencheur est l’existence de preuves fiables d’une exploitation par un acteur malveillant, pas la gravité technique de la faille. Une vulnérabilité critique jamais exploitée n’entre pas dans l’obligation de l’article 14.
Un identifiant CVE suffit-il à remplir l’obligation de signalement ?
Non. La publication ou l’attribution d’un identifiant CVE ne constitue pas un signalement au sens du règlement. Le dépôt doit être effectué séparément sur la plateforme unique de l’ENISA.
Le signalement volontaire d’un quasi-incident est-il possible ?
Oui, pour toute personne — pas seulement le fabricant. Un quasi-incident, une menace ou une vulnérabilité non encore exploitée peuvent être signalés sur une base volontaire, sans que cela constitue une obligation.
Mon produit est un SaaS accessible uniquement par navigateur : suis-je concerné ?
En principe non, ce cas relève plutôt de la directive NIS2. La qualification change si un composant est installé côté client ou si un traitement à distance de votre côté est indispensable au fonctionnement d’un autre produit — un point à trancher avec un conseil qualifié.
Qui, dans mon organisation, doit être désigné comme représentant sur la plateforme ?
Une personne joignable en permanence, avec un suppléant distinct enregistré séparément. Dans une petite structure, une seule personne peut cumuler ce rôle avec d’autres fonctions, mais le représentant principal et son suppléant doivent rester deux personnes différentes.
En résumé
- Depuis le 11 septembre 2026, tout fabricant de produit numérique doit signaler à l’ENISA les vulnérabilités activement exploitées et les incidents graves affectant ses produits, y compris ceux déjà commercialisés.
- Le calendrier impose une alerte sous 24 heures, une notification sous 72 heures, puis un rapport final.
- Le signalement se fait sur la plateforme unique de l’ENISA, transmise en France au CERT-FR.
- Le contrôle et la sanction relèvent en France de l’ANFR, avec l’appui technique de l’ANSSI.
- Un éditeur doit dès maintenant désigner un représentant et identifier son CSIRT compétent.
Sources
- Règlement (UE) 2024/2847, articles 14 à 16 – EUR-Lex
- ANSSI – Cadre réglementaire du CRA
- Commission européenne – Législation sur la cyberrésilience, obligations de signalement
- ANFR – Cyber Resilience Act et surveillance du marché
- MDP Data Protection – Cyber Resilience Act : définition, objectifs et calendrier d’application
Pour aller plus loin
- CNIL - Nouvelle édition : Guide 2024 de la sécurité des données personnelles
- MDP Data Protection - Logiciel RGPD : comment choisir la solution idéale pour votre entreprise
- MDP Data Protection —
- Une question sur votre situation ? Parlons-en — réponse sous 48 heures ouvrées.
Les solutions MDP Data Protection
MDP Data Protection et sa méthode CCOS accompagne les organisations dans la mise en conformité multi-réglementaire (RGPD, NIS2 et IA Act...), avec une approche opérationnelle et évolutive.
- SimplyRGPD : Pilotage de votre conformité au quotidien.
- MDP CAMPUS : Notre parcours de sensibilisation en vidéos pédagogiques de 3 à 7 minutes.
Notre Méthode : le Continuous Compliance Operating System - CCOS
Découvrez notre méthode pour passer à une conformité en continu.
Sinon retrouvez un résumé ici : le Continuous Compliance Operating System
Restez à jour sans y passer vos journées
Notre veille réglementaire, une fois par mois. Les textes qui bougent, ce qu'ils changent, ce qu'il faut faire.
À propos de l’auteur
Christophe SAINT-PIERRE est le dirigeant de MDP Data Protection. Expert reconnu en conformité réglementaire, RGPD, NIS2 et AI Act, il accompagne depuis plus de vingt ans les organisations dans leur transformation numérique.
Sa vision stratégique repose sur l'idée que la conformité ne doit pas être perçue comme une contrainte, mais comme un véritable levier de compétitivité, de sécurité et de confiance. Engagé pour une souveraineté numérique européenne, il défend également une approche éthique de l'intelligence artificielle et de la cybersécurité. Lire sa biographie complète.
