Cyber Resilience Act : signaler une faille en 24 heures

Le 11 septembre 2026, l’ENISA, l’agence européenne de cybersécurité, a mis en service la plateforme où les fabricants de logiciels et d’objets connectés doivent désormais déclarer leurs failles exploitées. Ce jour-là, la première obligation du Cyber Resilience Act (CRA), le règlement (UE) 2024/2847, est entrée en application, quinze mois avant le reste du texte.

Ce point de notre rubrique Développement d’applications est à jour au 20 octobre 2026. Ce n’est pas un conseil juridique : pour savoir si votre produit est visé et à quel titre, votre conseil a le dernier mot.

Qui doit signaler ses failles depuis le 11 septembre 2026 ?

Le CRA vise les « produits comportant des éléments numériques » mis à disposition sur le marché européen et capables de se connecter, directement ou non, à un appareil ou à un réseau. Selon l’analyse du cabinet McCann FitzGerald, qui s’appuie sur les lignes directrices publiées par la Commission en juillet 2026, cela couvre le logiciel autonome, le matériel avec son logiciel embarqué et les combinaisons des deux. Le règlement s’applique à tout opérateur qui vend en Europe, où qu’il soit établi.

Trois précisions comptent pour une entreprise de taille moyenne :

1. Le fabricant n’est pas forcément celui qui écrit le code. Une entreprise qui fait développer un produit et le commercialise sous son nom en est le fabricant ; un importateur ou un distributeur le devient s’il le vend sous sa propre marque ou le modifie substantiellement.
2. Les produits déjà vendus sont concernés. L’obligation de signalement s’applique depuis le 11 septembre 2026 à tous les produits couverts déjà mis à disposition sur le marché, rappelle le cabinet Hogan Lovells en citant l’article 69 du règlement. Cette lecture est celle d’un cabinet, pas une citation du Journal officiel : avant d’en tirer une conséquence pour un produit précis, relisez l’article 69 dans le texte du règlement (UE) 2024/2847 sur EUR-Lex.
3. Une application purement interne que vous ne mettez à disposition de personne hors de l’entreprise pose une autre question, à trancher avec votre conseil.

Que faut-il déclarer, et en combien de temps ?

Deux événements déclenchent l’obligation. Le premier est une faille déjà utilisée par un attaquant :

Le second est un incident grave : un incident qui affecte, ou peut affecter, la capacité du produit à protéger des données ou des fonctions importantes, ou qui a permis d’introduire ou d’exécuter du code malveillant dans le produit ou dans le réseau de l’utilisateur. Pour l’un comme pour l’autre, la page de la Commission sur les signalements fixe le même enchaînement :

1. Sous 24 heures

   Une alerte précoce, comptée à partir du moment où le fabricant a connaissance de la faille ou de l’incident.

2. Sous 72 heures

   La notification complète, avec ce que le fabricant sait de la faille et des mesures prises.

3. Sous 14 jours après le correctif

   Le rapport final pour une vulnérabilité exploitée, une fois une mesure corrective ou d’atténuation disponible.

4. Sous un mois après la notification

   Le rapport final pour un incident grave.

Le fabricant doit aussi informer les utilisateurs touchés, et si besoin tous ses utilisateurs ; s’il ne le fait pas à temps, l’autorité nationale peut le faire à sa place, selon Hogan Lovells.

Une seule déclaration, sur la plateforme de l’ENISA

Pour éviter qu’un éditeur déclare la même faille dans chaque pays où il vend, le règlement prévoit un guichet unique. La déclaration arrive à l’équipe nationale de réponse aux incidents (CSIRT) du pays où le fabricant a son établissement principal, et en même temps à l’ENISA ; ce CSIRT la transmet ensuite aux autres pays où le produit est vendu.

www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

L’ENISA annonçait son lancement le jour même, avec une foire aux questions, des guides et un service d’assistance. Les mainteneurs de logiciels libres impliqués dans le développement de produits, appelés « intendants », la rejoindront le 11 décembre 2027.

Que risque un fabricant qui ne signale pas ?

Le manquement à l’obligation de signalement entre dans la tranche la plus haute des sanctions du règlement :

Deux tempéraments existent : les microentreprises et les petites entreprises ne s’exposent pas à une amende pour le seul dépassement du délai de 24 heures de l’alerte précoce, et les intendants de logiciels libres ne sont pas soumis aux amendes administratives. Le délai de 72 heures, lui, vaut pour tous. Ces montants et cette exemption viennent de l’analyse du cabinet Hogan Lovells, qui renvoie aux articles 64 et 71 du règlement, et non d’une lecture du Journal officiel par nos soins : avant de vous engager sur un budget ou un contrat, vérifiez-les dans le règlement (UE) 2024/2847 publié au JO (nous les avons relevés le 20 octobre 2026).

Ce que ça change pour une équipe de 20 à 500 personnes

Le délai de 24 heures part du moment où vous savez. Il récompense donc les équipes qui l’apprennent vite, et pas celles qui l’apprennent par un client. C’est le vrai bénéfice de l’obligation : elle oblige à mettre en place ce qui réduit de toute façon le coût d’une faille.

1. 01Savoir ce que vous vendez.

   La liste de vos applications et objets connectés en circulation, avec leurs versions et les composants qu’ils embarquent : sans elle, impossible de dire en une heure si une faille publiée vous touche.

2. 02Être prévenu tôt.

   Une supervision qui alerte sur un comportement anormal, et une adresse où un chercheur ou un client peut signaler une faille, lue chaque jour.

3. 03Décider qui déclare.

   Une personne nommée, et sa remplaçante, avec un compte déjà créé sur la plateforme de l’ENISA, plutôt qu’une inscription au milieu d’un incident.

4. 04Pouvoir corriger vite.

   Le rapport final d’une faille exploitée se compte à partir du correctif disponible : une chaîne de livraison qui publie une correction en quelques heures raccourcit tout le reste.

La question de la publication pèse ici : une correction sur une application des stores attend la revue d’Apple ou de Google, une application web progressive se met à jour dès sa mise en ligne. Nous comparons les deux voies dans PWA ou application des stores. Le budget de cette veille fait partie du coût réel d’une application, que nous détaillons dans ce qui fait varier le prix d’une application et dans le budget de maintenance d’une application. Pour l’alerte elle-même, la méthode de supervision de nos automatisations s’applique aussi à une application.

Si vous achetez des logiciels plutôt que d’en éditer, le CRA vous sert aussi : demandez à vos éditeurs qui reçoit les signalements chez eux, comment ils vous préviendront d’une faille exploitée, et à quel rythme ils publient leurs correctifs. Une réponse claire en dit long sur leur maturité.

Et après : les exigences du 11 décembre 2027

Le signalement n’est que la première marche. À partir du 11 décembre 2027, les produits mis sur le marché devront respecter les exigences essentielles de cybersécurité du règlement, rappelle l’ENISA. Le CRA s’ajoute à NIS2, qui vise les organisations plutôt que les produits et dont la transposition attend toujours en France, comme nous l’expliquons dans notre point sur la loi Résilience. Toutes ces dates sont rassemblées dans notre calendrier de la réglementation numérique.

Si vous faites développer une application et voulez que la supervision, les mises à jour et la procédure de signalement soient prévues dès le départ, c’est le périmètre de notre offre développement d’applications.

Questions fréquentes

Sources

1. L’analyse du cabinet McCann FitzGerald (nouvel onglet)mccannfitzgerald.com
2. Le cabinet Hogan Lovells (nouvel onglet)hlc.com
3. Le texte du règlement (UE) 2024/2847 sur EUR-Lex (nouvel onglet)eur-lex.europa.eu
4. La page de la Commission sur les signalements (nouvel onglet)digital-strategy.ec.europa.eu
5. Annonçait son lancement (nouvel onglet)enisa.europa.eu