Depuis le 11 septembre 2026, un fabricant concerné par le Cyber Resilience Act doit pouvoir organiser une première alerte dans les 24 heures suivant la prise de connaissance d’un événement.
Lorsqu’une vulnérabilité activement exploitée affecte un produit concerné, une alerte précoce doit être transmise dans ce délai. Pour un éditeur de logiciel, cela suppose d’avoir déjà identifié les produits concernés, les personnes habilitées à qualifier l’événement et à déclencher le signalement, ainsi que les modalités d’articulation avec une éventuelle procédure de violation de données personnelles.
En pratique, votre organisation est-elle prête à répondre à trois questions un vendredi soir ? Quel produit est affecté ? L’exploitation est-elle avérée ? Qui peut notifier, avec quelles informations, avant l’expiration du délai ?
Cet article vous présente une méthode de préparation en cinq points, rappelle les délais applicables et clarifie le rôle respectif des équipes sécurité, produit et DPO.
Ce que le CRA exige
Le CRA, règlement européen 2024/2847, s’applique aux produits comportant des éléments numériques mis à disposition sur le marché de l’Union européenne. Son champ est large : caméras connectées, montres intelligentes, jouets connectés, compteurs intelligents, logiciels autonomes distribués à des clients, applications, firmware et autres produits matériels ou logiciels connectés, directement ou indirectement, à un appareil ou à un réseau.
Une petite structure qui commercialise un logiciel téléchargeable peut donc être concernée, même si elle n’entre pas dans le périmètre de NIS2. Le CRA ne fixe pas de seuil général de taille d’entreprise pour déterminer son champ d’application.
Un SaaS autonome, accessible uniquement via un navigateur et sans logiciel ou objet connecté mis à disposition du client, est généralement hors du champ direct du CRA. Cette règle doit toutefois être nuancée : un service de traitement à distance développé sous la responsabilité du fabricant et nécessaire au fonctionnement d’un logiciel distribué ou d’un produit connecté peut faire partie du périmètre du produit concerné.
L’article 14 impose aux fabricants de signaler deux catégories d’événements :
- Les vulnérabilités activement exploitées dans un produit comportant des éléments numériques.
- Les incidents graves ayant un impact sur la sécurité d’un tel produit.
Un incident n’est pas « grave » parce qu’il est simplement gênant ou coûteux. Au sens du CRA, il doit notamment compromettre ou risquer de compromettre la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles/importantes du produit, ou permettre l’introduction ou l’exécution de code malveillant.
Des délais très courts
Le délai court à compter du moment où le fabricant prend connaissance de l’événement. La première alerte n’a pas vocation à être parfaite : elle doit porter sur les faits connus, être prudente, factuelle et traçable, puis être complétée à mesure que les investigations avancent.
Événement |
Dans les 24 heures |
Dans les 72 heures |
Rapport final |
Vulnérabilité activement exploitée |
Alerte précoce : confirmation de l’exploitation active et, si connus, États membres potentiellement concernés |
Notification de vulnérabilité : nature, gravité, impact et mesures correctives ou d’atténuation prises ou envisagées |
Au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation |
Incident grave affectant la sécurité d’un produit |
Alerte précoce : notamment caractère potentiellement illicite ou malveillant et éventuel impact transfrontière |
Notification d’incident : gravité, impact, indicateurs de compromission et premières mesures de traitement |
Dans le mois suivant la notification |
Les délais de 14 jours et d’un mois ne constituent pas deux variantes d’un même délai. Ils correspondent à deux régimes distincts : le premier vise la vulnérabilité activement exploitée ; le second, l’incident grave
Les cinq préparatifs essentiels
1. Cartographier les produits concernés
Maintenez une vue fiable de vos produits, versions, composants et, le cas échéant, services de traitement à distance associés. L’objectif est de pouvoir identifier sans délai le périmètre technique potentiellement touché et les équipes compétentes.
2. Désigner les rôles et les suppléants
Nommez un responsable habilité à déclencher la procédure CRA, ainsi qu’un suppléant. Identifiez également les interlocuteurs sécurité, produit, support, juridique et DPO susceptibles d’intervenir dans la qualification et le traitement de l’événement.
Cette désignation doit être validée par la direction et intégrée à la procédure de gestion de crise : un signalement ne doit pas dépendre de la disponibilité d’une seule personne.
3. Préparer le dossier de première alerte
Préparez un modèle interne permettant de recueillir a minima :
- le produit, les versions et les composants potentiellement concernés ;
- la date et l’heure de détection ou de prise de connaissance ;
- la nature présumée de l’événement ;
- les impacts connus ou plausibles ;
- les premières mesures de confinement, d’atténuation ou de correction ;
- les coordonnées d’un contact opérationnel compétent.
Dès qu’un événement remonte, déclenchez un chronomètre de crise et consignez l’heure exacte à laquelle l’organisation a pris connaissance des faits. Cette donnée est essentielle pour piloter les échéances et démontrer votre diligence.
4. Préparer la notification SRP et le contact CSIRT
La Single Reporting Platform (SRP), mise en place par l’ENISA, est le point d’entrée pour les signalements de vulnérabilités activement exploitées et d’incidents graves au titre du CRA.
La notification est soumise via le point d’entrée du CSIRT désigné comme coordinateur dans l’État membre où le fabricant dispose de son établissement principal dans l’Union. Elle est également mise à disposition de l’ENISA. Il ne faut donc pas raisonner uniquement à partir du pays d’immatriculation, du lieu de fabrication ou de la localisation d’une filiale.
Pour un fabricant dont l’établissement principal dans l’Union est situé en France, le CSIRT coordinateur de référence est le CERT-FR, opéré par l’ANSSI. Vérifiez néanmoins le parcours et les modalités opérationnelles applicables à votre organisation dans la SRP avant la survenance d’un incident.
Organisez les accès au moyen de comptes professionnels et d’une relève documentée. Prévoyez également une solution de continuité en cas d’indisponibilité temporaire de la plateforme, conformément aux instructions opérationnelles de l’ENISA et du CSIRT compétent.
La SRP ne doit pas être confondue avec l’EUVD. La première est le canal de signalement prévu par le CRA ; la seconde est une base européenne consacrée aux vulnérabilités divulguées publiquement. Un signalement CRA n’équivaut donc pas à la divulgation publique immédiate de l’ensemble des détails techniques d’une vulnérabilité.
5. Tester votre chaîne de décision
Rédigez une fiche réflexe d’une page indiquant les personnes à alerter, la décision de notification, les informations à collecter, les preuves à préserver, le modèle de message et les échéances applicables.
Testez ensuite le dispositif à partir d’un scénario réaliste : une vulnérabilité activement exploitée est signalée un vendredi soir sur une version encore utilisée par plusieurs clients. Vos équipes peuvent-elles qualifier le risque, identifier les produits et versions touchés, obtenir la validation nécessaire et transmettre une première alerte utile dans les 24 heures ?
Chronomètre, preuves et sanctions
Dès qu’un événement remonte, déclenchez un chronomètre de crise. Consignez dans votre outil de ticketing ou registre d’incident l’heure exacte à laquelle l’organisation a pris connaissance des faits. Cette information est indispensable pour piloter les échéances de 24 heures, 72 heures, 14 jours ou un mois, et pour démontrer votre diligence en cas de contrôle.
En amont, maintenez à jour :
- La liste des produits, versions et composants critiques.
- Les responsables techniques et contacts support.
- Les procédures de rollback, de correctif et de communication client.
- Les éléments de preuve utiles : journaux, indicateurs de compromission, chronologie, analyses techniques et décisions prises.
- Une nomenclature fiable des produits et versions.
Côté sanctions, les manquements aux obligations de l’article 14 peuvent entraîner des amendes administratives allant jusqu’à 15 millions d’euros ou, pour une entreprise, 2,5% du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu. Les autorités doivent notamment tenir compte de la nature, de la gravité et de la durée du manquement, ainsi que de la taille de l’entreprise.
Le règlement prévoit une dérogation pour les microentreprises et petites entreprises concernant l’amende administrative liée au seul non-respect de l’échéance d’alerte précoce à 24 heures. Cette dérogation ne doit toutefois pas être comprise comme une immunité générale contre les conséquences d’une notification tardive, incomplète ou inexistante.
CRA et RGPD : deux procédures possibles
Le CRA ne remplace pas le RGPD. Lorsqu’un événement est également susceptible d’affecter des données personnelles, l’entreprise peut devoir mener deux procédures en parallèle.
D’une part, le fabricant évalue l’obligation de signalement au titre du CRA via la SRP. D’autre part, le responsable du traitement évalue s’il existe une violation de données personnelles et si celle-ci est susceptible d’engendrer un risque pour les droits et libertés des personnes concernées.
Dans cette hypothèse, l’article 33 du RGPD impose en principe une notification à l’autorité de contrôle compétente la CNIL (pour la France) dans les 72 heures suivant la prise de connaissance de la violation.
Prenons le cas d’un éditeur français de logiciel de santé dont une vulnérabilité activement exploitée permet à un attaquant d’accéder à des dossiers patients. Il doit, sans attendre, qualifier l’événement au regard du CRA et préparer son signalement. En parallèle, il doit analyser l’existence d’une violation de données personnelles, son ampleur, les personnes concernées et le niveau de risque afin de déterminer si une notification à la CNIL est requise.
Les éléments techniques peuvent se recouper, mais les destinataires, objectifs et critères de décision diffèrent. Une notification CRA ne remplace pas une notification RGPD, et inversement.
La cellule de qualification devrait réunir dès les premières heures :
- le responsable sécurité, pour qualifier le risque cyber et piloter la réponse technique ;
- le responsable produit ou technique, pour confirmer les produits, versions et composants affectés ;
- le DPO, pour évaluer l’exposition des données personnelles et les obligations RGPD éventuelles.
Cette coordination réduit les retards, les incohérences entre communications et les angles morts.
Le 11 septembre 2026 n’est pas qu’une échéance réglementaire : c’est un test concret de votre capacité à gérer une crise. Lorsqu’un événement survient, votre organisation doit pouvoir identifier le produit concerné, qualifier les faits, mobiliser rapidement les équipes sécurité, produit et DPO si nécessaire, préserver les éléments utiles et transmettre une première information fiable dans les délais applicables.