Signalement des vulnérabilités : les obligations du Cyber Résilience Act

Le Cyber Résilience Act (règlement (UE) 2024/2847) instaure un cadre juridique ambitieux pour la sécurité des produits comportant des éléments numériques au sein de l’Union européenne. Parmi les obligations les plus structurantes du texte, le signalement des vulnérabilités activement exploitées constitue sans doute celle qui aura l’impact opérationnel le plus immédiat pour les fabricants et les éditeurs de logiciels. Avec un délai initial de 24 heures pour effectuer une première notification, le CRA impose un rythme qui ne laissé aucune place à l’improvisation.

Voyons en détail ce que ces obligations impliquent et ce que votre équipe sécurité doit concrètement mettre en place.

Qu’est-ce qu’une vulnérabilité activement exploitée ?

Le CRA définit la notion de vulnérabilité activement exploitée de manière precise. Il s’agit d’une vulnérabilité pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire de ce système. Cette définition est importante, car elle distingue la vulnérabilité connue mais non exploitée – qui relève d’autres obligations – de celle qui fait l’objet d’une exploitation active et qui déclenche les obligations de signalement accélère.

Concrètement, cela signifie que la découverte d’une faille dans votre code, aussi critique soit-elle, ne déclenche pas en elle-même l’obligation de notification en 24 heures. C’est l’exploitation effective de cette faille par un tiers malveillant qui fait basculer la situation dans le régime de signalement accélère. Le CRA prévoit également un signalement pour les vulnérabilités non exploitées, mais selon un calendrier moins contraint.

En pratique, votre équipe doit être en mesure de déterminer rapidement si une vulnérabilité fait l’objet d’une exploitation active. Cela suppose une capacité de détection et d’analyse structurée en amont.

La procédure de signalement en trois étapes

Le CRA structuré le signalement des vulnérabilités activement exploitées en trois phases distinctes, chacune assortie d’un délai strict. Ce mécanisme est directement inspiré de la procédure de notification des incidents de sécurité prévue par la directive NIS 2, adaptée au contexte spécifique des vulnérabilités produit.

Étape 1 : Alerte précoce – 24 heures

Dans les 24 heures suivant la prise de connaissance de la vulnérabilité activement exploitée, le fabricant doit transmettre une alerte précoce (early warning) à l’équipe CSIRT désignée par son État membre et à l’ENISA. Cette alerte doit contenir au minimum :

• les informations générales sur le produit concerné (identité du fabricant, identification du produit) ;
• des informations préliminaires sur la nature de la vulnérabilité ;
• des informations sur la nature de l’exploitation observee ;
• toute mesure corrective ou d’attenuation déjà prise ou envisagée.

L’objectif de cette première notification n’est pas d’être exhaustif. Il s’agit d’alerter les autorités suffisamment tot pour qu’elles puissent évaluer le risque systémique et, le cas échéant, prendre des mesures de coordination à l’échelle européenne.

Étape 2 : Notification complète – 72 heures

Dans les 72 heures suivant la prise de connaissance, le fabricant doit transmettre une notification complète. Celle-ci doit inclure :

• une description détaillée de la vulnérabilité, y compris sa sévérité et son impact potentiel ;
• des informations sur tout acteur malveillant ayant exploite la vulnérabilité, si ces informations sont disponibles ;
• des détails techniques sur l’exploitation observee ;
• les mesures correctives appliquées ou en cours de déploiement ;
• les éventuelles vulnérabilités associées ou connexes identifiées.

Cette notification complète doit permettre aux autorités d’avoir une vision precise de la menace et de ses implications.

Étape 3 : Rapport final – 14 jours

Dans un délai de 14 jours suivant la notification complète, un rapport final doit être transmis. Ce rapport comprend :

• une description détaillée de la vulnérabilité, y compris sa sévérité et son impact ;
• des informations sur tout acteur malveillant ayant exploite ou exploitant la vulnérabilité ;
• les détails du correctif de sécurité ou d’autres mesures correctives mises à disposition ;
• le cas échéant, les informations communiquées aux utilisateurs pour qu’ils puissent atténuer l’impact de la vulnérabilité.

Si la vulnérabilité n’est pas totalement résolue au moment de ce rapport, les autorités peuvent demander des rapports complémentaires.

Schema récapitulatif de la procédure

DECOUVERTE D'UNE VULNERABILITE ACTIVEMENT EXPLOITEE
|
|  T+0h : Prise de connaissance
|
|--- [DANS LES 24H] ---> ALERTE PRECOCE (Early Warning)
|                         -> CSIRT national + ENISA
|                         -> Informations générales + nature de l'exploit
|
|--- [DANS LES 72H] ---> NOTIFICATION COMPLETE
|                         -> CSIRT national + ENISA
|                         -> Details techniques + mesures correctives
|
|--- [DANS LES 14J] ---> RAPPORT FINAL
|                         -> CSIRT national + ENISA
|                         -> Bilan complet + correctifs déployés
|
|--- [SI NON RESOLU] --> RAPPORTS COMPLEMENTAIRES
                          -> Sur demande des autorites

Le rôle de l’ENISA et des CSIRT

Le dispositif de signalement du CRA s’appuie sur une architecture institutionnelle a deux niveaux. Le CSIRT (Computer Security Incident Response Team) désigné par l’État membre du fabricant est le destinataire principal de la notification. En France, ce rôle est assuré par l’ANSSI (Agence nationale de la sécurité des systèmes d’information), qui opère le CERT-FR.

L’ENISA (Agence de l’Union européenne pour la cybersécurité) reçoit simultanément ces notifications via une plateforme de signalement unique mise en place à cet effet. L’ENISA joué un rôle de coordination essentiel : elle est chargée d’informer les autres CSIRT nationaux lorsque la vulnérabilité est susceptible d’affecter des produits distribues dans plusieurs États membres. C’est cette dimension de coordination européenne qui justifié la double notification.

L’ENISA doit traiter ces informations avec un haut niveau de confidentialité. Les données relatives aux vulnérabilités non encore corrigées ne doivent pas être divulguées de manière a accroître le risque pour les utilisateurs.

L’obligation d’informer les utilisateurs

Au-delà du signalement aux autorités, le CRA impose aux fabricants d’informer les utilisateurs de leurs produits. Cette obligation comporte deux dimensions.

Information sur la vulnérabilité. Le fabricant doit informer les utilisateurs de la vulnérabilité activement exploitée et, le cas échéant, des mesures d’attenuation qu’ils peuvent prendre en attendant le correctif. Le délai et la forme de cette communication ne sont pas aussi strictement encadrés que le signalement aux autorités, mais elle doit intervenir “sans retard injustifié”.

Déploiement des correctifs. Le fabricant doit mettre à disposition des correctifs de sécurité dans les meilleurs délais. Lorsqu’un correctif est disponible, les utilisateurs doivent en être informés et le correctif doit être déployé gratuitement. Le CRA prévoit que les mises à jour de sécurité doivent être separees des mises à jour fonctionnelles, afin de permettre aux utilisateurs d’appliquer les correctifs de sécurité sans être contraints d’accepter des modifications fonctionnelles non desirees.

Les équipes produit doivent donc être en mesure de publier des correctifs de sécurité de manière autonome, sans attendre un cycle de release complet.

La divulgation coordonnée des vulnérabilités

Le CRA impose également aux fabricants de mettre en place une politique de divulgation coordonnée des vulnérabilités (Coordinated Vulnerability Disclosure – CVD). Cette obligation, prévue à l’article 13, impose concrètement :

• de fournir une adressé de contact permettant aux chercheurs en sécurité de signaler des vulnérabilités ;
• de définir un calendrier de divulgation en concertation avec les parties prenantes ;
• de ne pas engager de poursuites contre les chercheurs en sécurité agissant de bonne foi, conformément à la politique CVD publiée.

Toute entreprise qui fabrique ou distribue un produit comportant des éléments numériques doit donc disposer d’un processus structuré de réception et de traitement des signalements de vulnérabilités. L’absence de ce processus est en elle-même une non-conformité.

Articulation avec NIS 2 et les notifications RGPD

Le régime de signalement du CRA ne fonctionne pas de manière isolée. Il s’articule avec deux autres cadres de notification majeurs.

NIS 2. La directive NIS 2 impose aux entités essentielles et importantes des obligations de signalement des incidents de sécurité selon un calendrier similaire (24h / 72h / 1 mois). Lorsqu’une vulnérabilité activement exploitée conduit à un incident de sécurité affectant une entité soumise à NIS 2, les deux obligations de notification coexistent. Le fabricant du produit doit notifier au titre du CRA, tandis que l’opérateur victime de l’incident doit notifier au titre de NIS 2. L’ENISA a été chargée de mettre en place des mécanismes pour éviter la duplication des signalements lorsque cela est possible.

RGPD. Lorsque l’exploitation d’une vulnérabilité conduit à une violation de données personnelles, les obligations de notification à l’autorité de protection des données et aux personnes concernées s’ajoutent aux obligations du CRA. Les deux procédures sont distinctes et ne se substituent pas l’une à l’autre. En pratique, une même vulnérabilité exploitée peut donc déclencher jusqu’à trois procédures de notification parallèles (CRA, NIS 2, RGPD), chacune avec ses propres destinataires et ses propres délais.

Sanctions en cas de non-respect

Le CRA prévoit un régime de sanctions significatif pour le non-respect des obligations de signalement. Les infractions aux obligations relatives au signalement des vulnérabilités sont passibles d’amendes administratives pouvant atteindre 5 millions d’euros ou 1 % du chiffre d’affaires annuel mondial total de l’entreprise, le montant le plus élevé étant retenu.

Ce niveau de sanction est inférieur aux plafonds prévus pour d’autres infractions au CRA (les obligations essentielles de cybersécurité sont passibles d’amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires), mais il reste suffisamment dissuasif pour justifier un investissement sérieux dans la mise en conformité.

À noter que les États membres sont charges de définir les règles nationales en matière de sanctions, ce qui pourrait conduire à des variations d’un pays à l’autre. Des sanctions pénales ne sont pas exclues par le texte, si les législations nationales le prévoient.

Ce que votre équipe sécurité doit mettre en place

La mise en conformité avec les obligations de signalement du CRA requiert une préparation méthodique. Voici les actions prioritaires.

1. Mettre en place une capacité de détection des exploitations actives. Il est indispensable de pouvoir identifier rapidement si une vulnérabilité découverte fait l’objet d’une exploitation. Cela peut passer par du threat intelligence, des honeypots, une surveillance des indicateurs de compromission, ou des remontées utilisateurs structurées.

2. Définir un processus de notification interne. Le délai de 24 heures ne laissé aucune marge. Le processus de décision entre la détection, la qualification et la notification doit être défini à l’avance, avec des rôles et responsabilités clairement attribues. En particulier, il faut désigner une personne ou une équipe responsable de l’envoi de la notification, et s’assurer que cette personne dispose de l’autorité suffisante pour agir sans attendre des validations hiérarchiques longues.

3. Préparer les modèles de notification. Les trois étapes du signalement (alerte précoce, notification complète, rapport final) doivent faire l’objet de modèles pré-remplis que l’équipe pourra compléter rapidement. L’ENISA devrait fournir des formulaires standardises via sa plateforme de signalement.

4. Mettre en place une politique de divulgation coordonnée. Si votre entreprise ne dispose pas encore d’un programme de CVD, c’est le moment de l’instaurer. Cela implique à minima une adressé de contact dédiée (par exemple security@votredomaine.com), un fichier security.txt conforme au standard RFC 9116, et une politique écrite définissant les règles d’engagement avec les chercheurs en sécurité.

5. Structurer la capacité de déploiement rapide de correctifs. L’obligation de fournir des correctifs de sécurité dans les meilleurs délais suppose une chaîne de compilation, de test et de déploiement qui soit opérationnelle en permanence. Les organisations qui ne disposent pas d’un pipeline CI/CD mature risquent de se retrouver dans l’incapacité de publier un correctif dans un délai raisonnable.

6. Cartographier les obligations croisées. Si votre organisation est également soumise à NIS 2 ou traité des données personnelles, les obligations de notification se cumulent. Il est essentiel de cartographier ces obligations et de définir des processus coordonnes afin d’éviter les oublis ou les contradictions dans les communications adressées aux différentes autorités.

Conclusion

Les obligations de signalement des vulnérabilités du Cyber Résilience Act représentent un changement de paradigme pour les fabricants de produits numériques en Europe. Le délai de 24 heures pour l’alerte précoce, en particulier, impose une réactivité qui ne peut être atteinte sans une préparation rigoureuse.

L’entrée en application de ces obligations de signalement est prévue pour le 11 septembre 2026, soit avant l’application complète du CRA fixée au 11 décembre 2027. Les fabricants disposent donc d’un temps limite pour mettre en place les processus, les outils et les équipes nécessaires.

La gestion des vulnérabilités ne peut plus être traitée comme un sujet purement technique relève de l’équipe sécurité. C’est désormais une obligation juridique, assortie de délais contraignants et de sanctions significatives, qui doit être intégrée dans la gouvernance de l’entreprise.

Pour aller plus loin, consultez notre analyse complète du Cyber Résilience Act et nos guides sur la gestion des fuites de données et la notification des violations de données.