Cyber Resilience Act : 24 heures pour déclarer

Un fabricant de Toronto ou d'Austin vend un boîtier réseau ou un logiciel en Europe. Depuis le 11 septembre 2026, s'il apprend qu'une vulnérabilité de son produit est activement exploitée, il a vingt-quatre heures pour le dire à un CSIRT européen. Pas à ses clients : à une autorité. Une horloge de plus, et un seul processus pour toutes.

Ce que dit le règlement

Selon la page de la Commission européenne sur les obligations de déclaration du Cyber Resilience Act (CRA), les fabricants de produits comportant des éléments numériques doivent, depuis le 11 septembre 2026, déclarer deux choses : les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit. Le calendrier est en trois temps : une alerte précoce dans les 24 heures après avoir pris connaissance du fait, une notification dans les 72 heures, puis un rapport final, au plus tard 14 jours après la mise à disposition d'une mesure corrective pour une vulnérabilité, ou dans le mois qui suit la notification de 72 heures pour un incident grave.

La même page précise le circuit : le fabricant déclare au CSIRT de l'État membre de son établissement principal, par la plateforme unique de déclaration que l'ENISA a lancée le 11 septembre 2026, et l'information est mise simultanément à la disposition de l'ENISA. Selon le communiqué de lancement, ce CSIRT diffuse l'information aux CSIRT des États membres où le produit est aussi disponible. Les « open-source software stewards » y seront soumis à partir du 11 décembre 2027, selon la Commission.

L'obligation suit le produit, pas le siège : vendre dans l'Union, c'est être fabricant au sens du règlement, avec la même horloge qu'un concurrent de Munich.

Pourquoi ça compte

Le 22 septembre 2026, le Centre canadien pour la cybersécurité a publié l'alerte AL26-022 sur CVE-2026-94127, un débordement de tampon dans F5 BIG-IP Access Policy Manager (APM) exploitable sans authentification lorsqu'une politique d'accès APM et un profil OAuth partagent le même serveur virtuel ; l'alerte indique que F5 a signalé une exploitation dans la nature. Sans rien dire du statut de ce fabricant face au CRA, un fabricant dans cette situation, avec un produit vendu dans l'Union, aurait eu l'horloge suivante : alerte précoce sur la plateforme de l'ENISA 24 heures après avoir su que la vulnérabilité était exploitée, notification à 72 heures, rapport final 14 jours après la publication du correctif.

Cette horloge s'ajoute à celles que l'équipe tient déjà.

Cinq régimes, cinq déclencheurs (exploitation, importance, préjudice, désignation) et cinq destinataires. La matière première, elle, est identique : qui a détecté quoi, à quelle heure, sur quel produit ou système, avec quel impact, quelles mesures. Une équipe qui réécrit cinq fois la même chose à trois heures du matin se trompe au moins une fois.

Ce que nous en pensons chez Sentrix

Le CRA ne crée pas un métier : il impose le délai le plus court de la liste à un métier qui existe déjà, le PSIRT (product security incident response team). Dans l'ordre :

1. Fixer le point zéro avant l'incident. L'horloge du CRA part du moment où le fabricant « prend connaissance » de l'exploitation. Écrivez ce qui la constitue chez vous : télémétrie, avis d'un client, catalogue d'exploitation connue. Nommez qui déclare T0.
2. Un seul dossier, plusieurs sorties. Le même dossier d'incident produit l'alerte précoce au CSIRT, le bulletin aux clients, la notification NIS 2 que vos clients européens exigent par contrat et la note au conseil pour la décision d'importance (SEC).
3. S'inscrire à la plateforme de l'ENISA maintenant. L'inscription, le représentant et le CSIRT compétent se règlent un mardi après-midi, pas la nuit d'un zero-day.
4. Rédiger les trois gabarits (24 heures, 72 heures, rapport final) avec les champs communs aux cinq régimes, puis les tester sur table, de la première alerte interne au rapport signé.
5. Savoir en heures qui est exposé. Dans le cas AL26-022, la question n'est pas « avons-nous BIG-IP » mais « quels serveurs virtuels ont une politique APM et un profil OAuth ». Une exposition continue, celle de notre module CTEM, répond par actif plutôt que par produit.
6. Faire descendre le délai chez vos fournisseurs. Le composant vulnérable est souvent celui d'un tiers : la clause de notification que vos clients vous imposent, imposez-la en amont.

Notre plateforme collecte la preuve une fois et la mappe à chaque référentiel ; notre page NIS2 détaille l'horloge voisine et notre service de réponse aux incidents monte le PSIRT avec vous.

La prochaine étape

Prenez votre dernier avis de sécurité produit ou votre dernier correctif d'urgence. Notez trois heures : celle où vous avez su, celle où vos clients ont su, celle où une autorité aurait été avisée. Si la troisième n'existe pas, c'est votre plan de travail. Pour le faire avec nous, contactez-nous.