Cyber Resilience Act: votre organisation est-elle prête à réagir en 24 heures ?
Face à une vulnérabilité activement exploitée, le défi ne réside pas uniquement dans le respect d’un délai. Il faut détecter l’exploitation, identifier les produits concernés, réunir des preuves, mobiliser les équipes et décider rapidement des premières mesures à prendre.
Depuis le 11 septembre 2026, le Cyber Resilience Act (CRA) fait de cette capacité une exigence concrète pour les fabricants de produits comportant des éléments numériques commercialisés dans l’Union européenne. Mais au-delà de cette échéance réglementaire, la règle des 24 heures constitue surtout un test grandeur nature de la résilience cyber des organisations.
Une entreprise résiliente sait détecter les signaux faibles, limiter les conséquences d’un incident et maintenir sa capacité de décision sous pression.
Les 24 heures comme test de résilience opérationnelle
Lorsqu’une faille est exploitée, une alerte ignorée, une dépendance mal identifiée ou une escalade trop lente peut accroître l’exposition de l’entreprise et de ses clients.
Le délai de 24 heures met ainsi à l’épreuve trois capacités fondamentales : voir, comprendre et agir.
Voir, c’est détecter suffisamment tôt les comportements inhabituels. Comprendre, c’est relier un signal technique aux produits, versions et clients potentiellement touchés. Agir, c’est déclencher une réponse coordonnée sans attendre que toutes les zones d’incertitude aient disparu.
Le temps nécessaire pour prendre connaissance d’une exploitation devient donc un indicateur essentiel. Sans cette mesure, l’organisation ne peut pas évaluer précisément son niveau de préparation.
Ce que le CRA exige à chaque étape du signalement
L’article 14 du Cyber Resilience Act prévoit trois étapes de signalement. Les délais de 24 et 72 heures commencent dès que le fabricant prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave. Le délai applicable au rapport final est calculé différemment selon la situation.
Étape | Délai | Informations à transmettre | Prérequis opérationnels |
Alerte précoce | Dans les 24 heures suivant la prise de connaissance | Signaler l’existence d’une vulnérabilité activement exploitée ou d’un incident grave. Indiquer, le cas échéant, les États membres dans lesquels le produit concerné a été mis à disposition. Pour un incident grave, préciser également s’il est susceptible de résulter d’un acte illicite ou malveillant. | Disposer d’une cartographie fiable des produits, de leurs versions et de leurs marchés de distribution. |
Notification détaillée | Dans les 72 heures suivant la prise de connaissance | Fournir les informations disponibles sur le produit concerné, la nature de la vulnérabilité, de son exploitation ou de l’incident, ainsi qu’une première évaluation. Présenter également les mesures correctives ou d’atténuation prises et celles que les utilisateurs peuvent appliquer. | Pouvoir identifier rapidement le produit concerné, réaliser une première analyse technique et mobiliser les équipes responsables. |
Rapport final | Pour une vulnérabilité : au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Pour un incident grave : dans le mois suivant la notification effectuée sous 72 heures. | Décrire en détail la vulnérabilité ou l’incident, sa gravité et son impact. Selon le cas, préciser les acteurs malveillants identifiés, la cause probable ainsi que les mesures correctives ou d’atténuation appliquées ou en cours. | Avoir achevé l’analyse des causes profondes, évalué l’impact et documenté les mesures correctives déployées. |
Ces obligations impliquent également une coordination en amont de la chaîne d’approvisionnement. Lorsqu’un fabricant découvre une vulnérabilité dans un composant intégré à son produit, y compris un composant open source, il doit en informer la personne ou l’entité qui fabrique ou maintient ce composant.
Il doit également traiter la vulnérabilité et, lorsqu’il a développé un correctif, partager le code ou la documentation correspondante lorsque cela est approprié.
Transformer l’observabilité en système d’alerte précoce
Les avis de sécurité ne suffisent pas toujours. Une exploitation peut commencer avant la publication d’une CVE ou la mise à disposition d’un correctif.
Une stratégie de résilience doit donc rapprocher les journaux, la télémétrie applicative, les alertes réseau, les renseignements sur les menaces et les informations provenant du support ou des fournisseurs.
L’observabilité dépasse alors le simple suivi des performances. La visibilité qu’elle offre sur l’infrastructure, les applications et le réseau aide les équipes à repérer les signes d’une exploitation, à reconstituer le déroulement d’un incident et à préserver les preuves nécessaires à son analyse.
Les alertes doivent toutefois être contextualisées, rapprochées de l’inventaire des produits et hiérarchisées selon la réalité de leur exploitation et leur impact potentiel. Une multiplication des alertes sans contexte peut ralentir la prise de décision au lieu de l’accélérer.
Connaître ses produits pour mesurer l’impact
Lorsqu’une bibliothèque open source est compromise, l’entreprise doit immédiatement pouvoir identifier les produits et les versions qui l’utilisent. Si cette recherche prend plusieurs jours, le niveau de visibilité reste insuffisant pour respecter les délais du CRA.
La nomenclature logicielle, ou SBOM (Software Bill of Materials), recense les composants et les dépendances de chaque produit. Plus qu’un document de conformité, elle constitue un outil de gestion des vulnérabilités et des risques liés aux fournisseurs.
Selon une étude publiée par l’ENISA en juin 2026, 78 % des organisations interrogées avaient commencé leur démarche d’adoption des SBOM. Cependant, 44 % se trouvaient encore au stade du projet pilote ou d’un déploiement limité, tandis que seules 9 % avaient atteint un niveau mature entièrement soutenu par l’automatisation.
Pour être réellement utile, l’inventaire doit être actualisé, lisible par machine et relié aux versions distribuées, à leurs propriétaires, aux marchés concernés ainsi qu’aux correctifs disponibles.
Cette visibilité permet de répondre rapidement à plusieurs questions essentielles : quels produits intègrent le composant vulnérable ? Quelles versions sont concernées ? Où ont-elles été distribuées ? Quels clients pourraient être exposés ? Une mesure corrective est-elle déjà disponible ?
Préparer une chaîne de réponse disponible en continu
La technologie ne suffit pas si personne ne sait qui doit décider. Une vulnérabilité découverte pendant le week-end ou en dehors des heures ouvrées exige un circuit d’escalade disponible en continu.
Les équipes de sécurité, de développement, d’exploitation, de support et les services juridiques doivent connaître leur rôle. Un responsable et son suppléant doivent pouvoir déclencher la réponse, mobiliser les équipes et coordonner les communications.
L’objectif n’est pas de disposer de toutes les réponses dans les premières heures, mais de réunir suffisamment d’éléments fiables pour qualifier la situation, prendre les premières décisions et limiter l’impact de l’incident.
Le dispositif doit également préciser les canaux à utiliser, les personnes à contacter et les informations minimales à fournir à chaque étape. Sans cette préparation, une partie du délai réglementaire risque d’être consacrée à rechercher les bons interlocuteurs plutôt qu’à traiter l’incident.
Un plan de préparation en trois semaines
Les DSI et RSSI peuvent commencer par un sprint ciblant les lacunes les plus critiques de leur dispositif.
Semaine 1 : cartographier le périmètre
Recensez les produits proposés dans l’Union européenne, les entités responsables, les versions maintenues et leurs principaux composants. Repérez les informations dispersées, obsolètes ou incomplètes.
Demandez ensuite combien de temps il faudrait pour retrouver tous les produits contenant une bibliothèque donnée. Une réponse exprimée en jours révèle une priorité immédiate.
Cette première semaine doit permettre de créer une source d’information commune reliant les produits, les composants, les versions, les responsables et les marchés sur lesquels ils sont disponibles.
Semaine 2 : relier les signaux aux responsabilités
Faites converger les alertes issues de la supervision, du réseau, du support et des fournisseurs vers un point de qualification clairement identifié. Définissez les critères d’escalade ainsi que les responsables de chaque décision.
Préparez un formulaire réunissant les informations indispensables : produit et versions concernés, preuve d’exploitation, marchés touchés, impact observé et premières mesures d’atténuation.
Définissez également les modalités de communication avec les équipes internes, les fournisseurs, les clients et les autorités concernées. Ces modèles ne doivent pas figer la réponse, mais réduire le temps consacré à collecter et à structurer les informations.
Semaine 3 : tester le dispositif
Simulez l’exploitation d’une vulnérabilité en dehors des heures ouvrées. Mesurez le temps nécessaire pour détecter le signal, identifier les produits concernés, réunir les équipes et produire une première synthèse exploitable.
Repérez les accès manquants, les inventaires incomplets ou les responsabilités ambiguës. Associez ensuite chaque correction à un responsable et à une échéance.
Évaluez l’exercice à l’aide de quelques indicateurs simples :
le délai avant la première détection ;
le temps nécessaire pour identifier les produits affectés ;
la durée de mobilisation des décideurs ;
le délai de production de l’alerte initiale ;
le niveau de fiabilité des informations recueillies.
Ces mesures donnent aux directions une vision plus concrète de la résilience de l’organisation que la seule existence d’une procédure écrite.
La priorité stratégique des DSI et RSSI
La première priorité consiste à investir dans la visibilité sur les produits et leurs composants. Un inventaire fiable sert à la fois la gestion des vulnérabilités, l’évaluation des fournisseurs, la réponse aux incidents et la préparation aux exigences du CRA.
La deuxième priorité est de désigner un responsable et un suppléant disposant d’un véritable pouvoir de décision. Une organisation ne peut pas agir rapidement si chaque mesure doit attendre la validation d’une personne indisponible.
Enfin, les fournisseurs doivent être intégrés au dispositif. Les délais de notification, les canaux de communication et les informations attendues doivent être clarifiés avant qu’un incident ne survienne.
Le délai de 24 heures ne doit donc pas être perçu uniquement comme une contrainte réglementaire. Il offre un repère concret pour évaluer la capacité de l’organisation à détecter, comprendre et contenir une menace.
La question essentielle devient alors : si l’un de nos produits était activement exploité demain, pourrions-nous prendre une décision fiable avant que l’incident ne prenne de l’ampleur ?
Sources
Commission européenne, obligations de signalement du Cyber Resilience Act.