CRA : signaler les vulnérabilités exploitées depuis septembre 2026

Le CRA signalement des vulnérabilités désigne l'obligation, prévue par l'article 14 du Cyber Resilience Act, pour tout fabricant de produit numérique de signaler les vulnérabilités activement exploitées et les incidents graves touchant ses produits. Applicable depuis le 11 septembre 2026, elle impose une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final, déposés sur la plateforme unique de l'ENISA. Elle vaut aussi pour les produits vendus avant cette date.

Le Cyber Resilience Act (règlement (UE) 2024/2847) impose aux produits comportant des éléments numériques des exigences de sécurité qui ne s'appliqueront pleinement que le 11 décembre 2027. Une obligation a toutefois été avancée : le signalement. Le législateur a voulu que les autorités soient informées sans attendre des failles que des attaquants exploitent déjà, pour pouvoir alerter et coordonner la réponse dans toute l'Union. Notre article Cyber Resilience Act : ce qui change pour les produits numériques présente le règlement dans son ensemble.

L'article 14 tient en quatre règles :

• signaler toute vulnérabilité activement exploitée contenue dans le produit (paragraphes 1 et 2) ;
• signaler tout incident grave ayant un impact sur la sécurité du produit (paragraphes 3 à 5) ;
• passer par la plateforme unique de signalement gérée par l'ENISA, à destination du CSIRT coordinateur compétent (paragraphe 7 et article 16) ;
• informer les utilisateurs concernés de la vulnérabilité ou de l'incident et des mesures à prendre (paragraphe 8).

Qui est concerné ?

L'obligation pèse sur le fabricant, c'est-à-dire celui qui met le produit sur le marché sous son nom, y compris l'importateur ou le distributeur requalifié en fabricant. Les gestionnaires de logiciels libres y sont également soumis dans la mesure où ils participent au développement des produits (article 24). L'article 69 étend le signalement à tous les produits déjà mis sur le marché : un routeur vendu en 2023 et toujours en service est concerné dès lors qu'une vulnérabilité exploitée y est découverte. Les produits exclus du CRA, comme les dispositifs médicaux, restent soumis à leur propre réglementation.

La vulnérabilité activement exploitée

Le règlement la définit comme une vulnérabilité pour laquelle il existe des éléments de preuve fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation de son propriétaire. Deux conséquences pratiques. D'abord, une faille découverte par vos équipes ou signalée par un chercheur, sans trace d'exploitation, ne déclenche pas l'article 14 : elle suit votre processus normal de correction et de divulgation. Ensuite, l'exploitation doit être avérée, pas seulement possible : une preuve de concept publiée ne suffit pas à elle seule, alors qu'une alerte du CERT-FR, une inscription au catalogue des vulnérabilités exploitées d'une agence publique ou un rapport d'incident d'un client sont des indices sérieux qu'il faut instruire immédiatement.

L'incident grave

Un incident est considéré comme grave lorsqu'il :

• affecte, ou peut affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ;
• ou a conduit, ou peut conduire, à l'introduction ou à l'exécution d'un code malveillant dans le produit ou dans les réseaux et systèmes d'information de ses utilisateurs.

L'exemple type est la compromission de l'infrastructure de mise à jour d'un éditeur : un attaquant qui pousse une mise à jour piégée vers les clients crée un incident grave, même si aucune vulnérabilité du produit lui-même n'est en cause. Une intrusion dans le système d'information de l'entreprise qui ne touche pas la sécurité du produit relève, elle, d'autres textes comme NIS 2 ou le RGPD.

Le signalement volontaire

À côté de ces obligations, l'article 15 permet à toute personne, fabricant ou non, de signaler volontairement une vulnérabilité, une cybermenace, un incident ou un quasi-incident. Selon l'ENISA, cette possibilité est ouverte sur la plateforme après le 11 septembre 2026. Par ailleurs, un fabricant qui découvre une vulnérabilité dans un composant tiers, y compris libre, intégré à son produit doit la signaler à la personne qui maintient ce composant (article 13, paragraphe 6) : c'est là que la nomenclature logicielle (SBOM) devient indispensable.

Les délais courent à partir du moment où le fabricant a connaissance de l'exploitation ou de l'incident, et non à partir de la découverte de la faille ni de la disponibilité d'un correctif. Les deux premières étapes sont communes aux deux types d'événement ; le rapport final diffère.

Alerte précoce : 24 heures

« Sans retard injustifié et en tout état de cause dans un délai de 24 heures », le fabricant envoie une alerte courte. Pour une vulnérabilité, elle indique notamment les États membres où le produit est disponible ; pour un incident, elle précise s'il est soupçonné d'avoir été causé par un acte illicite ou malveillant. Il ne s'agit pas d'avoir tout compris, mais de prévenir.

Notification : 72 heures

Dans les 72 heures, la notification complète l'alerte : informations générales sur le produit, nature de l'exploitation ou de l'incident, évaluation initiale, mesures correctives ou d'atténuation déjà prises et mesures que les utilisateurs peuvent appliquer, et degré de sensibilité des informations transmises.

Rapport final : 14 jours ou un mois

• Pour une vulnérabilité activement exploitée, le rapport final est dû au plus tard 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. Il décrit la vulnérabilité, sa gravité et son impact, ce que l'on sait de l'acteur malveillant, et le correctif.
• Pour un incident grave, il est dû dans le mois qui suit la notification de 72 heures. Il décrit l'incident, sa gravité, sa cause probable et les mesures d'atténuation appliquées ou en cours.

La page de l'ENISA détaille, pour chaque étape, les champs obligatoires, facultatifs ou conditionnels du formulaire, dont les identifiants CVE ou EUVD de la vulnérabilité. Le délai de 24 heures est le plus difficile à tenir ; c'est pourquoi l'article 64 exclut les amendes contre les micro et petites entreprises qui le manquent, sans les dispenser de signaler.

Tous les signalements passent par la plateforme unique de signalement prévue à l'article 16 et gérée par l'ENISA, l'agence de l'Union européenne pour la cybersécurité. Annoncée pour le 11 septembre 2026, elle est opérationnelle depuis cette date selon la Commission européenne. L'accès se fait avec un compte EU Login, que l'ENISA conseille de créer à l'avance ; à son lancement, le dépôt se fait par un formulaire web, sans interface de programmation.

Le CSIRT coordinateur

La notification est adressée simultanément à l'ENISA et au CSIRT désigné comme coordinateur de l'État membre où le fabricant a son établissement principal, c'est-à-dire là où sont prises la plupart des décisions de cybersécurité concernant ses produits. Pour un fabricant établi hors de l'Union, c'est l'État de son mandataire, puis de l'importateur ou du distributeur, qui détermine le CSIRT compétent. En France, l'ANSSI confirme que le CSIRT coordinateur est le CERT-FR.

Le CSIRT coordinateur transmet ensuite la notification aux CSIRT des autres États membres où le produit est vendu, et peut informer les autorités de surveillance du marché, en France l'ANFR. Dans des circonstances exceptionnelles, pour des raisons de cybersécurité, il peut retarder cette diffusion ; un acte délégué adopté par la Commission le 11 décembre 2025 en précise les conditions. Une fois le correctif disponible, l'ENISA verse la vulnérabilité dans la base européenne des vulnérabilités (EUVD).

Et l'omnibus numérique ?

La proposition d'omnibus numérique présentée par la Commission le 19 novembre 2025 prévoit un point d'entrée unique pour les notifications d'incidents au titre de NIS 2, du RGPD, de DORA et d'autres textes, que l'ENISA bâtirait à partir de son expérience de la plateforme CRA. Dans sa version proposée, elle ne modifie pas les obligations de signalement du CRA. Au 25 septembre 2026, le texte est toujours en examen en commission au Parlement européen : rien ne change pour l'instant.

Signaler aux autorités ne suffit pas. Après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, le fabricant doit en informer les utilisateurs touchés et, si nécessaire, tous les utilisateurs, ainsi que les mesures d'atténuation ou correctives qu'ils peuvent appliquer. Le règlement demande, lorsque c'est pertinent, un format structuré et lisible par machine, pour que les outils de gestion des vulnérabilités des clients puissent l'exploiter automatiquement. Si le fabricant ne le fait pas en temps utile, le CSIRT peut informer lui-même les utilisateurs.

Côté client, c'est un changement important : les RSSI recevront des informations plus rapides et plus homogènes de la part de leurs fournisseurs. Pour en tirer parti, il faut savoir quels produits vous utilisez et qui vous prévient : c'est l'un des apports d'une démarche de gestion des risques tiers qui tient à jour l'inventaire des produits et des contacts sécurité.

Les délais se ressemblent, mais les trois obligations ne visent ni les mêmes acteurs ni les mêmes événements. Un même incident peut pourtant les déclencher toutes les trois : un éditeur de logiciels, entité importante au sens de NIS 2, dont l'infrastructure de mise à jour est compromise et qui expose les données personnelles de ses clients.

L'article 14 traite des cas d'urgence. Le quotidien relève de la divulgation coordonnée des vulnérabilités, que l'annexe I du CRA rend obligatoire à partir du 11 décembre 2027. Le fabricant doit :

• publier une politique de divulgation coordonnée qui explique comment signaler une faille, comment elle sera traitée et dans quels délais ;
• fournir une adresse de contact pour les signalements, indiquée dans les informations destinées aux utilisateurs ;
• corriger sans délai et diffuser les correctifs gratuitement, de façon sécurisée ;
• publier des informations sur les vulnérabilités corrigées : description, produits touchés, gravité, moyens de remédiation.

Les deux mécanismes se rejoignent : une vulnérabilité reçue par la voie de la divulgation coordonnée devient un cas de l'article 14 dès qu'apparaissent des éléments fiables d'exploitation. Les lignes directrices de la Commission du 27 juillet 2026 admettent d'ailleurs que les fabricants s'appuient sur leurs processus de divulgation coordonnée existants. Un fabricant qui dispose déjà d'une adresse de contact, d'un processus de tri et d'un identifiant CVE attribué rapidement aura beaucoup moins de mal à tenir les 24 heures.

Vingt-quatre heures, week-end compris, c'est court. Les fabricants qui tiennent ce délai ont préparé le terrain avant le premier cas. Voici les briques à mettre en place, à adapter à la taille de l'organisation.

1. Détecter

Organisez une veille sur vos propres produits : avis du CERT-FR, catalogues publics de vulnérabilités exploitées, signalements de chercheurs et de clients, remontées du support et des équipes d'exploitation. Croisez ces sources avec la nomenclature logicielle de chaque version pour savoir en quelques minutes si un composant vulnérable est présent.

2. Qualifier

Écrivez une grille de décision : la vulnérabilité est-elle présente dans un produit couvert ? Existe-t-il des éléments fiables d'exploitation ? L'incident affecte-t-il la sécurité du produit ? Désignez qui tranche, avec une suppléance, et consignez chaque décision et son heure : la date de prise de connaissance est le point de départ des délais, et elle vous sera demandée.

3. Notifier

Créez à l'avance les comptes EU Login des personnes habilitées et faites valider leur rattachement au fabricant. Préparez des modèles d'alerte, de notification et de rapport final reprenant les champs de la plateforme. Prévoyez la relecture juridique sans qu'elle bloque l'alerte précoce.

4. Informer et corriger

Préparez les messages aux utilisateurs, la page d'avis de sécurité et, si possible, un format lisible par machine. Coordonnez la communication avec le correctif : le rapport final de 14 jours suppose qu'une mesure corrective soit disponible.

5. S'entraîner et articuler

Intégrez le scénario « vulnérabilité exploitée dans un produit vendu » à vos exercices de crise et à votre plan de continuité d'activité. Articulez le processus avec ceux de NIS 2 et du RGPD pour qu'un même incident ne soit pas traité trois fois par trois équipes différentes. Enfin, si vous achetez des produits plutôt que d'en fabriquer, vérifiez auprès de vos fournisseurs qu'ils ont mis en place ce dispositif : c'est une question à ajouter à vos évaluations, comme l'explique notre article sur le Cyber Resilience Act, et le classement de vos produits par catégorie est détaillé dans CRA : produits importants et critiques.

Pour relier ces processus à vos analyses de risques et suivre les plans d'action qui en découlent, voyez aussi notre module Risques & Conformité.