Signalement CRA : délais, SRP et rapport final

Depuis le 11 septembre 2026, un fabricant concerné par le Cyber Resilience Act doit signaler certaines vulnérabilités exploitées et certains incidents graves affectant la sécurité de ses produits. La procédure ne consiste pas à envoyer toutes les failles connues sous 24 heures, puis un rapport identique pour chaque situation.

Il faut qualifier l’événement et distinguer deux chronologies. Le point de départ du rapport final n’est notamment pas le même pour une vulnérabilité activement exploitée et pour un incident grave.

Identifier le régime applicable

L’Art. 14(1)–(5) du règlement (UE) 2024/2847 vise deux catégories : la vulnérabilité activement exploitée contenue dans le produit et l’incident grave ayant des répercussions sur sa sécurité.

L’incident est notamment grave lorsqu’il affecte ou peut affecter la capacité du produit à protéger certaines données ou fonctions, ou conduit ou peut conduire à l’introduction ou à l’exécution de code malveillant dans les conditions de l’Art. 14(5). Ne limitez pas votre procédure aux seuls événements ayant déjà provoqué un dommage prouvé chez un client.

La découverte d’une vulnérabilité non exploitée ne relève pas automatiquement de l’alerte obligatoire pour exploitation active. Le texte prévoit aussi un signalement volontaire à l’Art. 15. La gestion des vulnérabilités produit doit permettre de traiter les failles sans toutes les ranger dans la même procédure de notification.

Deux chronologies à conserver séparément

Les délais suivants résultent de l’Art. 14(2) et (4). Les alertes et notifications doivent être envoyées sans retard injustifié, les délais indiqués étant des maxima :

Le rapport final sur une vulnérabilité n’est donc pas dû « 14 jours après la notification complète ». Cette confusion peut conduire à programmer la mauvaise échéance. L’Art. 14(6) permet aussi au CSIRT coordinateur de demander un rapport intermédiaire de situation.

Les informations attendues varient selon l’étape. À 72 heures, documentez notamment la nature générale de l’événement, les informations disponibles et les mesures prises ou accessibles aux utilisateurs, conformément au texte. Signalez les inconnues et le degré de sensibilité pertinent ; ne présentez pas une hypothèse comme un constat définitif.

Utiliser la plateforme unique et le bon destinataire

L’ENISA a mis en service la plateforme unique de signalement, ou SRP. Les notifications de l’Art. 14 passent par cette plateforme et sont adressées au CSIRT coordinateur compétent, avec mise à disposition simultanée à l’ENISA.

L’Art. 14(7) retient notamment l’établissement principal dans l’Union, déterminé par les décisions relatives à la cybersécurité des produits, puis prévoit des règles pour les fabricants sans établissement principal dans l’Union. Vérifiez ce rattachement avant la crise et préparez un suppléant disposant des accès nécessaires.

Le calendrier CRA distingue les fabricants, déjà soumis au signalement, des obligations propres aux intendants de logiciels ouverts prévues par l’Art. 24(3), applicables à partir de décembre 2027.

Informer les utilisateurs et protéger les informations

L’Art. 14(8) prévoit l’information des utilisateurs touchés et, s’il y a lieu, de tous les utilisateurs, ainsi que les mesures correctives ou d’atténuation nécessaires. Une transmission à l’autorité ne remplace pas cette communication.

Préparez des messages adaptés : versions concernées, action attendue, mesure provisoire, canal de mise à jour et limites connues. Conservez les versions successives pour éviter qu’un ancien avis continue de circuler sans correction.

Les possibilités de retarder certaines diffusions prévues à l’Art. 16 sont encadrées et impliquent le CSIRT coordinateur. Elles ne constituent pas une autorisation générale donnée au fabricant de reporter son propre signalement parce que le dossier est sensible.

Une fiche de suivi utilisable en incident

Voici une structure de travail proposée pour chaque événement :

1. Produit, version, rôle de l’entreprise et personnes chargées de qualifier l’événement.
2. Heure de connaissance, faits disponibles, incertitudes et motif de qualification.
3. Échéances calculées séparément et responsable de chaque envoi.
4. Références des dépôts, pièces transmises et niveau de sensibilité.
5. Mesures disponibles, information des utilisateurs et suivi des autres obligations.

Les preuves doivent permettre de reconstituer les décisions. Le dossier technique CRA et les informations de support aident à identifier les versions et leurs dépendances.

Coordonner le CRA, le RGPD et NIS2

Une exploitation peut aussi entraîner une violation de données personnelles. L’Art. 33(1) du RGPD prévoit sa propre notification à l’autorité de protection des données, avec une exception lorsque la violation n’est pas susceptible d’engendrer un risque. L’Art. 34 distingue la communication aux personnes en cas de risque élevé et ses exceptions.

La procédure de notification des violations doit rester identifiable. Pour NIS2, vérifiez également l’assujettissement et les dispositions nationales applicables ; un même événement ne déclenche pas automatiquement trois notifications pour toutes les entreprises.

Le régime des sanctions CRA, applicable à partir du 11 décembre 2027, doit être lu séparément avec ses exceptions. L’Art. 64(2) rattache les obligations de l’Art. 14 au plafond de 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial, le plus élevé pour une entreprise. Le présenter uniformément comme un plafond de 5 millions ou 1 % serait inexact. L’Art. 64(10), corrigé le 2 juillet 2025, prévoit notamment une exception aux amendes pour le dépassement du délai d’alerte de 24 heures par les microentreprises et petites entreprises ; cela ne supprime pas leur obligation de signaler.

Préparer un dépôt lorsque l’enquête reste ouverte

Le dossier de signalement doit évoluer sans perdre son historique. Avant chaque transmission, vous pouvez tenir un tableau distinguant le fait observé, sa source, l’heure à laquelle il est connu et les conclusions encore à confirmer. Cette méthode aide à expliquer pourquoi une première notification est moins détaillée que le rapport final.

Par exemple, « un client signale une activité inhabituelle » et « l’exploitation de la vulnérabilité est établie » ne décrivent pas le même état de connaissance. Documentez les éléments qui conduisent à qualifier l’événement. La recherche d’une validation interne ne doit pas servir à décaler artificiellement le point de départ légal. À l’inverse, un score de criticité ou une rumeur ne suffit pas à établir tous les critères du signalement obligatoire.

Répartissez les tâches avant l’urgence : l’équipe technique décrit le produit et les faits ; un responsable rassemble les informations ; une personne habilitée effectue la transmission ; un suppléant peut reprendre le dossier. Faites apparaître les questions non résolues dans le document de travail. Une formule comme « aucune conséquence identifiée à ce stade » ne doit pas devenir « aucune conséquence » lors de la validation du message.

Cas fictif : deux rapports finaux, deux échéances

Dans cet exercice entièrement fictif, le fabricant Anémone prend connaissance d’une vulnérabilité activement exploitée le 28 septembre 2026 à 8 h UTC. Il met une mesure d’atténuation à disposition le 30 septembre à 15 h UTC. Sous ces hypothèses, les maxima de 24 et 72 heures se situent les 29 septembre et 1er octobre à 8 h UTC. L’obligation d’agir sans retard injustifié demeure ; ce ne sont pas des horaires d’envoi à attendre.

Le rapport final de vulnérabilité est dû au plus tard le 14 octobre à 15 h UTC, quatorze jours après la disponibilité de la mesure. Il faut donc conserver la preuve de cette disponibilité et préciser quelle version et quel périmètre la mesure couvre. Sa diffusion ne démontre pas que chaque utilisateur l’a appliquée. Le suivi des installations et la préparation du rapport répondent à des questions différentes.

Supposons séparément qu’un incident grave soit notifié au titre de l’Art. 14(4)(b) le 29 septembre à 10 h UTC. Son rapport final est dû dans le mois suivant cette présentation, soit le 29 octobre à 10 h UTC dans cet exemple. Le calcul part de l’envoi effectif de cette notification ; il ne repart pas automatiquement de l’expiration du maximum de 72 heures. Conservez deux lignes de suivi si les deux qualifications concernent le même dossier.

Ces horaires servent uniquement à comprendre les calculs. L’exercice ne constitue ni un signalement effectué ni une qualification d’événement réel.

Relire ce qui est effectivement transmis

Avant le dépôt, rapprochez le texte, les pièces jointes et les références produit. Une correction décrite pour une version ne doit pas être présentée comme disponible pour toute la gamme. Vérifiez aussi que les pièces n’exposent pas inutilement des identifiants, des secrets d’accès ou des données de clients. Le caractère sensible du dossier appelle des précautions de transmission ; il ne permet pas d’omettre les informations requises.

Après l’envoi, conservez la copie transmise, son horodatage et les références disponibles permettant de retrouver le dépôt. Un brouillon approuvé en interne ne prouve pas la transmission. Inscrivez les demandes complémentaires, les changements de qualification et les nouvelles mesures dans le même historique, avec une personne chargée de leur suivi.

Enfin, préparez une communication aux utilisateurs cohérente avec les faits connus et adaptée à leurs actions possibles. Si les premières consignes changent, identifiez ce qui est remplacé et les destinataires à prévenir. La clôture du rapport ne dispense pas de poursuivre le traitement de la vulnérabilité ni le suivi des informations utiles aux utilisateurs.

Ce qu’il faut retenir

• Distinguez vulnérabilité activement exploitée et incident grave.
• Les rapports finaux ont des points de départ différents.
• Préparez les accès SRP, le rattachement et les suppléants avant l’urgence.
• Tracez les faits, les inconnues, les envois et les communications aux utilisateurs.

FAQ

Toute faille critique déclenche-t-elle une alerte sous 24 heures ?

La criticité technique seule ne suffit pas à qualifier une vulnérabilité activement exploitée. Examinez les faits et, séparément, les critères d’un incident grave.

Le rapport final est-il toujours dû après 14 jours ?

Non. Pour une vulnérabilité exploitée, le délai court après disponibilité d’une mesure de correction ou d’atténuation. Pour un incident grave, il est d’un mois après la notification prévue à 72 heures.

Une notification CRA remplace-t-elle celle à la CNIL ?

Ne le présumez pas. Les obligations RGPD ont leur propre champ, leurs conditions et leurs destinataires.

Recevez nos analyses sur les obligations cyber et la protection des données.

Thiébaut Devergranne, docteur en droit et praticien du droit des technologies depuis plus de vingt ans.