Le 11 septembre 2026, les obligations de notification du Cyber Resilience Act entrent en vigueur pour les fabricants de produits comportant des éléments numériques. La plupart des équipes sécurité se sont préparées à ce délai. Moins nombreuses sont celles qui ont intégré dans leurs processus la base européenne de vulnérabilités, l'EUVD, que l'ENISA opère depuis mai 2025. Ces deux dispositifs coexistent, répondent à des finalités différentes et créent ensemble un angle mort dans les processus de patch management qui n'ont pas été mis à jour.
L'EUVD n'est pas le NVD européen
L'European Union Vulnerability Database a été lancée en avril 2025 et est opérationnelle depuis mai 2025. Elle est mandatée par l'article 12 de la directive NIS2, qui charge l'ENISA de constituer une base centralisée, alimentée par les CSIRT nationaux membres, les éditeurs et les bases de données partenaires. Elle publie ses propres identifiants (EUVD-AAAA-XXXXX) en complément des CVE, et dispose d'une API publique documentée.
La comparaison avec le NVD américain s'arrête là. L'EUVD ne se substitue pas au programme CVE géré par MITRE : elle en est un référentiel aval. L'ENISA est devenue en 2026 une CVE Program Root, ce qui lui permet d'attribuer directement des CVE IDs pour les vulnérabilités remontées par les CSIRT membres. Mais l'EUVD publie ses propres métadonnées d'exploitation spécifiques au périmètre européen. Concrètement, une vulnérabilité exploitée activement en Allemagne par un groupe APT ciblant le secteur de l'énergie peut recevoir un indicateur de menace active dans l'EUVD plusieurs heures avant que le NVD ne mette à jour son entrée.
Deux outils distincts, une confusion fréquente
Le Cyber Resilience Act prévoit une plateforme de signalement unique, le Single Reporting Platform (SRP), opérée par l'ENISA. C'est via le SRP que les fabricants notifient une vulnérabilité exploitée activement dans les 24 heures suivant sa découverte. Le SRP est l'outil de notification réglementaire. L'EUVD est l'outil de consultation et de référencement des vulnérabilités connues.
Ces deux outils coexistent sans se substituer l'un à l'autre. Consulter le SRP ne remplace pas une interrogation de l'EUVD. Notifier via le SRP ne garantit pas que votre processus de patch management est aligné sur les données de l'EUVD. En pratique, de nombreuses équipes opèrent encore avec un flux NVD comme source principale de veille sur les vulnérabilités, complété éventuellement par le flux MITRE CVE, et n'ont pas paramétré d'interrogation de l'API EUVD dans leurs outils SIEM ou de gestion des actifs. L'article sur les obligations de notification du Cyber Resilience Act détaille la mécanique du SRP et les délais applicables.
Ce que l'EUVD apporte que le NVD n'offre pas
Trois différences opérationnelles méritent attention.
D'abord, les données d'exploitation locale. L'EUVD agrège les signalements des CSIRT des 27 États membres et produit un indicateur de statut d'exploitation — non exploitée, exploitation connue, exploitation active — qui reflète la réalité du terrain européen. Pour un éditeur dont les clients sont majoritairement européens, cette granularité change les priorités de correctifs.
Ensuite, les identifiants EUVD. Certaines vulnérabilités reçoivent un identifiant EUVD avant que le CVE correspondant soit publié ou finalisé, notamment pour des failles signalées par des CSIRT membres dans des logiciels peu couverts par les CNA américains. Ignorer ce flux revient à dépendre d'une couverture incomplète pour les produits logiciels utilisés principalement en Europe.
Enfin, l'alignement NIS2. L'article 12 de NIS2 impose aux entités essentielles et importantes de déclarer les vulnérabilités affectant leurs systèmes via les CSIRT compétents. L'EUVD est le référentiel que ces CSIRT alimentent et consultent. Ne pas y être connecté opérationnellement, c'est traiter les incidents en dehors du référentiel que votre autorité de supervision utilisera lors d'un audit.
Un exemple concret : le décalage de signal
En juillet 2026, une faille dans un composant de gestion de session d'une bibliothèque open source répandue dans les applications web a été signalée par le CERT-FR à l'ANSSI, puis transmise à l'EUVD avec un indicateur "exploitation active". La vulnérabilité avait reçu son identifiant CVE deux jours plus tôt, mais le NVD n'avait pas encore intégré le vecteur d'attaque complet. Les équipes qui ne consultaient que le NVD ont priorisé d'autres correctifs pendant 48 heures, pendant lesquelles une partie de leurs clients en production était exposée.
Ce décalage n'est pas exceptionnel. Il illustre un principe structurel : l'EUVD est alimentée par un réseau de CSIRT qui observent les attaques en temps réel sur le territoire européen. Le NVD est alimenté par les éditeurs et les chercheurs, avec un processus de validation qui introduit mécaniquement un délai.
Trois ajustements à engager maintenant
Paramétrer une interrogation automatique de l'API EUVD. L'EUVD propose une API REST documentée sur euvd.enisa.europa.eu. Elle peut être interrogée sur la base d'une liste de composants (CPE, PURL, CVE) et renvoie le statut d'exploitation ainsi que les métadonnées associées. Si votre outil de gestion de correctifs ou votre SIEM supporte les flux personnalisés, l'intégration ne demande généralement pas plus d'une journée de développement.
Distinguer les flux dans votre politique de priorisation. Vos règles de priorisation distinguent probablement les CVSS critiques des autres. Ajoutez un critère "exploitation active signalée dans l'EUVD" comme facteur d'escalade, indépendamment du score CVSS. Selon une étude ENISA de 2025, 34 % des vulnérabilités exploitées activement dans le périmètre européen ont un CVSS inférieur à 7,0 : le score seul ne suffit pas à déclencher la priorité maximale.
Documenter la couverture EUVD dans votre registre de conformité NIS2. Lors d'un audit NIS2, la question de la gestion des vulnérabilités portera sur vos sources de veille et votre capacité à démontrer une réactivité proportionnée au statut d'exploitation réel. Un tableau de bord qui croise les données EUVD avec votre inventaire SBOM constitue une réponse solide à cette exigence.
Une fenêtre de dix-sept jours
Le 11 septembre 2026, les obligations de notification du CRA entrent en vigueur. Les fabricants qui n'ont pas encore complété leur processus de signalement via le SRP ont dix-sept jours pour le faire. Ceux qui ne consultent pas encore l'EUVD dans leur flux de veille ont la même fenêtre pour paramétrer l'intégration. Ces deux chantiers sont distincts mais complémentaires : le premier répond à une obligation de signalement, le second à une obligation de surveillance et de réactivité.
L'ENISA a publié, dans ses statistiques du premier semestre 2026, plus de 14 000 enregistrements de vulnérabilités dans l'EUVD depuis son lancement. Le rythme s'accélère. Attendre que le NVD relaie systématiquement ces données avec le même niveau de détail revient à accepter une latence structurelle dans votre gestion des risques, précisément au moment où les autorités de supervision disposent d'un référentiel qui, lui, ne souffre pas de ce délai.