Cyber Resilience Act : 24 heures pour signaler, à partir du 11 septembre

Dans vingt-cinq jours, le premier volet réellement opposable du Cyber Resilience Act entre en application. Le 11 septembre 2026, tout fabricant d’un produit comportant des éléments numériques mis à disposition sur le marché européen devra signaler, sous vingt-quatre heures, toute vulnérabilité activement exploitée dans ce produit, ainsi que tout incident grave affectant sa sécurité.

L’échéance est passée largement inaperçue pendant l’été, pour une raison simple : le CRA est associé dans les esprits au marquage CE et à décembre 2027. C’est exact pour les exigences essentielles de l’annexe I. Ça ne l’est pas pour le signalement, qui arrive quinze mois plus tôt et sans période transitoire — y compris pour les produits déjà commercialisés.

Qui est « fabricant », et qui ne l’est pas

C’est la première question à trancher, et beaucoup d’organisations la tranchent trop vite dans le sens qui les arrange.

Le CRA vise les opérateurs économiques qui mettent à disposition sur le marché européen un produit comportant des éléments numériques : logiciel, application, équipement connecté, composant matériel capable de communiquer avec un appareil ou un réseau. Une entreprise qui se contente d’utiliser un ERP, un pare-feu ou un service cloud n’est pas fabricant à ce titre.

En revanche, deux profils basculent plus souvent qu’ils ne le pensent. Celui qui distribue un produit sous sa propre marque, même s’il ne l’a pas développé. Et celui qui édite un logiciel métier vendu à des clients — y compris un outil interne devenu commercialisable, y compris un logiciel industriel de supervision. Le règlement ne fait pas de distinction entre un automate et le logiciel qui le pilote.

Le logiciel libre développé et distribué sans finalité commerciale est exclu, et un développeur individuel n’est pas un fabricant. Les fondations qui portent durablement des projets open source à visée commerciale relèvent d’un régime allégé propre.

Ce qui déclenche le compte à rebours

Le mot important est exploitée. Une vulnérabilité connue, même critique, même avec un score élevé, ne déclenche pas l’obligation tant qu’il n’existe pas d’élément indiquant qu’elle est exploitée en conditions réelles. Elle relève du processus de gestion des vulnérabilités ordinaire.

Ce qui doit être signalé, c’est la vulnérabilité activement exploitée dans le produit, et l’incident grave ayant une incidence sur la sécurité du produit. Deux catégories distinctes, deux délais de rapport final différents.

Le second mot important est prise de connaissance. Les vingt-quatre heures ne courent pas à partir de la publication d’un CVE ou de la disponibilité d’un correctif, mais du moment où le fabricant a connaissance du fait. Cela déplace le sujet : l’enjeu opérationnel n’est pas le formulaire, c’est la capacité à dater cette prise de connaissance et à la faire remonter au bon interlocuteur dans la journée. Un signalement qui arrive par le support client un vendredi soir consomme le délai avant même que quiconque en ait pris la mesure.

Ce qu’il faut avoir prêt avant le 11 septembre

Aucun de ces points ne demande un projet. Tous demandent une décision.

• Un responsable désigné et un suppléant. Une obligation à vingt-quatre heures ne survit pas à une période de congés ou à un arrêt maladie. C’est le premier point à régler, et le plus souvent oublié.
• Un canal d’entrée identifié. Support, équipe sécurité, adresse de divulgation coordonnée : les trois doivent converger vers la même personne, avec une consigne écrite de remontée immédiate.
• Un critère de qualification. Ce qui distingue une vulnérabilité activement exploitée d’une vulnérabilité théorique, et un incident grave d’un incident ordinaire. Une page suffit, mais elle doit exister avant l’événement, pas pendant.
• Un accès testé à la plateforme. La Single Reporting Platform de l’ENISA doit être opérationnelle à cette date. Vérifier l’accès un lundi matin de septembre coûte moins cher que de le découvrir en situation.
• Un registre. Chaque signalement, sa date de prise de connaissance, sa qualification, ses horodatages. C’est ce qui sera demandé en contrôle, et c’est aussi ce qui protège en cas de contestation sur le respect du délai.

Si vous n’êtes pas fabricant, l’échéance vous concerne quand même

Par deux canaux.

Le premier est un flux d’information amont. À partir du 11 septembre, vos fournisseurs d’équipements et vos éditeurs sont tenus de signaler ce qu’ils constatent d’exploité. Une partie de cette information redescendra vers vous, plus vite et plus formellement qu’aujourd’hui. Encore faut-il que quelqu’un chez vous la reçoive et sache quoi en faire — c’est-à-dire disposer d’un inventaire des produits et de leurs versions permettant de savoir, en lisant l’avis, si l’on est concerné.

Le second est contractuel. La rapidité de signalement devient un critère opposable au fournisseur. Les clauses de sécurité qui se contentent aujourd’hui d’une notification « dans les meilleurs délais » gagnent à être alignées sur les délais du règlement, au moins pour les fournisseurs critiques. Les renouvellements de l’automne sont le bon moment.

Ce que le 11 septembre ne fait pas

Il ne déclenche pas le marquage CE. Il n’impose pas la documentation technique de l’annexe I, ni la déclaration UE de conformité, ni l’évaluation par un organisme notifié. Tout cela reste au 11 décembre 2027 — une échéance nettement plus lourde, qui suppose un travail sur la conception des produits et non sur un processus.

Il ne dispense pas non plus des autres régimes. Une vulnérabilité exploitée qui entraîne une violation de données personnelles reste soumise à la notification RGPD, avec son propre délai et son propre destinataire. Les deux obligations coexistent, ne se substituent pas, et n’ont ni le même déclencheur ni la même autorité.

Enfin, il ne concerne pas un futur lointain. Un éditeur français de taille moyenne qui apprend le 15 septembre qu’une faille de son produit est exploitée chez un client a jusqu’au 16 pour émettre son alerte. La question n’est pas de savoir si le cas se présentera, mais qui, ce jour-là, aura la main.

Sources

• Règlement (UE) 2024/2847 du 23 octobre 2024 relatif à des exigences de cybersécurité horizontales pour les produits comportant des éléments numériques — articles 13, 14 et 64
• Commission européenne, orientations relatives à la mise en œuvre du Cyber Resilience Act, publiées le 27 juillet 2026
• ENISA — Single Reporting Platform, plateforme unique de signalement
• ANSSI / CERT-FR — coordination des signalements pour les fabricants établis en France