Obligations de signalement du CRA : ce que les fabricants doivent signaler depuis le 11 septembre 2026, à qui et dans quels délais

Depuis le 11 septembre 2026, l’article 14 du règlement sur la cyberrésilience (CRA) impose aux fabricants de produits comportant des éléments numériques de signaler les vulnérabilités activement exploitées et les incidents graves dans les 24 heures suivant leur prise de connaissance. Une notification suit dans les 72 heures, puis un rapport final. Les signalements vont à un CSIRT et à l’ENISA par une seule plateforme. C’est le fabricant qui signale, pas l’utilisateur.

Ce guide couvre ce qu’il faut signaler, les délais et le contenu des rapports, les destinataires, l’information des utilisateurs, le champ d’application, NIS2, les sanctions, ce que l’obligation laisse de côté et une liste de contrôle.

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	Dans les 24 heures suivant la prise de connaissance	Dans les 24 heures suivant la prise de connaissance
Notification	Dans les 72 heures suivant la prise de connaissance	Dans les 72 heures suivant la prise de connaissance
Rapport final	Au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation	Dans un délai d’un mois après la notification de l’incident
Destinataires	CSIRT désigné comme coordinateur et ENISA, via la plateforme unique de signalement	Les mêmes

Que doivent signaler les fabricants au titre du CRA ?

Deux choses, qui concernent toutes deux le produit plutôt que l’entreprise.

Vulnérabilités activement exploitées

L’article 14, paragraphe 1, vise toute vulnérabilité activement exploitée contenue dans le produit. L’article 3, point 42), fixe le seuil : il faut des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire de ce système.

Selon le considérant 68, une vulnérabilité découverte lors de tests menés de bonne foi, sans aucun signe d’utilisation malveillante, ne devrait pas faire l’objet d’une notification obligatoire. L’article 15 vous permet de la signaler volontairement, de même que les quasi-incidents.

À la lecture du texte, une vulnérabilité contenue dans le produit inclut celles des composants que vous n’avez pas écrits, un cas que la FAQ de la Commission sur le CRA traite à la section 5.4. En pratique, de nombreux signalements partiront du code de quelqu’un d’autre.

Incidents graves

L’article 14, paragraphe 3, vise tout incident grave ayant un impact sur la sécurité du produit. Selon l’article 14, paragraphe 5, un incident est grave lorsque :

1. il a ou est susceptible d’avoir une incidence négative sur 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
2. il a entraîné ou pourrait entraîner l’introduction ou l’exécution d’un code malveillant dans le produit ou dans les réseaux et systèmes d’information d’un utilisateur.

Les considérants donnent des exemples : un code malveillant introduit dans le canal de diffusion de vos mises à jour de sécurité, ou un incident dans vos processus de développement, de production ou de maintenance qui accroît le risque pour les utilisateurs. Votre sécurité interne entre dans le champ dès qu’elle touche ce que vous livrez.

Quels sont les délais de signalement du CRA et que contient chaque rapport ?

Pour les délais de 24 et 72 heures, le texte exige d’agir sans retard injustifié et, en tout état de cause, dans le délai indiqué.

1. Alerte précoce, 24 heures. Les États membres où, à votre connaissance, le produit est disponible ; pour un incident, également si vous soupçonnez un acte illicite ou malveillant.
2. Notification, 72 heures. Des informations générales sur le produit et sur la nature de l’exploitation et de la vulnérabilité (ou de l’incident, avec une première évaluation), les mesures prises, les mesures que les utilisateurs peuvent prendre et le degré de sensibilité que vous attribuez à ces informations.
3. Rapport intermédiaire. Le CSIRT destinataire peut demander un point de situation (article 14, paragraphe 6).
4. Rapport final. Une description, avec la gravité et l’impact. Pour une vulnérabilité, ajoutez l’éventuel acteur malveillant connu et la mise à jour de sécurité ; pour un incident, le type de menace ou la cause profonde probable et les mesures d’atténuation appliquées et en cours.

FICHE DE NOTIFICATION, ARTICLE 14 DU CRA

Produit, versions concernées : ..................................
Type :        [ ] Vulnérabilité exploitée   [ ] Incident grave
Connaissance : date/heure (UTC) ...... source ...................
Décidé par :  nom, fonction .....................................
États membres où le produit est disponible : ....................

Alerte précoce, échéance (connaissance + 24 h) : ................
  incident : acte illicite ou malveillant suspecté ? O / N
Notification, échéance (connaissance + 72 h) : ..................
  nature de l'exploitation ou de l'incident, mesures prises,
  mesures pour les utilisateurs, sensibilité des informations
Rapport final, échéance : .......................................
  vulnérabilité : 14 jours après la disponibilité du correctif
    ou de la mesure d'atténuation
  incident : un mois après la notification
  description, gravité, impact, acteur ou cause profonde,
  correctif

Utilisateurs informés (art. 14, par. 8) : date ..... canal ......
  format lisible par machine ? O / N

Qui reçoit les signalements de vulnérabilités au titre du CRA ?

Vous signalez une seule fois, via la plateforme unique de signalement que l’ENISA gère en vertu de l’article 16. L’ENISA a mis en service sa capacité opérationnelle initiale le 11 septembre 2026. Chaque notification est transmise simultanément au CSIRT désigné comme coordinateur et à l’ENISA.

Ce CSIRT se trouve dans l’État membre de votre établissement principal, c’est-à-dire là où les décisions relatives à la cybersécurité de vos produits sont principalement prises. Sans établissement dans l’UE, l’article 14, paragraphe 7, fixe un ordre de repli : le mandataire, puis l’importateur, puis le distributeur, chacun selon le nombre de produits, puis l’État membre qui compte le plus d’utilisateurs. Ce sont les mêmes CSIRT qui coordonnent la divulgation des vulnérabilités au titre de NIS2, comme le décrit le cadre de divulgation des vulnérabilités de NIS2.

Le CSIRT destinataire transmet la notification aux CSIRT des États membres où, selon vos indications, le produit est disponible. Dans des circonstances exceptionnelles, notamment à votre demande, il peut retarder cette transmission pour des motifs justifiés liés à la cybersécurité, pas plus longtemps que strictement nécessaire (article 16, paragraphe 2).

D’après la FAQ de l’ENISA :

• Chaque personne qui dépose un signalement doit disposer d’un compte EU Login avec authentification à plusieurs facteurs et s’enregistrer comme représentant désigné.
• L’ENISA conseille de s’enregistrer au moment où vous devez soumettre un signalement ; la validation se déroule en parallèle et ne bloque pas un premier signalement.
• Si la plateforme est indisponible, attendez et déposez le signalement dès son rétablissement. Si vous devez communiquer plus tôt, vous pouvez contacter directement votre CSIRT, mais vous devez tout de même déposer le signalement sur la plateforme.

Devez-vous informer vos utilisateurs ?

Oui. L’article 14, paragraphe 8, vous impose d’informer les utilisateurs concernés et, le cas échéant, tous les utilisateurs, de la vulnérabilité ou de l’incident et, si nécessaire, des mesures qu’ils peuvent déployer pour en atténuer les effets. Le cas échéant, utilisez un format structuré et lisible par machine. Si vous ne les informez pas en temps utile, les CSIRT que vous avez notifiés peuvent le faire.

Qui est fabricant et quels produits sont concernés ?

Selon l’article 3, point 13), est fabricant toute personne qui développe ou fabrique des produits comportant des éléments numériques, ou les fait fabriquer, et les commercialise sous son nom ou sa marque, que ce soit à titre onéreux, à des fins de monétisation ou à titre gratuit. Un produit comportant des éléments numériques est un logiciel ou un matériel et ses solutions de traitement de données à distance, y compris les composants vendus séparément, dont l’utilisation prévue ou prévisible comprend une connexion de données à un appareil ou à un réseau. C’est ce que prévoient l’article 2, paragraphe 1, et l’article 3, point 1).

Le périmètre dépasse les éditeurs de logiciels : un capteur connecté, un contrôleur industriel, un routeur, un micrologiciel embarqué, le back-end cloud qui fait fonctionner un appareil. Un SaaS seul n’en fait généralement pas partie : le considérant 12 exclut du CRA les services cloud développés en dehors de la responsabilité d’un fabricant et relève que NIS2 couvre le SaaS. Sont exclus les produits relevant des règles de l’UE sur les dispositifs médicaux, les dispositifs médicaux de diagnostic in vitro, la réception par type des véhicules à moteur, les produits certifiés de l’aviation civile et les équipements marins, ainsi que les produits conçus exclusivement pour la sécurité nationale ou la défense.

Côté calendrier :

• Les produits déjà sur le marché sont couverts. L’article 69, paragraphe 3, applique l’article 14 à tous les produits mis sur le marché avant le 11 décembre 2027. Un routeur vendu en 2023 est concerné.
• Le reste du CRA arrive plus tard. Les exigences essentielles, l’évaluation de la conformité et le marquage CE s’appliquent à partir du 11 décembre 2027 et ne visent les produits plus anciens qu’après une modification substantielle (article 69, paragraphe 2).
• Les gestionnaires de logiciels libres (open-source software stewards) signalent à partir du 11 décembre 2027, selon la Commission.
• Déjà passé : l’entrée en vigueur (10 décembre 2024) et le début de l’application des règles sur la notification des organismes d’évaluation de la conformité (11 juin 2026).

Quel lien entre le signalement CRA et la notification d’incidents NIS2 ?

NIS2 demande si votre organisation est sécurisée. Le CRA s’intéresse à ce que vous vendez. Une entreprise peut être hors du champ de NIS2 et dans celui du CRA, ou relever des deux et devoir deux signalements pour un même événement.

	Article 23 de NIS2	Article 14 du CRA
Qui signale	Entités essentielles et importantes	Fabricants de produits comportant des éléments numériques
Déclencheur	Incident important affectant vos services	Vulnérabilité exploitée ou incident grave dans votre produit
Alerte précoce	24 heures	24 heures
Notification	72 heures	72 heures
Rapport final	Un mois après la notification	14 jours après le correctif, ou un mois après la notification
Destinataire	CSIRT ou autorité compétente	CSIRT coordinateur et ENISA, via la plateforme

L’annexe II de NIS2 mentionne les fabricants de produits informatiques, électroniques et optiques, d’équipements électriques et de machines ; les moyennes entreprises et les entreprises plus grandes entrent dans le champ de NIS2. Dans une telle entreprise, un serveur de mises à jour compromis peut constituer à la fois un incident grave au sens du CRA et un incident important au sens de NIS2. En pratique, établissez quels événements déclenchent quel signalement et rédigez les deux à partir d’un seul dossier d’incident. Le volet NIS2 est traité dans le calendrier de notification des incidents NIS2 et sur la page conformité NIS2.

Le CRA vous atteint aussi par vos clients. Une entité soumise à NIS2 doit tenir compte de la qualité des produits de ses fournisseurs directs et de leurs procédures de développement sécurisé (sécurité de la chaîne d’approvisionnement NIS2). Attendez-vous à la question « comment signalez-vous les vulnérabilités exploitées ? » dans les questionnaires de sécurité et les contrats, comme le constatent déjà les fournisseurs télécoms face à NIS2.

Que se passe-t-il si vous manquez un délai du CRA ?

L’article 64, paragraphe 2, prévoit pour les manquements à l’article 14 des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu ; les États membres fixent le régime des sanctions. Selon l’article 64, paragraphe 10, point a), les amendes ne s’appliquent pas aux fabricants qui sont des microentreprises ou des petites entreprises et qui manquent le délai de 24 heures de l’alerte précoce prévu à l’article 14, paragraphe 2, point a), ou paragraphe 4, point a), et le résumé de la Commission le lit ainsi. Ce paragraphe est toutefois formulé comme une dérogation aux paragraphes 3 à 9, alors que l’amende liée à l’article 14 figure au paragraphe 2 : ne considérez donc pas cette exemption comme acquise. Elle ne couvre jamais la notification à 72 heures ni le rapport final.

L’article 71 n’avance que l’application de l’article 14 et des règles sur les organismes d’évaluation de la conformité ; tout le reste, y compris l’article 64, s’applique à partir du 11 décembre 2027. Cela influe sur le calendrier de l’application des sanctions, pas sur l’obligation, qui s’applique depuis le 11 septembre 2026.

Que laisse de côté l’obligation de signalement du CRA ?

Le signalement est la partie facile. L’article 14 est procédural : désigner une personne, surveiller les bons canaux, déposer dans le délai. Il ne dit rien de la manière dont vous êtes informé, et c’est là que se situe le risque. L’information vient souvent de l’extérieur : un chercheur, un client, un avis d’un CSIRT. Un délai de 24 heures est facile à tenir si vous savez tout dès l’heure zéro. Il est impossible à tenir si vous l’apprenez le neuvième jour parce que l’adresse de contact sécurité aboutit dans une boîte que personne ne lit.

La question plus difficile vient après le dépôt : chaque client demande depuis combien de temps la vulnérabilité existait et s’il est concerné. Pour répondre, il faut un inventaire de ce que contient chaque version du produit, un registre indiquant quel client utilise quelle version, et les journaux de votre infrastructure de build et de mise à jour. Le règlement vous demande de signaler ce que vous savez. Il ne vous fait rien savoir.

Une partie de ces éléments deviendra obligatoire plus tard. À partir du 11 décembre 2027, l’annexe I, partie II, exige une nomenclature logicielle couvrant au moins les dépendances de premier niveau, une politique de divulgation coordonnée des vulnérabilités et une adresse de contact pour le signalement des vulnérabilités. L’obligation de signalement actuelle suppose que vous en disposez déjà.

Combler l’écart consiste à relier ces registres, pour qu’une CVE dans un composant devienne en quelques heures une liste de versions et de clients concernés, avec une personne qui décide de ce qui doit être signalé. C’est ainsi que fonctionne la plateforme CloudSoul : une collecte automatisée des preuves depuis vos systèmes, avec une expertise humaine dans la boucle. Si vous n’êtes pas sûr que votre processus de publication et de gestion des vulnérabilités tiendrait, un audit de sécurité vous le dira avant qu’un incident ne le fasse.

Liste de contrôle : obligations de signalement du CRA

• Déterminez si vous mettez des produits comportant des éléments numériques sur le marché de l’UE, y compris des produits vendus avant le 11 septembre 2026.
• Désignez la personne qui décide qu’un signalement est requis, ainsi qu’un suppléant, tous deux joignables en dehors des heures de bureau.
• Ouvrez-leur dès maintenant des comptes EU Login avec authentification à plusieurs facteurs.
• Publiez une adresse de contact sécurité et assurez-vous que quelqu’un la lit chaque jour.
• Tenez un inventaire des composants par version de produit et confrontez-le aux flux d’information sur les vulnérabilités.
• Consignez, pour chaque produit, votre établissement principal, votre CSIRT et les États membres où il est vendu.
• Préparez un canal pour informer les utilisateurs concernés, dans un format lisible par machine le cas échéant.
• Si vous relevez aussi de NIS2, établissez quels événements déclenchent un signalement et lesquels en déclenchent deux.

Sources

• Règlement (UE) 2024/2847 (règlement sur la cyberrésilience), articles 2, 3, 14, 15, 16, 64, 69 et 71, annexe I et considérants 12, 67 et 68, EUR-Lex.
• Commission européenne, Règlement sur la cyberrésilience : obligations de signalement et résumé du texte législatif.
• ENISA, Lancement de la plateforme unique de signalement du CRA et FAQ de la plateforme unique de signalement.
• Directive (UE) 2022/2555 (NIS2), article 23 et annexe II, EUR-Lex.

Questions fréquentes