La gestion des vulnérabilités reposait jusqu'ici sur un mécanisme mondial unique : le programme CVE de MITRE, alimenté par un réseau de CNAs mandatées à l'échelle internationale. Ce modèle reste en place. Mais depuis novembre 2025, un second niveau de gouvernance s'y superpose pour l'Europe : ENISA est devenue CVE Root, autorité faîtière pour les CNAs opérant dans le périmètre européen. Maintenant que le Cyber Resilience Act impose des notifications via la plateforme ENISA à partir du 11 septembre 2026, cette architecture à deux niveaux a des conséquences directes sur vos processus.
Qu'est-ce qu'un CVE Root ?
Le programme CVE est structuré en trois niveaux. Au sommet, les Roots supervisent des réseaux de CNAs (CVE Numbering Authorities) dans un périmètre délimité. Les CNAs assignent les identifiants CVE et publient les CVE Records pour les vulnérabilités dans leur périmètre. En dessous, les Sub-CNAs opèrent sous la supervision directe d'un CNA.
MITRE est le Root historique et mondial, premier point de contact pour les vulnérabilités sans CNA désigné. ENISA est désormais le Root européen, superviseur des CNAs européens : CSIRTs nationaux, agences de cybersécurité des États membres, autorités sectorielles. En pratique, ENISA recrute, forme et coordonne les CNAs dans sa sphère de compétence. Quatre organisations ont rejoint le programme CVE sous supervision ENISA depuis novembre 2025, selon le communiqué ENISA du 3 avril 2026 : le BSI allemand, le NCSC néerlandais, le CCN espagnol et l'ANSSI française, qui était déjà CNA, a renforcé son rattachement au Root européen.
L'EUVD comme second registre de référence
ENISA opère la European Vulnerability Database (EUVD), déployée sous le mandat de la directive NIS2 et opérationnelle depuis janvier 2026. L'EUVD agrège les CVE du registre MITRE, mais y ajoute les vulnérabilités remontées via les CSIRTs nationaux et les CNAs européens.
La distinction est importante. Une vulnérabilité peut exister dans l'EUVD avec un identifiant EUVD propre avant d'avoir reçu un numéro CVE MITRE, notamment lorsque la divulgation initiale passe par le canal européen. Elle peut aussi être publiée dans l'EUVD avec des métadonnées plus riches que dans le NVD américain, incluant des informations de coordination transfrontalière entre États membres.
Pour vos outils de gestion des vulnérabilités — scanners, SIEM, plateformes GRC — cela implique une double source. Les feeds qui ne consultent que le NVD américain peuvent manquer des vulnérabilités divulguées d'abord via le canal ENISA. Ce n'est pas un risque théorique : depuis la mise en service de l'EUVD, plusieurs vulnérabilités affectant des équipements industriels européens ont reçu leur identifiant EUVD avant leur entrée dans le NVD, avec un délai observé de deux à cinq jours ouvrés.
Ce que le CRA change à partir du 11 septembre
Le Cyber Resilience Act impose aux fabricants de produits numériques de notifier les vulnérabilités activement exploitées dans leurs produits via le Single Reporting Platform (SRP) d'ENISA dans les 24 heures suivant leur détection. Cette obligation est active depuis le 11 septembre 2026.
La notification doit référencer la vulnérabilité. Si un identifiant CVE existe, il doit être mentionné. Si la vulnérabilité n'a pas encore reçu de CVE, ENISA coordonne l'attribution via son rôle de Root. Le processus est donc inversé par rapport à l'habitude : dans le canal MITRE, le CNA du vendeur attribue le CVE avant la divulgation publique. Dans le canal CRA, la notification arrive d'abord, et l'identifiant suit.
Cette inversion a une conséquence opérationnelle directe. La fenêtre de 24 heures ne laisse pas de temps pour attendre l'attribution d'un CVE. Vos équipes doivent anticiper le scénario où une vulnérabilité exploitée dans l'un de vos produits n'a pas encore d'identifiant MITRE. Dans ce cas, la notification SRP doit décrire la vulnérabilité par ses caractéristiques techniques : composant, version, nature de la faille, impact observé, vecteur d'attaque. L'identifiant CVE sera attribué a posteriori par ENISA.
Trois ajustements pour vos processus
Première action : auditer vos sources de surveillance des vulnérabilités. Vos flux d'intelligence (NVD, feeds CERT-FR, abonnements MITRE) doivent être complétés par l'EUVD. L'API EUVD est accessible publiquement. Certains outils de patch management intègrent déjà ces flux nativement depuis début 2026 ; vérifiez si votre plateforme de gestion des actifs consulte bien les deux registres, et non le seul NVD américain.
Deuxième action : documenter votre processus de notification SRP. Un exercice sur table révèle rapidement les lacunes : que se passe-t-il si une vulnérabilité activement exploitée dans votre produit est détectée à 18h un vendredi ? Qui décide de notifier ? Qui remplit le formulaire SRP ? Qui valide le contenu en moins de 24 heures ? Ces questions appellent des réponses documentées, pas des improvisations. La description technique de la vulnérabilité sans identifiant CVE doit pouvoir être rédigée en moins d'une heure par votre équipe.
Troisième action : mettre à jour vos registres de risques. Si votre outil GRC référence les vulnérabilités par identifiant CVE MITRE uniquement, vous risquez de manquer les entrées EUVD natives. Un rapprochement entre les deux registres doit être intégré dans votre processus de revue mensuelle. Pour les organisations qui ont structuré leur inventaire logiciel autour d'un SBOM connecté à des feeds CVE, l'ajout de l'EUVD s'inscrit dans la continuité de ce travail — l'article SBOM et inventaire logiciel sous NIS2/DORA détaille la mécanique de cet inventaire et ses exigences réglementaires.
Le cas particulier des multinationales
Pour les organisations opérant hors d'Europe, la double gouvernance crée un régime d'identification parallèle. Une vulnérabilité dans un produit distribué en Europe et aux États-Unis peut recevoir un identifiant MITRE via le CNA du vendeur et un identifiant EUVD via le canal européen. Ces deux identifiants coexistent sans hiérarchie formelle entre eux.
Une étude de la Cloud Security Alliance publiée en mai 2026 souligne que les organisations multinationales doivent désormais maintenir une table de correspondance entre les deux systèmes d'identification pour éviter les doublons dans leur registre de risques et les incohérences dans leurs rapports d'audit. Ce travail de mapping est manuel dans la plupart des organisations aujourd'hui. Les éditeurs d'outils de gestion des vulnérabilités ont annoncé des intégrations natives, mais peu sont disponibles à ce jour.
Ce qu'il faut retenir
Le statut de CVE Root d'ENISA n'est pas un détail de gouvernance institutionnelle. Il structure le canal par lequel les vulnérabilités sont identifiées et coordonnées en Europe, et par lequel vos obligations de notification CRA doivent désormais transiter. Les équipes qui traitent encore la gestion des vulnérabilités comme un processus à source unique — MITRE et NVD — devront adapter leurs flux avant que la première notification CRA ne les force à improviser sous contrainte de temps.
La double gouvernance n'est pas une complexité supplémentaire pour sa propre satisfaction. Elle traduit la volonté européenne de ne plus dépendre d'une infrastructure américaine pour coordonner les réponses aux vulnérabilités critiques affectant ses entités. Pour vos équipes, l'enjeu est de transformer cette réalité institutionnelle en processus opérationnel avant qu'un incident réel ne pose la question.