Cyber Resilience Act : préparer la notification des vulnérabilités exploitées
À partir du 11 septembre 2026, certaines obligations de notification du Cyber Resilience Act deviennent applicables. Les fabricants concernés doivent pouvoir qualifier un signal, conserver les preuves et déclencher un processus réglementaire sans attendre la fin de l’enquête technique.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Le règlement (UE) 2024/2847, dit Cyber Resilience Act, organise la cybersécurité des produits comportant des éléments numériques mis sur le marché de l’Union européenne. Son application générale est prévue à partir du 11 décembre 2027, mais ses obligations de notification s’appliquent dès le 11 septembre 2026. Ce décalage est important : un fournisseur peut ne pas avoir achevé tout son programme de conformité produit et devoir néanmoins être prêt à traiter un événement soumis à notification. Le sujet ne relève donc plus seulement de la feuille de route sécurité. Il faut un dispositif opérationnel, avec des responsabilités définies, des critères de qualification et des traces exploitables.
Tout défaut n’est pas à notifier
Le règlement vise notamment les fabricants de logiciels ou de matériels comportant des éléments numériques. Il ne faut pas en déduire que tout prestataire informatique ou tout service en ligne entre automatiquement dans ce périmètre. Certaines solutions de traitement de données à distance peuvent être incluses lorsqu’elles sont conçues sous la responsabilité du fabricant et que leur absence empêcherait le produit d’assurer une de ses fonctions. Le statut du fournisseur, la manière dont le produit est commercialisé et la répartition réelle des responsabilités doivent donc être établis. De même, une vulnérabilité théorique, une faiblesse détectée par un scanner ou un défaut sans preuve d’exploitation ne deviennent pas automatiquement une vulnérabilité activement exploitée au sens du texte. La qualification doit reposer sur des éléments fiables montrant qu’un acteur malveillant a exploité la faiblesse sans autorisation. Le règlement couvre aussi les incidents graves ayant un effet sur la sécurité du produit. Ces deux catégories suivent un calendrier de notification progressif, dont la première échéance intervient au plus tard vingt-quatre heures après que le fabricant en a eu connaissance.
L’horloge part avant la certitude
- Définir le point de départ. La « prise de connaissance » ne doit pas dépendre de la disponibilité d’un dirigeant ou de la clôture d’une analyse forensique. Les canaux de support, de supervision, de réponse aux incidents et de divulgation de vulnérabilités doivent horodater le premier signal crédible et conserver son origine.
- Séparer qualification et résolution. La notification initiale intervient rapidement et peut être complétée ensuite. Exiger une cause racine certaine avant toute escalade crée un risque mécanique de retard. Le processus doit accepter l’incertitude, indiquer ce qui est confirmé et distinguer les faits des hypothèses.
- Préparer les données attendues. L’équipe doit pouvoir identifier le produit et ses versions affectées, décrire la vulnérabilité ou l’incident, évaluer les conséquences connues et documenter les mesures correctives ou compensatoires. Une nomenclature produit incohérente entre développement, support et contrats rend cet exercice inutilement fragile.
- Relier les sous-traitants au processus. Un composant, une bibliothèque ou une capacité distante peut être exploité sans que le fabricant dispose directement de tous les journaux. Les contrats et procédures d’escalade doivent permettre la remontée rapide des faits, des indicateurs techniques et des mesures prises. Déléguer l’exploitation n’efface pas automatiquement les obligations attachées au rôle de fabricant.
- Organiser les communications. Le signalement réglementaire, l’information des utilisateurs concernés, la publication d’un correctif et la communication publique n’ont ni le même destinataire ni le même niveau de détail. Les fusionner dans un message unique expose soit trop d’informations, soit trop peu. Chaque sortie doit être validée, versionnée et rattachée aux mêmes faits.
Tester le chemin complet
Un document de procédure ne démontre pas que l’organisation saura agir dans le délai. Un exercice utile part d’un signal imparfait reçu par un canal ordinaire : ticket de support, alerte de supervision, message d’un chercheur ou information transmise par un sous-traitant. Il vérifie qui qualifie le périmètre, qui décide de l’escalade, comment sont établies les versions touchées, quelles preuves sont conservées et qui prépare les notifications successives. Il faut également tester les périodes non ouvrées et les produits anciens encore maintenus. Enfin, le Cyber Resilience Act ne remplace pas les autres régimes de notification. Un même événement peut relever d’obligations distinctes, notamment au titre du RGPD, de NIS2 ou de DORA, avec des critères, destinataires et calendriers différents. Leur coordination doit éviter les contradictions sans supposer qu’une notification en vaut automatiquement une autre. L’analyse du périmètre juridique reste à effectuer selon le rôle précis de chaque organisation et les caractéristiques du produit.
Regulation (EU) 2024/2847, known as the Cyber Resilience Act, establishes cybersecurity requirements for products with digital elements placed on the European Union market. The Regulation generally applies from 11 December 2027, but its reporting obligations apply from 11 September 2026. This gap matters: a supplier may not yet have completed its full product compliance programme but must still be ready to handle a reportable event. The issue can therefore no longer remain confined to the security roadmap. It requires an operational process with assigned responsibilities, assessment criteria and usable records.
Not every flaw must be reported
The Regulation notably covers manufacturers of software or hardware products with digital elements. This does not mean that every IT provider or online service automatically falls within its scope. Some remote data processing solutions may be included when they are designed under the manufacturer’s responsibility and their absence would prevent the product from performing one of its functions. The supplier’s legal role, the way the product is marketed and the actual allocation of responsibilities must therefore be established. Likewise, a theoretical vulnerability, a weakness detected by a scanner or a flaw without evidence of exploitation does not automatically qualify as an actively exploited vulnerability under the Regulation. Assessment must be based on reliable evidence that a malicious actor exploited the weakness without authorisation. The Regulation also covers severe incidents affecting the security of a product. These two categories follow staged reporting timelines, with the first deadline falling no later than twenty-four hours after the manufacturer becomes aware of the event.
The clock starts before certainty
- Define the starting point. “Awareness” must not depend on a senior manager being available or a forensic investigation being complete. Support, monitoring, incident response and vulnerability disclosure channels should timestamp the first credible signal and preserve its origin.
- Separate assessment from resolution. The initial report is submitted quickly and can be supplemented later. Requiring a confirmed root cause before escalation creates a direct risk of delay. The process must accommodate uncertainty, state what has been confirmed and distinguish facts from assumptions.
- Prepare the required data. The team must be able to identify the product and affected versions, describe the vulnerability or incident, assess known consequences and document corrective or mitigating measures. Inconsistent product naming across development, support and contracts makes this task unnecessarily fragile.
- Connect subcontractors to the process. A component, library or remote capability may be exploited even when the manufacturer does not directly hold all relevant logs. Contracts and escalation procedures should support the rapid transfer of facts, technical indicators and measures taken. Outsourcing operations does not automatically remove obligations associated with the manufacturer’s role.
- Structure communications. Regulatory reporting, notification of affected users, release of a patch and public communication do not have the same audience or require the same level of detail. Combining them into a single message will either disclose too much or provide too little. Each output should be approved, versioned and tied to the same underlying facts.
Test the complete path
A written procedure does not demonstrate that the organisation can act within the required timeframe. A useful exercise begins with an incomplete signal arriving through an ordinary channel: a support ticket, monitoring alert, message from a researcher or information passed on by a subcontractor. It tests who assesses the scope, who decides to escalate, how affected versions are identified, what evidence is retained and who prepares each successive report. Non-working hours and older products that remain under maintenance should also be tested. Finally, the Cyber Resilience Act does not replace other reporting regimes. The same event may trigger separate obligations under the GDPR, NIS2 or DORA, with different criteria, recipients and timelines. Coordination should prevent contradictions without assuming that one report automatically satisfies another obligation. The legal scope still needs to be assessed against each organisation’s specific role and the characteristics of the product.