Règlement sur la cyberrésilience : quoi signaler et à partir de quand

Selon la page de la Commission européenne consacrée aux obligations de signalement, l’obligation prévue par le règlement sur la cyberrésilience (CRA, selon son sigle anglais) s’applique aux fabricants depuis le 11 septembre 2026. Cette date est importante, mais les documents fournis ne permettent pas d’établir qu’une modification législative ou une nouvelle règle vient d’être annoncée. Le sujet se comprend donc mieux comme un guide de mise en œuvre que comme une actualité portant sur une modification récente. Commission européenne : obligations de signalement.

L’obligation concerne deux situations : les vulnérabilités activement exploitées et les incidents graves affectant la sécurité d’un produit comportant des éléments numériques. Elle n’impose pas de signaler chaque défaut, alerte ou vulnérabilité détecté au cours du développement. Le seuil est important : les fabricants doivent définir un processus de classification et de réponse avant de recevoir un signalement urgent. Règlement (UE) 2024/2847, texte publié au Journal officiel.

La date ultérieure d’application générale du règlement ne doit pas être confondue avec ce début spécifique. La Commission indique que les obligations de signalement des fabricants ont commencé en septembre 2026, tandis que le règlement prévoit d’autres dates pour différentes obligations et différents acteurs. Il faut vérifier l’application au regard de l’article concerné, sans la déduire d’une date générale unique.

Le premier cas est celui d’une vulnérabilité faisant l’objet d’une exploitation active. La simple existence d’un défaut, même susceptible d’avoir des conséquences pour la sécurité, ne suffit pas à démontrer que ce critère est rempli. Le second cas concerne les incidents graves ayant une incidence sur la sécurité du produit. La Commission présente ces deux catégories comme relevant de l’obligation de signalement des fabricants. Commission européenne : obligations de signalement.

Cette distinction permet de séparer le signalement réglementaire de la gestion courante des vulnérabilités. Un fabricant doit traiter et corriger les problèmes de sécurité pendant tout le cycle de vie du produit, mais l’obligation décrite ici se déclenche dans les cas précis prévus par le CRA. En cas de doute sur le fait qu’une situation donnée atteigne le seuil, une documentation secondaire ne remplace ni le texte juridique ni une évaluation juridique de l’incident.

D’après le résumé de la Commission, le CRA vise les produits comportant des éléments numériques mis à disposition sur le marché de l’Union. Il ne se limite pas aux appareils connectés utilisés à domicile : son champ couvre également les logiciels et les composants, même si la classification d’un produit donné doit être vérifiée au regard du texte intégral et de ses exclusions. Commission européenne : résumé du texte législatif.

La séquence commence lorsque le fabricant prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave. La Commission prévoit une alerte précoce dans un délai maximal de 24 heures et un signalement complet dans un délai maximal de 72 heures. Ces délais ne courent pas à compter de la publication d’un correctif, ni de la découverte du problème par un tiers si le fabricant n’en a pas encore connaissance, selon le point de départ résumé par la Commission. Commission européenne : obligations de signalement.

Un rapport final est ensuite requis, mais le point de référence varie selon le cas. Pour les vulnérabilités activement exploitées, le délai est de 14 jours à compter de la disponibilité d’une mesure corrective. Pour les incidents graves, il est d’un mois à compter du signalement effectué dans les 72 heures. Il ne faut pas ramener les deux cas à un calendrier unique : la nature du cas détermine le calcul de l’étape finale.

Les délais et leurs points de départ proviennent du résumé de la Commission européenne ; pour un cas réel, il faut consulter l’article 14 du règlement et les consignes opérationnelles en vigueur. Règlement (UE) 2024/2847.

L’obligation incombe au fabricant. La Commission précise que le signalement est effectué une seule fois par l’intermédiaire de la plateforme unique de signalement du CRA et adressé au CSIRT désigné comme coordinateur dans l’État membre où le fabricant a son établissement principal. Les informations sont également mises à la disposition de l’ENISA, conformément au mécanisme décrit par la Commission. Commission européenne : obligations de signalement.

L’ENISA dispose d’une page consacrée à la Single Reporting Platform (SRP) et publie des documents d’orientation relatifs à l’inscription et à la transmission des signalements. Ces documents aident à comprendre le canal, mais l’existence d’une page ou d’instructions d’utilisation ne prouve pas à elle seule que toutes les fonctions sont accessibles à tous les utilisateurs à tout moment. Il convient de vérifier la disponibilité opérationnelle directement sur la plateforme et dans les instructions officielles en vigueur. ENISA : Single Reporting Platform.

Pour les équipes produit et sécurité, la conséquence pratique est organisationnelle : elles doivent pouvoir détecter un cas, le faire remonter, consigner le moment où elles en ont eu connaissance et décider rapidement s’il relève de l’une des catégories à signaler. Il ne s’agit pas d’une liste supplémentaire d’exigences textuelles, mais d’une déduction opérationnelle à partir de délais qui commencent lorsque le cas est connu. Il est utile de désigner des responsables et de préparer la coordination entre sécurité, produit, assistance et conseil juridique.

La Commission indique que les open-source software stewards sont soumis aux obligations de signalement correspondantes à partir du 11 décembre 2027, conformément à l’article 24(3) et au calendrier de l’article 71(2). Cette date diffère du début d’application des obligations des fabricants, qui a eu lieu en septembre 2026. Commission européenne : obligations de signalement.

Il ne faut pas considérer automatiquement comme steward toute personne contribuant à un projet open source, ni supposer que le calendrier applicable aux fabricants s’applique sans changement à chaque projet communautaire. La qualification dépend des définitions et des conditions prévues par le règlement. Le résumé officiel aide à situer la question, mais le texte publié au Journal officiel constitue la référence juridique pour déterminer le champ applicable à une situation donnée. Règlement (UE) 2024/2847.

Pour les organisations qui développent ou maintiennent des logiciels open source, la démarche prudente consiste à identifier la personne qui exerce la fonction concernée et à vérifier si le travail répond aux conditions prévues par le CRA. La date future laisse du temps pour préparer les processus, mais ne permet pas d’anticiper une qualification juridique sans examiner l’activité concrète.

Les informations officielles permettent d’établir le calendrier, les catégories générales et le canal de signalement. Elles ne suffisent pas, à elles seules, à résoudre toutes les subtilités techniques d’une vulnérabilité ou d’un incident donné. Pour prendre une décision documentée, l’équipe responsable peut procéder aux vérifications initiales suivantes :

• Identifier le produit et le responsable : vérifier s’il s’agit d’un produit comportant des éléments numériques entrant dans le champ du règlement et déterminer qui agit en qualité de fabricant.
• Déterminer la situation : distinguer une vulnérabilité activement exploitée d’un incident grave et documenter les indices disponibles.
• Consigner le moment où le cas a été connu : conserver la chronologie permettant d’appliquer les délais à partir du point de départ indiqué.
• Consulter la procédure officielle : examiner l’article 14 et les informations actuelles de la SRP, et faire remonter le cas lorsque sa qualification n’est pas claire.

Le règlement ne transforme pas chaque défaut en signalement automatique, mais il est également déconseillé d’attendre la fin d’une enquête pour commencer à analyser les délais. La fenêtre de 24 heures rend importante l’existence d’un processus d’évaluation précoce. Il s’agit d’une conséquence pratique des délais légaux, et non d’une mesure du temps nécessaire aux entreprises ni de l’affirmation qu’une procédure interne supplémentaire serait légalement obligatoire.