24 heures pour signaler une faille cyber : la nouvelle règle européenne qui change la donne pour les entreprises

Depuis le 11 septembre 2026, le Cyber Resilience Act impose aux fabricants de signaler sous 24 heures certaines failles exploitées et incidents graves. Un tournant pour la cybersécurité produit.

Depuis le 11 septembre 2026, le Cyber Resilience Act impose de nouvelles obligations de signalement en cas de vulnérabilité activement exploitée ou d’incident de sécurité grave.

Pour les entreprises concernées, le changement est majeur; elles doivent désormais être capables d’identifier, qualifier et notifier rapidement les failles qui touchent leurs produits numériques.

Le Cyber Resilience Act entre dans sa phase concrète

Le Cyber Resilience Act n’entre pas en application d’un seul bloc. Si l’essentiel de ses exigences deviendra applicable le 11 décembre 2027, une première obligation majeure s’impose déjà depuis le 11 septembre 2026; le signalement de certaines vulnérabilités et de certains incidents de sécurité.

Pour les entreprises concernées, ce calendrier change la donne. Il ne s’agit plus seulement de préparer progressivement leur conformité au CRA. Elles doivent déjà être capables d’identifier les événements entrant dans le champ du règlement et d’enclencher rapidement une procédure de notification.

Une obligation de signalement qui entre en vigueur avant le reste du CRA

Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques doivent signaler deux catégories d’événements : les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité de leurs produits. 

Les principales autres obligations prévues par le CRA, notamment celles relatives à la conception, à la documentation ou encore à la gestion des vulnérabilités sur l’ensemble du cycle de vie du produit, deviendront applicables à partir du 11 décembre 2027.

Ce décalage n’est pas anodin. Il oblige les fabricants à mettre en place dès maintenant une chaîne de remontée et de qualification des incidents, alors même que leur chantier global de conformité peut encore être en cours.

Mais qui est réellement concerné ? Le CRA ne vise pas toutes les entreprises de manière indistincte.

Quels produits et quelles entreprises sont réellement concernés ?

Le règlement cible les produits comportant des éléments numériques mis à disposition sur le marché européen. Cela englobe aussi bien des logiciels que des équipements matériels connectés; applications, systèmes d’exploitation, routeurs, objets connectés, solutions de cybersécurité ou encore certains équipements domestiques intelligents.

L’obligation de notification pèse en premier lieu sur le fabricant, c’est-à-dire l’acteur qui développe ou fait développer le produit et le commercialise sous son nom ou sa marque. Elle peut également concerner une entreprise qui apporte une modification substantielle à un produit existant et le remet sur le marché, puisqu’elle peut alors être considérée comme fabricant au sens du règlement.

Autre point important; l’obligation de signalement ne concerne pas uniquement les nouveaux produits lancés après septembre 2026. La Commission précise qu’elle s’applique également aux produits numériques déjà disponibles sur le marché européen.

Vulnérabilité exploitée et incident grave : ce qui doit être déclaré

Le CRA n’impose pas aux fabricants de signaler chaque vulnérabilité découverte dans leurs produits. L’obligation vise notamment les vulnérabilités dont ils ont connaissance et qui sont activement exploitées.

Autrement dit, la simple existence d’une faille n’entraîne pas automatiquement une notification au titre de cette obligation. Le changement intervient lorsqu’il existe des éléments montrant qu’un acteur malveillant l’exploite effectivement.

Le règlement prévoit également la déclaration des incidents graves ayant un impact sur la sécurité du produit. Dans ce cas, le fabricant doit notamment fournir une première appréciation de l’incident, des mesures correctives ou d’atténuation déjà prises et, lorsque cela est possible, des recommandations permettant aux utilisateurs de réduire le risque.

Cette distinction est essentielle, avant même de déclarer un événement, l’entreprise doit donc être capable de déterminer rapidement ce qui s’est passé, quels produits sont concernés et si les critères prévus par le CRA sont remplis.

24 heures pour réagir

Le point le plus visible du nouveau dispositif tient en un chiffre : 24 heures.

À compter du moment où un fabricant prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave concerné par le CRA, le compte à rebours commence. Cette première échéance transforme une obligation réglementaire en véritable contrainte opérationnelle.

Une première alerte dans les 24 heures

Le fabricant doit transmettre une alerte précoce dans un délai maximal de 24 heures après avoir pris connaissance de l’événement.

Pour une vulnérabilité activement exploitée, cette première notification doit notamment permettre d’indiquer, lorsqu’ils sont connus, les États membres dans lesquels le produit concerné a été mis à disposition. Pour un incident grave, elle doit également préciser si celui-ci semble résulter d’un acte illicite ou malveillant.

Les déclarations sont effectuées via la Single Reporting Platform, mise en place par l’ENISA. Elles sont ensuite adressées au CSIRT compétent et mises à disposition de l’ENISA selon le mécanisme prévu par le règlement.

Le défi tient au fait qu’en 24 heures, une entreprise dispose rarement d’une vision définitive de l’incident. Cette première notification n’est donc pas pensée comme un rapport d’investigation complet, mais comme le début d’un processus.

Une notification complète sous 72 heures

Une deuxième échéance intervient rapidement, 72 heures après la prise de connaissance de l’événement.

Dans le cas d’une vulnérabilité activement exploitée, la notification doit fournir les informations disponibles sur le produit concerné, la nature générale de la vulnérabilité et de son exploitation ainsi que les mesures correctives ou d’atténuation déjà prises.

Pour un incident grave, le fabricant doit notamment communiquer une première évaluation de l’incident, sa nature ainsi que les mesures engagées pour en limiter les conséquences.

Le processus ne s’arrête d’ailleurs pas au délai de 72 heures. Un rapport final est également prévu, au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation pour une vulnérabilité activement exploitée, et dans un délai d’un mois après la notification des 72 heures pour un incident grave. 

Pourquoi attendre d’avoir compris toute l’attaque n’est désormais plus possible ?

C’est probablement l’un des changements organisationnels les plus importants introduits par le dispositif.

Dans une gestion classique d’incident, les équipes peuvent être tentées d’attendre d’avoir consolidé les faits avant de faire remonter l’information à l’extérieur. 

Avec le CRA, cette logique devient beaucoup plus difficile à tenir, le délai réglementaire commence dès que le fabricant prend connaissance de l’événement, pas lorsqu’il dispose d’un rapport technique finalisé.

Cela oblige les entreprises à fonctionner avec des informations encore partielles. Une vulnérabilité peut être en cours d’analyse, le périmètre exact de l’incident peut rester incertain et la cause racine ne pas encore avoir été identifiée. Pourtant, la première échéance continue de courir.

Cette nouvelle contrainte oblige surtout les entreprises à revoir leur organisation interne. L’information doit remonter rapidement vers les équipes concernées, être qualifiée sans délai et permettre une notification même lorsque l’analyse technique est encore en cours.

Le délai de 24 heures transforme ainsi la capacité à détecter et qualifier une vulnérabilité en véritable enjeu de gouvernance. Pour les fabricants concernés, disposer d’un bon dispositif de sécurité ne suffira plus; encore faudra-t-il que l’information circule assez rapidement pour permettre une décision dans les délais imposés.

Les entreprises vont devoir savoir qu’elles ont été attaquées

Le CRA introduit une contrainte simple en apparence; signaler rapidement certaines vulnérabilités et certains incidents. Mais encore faut-il les détecter à temps. Le délai de 24 heures ne commence pas au moment où l’entreprise termine son investigation, mais lorsqu’elle prend connaissance de l’événement concerné.

Cela remet directement la capacité de détection au centre du dispositif. Une entreprise qui découvre trop tard qu’une vulnérabilité a été exploitée dispose mécaniquement de moins de temps pour qualifier l’événement, mobiliser les équipes concernées et préparer sa notification.

Détecter rapidement une exploitation devient une obligation stratégique

Le CRA ne demande pas de notifier toutes les vulnérabilités connues. L’obligation vise notamment celles qui sont activement exploitées. Cela suppose donc de pouvoir distinguer une faille simplement identifiée d’une vulnérabilité déjà utilisée dans le cadre d’une attaque.

En pratique, les fabricants doivent pouvoir s’appuyer sur plusieurs sources d’information :

• les alertes issues de leurs outils de supervision ;
• les signalements remontés par les équipes internes ou les utilisateurs ;
• les informations provenant de chercheurs en sécurité ;
• les notifications de fournisseurs ou de composants tiers ;
• les indicateurs laissant penser qu’une faille est effectivement exploitée.

Cette capacité à consolider rapidement des signaux parfois dispersés devient essentielle.

La supervision devient difficilement contournable

Une organisation qui ne dispose pas d’une visibilité suffisante sur ses produits, leurs composants et les événements de sécurité qui les affectent risque de découvrir certains incidents trop tard.

Le CRA renforce donc indirectement l’importance de dispositifs déjà familiers aux équipes cyber, surveillance des événements, remontée des vulnérabilités, suivi des composants logiciels et procédures d’escalade internes.

Pour les fabricants, plusieurs questions deviennent très concrètes :

• quels produits sont actuellement exposés ?
• quelles versions sont concernées ?
• quels composants tiers sont embarqués ?
• quelles équipes doivent être alertées en priorité ?
• quelles informations peuvent être réunies dans les premières heures ?

Le règlement ne prescrit pas un outil de supervision précis. Il crée en revanche une obligation de résultat qui rend beaucoup plus difficile une gestion artisanale ou tardive des vulnérabilités.

RSSI, développeurs et directions juridiques vont devoir travailler ensemble

Le respect des délais dépendra aussi de la circulation de l’information en interne.

Une équipe de développement peut être la première à identifier une faille. Le RSSI devra en évaluer l’impact et le niveau de criticité. Les équipes juridiques et conformité devront ensuite déterminer les obligations applicables, pendant que les équipes produit préparent éventuellement une mesure corrective.

Ce fonctionnement impose davantage de coordination. Une procédure de notification efficace devra donc être préparée avant l’incident, avec des rôles clairement définis et des circuits de validation suffisamment courts.

Le CRA transforme ainsi un sujet longtemps traité principalement par les équipes techniques en un processus beaucoup plus transversal.

Le CRA change aussi la manière de concevoir les produits numériques

Les nouvelles obligations de notification ne constituent qu’une première étape. Le Cyber Resilience Act introduit surtout un cadre beaucoup plus large : les produits numériques mis sur le marché européen devront intégrer des exigences de cybersécurité dès leur conception et pendant leur période de support. L’essentiel de ces obligations deviendra applicable le 11 décembre 2027.

La cybersécurité doit être pensée avant la mise sur le marché

Le CRA impose aux fabricants de concevoir, développer et produire leurs produits avec des exigences de cybersécurité intégrées dès l’origine. L’objectif est d’éviter que la sécurité ne soit traitée uniquement après l’apparition d’une faille ou après la commercialisation.

Cela implique notamment de mieux anticiper les risques liés :

• à l’architecture du produit ;
• aux composants logiciels intégrés ;
• aux mécanismes d’authentification ;
• aux mises à jour de sécurité ;
• aux vulnérabilités connues au moment de la commercialisation.

Cette logique rapproche clairement le CRA des approches de security by design, la sécurité doit faire partie du cycle de développement au même titre que les fonctionnalités ou la performance.

Les vulnérabilités devront être suivies pendant toute la période de support

Le CRA ne s’arrête pas à la mise sur le marché. Le fabricant devra définir une période de support pendant laquelle il restera responsable de la gestion des vulnérabilités affectant son produit. Cette période devra être communiquée clairement aux utilisateurs.

Cela suppose une organisation durable autour de la sécurité du produit :

• surveiller l’apparition de nouvelles vulnérabilités ;
• analyser leur impact ;
• publier des correctifs lorsqu’ils sont nécessaires ;
• maintenir les mises à jour de sécurité ;
• informer les utilisateurs lorsque des mesures doivent être prises.

La cybersécurité devient ainsi une responsabilité qui accompagne le produit après sa commercialisation.

Les éditeurs de logiciels sont directement concernés

Le terme utilisé par le règlement est volontairement large; produit comportant des éléments numériques. Il couvre aussi bien des produits matériels que des logiciels, ainsi que certains composants distribués séparément.

Les éditeurs de logiciels sont donc directement concernés par le CRA lorsque leurs produits entrent dans son champ d’application. Pour eux, la conformité ne se résumera pas à produire une documentation réglementaire. Elle touchera aussi les méthodes de développement, le suivi des vulnérabilités, les mises à jour et la relation avec les utilisateurs.

Le règlement pousse ainsi les éditeurs à considérer la sécurité comme une caractéristique permanente du produit et non comme une correction ponctuelle lorsqu’un problème apparaît.

Signaler une faille à l’Europe : que deviennent les informations transmises ?

Une plateforme unique pilotée par l’ENISA

La Single Reporting Platform centralise les déclarations relatives aux vulnérabilités activement exploitées et aux incidents graves concernés par le règlement.

Le principe est celui du report once; le fabricant transmet une seule notification via la plateforme, qui permet ensuite de partager l’information avec les autorités concernées.

L’ENISA assure notamment :

• le développement et la maintenance de la plateforme ;
• sa sécurité ;
• la disponibilité du service ;
• la mise à disposition des informations aux acteurs habilités.

La plateforme est opérationnelle depuis le 11 septembre 2026 et constitue désormais le canal officiel pour ces notifications.

Les CSIRT nationaux restent au cœur du dispositif

Une déclaration effectuée sur la plateforme n’est pas simplement stockée au niveau européen.

Le CSIRT désigné comme coordinateur dans l’État membre concerné reçoit la notification. Il peut ensuite transmettre les informations aux CSIRT des autres États membres dans lesquels le produit affecté a été mis à disposition. L’ENISA reçoit également la notification.

Cette organisation doit permettre une réaction coordonnée lorsqu’un même produit est commercialisé dans plusieurs pays européens.

Elle présente un intérêt évident dans le cas d’un logiciel ou d’un équipement largement diffusé, une vulnérabilité découverte dans un pays peut rapidement concerner des utilisateurs dans plusieurs autres États.

Le partage d’une vulnérabilité sensible doit lui-même être sécurisé

Le mécanisme soulève toutefois un enjeu délicat, les informations transmises peuvent être extrêmement sensibles.

Une notification peut contenir des éléments sur :

• la nature d’une vulnérabilité ;
• son exploitation ;
• les produits concernés ;
• les mesures correctives en préparation ;
• le niveau de sensibilité des informations communiquées.

Diffuser trop largement ce type d’informations avant qu’un correctif soit disponible pourrait créer un risque supplémentaire. Le CRA prévoit donc un cadre spécifique autour de leur traitement, et l’ENISA indique que la plateforme intègre des mesures destinées à protéger la confidentialité des données transmises.

Le défi consiste ainsi à trouver un équilibre entre deux impératifs; partager suffisamment vite les informations pour permettre aux autorités de réagir, sans augmenter l’exposition de la vulnérabilité concernée.

La cybersécurité devient une responsabilité produit

Le CRA ne se contente pas d’ajouter une nouvelle procédure de déclaration. Il modifie progressivement la place de la cybersécurité dans la gestion des produits numériques.

Jusqu’ici, la sécurité pouvait parfois être traitée comme un sujet séparé du développement ou de la stratégie produit. Le règlement pousse au contraire les entreprises à l’intégrer directement dans leurs processus de conception, de maintenance et de gouvernance.

Corriger une faille ne peut plus relever d’une décision improvisée

Une vulnérabilité découverte après la mise sur le marché devra être suivie, analysée et, si nécessaire, corrigée dans le cadre d’un processus structuré.

Le fabricant devra donc savoir qui prend en charge la vulnérabilité, comment son impact est évalué et à quel moment une mise à jour doit être publiée.

Cette formalisation réduit la place laissée aux décisions prises au cas par cas. La gestion des vulnérabilités devient un processus documenté et intégré au fonctionnement normal du produit.

Détecter, documenter et corriger devra être prévu en amont

Les exigences du CRA incitent les entreprises à préparer ces mécanismes avant même qu’une faille apparaisse.

Un dispositif cohérent pourra notamment prévoir :

• un canal de remontée des vulnérabilités ;
• une procédure interne de qualification ;
• des responsables clairement identifiés ;
• un processus de développement et de diffusion des correctifs ;
• une documentation conservant la trace des décisions prises.

L’enjeu est autant organisationnel que technique. Une entreprise disposant d’excellents outils mais incapable de faire circuler rapidement l’information restera en difficulté face aux délais imposés.

Le CRA rapproche cybersécurité, conformité et gouvernance

La sécurité des produits numériques ne relève donc plus exclusivement du RSSI ou des développeurs.

Le CRA fait intervenir simultanément les équipes produit, sécurité, juridique, conformité et parfois la direction générale. Une vulnérabilité peut désormais avoir une dimension technique, réglementaire et réputationnelle au même moment.

Cette convergence pourrait être l’un des effets les plus durables du règlement; faire de la cybersécurité produit un véritable sujet de gouvernance.

Attendre risque de compliquer la mise en conformité

L’essentiel des exigences du Cyber Resilience Act deviendra applicable le 11 décembre 2027, mais certaines obligations sont déjà en vigueur depuis septembre 2026. En France comme dans le reste de l’Union européenne, les entreprises concernées doivent donc commencer à adapter leurs processus dès maintenant. 

Le CRA entre déjà dans sa phase opérationnelle, et 2027 marquera surtout l’élargissement d’exigences qui commencent à transformer la manière dont les produits numériques sont conçus, suivis et sécurisés.