La loi sur la cyber-résilience (Cyber Resilience Act) est souvent associée avant tout à l’année 2027. Cela se comprend tout à fait, car la plupart des exigences du règlement européen s’appliquent à compter du 11 décembre 2027. Cependant, ceux qui en déduisent qu’il reste encore suffisamment de temps d’ici là négligent un point essentiel : les obligations de déclaration prévues par la CRA concernant certaines vulnérabilités et certains incidents de sécurité s’appliquent déjà depuis le 11 septembre 2026. Pour les fabricants concernés, cela signifie qu’ils doivent dès aujourd’hui être en mesure de procéder à une évaluation fiable dans des délais courts et de communiquer les informations requises.
Il ne s’agit pas seulement d’utiliser un portail de signalement. Les entreprises ont besoin de responsabilités clairement définies, d’une gestion efficace des vulnérabilités et d’un dispositif de réponse aux incidents opérationnel. En effet, le premier délai est fixé à 24 heures au maximum à compter du moment où le fabricant a connaissance d’un fait soumis à l’obligation de déclaration. Si l’on attend ce moment-là pour déterminer quels produits sont concernés, qui est habilité à prendre les décisions et où se trouvent les informations pertinentes, on perd un temps précieux.
La loi sur la cyber-résilience n’entrera pas en vigueur seulement à partir de 2027
La loi sur la cyber-résilience, le règlement (UE) 2024/2847, établit des exigences de cybersécurité contraignantes à l’échelle européenne pour les produits comportant des éléments numériques. Sont en principe concernés de nombreux produits matériels et logiciels qui sont directement ou indirectement connectés à un appareil ou à un réseau. Il peut s’agir, par exemple, de machines connectées, d’appareils IoT, de routeurs, de caméras de sécurité, d’applications mobiles ou de solutions logicielles autonomes. Pour déterminer si un produit donné relève effectivement du champ d’application, il convient de se référer au règlement et à ses modalités de mise sur le marché de l’UE.
Le calendrier de mise en œuvre est ici important. Le règlement est déjà entré en vigueur en décembre 2024. Les dispositions relatives aux autorités de notification s’appliquent depuis juin 2026. Les exigences détaillées relatives aux produits s’appliqueront pour l’essentiel à compter du 11 décembre 2027. Toutefois, l’article 14, et par conséquent les obligations de déclaration au titre de la CRA, s’appliquent aux fabricants depuis le 11 septembre 2026.
Ces obligations ne se limitent pas automatiquement aux produits qui ne seront mis sur le marché qu’à partir de fin 2027. Selon les dernières indications de la Commission européenne et de l’ENISA, les produits comportant des éléments numériques déjà commercialisés auparavant peuvent également être concernés, dans la mesure où ils relèvent du champ d’application du règlement. Les fabricants ne devraient donc pas évaluer leurs gammes de produits uniquement en fonction des évolutions futures.
Quels événements doivent être signalés ?
Toutes les vulnérabilités détectées et tous les dysfonctionnements techniques ne donnent pas automatiquement lieu à une notification. L’article 14 distingue deux catégories principales : les vulnérabilités activement exploitées et les incidents de sécurité graves ayant des répercussions sur la sécurité d’un produit comportant des éléments numériques.
On parle de vulnérabilité activement exploitée lorsqu’il existe des indices fiables indiquant qu’un acteur malveillant a effectivement exploité cette vulnérabilité sans le consentement du propriétaire du système. La simple possibilité théorique d’une attaque ou la publication d’une preuve de concept ne suffit donc pas nécessairement. Néanmoins, une gestion efficace des vulnérabilités doit permettre de rassembler et d’évaluer rapidement les informations provenant de différentes sources. Ces informations peuvent, par exemple, provenir de votre propre système de surveillance de la sécurité, de clients, de chercheurs en sécurité, de prestataires de services ou d’alertes accessibles au public.
Un incident de sécurité grave affecte la sécurité du produit et peut notamment compromettre sa disponibilité, son authenticité, son intégrité ou sa confidentialité. Pour déterminer si un incident répond aux critères légaux, il convient de l’évaluer au cas par cas en fonction de ses répercussions. C’est précisément à ce stade que l’analyse technique, la qualification juridique et la réponse aux incidents s’articulent. Une entreprise a besoin d’informations suffisantes pour pouvoir prendre une décision rapide, mais elle ne doit pas non plus retarder l’évaluation jusqu’à ce que chaque détail technique ait été définitivement clarifié.
Un exemple tiré de la pratique
Un fabricant de capteurs connectés reçoit de la part d’un client des données de journalisation indiquant qu’une vulnérabilité du micrologiciel de l’appareil a été exploitée avec succès. Dans un premier temps, on ignore quelles versions du produit sont concernées et si d’autres clients ont été attaqués. Néanmoins, le délai ne commence pas à courir seulement à l’issue de l’enquête informatique. Ce qui est déterminant, c’est le moment où le fabricant a pris connaissance de l’exploitation active de cette faille.
Dans une telle situation, le service chargé de la gestion des vulnérabilités doit enregistrer le signalement, identifier les versions des produits concernées et consigner les informations disponibles. Parallèlement, l’équipe chargée de la réponse aux incidents évalue les répercussions techniques, les contre-mesures possibles et la suite de la remontée de l’information. L’instance responsable doit ensuite déterminer si les conditions requises pour le signalement sont remplies et veiller à ce que celui-ci soit transmis dans les délais impartis.
24 heures, 72 heures et le rapport final
Les obligations de déclaration prévues par la CRA prévoient une procédure par étapes. La première alerte doit être transmise sans retard injustifié et au plus tard dans les 24 heures suivant la prise de connaissance des faits. Elle a pour but, dans un premier temps, d’attirer l’attention sur l’événement et ne contient que les informations nécessaires ou disponibles à ce moment-là.
Un rapport complémentaire doit être transmis dans un délai maximal de 72 heures. En cas d’exploitation active d’une vulnérabilité, il convient notamment de fournir des informations générales sur le produit concerné, la nature de la vulnérabilité et son exploitation, ainsi que sur les mesures correctives déjà mises en œuvre ou envisageables. En cas d’incident de sécurité grave, des informations supplémentaires et une première évaluation de l’incident sont requises.
Un rapport final est ensuite prévu. En cas de vulnérabilités activement exploitées, ce rapport doit être remis au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’un correctif. En cas d’incidents de sécurité graves, le délai applicable est en principe d’un mois à compter de la notification initiale dans les 72 heures. Cette approche par étapes tient compte du fait que, souvent, on ne dispose pas encore d’une vue d’ensemble complète de la situation au cours des premières 24 heures. Elle ne dispense toutefois pas les fabricants d’agir de manière structurée et transparente dès le début.
Les déclarations s’effectuent via la plateforme unique de signalement (Single Reporting Platform) gérée par l’ENISA. Les fabricants y sélectionnent l’équipe de coordination chargée de la réponse aux incidents de sécurité informatique (CSIRT) compétente. Le choix du CSIRT compétent dépend en principe du siège social au sein de l’UE et du lieu où sont principalement prises les décisions relatives à la cybersécurité des produits. La préparation organisationnelle implique donc également de déterminer qui, au sein de l’entreprise, est habilité à effectuer la déclaration sur le plan technique et qui le remplace en cas d’absence.
Pourquoi une liste de contacts ne suffit-elle pas à elle seule ?
Le délai de 24 heures montre clairement que la capacité à signaler les incidents est un processus et non un simple document. Une liste de contacts peut s’avérer utile, mais elle ne remplace ni une gestion rigoureuse des vulnérabilités, ni une procédure d’intervention en cas d’incident bien rodée. Plusieurs services de l’entreprise doivent collaborer dans un délai très court : le service de développement de produits connaît les versions et les composants, le service de sécurité informatique analyse les indications techniques, le service juridique ou de conformité évalue les exigences réglementaires et le service de communication d’entreprise prépare, si nécessaire, les informations destinées aux clients et aux partenaires.
Les points de relais mal définis constituent un point particulièrement critique. Si une équipe d’assistance détecte une attaque potentielle, il faut déterminer à quel moment et à qui elle doit transmettre cette information. Si un chercheur en sécurité externe signale une vulnérabilité, l’entreprise doit disposer d’un point de réception surveillé et d’un processus d’évaluation bien défini. Si un composant tiers est concerné, il doit être possible de déterminer rapidement dans quels produits et versions de l’entreprise il est utilisé.
Un inventaire fiable des produits en constitue la base. Il ne doit pas seulement contenir les noms des produits, mais également répertorier les versions, les composants logiciels, les responsables, les périodes de support et les dépendances pertinentes. Une nomenclature logicielle (Software Bill of Materials) peut faciliter cette analyse, car elle permet d’associer plus facilement les composants tiers concernés à des produits concrets. Elle ne remplace toutefois pas l’évaluation technique visant à déterminer s’il existe effectivement une obligation de déclaration dans chaque cas particulier.
C’est ainsi que naît une véritable volonté de signalement
Un processus applicable dans la pratique commence par une définition claire des rôles. Les entreprises doivent déterminer qui reçoit les signalements, qui est chargé de l’évaluation technique, qui prend la décision juridique et qui transmet le signalement. Des remplaçants doivent être désignés pour chacun de ces rôles. En outre, il convient de documenter les informations requises au cours des différentes étapes du signalement, ainsi que les systèmes à partir desquels elles peuvent être obtenues.
La gestion des vulnérabilités doit être intégrée à l’inventaire des produits, à la communication avec les clients et aux processus de développement. C’est la seule façon pour les responsables d’identifier les versions concernées, les mesures correctives disponibles et la manière d’informer les utilisateurs. Parallèlement, la réponse aux incidents doit être complétée par des scénarios spécifiques aux produits. Un plan d’urgence informatique classique, qui ne prend en compte que l’infrastructure interne, ne suffit pas lorsqu’un incident affecte la sécurité des produits livrés.
Des exercices réguliers permettent de vérifier si les procédures définies fonctionnent également en situation de pression. Un scénario approprié pourrait débuter par un signalement d’un client concernant une vulnérabilité qui serait en train d’être exploitée. L’équipe devrait alors évaluer la plausibilité de cette information, identifier les produits concernés, consigner la date à laquelle elle en a pris connaissance et préparer une décision dans un délai simulé. Ce type d’exercice met souvent en évidence des lacunes : absence d’interlocuteurs, données produit incomplètes, décideurs injoignables ou incertitude quant à la procédure de signalement.
Les résultats de ces exercices devraient déboucher sur des mesures d’amélioration concrètes. La loi sur la cyber-résilience (Cyber Resilience Act) n’exige certes pas une connaissance parfaite de tous les détails dans un délai de 24 heures. Elle suppose toutefois que les fabricants agissent sans retard injustifié et soient en mesure de transmettre de manière structurée les informations disponibles à chaque instant.
Conclusion : le compte à rebours a déjà commencé
La loi sur la cyber-résilience ne concerne pas uniquement l’avenir, à savoir fin 2027. Les premières obligations particulièrement exigeantes sur le plan opérationnel sont déjà en vigueur. Depuis le 11 septembre 2026, les fabricants concernés sont tenus de signaler, dans des délais très courts, les vulnérabilités activement exploitées et les incidents de sécurité graves via la plateforme européenne de signalement.
Les obligations de déclaration CRA ne peuvent être respectées que si les informations relatives aux produits, les responsabilités et les procédures d’escalade sont clairement définies avant la survenue d’un incident grave. Les entreprises doivent donc vérifier si les indications pertinentes sont détectées de manière fiable, qui évalue l’obligation de déclaration, comment le moment de la prise de connaissance est consigné et qui est habilité à soumettre une déclaration dans les délais impartis.
Syngenity® GmbH aide les organisations à intégrer de manière structurée les exigences du règlement européen dans leurs processus existants en matière de sécurité et de conformité. Cela comprend l’évaluation de l’impact, la définition de rôles clairs et de procédures d’escalade, ainsi que le perfectionnement des processus de gestion des vulnérabilités et des incidents.
En effet, la volonté de signaler un incident ne naît pas seulement lorsque le délai de 24 heures a déjà commencé à courir. La question décisive est donc la suivante : votre entreprise serait-elle aujourd’hui en mesure de prendre la bonne décision et d’engager les démarches nécessaires dans un délai de 24 heures ?
