Leader dans le secteur des formations en cybersécurité.
Frédéric Schilton · 9 septembre 2026 · Lecture 6 min
À retenir
À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent déclarer les vulnérabilités activement exploitées et les incidents graves.
La découverte d’une vulnérabilité ne signifie pas qu’elle est activement exploitée. Une vulnérabilité peut être connue et présenter un risque important sans qu’un attaquant ne l’utilise réellement.
Pour parler d’exploitation active, il faut constater qu’un attaquant utilise effectivement la vulnérabilité. Par exemple : des traces d’attaque dans les journaux, une compromission constatée ou des attaques observées sur des systèmes en production.
Un PoC ou un exploit disponible ne suffit donc pas à lui seul. De même, un score CVSS élevé indique la gravité potentielle de la vulnérabilité, mais ne prouve pas qu’elle est exploitée.
Le délai de déclaration commence lorsque le fabricant a connaissance de l’exploitation, et non simplement lorsqu’il découvre ou reçoit l’information sur la vulnérabilité.
Une seule déclaration est nécessaire. La plateforme de l’ENISA assure ensuite la transmission aux CSIRT concernés et aux autorités de surveillance du marché.
Les délais sont connus. Leur point de départ l’est moins.
À partir du 11 septembre 2026, un fabricant qui a connaissance d’une vulnérabilité activement exploitée dans son produit dispose de vingt-quatre heures pour envoyer une alerte précoce, de soixante-douze heures pour une notification argumentée, et de quatorze jours après la mise à disposition d’un correctif pour son rapport final. Ces trois délais sont désormais bien documentés.
Reste l’autre moitié de la question. Une équipe qui découvre une vulnérabilité un vendredi soir ne se demande pas combien de temps elle a. Elle se demande si le compteur vient de démarrer.
Cet article traite de cette question-là, et de ce qui se passe une fois la déclaration envoyée. Il ne reprend pas les obligations générales de conformité, qui s’appliqueront le 11 décembre 2027 et relèvent d’un autre calendrier.
Ce qui déclenche l’obligation, et ce qui ne la déclenche pas
Le règlement définit la vulnérabilité activement exploitée à son article 3(42) : une vulnérabilité pour laquelle il existe des éléments montrant qu’un acteur malveillant l’exploite actuellement. Le mot qui porte tout le poids est actuellement.
Reste à savoir ce que cela donne sur des cas réels. Voici les sept situations que nous rencontrons le plus souvent.
Ce qui met le compteur en marche, et ce qui le laisse à l’arrêt. Sources : règlement (UE) 2024/2847, articles 3(42), 3(44), 14 et 69.
Quatre situations qui ne déclenchent rien
Une vulnérabilité découverte en interne, par vos équipes ou par un audit. Tant qu’aucun élément ne montre qu’elle est exploitée, elle relève de votre processus de correction habituel, pas du signalement réglementaire.
Une preuve de concept publiée. Un code de démonstration circulant sur un dépôt public établit l’exploitabilité, pas l’exploitation. La distinction est ténue et elle est déterminante.
Un score de criticité élevé. Un CVSS à 9,8 mesure l’impact potentiel sur un produit donné. Il ne dit rien de l’usage qui en est fait, ni du nombre d’organisations réellement visées.
Un incident sans impact sur la sécurité du produit. L’article 3(44) vise les incidents qui affectent gravement la disponibilité, l’authenticité, l’intégrité ou la confidentialité du produit. Une panne d’hébergement sans compromission n’entre pas dans ce champ.
Trois situations où le compteur démarre
Une exploitation observée chez un client. Un renseignement sur la menace documenté et attribuable. Un signalement externe que vous avez vérifié.
Dans les trois cas, l’élément commun est la preuve d’une utilisation contre un système en production, pas en laboratoire.
Le vrai piège n’est pas la définition, c’est la date
Le règlement fait courir les vingt-quatre heures à partir du moment où le fabricant a connaissance de l’exploitation. Il ne définit pas ce que « avoir connaissance » veut dire à l’échelle d’une organisation.
Est-ce le moment où un analyste voit passer une alerte dans un tableau de bord ? Celui où il la qualifie ? Celui où son responsable en est informé ? Celui où la direction technique valide l’analyse ?
Entre le premier et le dernier, il peut s’écouler deux jours. Sur une fenêtre de vingt-quatre heures, cet écart n’est pas un détail de procédure : c’est la différence entre une déclaration dans les temps et un manquement.
Les orientations de la Commission européenne du 27 juillet 2026, adoptées sous la référence C(2026) 5252, confirment que le délai court à partir de la prise de connaissance et non de la confirmation. Elles ne sont pas contraignantes, seule la Cour de justice pouvant interpréter le règlement de façon définitive. Et elles ne disent pas à quel niveau d’une organisation cette connaissance est réputée acquise.
La décision à prendre avant vendredi. Écrire, en une phrase, le moment précis qui fait démarrer votre compteur, et le nom de la personne qui en est juge.
Ce n’est pas un travail juridique. C’est une décision d’organisation, et elle se prend en réunion, pas dans un texte.
Ce qui se passe une fois la déclaration envoyée
La déclaration passe par la plateforme unique gérée par l’ENISA. Le principe est celui d’une saisie unique : connexion, choix du CSIRT national, saisie et envoi.
Le CSIRT à qui vous déclarez est celui de votre lieu d’établissement principal. Pour un groupe présent dans plusieurs États membres, c’est le siège qui détermine l’interlocuteur, et l’article 14(7) précise les cas particuliers.
Ce CSIRT diffuse ensuite l’information sans délai aux CSIRT des autres États membres où le produit est commercialisé. L’ENISA reçoit la notification simultanément. Les CSIRT partagent enfin certains éléments avec leurs autorités de surveillance du marché, qui sont chargées de faire appliquer le règlement.
Autrement dit, vous ne contactez pas chaque autorité une par une, et vous ne choisissez pas non plus qui reçoit quoi.
Le circuit d’une déclaration, de la saisie aux autorités de surveillance. Source : ENISA, fiche d’information sur la plateforme de déclaration unique du CRA.
Une exception existe. Dans des circonstances exceptionnelles, l’article 16(2) permet de retarder cette diffusion, selon des conditions précisées par le règlement délégué (UE) 2026/881. C’est une soupape encadrée, pas une façon de gagner du temps.
Sur-déclarer n’est pas la solution de facilité
Face à l’incertitude, le réflexe est de tout envoyer. Il se comprend, et il coûte plus qu’il n’y paraît.
Chaque notification part au CSIRT national qui la reçoit, puis à celui de chaque État membre où le produit est commercialisé, et simultanément à l’ENISA. Les CSIRT transmettent ensuite certains éléments à leurs autorités de surveillance du marché.
Une déclaration inutile mobilise donc plusieurs autorités sur un non-événement. Répétée, elle affaiblit la crédibilité de vos signalements réels, et elle occupe vos propres équipes au moment où elles devraient corriger.
L’inverse est vrai aussi : attendre un rapport d’expertise complet avant d’escalader consomme l’essentiel de la fenêtre. Le processus prévoit précisément une déclaration initiale incomplète, enrichie ensuite. Une alerte précoce n’est pas un rapport.
Les cas limites
Les produits anciens sont concernés. Le règlement prévoit un régime transitoire : les produits mis sur le marché avant le 11 décembre 2027 échappent aux obligations générales de conformité, sauf modification substantielle. Les obligations de signalement, elles, font exception à ce régime et s’appliquent. Une version livrée en 2018 et toujours utilisée chez un client entre dans le champ.
Les responsables de logiciels libres aussi. Le règlement crée un statut d’intendant de logiciel open source, avec des obligations adaptées, dès lors qu’ils participent au développement d’un produit comportant des éléments numériques.
Ce que ça demande à une équipe
Ces décisions ne se prennent pas dans l’urgence. Elles reposent sur trois compétences, dont aucune n’est juridique.
Qualifier une exploitation. Savoir distinguer un indice d’exploitabilité d’une preuve d’exploitation, à partir de sources de renseignement, de journaux clients ou d’un signalement externe. C’est un travail d’analyste, pas de conformité.
Décider vite avec une information incomplète. La fenêtre de vingt-quatre heures interdit d’attendre la certitude. Cela s’apprend en exercice, pas en réunion.
Tenir un registre produit exploitable. Nom commercial, versions diffusées, responsable interne, composants critiques, territoires de distribution, statut de support. Sans lui, la question « quels clients sont concernés » reste sans réponse pendant les heures qui comptent.
Comment nous formons sur ces sujets
Ces compétences sont travaillées dans notre formation Cyber Resilience Act, sécurité produit et gestion des vulnérabilités, ainsi que dans nos sessions sur les premiers réflexes en cas d’incident et sur la gestion de crise cyber. Elles combinent la lecture du règlement, la qualification de cas réels et la mise en situation sur les délais.
ACG CyberAcademy est l’organisme de formation d’ACG Cybersecurity, certifié Qualiopi au titre des actions de formation.
Pour aller plus loin
La fiche de l’ENISA sur la plateforme de déclaration unique décrit le processus en deux pages et se télécharge librement. Les orientations de la Commission européenne du 27 juillet 2026, référence C(2026) 5252, contiennent 67 exemples pratiques et des arbres de décision. Elles ne sont pas contraignantes. Ces deux documents suffisent à préparer une première réunion en interne. Si un cas vous laisse dans le doute, écrivez à formation@acgcybersecurity.fr.
Questions fréquentes
Non, tant qu’aucun élément ne montre qu’elle est activement exploitée. Elle relève du processus de correction habituel.
Non. Elle établit qu’une exploitation est possible, pas qu’elle a lieu. Le règlement vise l’exploitation constatée contre un système en production.
À partir du moment où le fabricant a connaissance de l’exploitation, et non de sa confirmation, comme le précisent les orientations de la Commission du 27 juillet 2026. Ni le règlement ni ces orientations ne disent à quel niveau d’une organisation cette connaissance est réputée acquise : c’est à chaque entreprise de le fixer et de désigner qui en juge.
Oui pour le signalement. Le régime transitoire du règlement dispense les produits mis sur le marché avant le 11 décembre 2027 des obligations générales de conformité, sauf modification substantielle, mais les obligations de signalement en sont expressément exclues et s’appliquent.
La notification est diffusée aux CSIRT concernés et à l’ENISA, puis partagée avec les autorités de surveillance du marché. Sur-déclarer mobilise plusieurs autorités et affaiblit la portée de vos signalements réels.
Consultant Senior cybersécurité chez ACG Cybersecurity. Spécialiste de la gouvernance, des risques et de la conformité, il accompagne les organisations sur NIS2, DORA et le Cyber Resilience Act.
Publié le 9 septembre 2026 · Mis à jour le 9 septembre 2026 · Sources vérifiées le 10 septembre 2026.
À retenir
À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent déclarer les vulnérabilités activement exploitées et les incidents graves.
La découverte d’une vulnérabilité ne signifie pas qu’elle est activement exploitée. Une vulnérabilité peut être connue et présenter un risque important sans qu’un attaquant ne l’utilise réellement.
Pour parler d’exploitation active, il faut constater qu’un attaquant utilise effectivement la vulnérabilité. Par exemple : des traces d’attaque dans les journaux, une compromission constatée ou des attaques observées sur des systèmes en production.
Un PoC ou un exploit disponible ne suffit donc pas à lui seul. De même, un score CVSS élevé indique la gravité potentielle de la vulnérabilité, mais ne prouve pas qu’elle est exploitée.
Le délai de déclaration commence lorsque le fabricant a connaissance de l’exploitation, et non simplement lorsqu’il découvre ou reçoit l’information sur la vulnérabilité.
Une seule déclaration est nécessaire. La plateforme de l’ENISA assure ensuite la transmission aux CSIRT concernés et aux autorités de surveillance du marché.
Les délais sont connus. Leur point de départ l’est moins.
À partir du 11 septembre 2026, un fabricant qui a connaissance d’une vulnérabilité activement exploitée dans son produit dispose de vingt-quatre heures pour envoyer une alerte précoce, de soixante-douze heures pour une notification argumentée, et de quatorze jours après la mise à disposition d’un correctif pour son rapport final. Ces trois délais sont désormais bien documentés.
Reste l’autre moitié de la question. Une équipe qui découvre une vulnérabilité un vendredi soir ne se demande pas combien de temps elle a. Elle se demande si le compteur vient de démarrer.
Cet article traite de cette question-là, et de ce qui se passe une fois la déclaration envoyée. Il ne reprend pas les obligations générales de conformité, qui s’appliqueront le 11 décembre 2027 et relèvent d’un autre calendrier.
Ce qui déclenche l’obligation, et ce qui ne la déclenche pas
Le règlement définit la vulnérabilité activement exploitée à son article 3(42) : une vulnérabilité pour laquelle il existe des éléments montrant qu’un acteur malveillant l’exploite actuellement. Le mot qui porte tout le poids est actuellement.
Reste à savoir ce que cela donne sur des cas réels. Voici les sept situations que nous rencontrons le plus souvent.
Ce qui met le compteur en marche, et ce qui le laisse à l’arrêt. Sources : règlement (UE) 2024/2847, articles 3(42), 3(44), 14 et 69.
Quatre situations qui ne déclenchent rien
Une vulnérabilité découverte en interne, par vos équipes ou par un audit. Tant qu’aucun élément ne montre qu’elle est exploitée, elle relève de votre processus de correction habituel, pas du signalement réglementaire.
Une preuve de concept publiée. Un code de démonstration circulant sur un dépôt public établit l’exploitabilité, pas l’exploitation. La distinction est ténue et elle est déterminante.
Un score de criticité élevé. Un CVSS à 9,8 mesure l’impact potentiel sur un produit donné. Il ne dit rien de l’usage qui en est fait, ni du nombre d’organisations réellement visées.
Un incident sans impact sur la sécurité du produit. L’article 3(44) vise les incidents qui affectent gravement la disponibilité, l’authenticité, l’intégrité ou la confidentialité du produit. Une panne d’hébergement sans compromission n’entre pas dans ce champ.
Trois situations où le compteur démarre
Une exploitation observée chez un client. Un renseignement sur la menace documenté et attribuable. Un signalement externe que vous avez vérifié.
Dans les trois cas, l’élément commun est la preuve d’une utilisation contre un système en production, pas en laboratoire.
Le vrai piège n’est pas la définition, c’est la date
Le règlement fait courir les vingt-quatre heures à partir du moment où le fabricant a connaissance de l’exploitation. Il ne définit pas ce que « avoir connaissance » veut dire à l’échelle d’une organisation.
Est-ce le moment où un analyste voit passer une alerte dans un tableau de bord ? Celui où il la qualifie ? Celui où son responsable en est informé ? Celui où la direction technique valide l’analyse ?
Entre le premier et le dernier, il peut s’écouler deux jours. Sur une fenêtre de vingt-quatre heures, cet écart n’est pas un détail de procédure : c’est la différence entre une déclaration dans les temps et un manquement.
Les orientations de la Commission européenne du 27 juillet 2026, adoptées sous la référence C(2026) 5252, confirment que le délai court à partir de la prise de connaissance et non de la confirmation. Elles ne sont pas contraignantes, seule la Cour de justice pouvant interpréter le règlement de façon définitive. Et elles ne disent pas à quel niveau d’une organisation cette connaissance est réputée acquise.
La décision à prendre avant vendredi. Écrire, en une phrase, le moment précis qui fait démarrer votre compteur, et le nom de la personne qui en est juge.
Ce n’est pas un travail juridique. C’est une décision d’organisation, et elle se prend en réunion, pas dans un texte.
Ce qui se passe une fois la déclaration envoyée
La déclaration passe par la plateforme unique gérée par l’ENISA. Le principe est celui d’une saisie unique : connexion, choix du CSIRT national, saisie et envoi.
Le CSIRT à qui vous déclarez est celui de votre lieu d’établissement principal. Pour un groupe présent dans plusieurs États membres, c’est le siège qui détermine l’interlocuteur, et l’article 14(7) précise les cas particuliers.
Ce CSIRT diffuse ensuite l’information sans délai aux CSIRT des autres États membres où le produit est commercialisé. L’ENISA reçoit la notification simultanément. Les CSIRT partagent enfin certains éléments avec leurs autorités de surveillance du marché, qui sont chargées de faire appliquer le règlement.
Autrement dit, vous ne contactez pas chaque autorité une par une, et vous ne choisissez pas non plus qui reçoit quoi.
Le circuit d’une déclaration, de la saisie aux autorités de surveillance. Source : ENISA, fiche d’information sur la plateforme de déclaration unique du CRA.
Une exception existe. Dans des circonstances exceptionnelles, l’article 16(2) permet de retarder cette diffusion, selon des conditions précisées par le règlement délégué (UE) 2026/881. C’est une soupape encadrée, pas une façon de gagner du temps.
Sur-déclarer n’est pas la solution de facilité
Face à l’incertitude, le réflexe est de tout envoyer. Il se comprend, et il coûte plus qu’il n’y paraît.
Chaque notification part au CSIRT national qui la reçoit, puis à celui de chaque État membre où le produit est commercialisé, et simultanément à l’ENISA. Les CSIRT transmettent ensuite certains éléments à leurs autorités de surveillance du marché.
Une déclaration inutile mobilise donc plusieurs autorités sur un non-événement. Répétée, elle affaiblit la crédibilité de vos signalements réels, et elle occupe vos propres équipes au moment où elles devraient corriger.
L’inverse est vrai aussi : attendre un rapport d’expertise complet avant d’escalader consomme l’essentiel de la fenêtre. Le processus prévoit précisément une déclaration initiale incomplète, enrichie ensuite. Une alerte précoce n’est pas un rapport.
Les cas limites
Les produits anciens sont concernés. Le règlement prévoit un régime transitoire : les produits mis sur le marché avant le 11 décembre 2027 échappent aux obligations générales de conformité, sauf modification substantielle. Les obligations de signalement, elles, font exception à ce régime et s’appliquent. Une version livrée en 2018 et toujours utilisée chez un client entre dans le champ.
Les responsables de logiciels libres aussi. Le règlement crée un statut d’intendant de logiciel open source, avec des obligations adaptées, dès lors qu’ils participent au développement d’un produit comportant des éléments numériques.
Ce que ça demande à une équipe
Ces décisions ne se prennent pas dans l’urgence. Elles reposent sur trois compétences, dont aucune n’est juridique.
Qualifier une exploitation. Savoir distinguer un indice d’exploitabilité d’une preuve d’exploitation, à partir de sources de renseignement, de journaux clients ou d’un signalement externe. C’est un travail d’analyste, pas de conformité.
Décider vite avec une information incomplète. La fenêtre de vingt-quatre heures interdit d’attendre la certitude. Cela s’apprend en exercice, pas en réunion.
Tenir un registre produit exploitable. Nom commercial, versions diffusées, responsable interne, composants critiques, territoires de distribution, statut de support. Sans lui, la question « quels clients sont concernés » reste sans réponse pendant les heures qui comptent.
Comment nous formons sur ces sujets
Ces compétences sont travaillées dans notre formation Cyber Resilience Act, sécurité produit et gestion des vulnérabilités, ainsi que dans nos sessions sur les premiers réflexes en cas d’incident et sur la gestion de crise cyber. Elles combinent la lecture du règlement, la qualification de cas réels et la mise en situation sur les délais.
ACG CyberAcademy est l’organisme de formation d’ACG Cybersecurity, certifié Qualiopi au titre des actions de formation.
Pour aller plus loin
La fiche de l’ENISA sur la plateforme de déclaration unique décrit le processus en deux pages et se télécharge librement. Les orientations de la Commission européenne du 27 juillet 2026, référence C(2026) 5252, contiennent 67 exemples pratiques et des arbres de décision. Elles ne sont pas contraignantes. Ces deux documents suffisent à préparer une première réunion en interne. Si un cas vous laisse dans le doute, écrivez à formation@acgcybersecurity.fr.
Questions fréquentes
Non, tant qu’aucun élément ne montre qu’elle est activement exploitée. Elle relève du processus de correction habituel.
Non. Elle établit qu’une exploitation est possible, pas qu’elle a lieu. Le règlement vise l’exploitation constatée contre un système en production.
À partir du moment où le fabricant a connaissance de l’exploitation, et non de sa confirmation, comme le précisent les orientations de la Commission du 27 juillet 2026. Ni le règlement ni ces orientations ne disent à quel niveau d’une organisation cette connaissance est réputée acquise : c’est à chaque entreprise de le fixer et de désigner qui en juge.
Oui pour le signalement. Le régime transitoire du règlement dispense les produits mis sur le marché avant le 11 décembre 2027 des obligations générales de conformité, sauf modification substantielle, mais les obligations de signalement en sont expressément exclues et s’appliquent.
La notification est diffusée aux CSIRT concernés et à l’ENISA, puis partagée avec les autorités de surveillance du marché. Sur-déclarer mobilise plusieurs autorités et affaiblit la portée de vos signalements réels.
Consultant Senior cybersécurité chez ACG Cybersecurity. Spécialiste de la gouvernance, des risques et de la conformité, il accompagne les organisations sur NIS2, DORA et le Cyber Resilience Act.
Publié le 9 septembre 2026 · Mis à jour le 9 septembre 2026 · Sources vérifiées le 10 septembre 2026.
Demande d’information
Demande d’information