Cyber Resilience Act : les notifications dès le 11 septembre 2026

Une entreprise de logiciels apprend qu’une vulnérabilité de son produit est déjà utilisée dans des attaques réelles. À compter du 11 septembre 2026, si le produit et l’entreprise relèvent du Cyber Resilience Act, la réponse ne se limite pas à publier une mise à jour de sécurité : une procédure précise de notification s’applique. Le premier délai maximal est de 24 heures après la prise de connaissance de l’exploitation active.

Pour une entreprise grecque qui développe des applications ou fournit des appareils connectés, les questions pratiques sont les suivantes : qui identifie l’événement, qui est informé en interne et qui transmet la notification dans les délais ?

Ce qui commence en septembre et ce qui reste prévu pour 2027

Le CRA est le règlement (UE) 2024/2847. Il s’applique directement dans les États membres, donc également en Grèce. Ses principales exigences concernant les produits s’appliquent généralement à compter du 11 décembre 2027. Toutefois, les obligations de notification des fabricants prévues à l’article 14 commencent plus tôt, le 11 septembre 2026.

La période transitoire précédant la conformité complète ne permet pas de reporter la préparation des notifications. La Commission distingue expressément les deux dates dans sa présentation officielle du CRA.

Quels produits et quelles entreprises sont concernés ?

Le CRA couvre les produits logiciels et matériels mis à disposition sur le marché de l’UE dont l’utilisation prévoit une connexion de données directe ou indirecte avec un appareil ou un réseau. Il peut s’agir d’une application mobile, d’un programme installé, d’un appareil connecté ou d’un composant vendu séparément. La personne qui fait développer un produit et le commercialise sous son propre nom ou sa propre marque peut également être un fabricant.

La simple utilisation d’un programme ne transforme pas une entreprise en fabricant. De même, un site de présentation ou une application fonctionnant exclusivement dans un navigateur, sans prendre en charge une fonction d’un produit couvert, ne relève pas automatiquement du CRA. À l’inverse, un traitement de données à distance nécessaire, sous la responsabilité du fabricant, peut faire partie du produit.

Les logiciels libres et ouverts fournis en dehors d’une activité commerciale sont exclus du champ du CRA. Cela n’exempte pas automatiquement tous les produits contenant des composants ouverts. La mention « gratuit » ne suffit pas : il faut examiner les modalités de fourniture et d’exploitation économique. Les intendants de logiciels ouverts sont soumis à un régime distinct, avec les obligations correspondantes à partir du 11 décembre 2027. Il existe aussi des exclusions sectorielles, notamment pour les produits couverts par certaines règles de l’UE sur les dispositifs médicaux. Les lignes directrices de la Commission du 27 juillet 2026 aident à mener une évaluation individualisée.

Quand la notification devient-elle obligatoire ?

L’article 14 couvre deux catégories :

• Vulnérabilité activement exploitée : des éléments fiables démontrent qu’un acteur malveillant a exploité la vulnérabilité sans l’autorisation du propriétaire du système.
• Incident grave ayant une incidence sur la sécurité du produit : les critères de l’article 14, paragraphe 5, sont remplis, par exemple une incidence réelle ou possible sur la protection de données ou de fonctions importantes, ou la possibilité d’introduire ou d’exécuter un code malveillant.

Un dysfonctionnement ordinaire ou la possibilité théorique d’une attaque ne suffit pas, à lui seul, à établir une exploitation active. Une évaluation technique et la conservation des éléments probants sont nécessaires. Les critères figurent aux articles 3 et 14 du règlement.

Les délais de 24 heures, de 72 heures et du rapport final

Les deux premières communications sont transmises sans retard injustifié, dans les délais maximaux ci-dessous. Les 72 heures courent à partir de la même prise de connaissance, et non à partir de la communication précédente.

Le délai du rapport final a donc un point de départ différent selon la catégorie. La notification des 72 heures comprend les informations disponibles et les mesures de réponse ; elle ne suppose pas que toutes les investigations techniques soient terminées. Voir la synthèse de la Commission sur les obligations de notification.

Un exemple pour ne pas confondre les dates

Supposons que le fabricant d’une application couverte prenne connaissance d’une exploitation active le lundi 14 septembre 2026 à 10 h 00. L’alerte précoce doit être transmise au plus tard le 15 septembre à 10 h 00. Le délai maximal correspondant à la notification des 72 heures expire le 17 septembre à 10 h 00.

Si la première mesure corrective ou d’atténuation devient disponible le 18 septembre, le rapport final doit être transmis au plus tard le 2 octobre. L’entreprise n’attend pas que le correctif soit prêt pour envoyer les premières notifications.

Cet exemple concerne une vulnérabilité. Pour un incident grave, le mois prévu pour le rapport final court à compter de la transmission de la notification de l’étape des 72 heures. Les dates de l’exemple sont hypothétiques et se rapportent au même fuseau horaire.

Où transmettre la notification et que faut-il préparer ?

La procédure passe par la plateforme unique de notification du CRA, la Single Reporting Platform — SRP. Le CSIRT coordinateur compétent et l’ENISA en sont destinataires selon les règles du règlement. Dans ses instructions du 8 septembre, l’ENISA situe le début de fonctionnement au 11 septembre 2026. Cela ne permet pas d’affirmer que la plateforme est déjà disponible pour les transmissions ordinaires.

Pour le fabricant, une vérification pratique de la préparation comprend :

1. Un inventaire des produits : versions, responsables, composants critiques et marchés de distribution.
2. Un circuit d’alerte clair : qui reçoit les signalements des clients ou des chercheurs et qui les évalue immédiatement ?
3. Un responsable et un suppléant : compétence pour transmettre, coordonnées disponibles et préparation d’un compte EU Login personnel avec authentification multifacteur.
4. Un dossier de l’événement : moment de la prise de connaissance, éléments techniques, décisions, transmissions et date de disponibilité des mesures.
5. Des informations prêtes pour les utilisateurs : version touchée et actions concrètes qu’ils peuvent effectuer.
6. Un exercice avec un événement hypothétique : vérifier que la coordination interne respecte les délais légaux.

Il s’agit d’une proposition pratique d’organisation. L’ENISA recommande d’entamer l’enregistrement du fabricant dans la SRP lorsqu’une notification doit être transmise, avec un compte EU Login du représentant déjà actif. Les détails doivent être vérifiés dans les instructions officielles actuelles de la plateforme.

Pourquoi vérifier séparément le RGPD et NIS2 ?

Une notification au titre du CRA ne doit pas être considérée comme l’exécution automatique de toutes les autres obligations. Le RGPD traite des violations de données à caractère personnel. Son article 33 prévoit, lorsque cela est requis, une notification par le responsable du traitement à l’autorité de contrôle compétente, sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance. Une exception s’applique si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. Voir le guide du Comité européen de la protection des données.

NIS2 concerne certaines catégories d’entités et les incidents importants affectant leurs services. L’application du cadre national correspondant doit être vérifiée séparément. Un même événement peut nécessiter plusieurs évaluations et notifications, avec des destinataires et des contenus différents. La Commission présente son champ d’application sur la page officielle consacrée à NIS2.

Réponses courtes aux questions fréquentes

Les produits déjà commercialisés sont-ils concernés ?

Oui. Les obligations de notification couvrent aussi les produits relevant du champ d’application et mis sur le marché avant le 11 décembre 2027. Une commercialisation antérieure ne suffit pas à justifier une exemption.

Faut-il signaler rétroactivement toutes les anciennes vulnérabilités ?

L’ENISA précise qu’il n’existe pas d’obligation rétroactive pour une exploitation active déjà connue du fabricant avant le 11 septembre 2026. Le moment de la prise de connaissance est déterminant, et non le seul âge du défaut.

Informer les autorités suffit-il ?

L’article 14, paragraphe 8, prévoit également d’informer les utilisateurs touchés, notamment des mesures nécessaires pour réduire les risques. Un rapport technique aux autorités et des instructions compréhensibles pour l’utilisateur répondent à des besoins différents.

Pour les situations transitoires, voir les réponses de l’ENISA et les articles 14, 69 et 71 du CRA.

Équipe éditoriale de Nomika Epilekta
Sources officielles vérifiées le 9 septembre 2026.

Cet article a été rédigé avec une assistance par intelligence artificielle et un recoupement des sources officielles citées. Il fournit une information juridique générale et ne remplace pas l’analyse d’un cas particulier. Sources vérifiées le 9 septembre 2026.