Depuis le 11 septembre 2026, une faille exploitée dans un produit numérique peut déclencher une obligation de signalement sous 24 heures. Pour les fabricants, l’enjeu est d’être prêts avant l’alerte.
Le Cyber Resilience Act (CRA) impose désormais aux fabricants de déclarer les vulnérabilités activement exploitées et les incidents graves touchant la sécurité de leurs produits comportant des éléments numériques. Le premier délai, fixé à 24 heures après la prise de connaissance, correspond à une alerte précoce, pas à une expertise achevée. Une notification plus détaillée suit sous 72 heures, puis un rapport final selon la nature de l’événement.
Le délai commence quand le fabricant est informé
Vendredi, 17 h 30. Un chercheur signale qu’une vulnérabilité affectant un logiciel est activement exploitée. Le message arrive dans une boîte générique. Si personne ne le lit avant lundi, le premier obstacle n’est pas technique : l’information n’a pas atteint l’équipe capable d’agir.
Depuis le 11 septembre 2026, le CRA oblige les fabricants concernés à signaler, sans retard injustifié et au plus tard sous 24 heures après en avoir pris connaissance, une vulnérabilité activement exploitée ou un incident grave ayant une incidence sur la sécurité d’un produit comportant des éléments numériques. Cette première déclaration sert à donner l’alerte. Elle ne suppose pas que l’enquête soit terminée.
Le fabricant dispose ensuite de 72 heures pour transmettre une notification plus détaillée. Pour une vulnérabilité activement exploitée, le rapport final doit parvenir au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Pour un incident grave, il est attendu dans le mois suivant la notification des 72 heures. Ces étapes permettent d’enrichir progressivement les informations disponibles, à condition de lancer l’investigation sans attendre.
La première décision consiste donc à qualifier ce qui remonte du terrain. Une faille possible, découverte dans une bibliothèque utilisée par l’entreprise, ne suffit pas à établir qu’elle est activement exploitée. À l’inverse, une information reçue par le support, le SOC, un client, un fournisseur ou un chercheur peut nécessiter une escalade immédiate. Le fabricant doit savoir qui examine le signalement, comment il vérifie les éléments disponibles et à quel moment les responsables de la déclaration sont informés.
Cette circulation de l’information demande un point de contact surveillé, une politique de divulgation coordonnée et une équipe chargée de la sécurité des produits. Son nom importe moins que sa capacité à recevoir une alerte, ouvrir une enquête et mobiliser les bonnes personnes le soir, le week-end ou pendant les congés.
Inventaire, responsabilités et accès prêts à l’emploi
Une fois l’alerte reçue, une autre question surgit : quels produits sont réellement touchés ? Le fabricant doit pouvoir relier un composant, une version de bibliothèque ou un firmware à ses logiciels et équipements. Un inventaire exploitable et une nomenclature logicielle, ou SBOM, facilitent ce rapprochement. Sans cette visibilité, les premières heures risquent d’être consacrées à rechercher où se trouve le composant concerné.
La chaîne de décision doit être définie avec la même précision. Sécurité, développement, responsables produit, juridique, conformité et communication ont besoin d’un circuit d’escalade connu. Qui confirme les faits disponibles ? Qui valide le périmètre des produits ? Qui transmet la notification ? Qui prend le relais si la personne désignée est absente ? Une matrice de responsabilités et des remplaçants évitent qu’une déclaration reste bloquée dans l’attente d’une signature.
Les déclarations passent par la Single Reporting Platform (SRP), exploitée par l’ENISA. Son accès repose sur un compte EU Login avec authentification multifacteur. L’organisation peut désigner un représentant principal et des représentants secondaires. Identifier ces personnes et vérifier leurs accès avant le premier incident écarte une difficulté administrative au moment où chaque heure compte.
Les équipes doivent aussi préparer les informations qu’elles chercheront dès le début de l’enquête : produit et versions concernés, composant en cause, éléments attestant l’exploitation, correctif ou mesure d’atténuation disponible, et pays où le produit est commercialisé. Le premier signalement peut rester succinct. Les échéances suivantes exigent toutefois une connaissance de plus en plus précise de la vulnérabilité, de son exploitation et des mesures prises. Un exercice permet de mesurer cette préparation. Le scénario peut tenir en une phrase : une vulnérabilité du produit X est activement exploitée à 17 h 30. Jusqu’au lendemain à la même heure, l’entreprise doit retrouver les versions touchées, joindre ses responsables, établir ce qu’elle sait et déposer l’alerte. Les retards observés indiquent où corriger le processus.
Cette obligation concerne aussi les produits relevant du CRA déjà mis sur le marché avant son application complète, prévue le 11 décembre 2027. Pour la cyber intelligence des fabricants, le changement est immédiat : une alerte n’est utile que si elle peut être reliée rapidement à un produit, qualifiée et transmise aux personnes capables d’agir.
En résumé, les 24 heures ne se gagnent pas le jour de l’incident. Elles se gagnent auparavant, avec un inventaire précis, une SBOM exploitable, une surveillance des vulnérabilités, un canal de signalement efficace, une équipe Product Security identifiée, une procédure d’escalade, des remplaçants, des accès prêts et des exercices réguliers. Le CRA transforme ainsi la gestion des vulnérabilités en processus industriel mesurable, et plus seulement en problème technique traité lorsqu’une faille devient publique.