# Cyber Resilience Act : les obligations de signalement depuis le 11 septembre 2026

URL: https://mdp-data.com/cyber-resilience-act-obligations-signalement-2026/
Date: 2026-09-15
Last modified: 2026-09-14
Author: Christophe SAINT-PIERRE

---

> Depuis le 11 septembre 2026, tout éditeur doit signaler ses vulnérabilités activement exploitées sous 24h. Délais, plateforme ENISA, et ce qu'il faut mettre en place maintenant.

## 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](https://mdp-data.com/cyber-resilience-act-definition-objectifs-calendrier/).

_Le calendrier du Cyber Resilience Act prévoit une mise en application progressive entre 2024 et décembre 2027.

## 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](https://www.cyberresilienceact.eu/fr/reporting.html). 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

ÉtapeDélaiContenuAlerte précoce24 heures après la prise de connaissanceSignalement sommaire, sans exiger une analyse complèteNotification72 heuresÉvaluation de la gravité et de l’impact, mesures correctives ou d’atténuationRapport final14 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](https://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](https://www.cert.ssi.gouv.fr/)**, rattaché à l’ANSSI.

Le contrôle et la sanction relèvent en revanche d’une autre autorité : l’[**ANFR**](https://www.anfr.fr/accueil)(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](https://cyber.gouv.fr/nous-connaitre/lagence/)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](https://mdp-data.com/cyber-resilience-act-definition-objectifs-calendrier/) 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](https://mdp-data.com/contact/)

## 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](https://mdp-data.com/cyber-resilience-act-definition-objectifs-calendrier/). 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](https://eur-lex.europa.eu/eli/reg/2024/2847/oj?locale=fr)

- ANSSI – [Cadre réglementaire du CRA](https://cyber.gouv.fr/reglementation/cybersecurite-des-produits/cyber-resilience-act/cadre-reglementaire-du-cra/)

- Commission européenne – [Législation sur la cyberrésilience, obligations de signalement](https://digital-strategy.ec.europa.eu/fr/policies/cra-reporting)

- ANFR – [Cyber Resilience Act et surveillance du marché](https://www.anfr.fr/proteger/equipements-radio-electriques/cyber-resilient-act)

- MDP Data Protection – [Cyber Resilience Act : définition, objectifs et calendrier d’application](https://mdp-data.com/cyber-resilience-act-definition-objectifs-calendrier/)

---
Source: https://mdp-data.com/cyber-resilience-act-obligations-signalement-2026/
Generated by Hack The SEO