NIS2 : divulgation coordonnée des vulnérabilités

NIS2 traite les vulnérabilités à deux niveaux. L’article 12 impose à chaque État membre de désigner un CSIRT comme coordinateur aux fins de la divulgation coordonnée des vulnérabilités et charge l’ENISA d’une base de données européenne des vulnérabilités, en ligne depuis mai 2025. L’article 21, paragraphe 2, point e), impose aux entités essentielles et importantes d’inclure le traitement et la divulgation des vulnérabilités dans leurs mesures de sécurité.

Ce guide couvre ce que met en place l’article 12, la base de données européenne des vulnérabilités, ce que votre entreprise doit faire, les règles plus strictes pour les fournisseurs numériques et les fabricants, les ajouts nationaux, un modèle de politique, ce que la loi laisse ouvert et une liste de contrôle.

Disposition	Qui est visé	Ce qu’elle exige	Situation en septembre 2026
NIS2, art. 7, par. 2, point c)	États membres	Politique nationale de gestion des vulnérabilités et de promotion de la divulgation coordonnée	Intégrée à chaque stratégie nationale
NIS2, art. 12, par. 1	États membres et leurs CSIRT	Un CSIRT coordinateur qui reçoit les signalements, de manière anonyme sur demande	Requis depuis le 18 octobre 2024
NIS2, art. 12, par. 2	ENISA	Une base de données européenne des vulnérabilités	EUVD lancée le 13 mai 2025
NIS2, art. 21, par. 2, point e)	Entités essentielles et importantes	Traitement et divulgation des vulnérabilités dans le cadre des mesures de sécurité	Par le droit national, requis depuis le 18 octobre 2024
Règlement d’exécution 2024/2690, annexe, section 6.10	Cloud, centres de données, MSP, MSSP et autres fournisseurs numériques listés	Surveiller, scanner, corriger les vulnérabilités critiques, procédure de divulgation	En vigueur depuis le 7 novembre 2024
CRA, art. 14	Fabricants de produits comportant des éléments numériques	Signaler les vulnérabilités activement exploitées, d’abord dans les 24 heures	Applicable depuis le 11 septembre 2026
CRA, annexe I, partie II	Fabricants	Politique de divulgation, adresse de contact, nomenclature logicielle	À partir du 11 décembre 2027

Qu’est-ce que la divulgation coordonnée des vulnérabilités au titre de NIS2 ?

Le considérant 58 décrit la divulgation coordonnée des vulnérabilités (CVD) comme un processus structuré : une vulnérabilité est signalée au fabricant ou au fournisseur afin qu’il puisse la diagnostiquer et y remédier « avant que des informations détaillées à ce sujet soient divulguées à des tiers ou au public ». Le considérant renvoie aux normes ISO/IEC 29147 (divulgation) et ISO/IEC 30111 (traitement) pour des orientations. NIS2 ne rend aucune des deux obligatoire.

Que prévoit l’article 12 de NIS2 ?

L’article 12 s’adresse aux États membres et à l’ENISA, pas aux entreprises.

Un CSIRT comme coordinateur

Chaque État membre doit désigner l’un de ses CSIRT comme coordinateur. Si nécessaire, celui-ci fait office d’« intermédiaire de confiance » entre la personne qui signale une vulnérabilité et le fabricant ou le fournisseur concerné. Ses missions sont les suivantes :

identifier et contacter les entités concernées ;
assister les personnes qui signalent une vulnérabilité ;
négocier les calendriers de divulgation et gérer les vulnérabilités qui touchent plusieurs entités.

Toute personne doit pouvoir faire un signalement au coordinateur, de manière anonyme si elle le demande, et le coordinateur doit assurer un suivi diligent. Lorsqu’une vulnérabilité pourrait avoir un impact important dans plus d’un État membre, les coordinateurs coopèrent, le cas échéant, au sein du réseau des CSIRT. La place du coordinateur parmi les organismes nationaux est décrite dans l’architecture institutionnelle de NIS2. L’article 7, paragraphe 2, point c), ajoute que chaque stratégie nationale doit comprendre une politique de gestion des vulnérabilités qui promeut et facilite la divulgation coordonnée.

Ce que l’article 12 ne fait pas

Il ne fixe aucun délai de divulgation : les calendriers se négocient. Il ne crée aucune obligation pour votre entreprise de signaler des vulnérabilités : la notification obligatoire prévue à l’article 23 concerne les incidents importants. Il ne confère pas non plus d’immunité juridique aux chercheurs. Le considérant 60 se contente d’encourager les États membres à adopter des lignes directrices sur la non-poursuite des chercheurs en sécurité de l’information et sur une exemption de responsabilité civile. C’est le droit national qui décide.

Qu’est-ce que la base de données européenne des vulnérabilités (EUVD) ?

L’article 12, paragraphe 2, impose à l’ENISA de développer et de tenir à jour une base de données européenne des vulnérabilités. Les entités, qu’elles relèvent ou non du champ d’application de NIS2, et leurs fournisseurs peuvent y enregistrer, à titre volontaire, des vulnérabilités connues du public, et toutes les parties prenantes y ont accès. Les entrées décrivent la vulnérabilité, les produits ou services concernés et la gravité, ainsi que les correctifs disponibles ou, à défaut, les recommandations d’atténuation des autorités ou des CSIRT.

L’ENISA l’a lancée sous le nom d’EUVD le 13 mai 2025. Elle agrège les enregistrements CVE, les avis de sécurité des fournisseurs, le catalogue Known Exploited Vulnerabilities de la CISA et les informations des CSIRT nationaux, avec des tableaux de bord pour les vulnérabilités critiques, exploitées et coordonnées par l’UE. Le considérant 63 demande à l’ENISA d’étudier une coopération étroite avec le système CVE plutôt que de le dupliquer. Pour la plupart des entreprises, c’est une source à surveiller, pas un registre où déposer des déclarations.

Que doit faire votre entreprise face aux vulnérabilités au titre de NIS2 ?

L’article 21, paragraphe 2, point e), cite parmi les mesures minimales « la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités ». Il s’applique aussi bien aux entités essentielles qu’aux entités importantes, en proportion de leur risque, et n’entre pas davantage dans le détail. Le considérant 58 en explique l’intention : les entités qui mettent au point ou administrent des systèmes « devraient » établir des procédures pour gérer les vulnérabilités, et les fabricants et fournisseurs « devraient » pouvoir recevoir des informations sur les vulnérabilités communiquées par des tiers. La mesure comporte donc deux volets.

Traitement : trouver et corriger vos propres vulnérabilités

Une approche raisonnable, que les auditeurs connaissent grâce à la mesure A.8.8 de l’ISO 27001, consiste à :

tenir un inventaire des systèmes et des logiciels, y compris tout ce qui est exposé à internet ;
scanner à intervalles planifiés et suivre les avis des fournisseurs, des CSIRT et de l’EUVD ;
évaluer chaque constat selon sa gravité et son exposition, y compris s’il est exploité ;
fixer des délais de correction par niveau, par exemple quelques jours pour les failles critiques exploitées et quelques semaines pour le reste ;
suivre chaque exception avec un responsable, un motif et une date de fin.

Ces délais relèvent de la pratique. NIS2 ne fixe aucun délai de correction.

Divulgation : permettre aux autres de vous alerter

Des chercheurs, des clients et des CSIRT trouveront des vulnérabilités dans vos systèmes. En pratique, leur permettre de vous joindre suppose :

une courte politique de divulgation publiée ;
un fichier security.txt à l’adresse /.well-known/security.txt (RFC 9116), dont les seuls champs obligatoires sont Contact et Expires ;
une boîte de réception surveillée, avec un responsable nommé et un suppléant ;
un tri dans un délai convenu, et un enregistrement de chaque signalement ;
si vous développez des logiciels, des avis de sécurité lorsque vous publiez un correctif.

Quelles règles plus strictes pour les fournisseurs numériques ?

Pour les fournisseurs DNS, les registres de TLD, les fournisseurs de services d’informatique en nuage, de centres de données et de CDN, les fournisseurs de services gérés et de services de sécurité gérés, les places de marché en ligne, les moteurs de recherche, les réseaux sociaux et les prestataires de services de confiance, le règlement d’exécution (UE) 2024/2690 entre dans le détail. La section 6.10 de son annexe leur impose de :

surveiller les informations sur les vulnérabilités, par exemple les annonces des CSIRT et des autorités et les informations des fournisseurs ;
le cas échéant, scanner à intervalles planifiés et conserver la preuve des résultats ;
traiter sans retard injustifié les vulnérabilités critiques pour leurs activités ;
aligner le traitement des vulnérabilités sur la gestion des changements, des correctifs, des risques et des incidents ;
établir une procédure de divulgation des vulnérabilités conforme à la politique nationale applicable en matière de divulgation coordonnée des vulnérabilités.

Lorsque l’impact le justifie, ils planifient et mettent en œuvre des mesures d’atténuation ; sinon, ils documentent pourquoi aucune correction n’est nécessaire. La section 6.6 ajoute que les correctifs sont appliqués dans un délai raisonnable, testés et obtenus auprès de sources fiables, et qu’une décision de ne pas appliquer un correctif est justifiée par écrit. Les autres entités ne sont pas liées par ce règlement, mais il offre une lecture officielle et concrète de l’article 21, paragraphe 2, point e), comme le montre notre article sur les dix mesures de l’article 21.

Qu’ajoute le règlement sur la cyberrésilience pour les fabricants ?

Si vous mettez sur le marché de l’UE des produits comportant des éléments numériques (matériels ou logiciels), le règlement sur la cyberrésilience (règlement (UE) 2024/2847) s’applique, sous réserve de certaines exclusions sectorielles, que vous releviez ou non de NIS2.

Depuis le 11 septembre 2026, l’article 14 impose aux fabricants de signaler les vulnérabilités activement exploitées dans leurs produits : alerte précoce dans les 24 heures, notification dans les 72 heures, rapport final dans les 14 jours suivant la mise à disposition d’une mesure corrective ou d’atténuation. Les signalements passent par la plateforme unique de signalement de l’ENISA et parviennent au CSIRT désigné comme coordinateur au titre de l’article 12 de NIS2, ainsi qu’à l’ENISA. Voir les obligations de signalement du CRA.
À partir du 11 décembre 2027, l’article 13, paragraphe 8, exige un traitement efficace des vulnérabilités pendant la période d’assistance, conformément à l’annexe I, partie II : une nomenclature logicielle, une politique de divulgation coordonnée des vulnérabilités, une adresse de contact pour les signalements et la divulgation publique des vulnérabilités corrigées.

Vos clients soumis à NIS2 vous poseront la question. L’article 21, paragraphe 3, leur impose de tenir compte de la qualité des produits et du développement sécurisé de leurs fournisseurs directs, comme l’explique notre article sur la sécurité de la chaîne d’approvisionnement NIS2.

Les lois nationales vont-elles plus loin ?

Certaines, oui. Selon le Centre pour la Cybersécurité Belgique (CCB), la loi belge NIS2 fait d’une politique de divulgation coordonnée des vulnérabilités une onzième mesure pour les entités essentielles et importantes, à côté des dix mesures de la directive. Les détails figurent dans notre article sur la loi belge NIS2. Vérifiez votre propre droit national et lisez votre politique nationale de divulgation coordonnée des vulnérabilités : le règlement d’exécution 2024/2690 y renvoie directement.

Modèle de politique de divulgation des vulnérabilités

Une politique n’a pas besoin d’être longue. Cette version minimale couvre ce que les chercheurs attendent. Les délais de réponse sont des exemples, pas des exigences légales ; faites vérifier la formulation juridique par un avocat.

POLITIQUE DE DIVULGATION DES VULNÉRABILITÉS   [Entreprise]   v1.0, [date]

Périmètre
  Inclus :        [domaines, applications, produits et versions]
  Exclus :        services tiers, déni de service,
                  ingénierie sociale, tests physiques

Comment signaler
  E-mail :        security@[domaine]   (clé de chiffrement : [URL])
  security.txt :  https://[domaine]/.well-known/security.txt
  À inclure :     actif concerné, étapes de reproduction, impact
  Les signalements anonymes sont acceptés.

Nos engagements
  Accuser réception de votre signalement sous [3] jours ouvrés
  Fournir une première évaluation sous [10] jours ouvrés
  Vous tenir informé jusqu'à la correction
  Convenir avec vous d'une date de divulgation, normalement
    sous [90] jours
  Vous citer, si vous le souhaitez, une fois le correctif publié

Ce que nous vous demandons
  Ne tester que ce qui est nécessaire pour montrer la vulnérabilité
  Ne pas consulter, modifier ni conserver plus de données
    que nécessaire
  Ne pas perturber les services ni nuire aux utilisateurs
  Ne rien divulguer publiquement avant la date convenue

Coordination
  Si nous ne répondons pas, ou si plusieurs fournisseurs sont
  concernés, vous pouvez contacter le CSIRT national désigné
  comme coordinateur : [nom, URL]

Aspects juridiques
  Nous n'engagerons aucune action en justice pour une recherche
  menée de bonne foi dans le respect de cette politique.
  [À vérifier au regard du droit national.]

Que laisse ouvert la loi ?

Le texte juridique s’en tient à la formule « le traitement et la divulgation des vulnérabilités ». Il ne dit ni à quelle vitesse, ni avec quelle rigueur, ni comment le prouver. Trois lacunes apparaissent en pratique.

La boîte de réception. Une politique publiée ne vaut rien si security@ aboutit dans une boîte partagée que personne ne lit. Quelqu’un doit être responsable de la réception et savoir reconnaître quand un signalement est en réalité un incident.

L’inventaire. Vous ne pouvez dire à personne si une nouvelle CVE vous concerne sans savoir quels systèmes et quelles versions vous exploitez. Les listes d’actifs couvrent généralement les serveurs et oublient les appliances, les intégrations SaaS et les anciens sous-domaines.

Les preuves. Une autorité qui s’intéresse à l’article 21, paragraphe 2, point e), veut voir des résultats de scans, des délais de correction comparés à vos propres objectifs, et les exceptions que vous avez acceptées, avec leur justification. Collecté à la main une fois par an, ce dossier est périmé dès sa constitution. Alimenté en continu par les scanners, les outils de protection des postes et la gestion des tickets, avec une personne qui examine les exceptions, il montre que la mesure est réellement appliquée. C’est le principe de la plateforme CloudSoul : une collecte automatisée des preuves, avec une expertise humaine dans la boucle. Un audit de sécurité montre où en est aujourd’hui votre processus de gestion des vulnérabilités, et le programme complet est présenté sur la page conformité NIS2.

Liste de contrôle : divulgation des vulnérabilités NIS2

Publiez une politique de divulgation et un fichier security.txt avec une date Expires à jour.
Nommez un responsable et un suppléant pour la boîte de réception sécurité, et fixez un délai de réponse.
Tenez un inventaire des systèmes et des logiciels, y compris les actifs exposés à internet.
Suivez les avis de vos fournisseurs, de votre CSIRT national et de l’EUVD.
Scannez à intervalles planifiés et conservez les résultats.
Fixez des délais de correction selon la gravité et consignez chaque exception avec son motif.
Identifiez le CSIRT coordinateur de votre pays et lisez la politique nationale de divulgation coordonnée des vulnérabilités.
Si vous fabriquez des produits, respectez dès maintenant les obligations de signalement du CRA et préparez les règles de divulgation du CRA applicables à partir de décembre 2027.

Sources

Directive (UE) 2022/2555 (NIS2), articles 7, 12, 21 et 23 et considérants 58 à 63, EUR-Lex ; texte des articles également sur nis-2-directive.com.
Règlement d’exécution (UE) 2024/2690 de la Commission, sections 6.6 et 6.10 de l’annexe, EUR-Lex.
Règlement (UE) 2024/2847 (règlement sur la cyberrésilience), articles 13, 14 et 71 et annexe I, partie II, EUR-Lex.
ENISA, Consultez la base de données européenne des vulnérabilités pour renforcer votre sécurité numérique, 13 mai 2025, et l’EUVD.
Centre pour la Cybersécurité Belgique, Obligations NIS2.
IETF, RFC 9116 : un format de fichier pour faciliter la divulgation des vulnérabilités de sécurité, avril 2022.
ISO, ISO/IEC 29147:2018, divulgation des vulnérabilités et ISO/IEC 30111:2019, processus de traitement des vulnérabilités.

Questions fréquentes

Que prévoit l'article 12 de NIS2 ?

Chaque État membre doit désigner l'un de ses CSIRT comme coordinateur aux fins de la divulgation coordonnée des vulnérabilités. Celui-ci fait office d'intermédiaire de confiance entre les personnes qui signalent des vulnérabilités et les fabricants ou fournisseurs concernés. L'article 12, paragraphe 2, impose à l'ENISA de tenir une base de données européenne des vulnérabilités, lancée sous le nom d'EUVD le 13 mai 2025.

Une politique de divulgation des vulnérabilités est-elle obligatoire au titre de NIS2 ?

L'article 21, paragraphe 2, point e), impose aux entités essentielles et importantes d'inclure le traitement et la divulgation des vulnérabilités dans leurs mesures de sécurité, sans prescrire de document. Les fournisseurs numériques couverts par le règlement d'exécution (UE) 2024/2690 doivent établir une procédure de divulgation, et certaines lois nationales, comme la loi belge, font d'une politique de divulgation coordonnée des vulnérabilités une mesure à part entière.

Les entreprises doivent-elles signaler les vulnérabilités au CSIRT au titre de NIS2 ?

Non. L'article 23 de NIS2 impose de notifier les incidents importants, pas les vulnérabilités. Les fabricants de produits comportant des éléments numériques doivent en revanche signaler les vulnérabilités activement exploitées au titre de l'article 14 du règlement sur la cyberrésilience, applicable depuis le 11 septembre 2026.

NIS2 protège-t-elle les hackers éthiques contre les poursuites ?

Pas directement. Le considérant 60 encourage les États membres à adopter des lignes directrices sur la non-poursuite des chercheurs en sécurité de l'information et une exemption de responsabilité civile. La protection d'un chercheur dépend du droit national.

Qu'est-ce que l'EUVD ?

La base de données européenne des vulnérabilités, que l'ENISA gère au titre de l'article 12, paragraphe 2, de NIS2. Lancée le 13 mai 2025, elle agrège des sources telles que les enregistrements CVE, les avis de sécurité des fournisseurs et les CSIRT nationaux. L'enregistrement par les entités est volontaire.

Divulgation coordonnée des vulnérabilités NIS2 : ce que met en place l'article 12 et ce que votre entreprise doit faire face aux vulnérabilités