NOTIFICATION ENISA CRA
Notification ENISA et Cyber Resilience Act : obligations, délais et procédure
Depuis le 11 septembre 2026, les fabricants concernés par le Cyber Resilience Act (CRA) doivent notifier certaines vulnérabilités activement exploitées et certains incidents graves ayant un impact sur la sécurité des produits comportant des éléments numériques. Ces notifications passent par la Single Reporting Platform (SRP), exploitée par l'ENISA, dans les conditions prévues par les articles 14 à 16 du règlement (UE) 2024/2847.
L'enjeu opérationnel est double : qualifier rapidement les faits et organiser les informations à transmettre sans confondre un signal de sécurité avec un événement réellement soumis à notification.
Navigation utile : Comprendre le CRA · Découvrir CRA Manager · Voir le dossier technique CRA · Guide Cyber Resilience Act
Quels événements doivent être notifiés à l'ENISA au titre du CRA ?
L'article 14 distingue principalement deux catégories :
1. Une vulnérabilité activement exploitée contenue dans un produit comportant des éléments numériques, lorsque le fabricant en prend connaissance et que les conditions du texte sont réunies. La seule présence d'une CVE ou d'une alerte émise par un fournisseur ne suffit pas à démontrer que la vulnérabilité affecte effectivement le produit et répond aux critères de signalement.
2. Un incident grave ayant un impact sur la sécurité du produit, dans les conditions prévues par le CRA. L'analyse doit porter sur l'incident, sa gravité, ses effets et son lien avec la sécurité du produit ; tous les événements de cybersécurité ne sont pas automatiquement des incidents graves à notifier au titre de ce règlement.
La qualification relève des personnes responsables au sein du fabricant. Elle tient compte du produit, de son périmètre, des faits établis et des orientations applicables.
Quels sont les délais de notification CRA ?
Les échéances sont calculées à partir du moment où le fabricant prend connaissance de l'événement entrant dans le champ de l'article 14, et non automatiquement à partir de la publication d'une CVE ou d'une alerte extérieure.
| Étape | Vulnérabilité activement exploitée | Incident grave affectant la sécurité du produit |
|---|---|---|
| Alerte précoce | Sans retard injustifié, au plus tard dans les 24 heures après en avoir eu connaissance. | Sans retard injustifié, au plus tard dans les 24 heures après en avoir eu connaissance. |
| Notification complémentaire | Sans retard injustifié, au plus tard dans les 72 heures après en avoir eu connaissance. | Sans retard injustifié, au plus tard dans les 72 heures après en avoir eu connaissance. |
| Rapport final | Au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. | Dans le mois suivant la notification à 72 heures. |
Les informations requises varient selon la phase et la catégorie d'événement. Consulter le texte du CRA et le glossaire SRP de l'ENISA pour les champs à renseigner ; ne pas présumer que toutes les données sont disponibles dès l'alerte initiale.
La plateforme ENISA SRP : où effectuer le signalement ?
La plateforme unique de signalement CRA (SRP) est opérationnelle depuis le 11 septembre 2026. Elle permet au fabricant de notifier l'événement en une procédure, pour communication aux autorités concernées dans les conditions du règlement.
Accès officiel : Ouvrir la plateforme ENISA CRA SRP
La démarche implique notamment d'identifier l'organisation déclarant, ses représentants habilités et le CSIRT désigné comme coordinateur compétent. Selon les instructions ENISA, l'accès repose sur un compte EU Login et les modalités d'enregistrement et d'habilitation de la SRP.
Les interfaces et procédures peuvent évoluer : la documentation de l'ENISA, notamment mise à jour en octobre 2026, doit être consultée avant tout dépôt effectif.
Comment organiser une notification CRA en pratique ?
1. Enregistrer le signal ou l'incident et son origine
Noter l'heure de prise de connaissance, la source, le produit et les versions concernés. Préserver la distinction entre une alerte non confirmée, un problème de sécurité en cours d'examen et un événement formellement qualifié.
2. Qualifier l'événement avec les responsables compétents
Examiner la réalité de l'exploitation ou la gravité de l'incident, ainsi que l'impact sur la sécurité du produit. Consigner la décision, le périmètre et les incertitudes éventuelles.
3. Préparer l'alerte initiale et la notification à 72 heures
Rassembler les informations disponibles sur le produit, la nature de l'événement, les impacts connus, les États membres concernés lorsque pertinent, les mesures déjà prises et les mesures d'atténuation envisageables. Les champs et leur degré d'obligation évoluent selon la phase de dépôt.
4. Déposer sur le portail officiel et conserver les justificatifs
Le déclarant habilité réalise le dépôt dans la SRP de l'ENISA et conserve l'identifiant, l'heure, le contenu transmis et les accusés ou références disponibles. Une préparation dans un outil interne ne remplace pas le dépôt officiel.
5. Préparer le rapport final et les mises à jour
Pour une vulnérabilité activement exploitée, documenter la correction ou l'atténuation et la date de disponibilité. Pour un incident grave, préparer le rapport dans la temporalité qui lui est propre. Archiver les éléments de décision et les communications utiles.
Les notifications s'appliquent-elles aussi aux produits déjà commercialisés ?
Oui, les obligations de notification entrées en application le 11 septembre 2026 peuvent concerner des produits déjà mis sur le marché avant le 11 décembre 2027, dès lors qu'ils entrent dans le champ applicable du CRA. Il ne faut donc pas attendre l'application générale de 2027 pour examiner l'article 14.
L'ENISA précise qu'une exploitation active déjà connue avant le 11 septembre 2026 n'entraîne pas, dans les conditions exposées par la Commission, une obligation de déclaration rétroactive simplement du fait de l'entrée en application ; l'analyse d'un événement dont le fabricant prend connaissance après cette date est différente.
Pour les open-source software stewards, le calendrier spécifique de l'article 24, paragraphe 3, prévoit l'application des obligations correspondantes à compter du 11 décembre 2027, sous réserve des conditions du règlement.
Comment CRA Manager accompagne-t-il la préparation d'une notification ENISA ?
CRA Manager aide à préparer et suivre le dossier relatif à une vulnérabilité activement exploitée (AEV) : qualification, informations de contexte, échéances, actions et traçabilité de la décision et du dépôt officiel.
Limite essentielle : CRA Manager ne soumet pas automatiquement les notifications dans la SRP. Le dépôt est effectué par le déclarant habilité sur le portail ENISA. Le module AEV ne doit pas être présenté comme un assistant exhaustif couvrant tous les cas d'incident grave de l'article 14. Les fonctions disponibles dépendent de l'édition, des droits et de la configuration.
La valeur du pilotage est de conserver une chaîne lisible entre le produit, les données d'analyse, les décisions, les mesures prises et les preuves utiles — et non de rendre automatiquement une décision réglementaire.
FAQ — Notification ENISA et CRA
Toutes les vulnérabilités CVE doivent-elles être notifiées ?
Non. Une entrée CVE ne prouve pas à elle seule que le produit est affecté ni que les critères de notification d'une vulnérabilité activement exploitée sont réunis. Une analyse du produit et des faits est nécessaire.
Les délais de 24 heures et 72 heures concernent-ils aussi les incidents graves ?
Oui, l'article 14 fixe ces premières étapes pour les deux catégories, mais les informations à communiquer et les délais du rapport final diffèrent selon le type d'événement.
Quelle est la différence entre le rapport final pour une vulnérabilité et celui pour un incident ?
Pour une vulnérabilité activement exploitée, le délai est lié à la disponibilité d'une mesure de correction ou d'atténuation : 14 jours après. Pour un incident grave, il est lié à la notification à 72 heures : dans le mois suivant cette notification.
Peut-on envoyer une notification directement depuis CRA Manager ?
Non. CRA Manager peut aider à préparer et tracer les informations concernant les vulnérabilités activement exploitées ; le dépôt officiel se fait dans la plateforme ENISA SRP.
Faut-il notifier un événement sur un produit commercialisé en 2025 ?
L'ancienneté de la mise sur le marché n'exclut pas, en elle-même, les obligations de notification applicables depuis le 11 septembre 2026. Il faut examiner le périmètre du CRA et les faits propres à l'événement.
Sources officielles
- Règlement (UE) 2024/2847 — articles 14 à 17 et dispositions transitoires
- Commission européenne — CRA, obligations de notification
- ENISA — plateforme unique de signalement CRA
- ENISA — FAQ SRP, mise à jour le 15 octobre 2026
Rédaction : équipe Hoctave. Ce contenu expose le cadre général et ne remplace pas une analyse réglementaire de l'événement et du produit.