Le Cyber Resilience Act (reglement (UE) 2024/2847) instaure un cadre juridique ambitieux pour la securite des produits comportant des elements numeriques au sein de l’Union europeenne. Parmi les obligations les plus structurantes du texte, le signalement des vulnerabilites activement exploitees constitue sans doute celle qui aura l’impact operationnel le plus immediat pour les fabricants et les editeurs de logiciels. Avec un delai initial de 24 heures pour effectuer une premiere notification, le CRA impose un rythme qui ne laisse aucune place a l’improvisation.

Voyons en detail ce que ces obligations impliquent et ce que votre equipe securite doit concretement mettre en place.

Qu’est-ce qu’une vulnerabilite activement exploitee ?

Le CRA definit la notion de vulnerabilite activement exploitee de maniere precise. Il s’agit d’une vulnerabilite pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitee dans un systeme sans l’autorisation du proprietaire de ce systeme. Cette definition est importante, car elle distingue la vulnerabilite connue mais non exploitee – qui releve d’autres obligations – de celle qui fait l’objet d’une exploitation active et qui declenche les obligations de signalement accelere.

Concretement, cela signifie que la decouverte d’une faille dans votre code, aussi critique soit-elle, ne declenche pas en elle-meme 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 regime de signalement accelere. Le CRA prevoit egalement un signalement pour les vulnerabilites non exploitees, mais selon un calendrier moins contraint.

En pratique, votre equipe doit etre en mesure de determiner rapidement si une vulnerabilite fait l’objet d’une exploitation active. Cela suppose une capacite de detection et d’analyse structuree en amont.

La procedure de signalement en trois etapes

Le CRA structure le signalement des vulnerabilites activement exploitees en trois phases distinctes, chacune assortie d’un delai strict. Ce mecanisme est directement inspire de la procedure de notification des incidents de securite prevue par la directive NIS 2, adaptee au contexte specifique des vulnerabilites produit.

Etape 1 : Alerte precoce – 24 heures

Dans les 24 heures suivant la prise de connaissance de la vulnerabilite activement exploitee, le fabricant doit transmettre une alerte precoce (early warning) a l’equipe CSIRT designee par son Etat membre et a l’ENISA. Cette alerte doit contenir au minimum :

• les informations generales sur le produit concerne (identite du fabricant, identification du produit) ;
• des informations preliminaires sur la nature de la vulnerabilite ;
• des informations sur la nature de l’exploitation observee ;
• toute mesure corrective ou d’attenuation deja prise ou envisagee.

L’objectif de cette premiere notification n’est pas d’etre exhaustif. Il s’agit d’alerter les autorites suffisamment tot pour qu’elles puissent evaluer le risque systemique et, le cas echeant, prendre des mesures de coordination a l’echelle europeenne.

Etape 2 : Notification complete – 72 heures

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

• une description detaillee de la vulnerabilite, y compris sa severite et son impact potentiel ;
• des informations sur tout acteur malveillant ayant exploite la vulnerabilite, si ces informations sont disponibles ;
• des details techniques sur l’exploitation observee ;
• les mesures correctives appliquees ou en cours de deploiement ;
• les eventuelles vulnerabilites associees ou connexes identifiees.

Cette notification complete doit permettre aux autorites d’avoir une vision precise de la menace et de ses implications.

Etape 3 : Rapport final – 14 jours

Dans un delai de 14 jours suivant la notification complete, un rapport final doit etre transmis. Ce rapport comprend :

• une description detaillee de la vulnerabilite, y compris sa severite et son impact ;
• des informations sur tout acteur malveillant ayant exploite ou exploitant la vulnerabilite ;
• les details du correctif de securite ou d’autres mesures correctives mises a disposition ;
• le cas echeant, les informations communiquees aux utilisateurs pour qu’ils puissent attenuer l’impact de la vulnerabilite.

Si la vulnerabilite n’est pas totalement resolue au moment de ce rapport, les autorites peuvent demander des rapports complementaires.

Schema recapitulatif de la procedure

DECOUVERTE D'UNE VULNERABILITE ACTIVEMENT EXPLOITEE
|
|  T+0h : Prise de connaissance
|
|--- [DANS LES 24H] ---> ALERTE PRECOCE (Early Warning)
|                         -> CSIRT national + ENISA
|                         -> Informations generales + 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 deployes
|
|--- [SI NON RESOLU] --> RAPPORTS COMPLEMENTAIRES
                          -> Sur demande des autorites

Le role 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) designe par l’Etat membre du fabricant est le destinataire principal de la notification. En France, ce role est assure par l’ANSSI (Agence nationale de la securite des systemes d’information), qui opere le CERT-FR.

L’ENISA (Agence de l’Union europeenne pour la cybersecurite) recoit simultanement ces notifications via une plateforme de signalement unique mise en place a cet effet. L’ENISA joue un role de coordination essentiel : elle est chargee d’informer les autres CSIRT nationaux lorsque la vulnerabilite est susceptible d’affecter des produits distribues dans plusieurs Etats membres. C’est cette dimension de coordination europeenne qui justifie la double notification.

L’ENISA doit traiter ces informations avec un haut niveau de confidentialite. Les donnees relatives aux vulnerabilites non encore corrigees ne doivent pas etre divulguees de maniere a accroitre le risque pour les utilisateurs.

L’obligation d’informer les utilisateurs

Au-dela du signalement aux autorites, le CRA impose aux fabricants d’informer les utilisateurs de leurs produits. Cette obligation comporte deux dimensions.

Information sur la vulnerabilite. Le fabricant doit informer les utilisateurs de la vulnerabilite activement exploitee et, le cas echeant, des mesures d’attenuation qu’ils peuvent prendre en attendant le correctif. Le delai et la forme de cette communication ne sont pas aussi strictement encadres que le signalement aux autorites, mais elle doit intervenir “sans retard injustifie”.

Deploiement des correctifs. Le fabricant doit mettre a disposition des correctifs de securite dans les meilleurs delais. Lorsqu’un correctif est disponible, les utilisateurs doivent en etre informes et le correctif doit etre deploye gratuitement. Le CRA prevoit que les mises a jour de securite doivent etre separees des mises a jour fonctionnelles, afin de permettre aux utilisateurs d’appliquer les correctifs de securite sans etre contraints d’accepter des modifications fonctionnelles non desirees.

Les equipes produit doivent donc etre en mesure de publier des correctifs de securite de maniere autonome, sans attendre un cycle de release complet.

La divulgation coordonnee des vulnerabilites

Le CRA impose egalement aux fabricants de mettre en place une politique de divulgation coordonnee des vulnerabilites (Coordinated Vulnerability Disclosure – CVD). Cette obligation, prevue a l’article 13, impose concretement :

• de fournir une adresse de contact permettant aux chercheurs en securite de signaler des vulnerabilites ;
• de definir un calendrier de divulgation en concertation avec les parties prenantes ;
• de ne pas engager de poursuites contre les chercheurs en securite agissant de bonne foi, conformement a la politique CVD publiee.

Toute entreprise qui fabrique ou distribue un produit comportant des elements numeriques doit donc disposer d’un processus structure de reception et de traitement des signalements de vulnerabilites. L’absence de ce processus est en elle-meme une non-conformite.

Articulation avec NIS 2 et les notifications RGPD

Le regime de signalement du CRA ne fonctionne pas de maniere isolee. Il s’articule avec deux autres cadres de notification majeurs.

NIS 2. La directive NIS 2 impose aux entites essentielles et importantes des obligations de signalement des incidents de securite selon un calendrier similaire (24h / 72h / 1 mois). Lorsqu’une vulnerabilite activement exploitee conduit a un incident de securite affectant une entite soumise a NIS 2, les deux obligations de notification coexistent. Le fabricant du produit doit notifier au titre du CRA, tandis que l’operateur victime de l’incident doit notifier au titre de NIS 2. L’ENISA a ete chargee de mettre en place des mecanismes pour eviter la duplication des signalements lorsque cela est possible.

RGPD. Lorsque l’exploitation d’une vulnerabilite conduit a une violation de donnees personnelles, les obligations de notification a l’autorite de protection des donnees et aux personnes concernees s’ajoutent aux obligations du CRA. Les deux procedures sont distinctes et ne se substituent pas l’une a l’autre. En pratique, une meme vulnerabilite exploitee peut donc declencher jusqu’a trois procedures de notification paralleles (CRA, NIS 2, RGPD), chacune avec ses propres destinataires et ses propres delais.

Sanctions en cas de non-respect

Le CRA prevoit un regime de sanctions significatif pour le non-respect des obligations de signalement. Les infractions aux obligations relatives au signalement des vulnerabilites 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 eleve etant retenu.

Ce niveau de sanction est inferieur aux plafonds prevus pour d’autres infractions au CRA (les obligations essentielles de cybersecurite 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 serieux dans la mise en conformite.

A noter que les Etats membres sont charges de definir les regles nationales en matiere de sanctions, ce qui pourrait conduire a des variations d’un pays a l’autre. Des sanctions penales ne sont pas exclues par le texte, si les legislations nationales le prevoient.

Ce que votre equipe securite doit mettre en place

La mise en conformite avec les obligations de signalement du CRA requiert une preparation methodique. Voici les actions prioritaires.

1. Mettre en place une capacite de detection des exploitations actives. Il est indispensable de pouvoir identifier rapidement si une vulnerabilite decouverte fait l’objet d’une exploitation. Cela peut passer par du threat intelligence, des honeypots, une surveillance des indicateurs de compromission, ou des remontees utilisateurs structurees.

2. Definir un processus de notification interne. Le delai de 24 heures ne laisse aucune marge. Le processus de decision entre la detection, la qualification et la notification doit etre defini a l’avance, avec des roles et responsabilites clairement attribues. En particulier, il faut designer une personne ou une equipe responsable de l’envoi de la notification, et s’assurer que cette personne dispose de l’autorite suffisante pour agir sans attendre des validations hierarchiques longues.

3. Preparer les modeles de notification. Les trois etapes du signalement (alerte precoce, notification complete, rapport final) doivent faire l’objet de modeles pre-remplis que l’equipe pourra completer rapidement. L’ENISA devrait fournir des formulaires standardises via sa plateforme de signalement.

4. Mettre en place une politique de divulgation coordonnee. Si votre entreprise ne dispose pas encore d’un programme de CVD, c’est le moment de l’instaurer. Cela implique a minima une adresse de contact dediee (par exemple security@votredomaine.com), un fichier security.txt conforme au standard RFC 9116, et une politique ecrite definissant les regles d’engagement avec les chercheurs en securite.

5. Structurer la capacite de deploiement rapide de correctifs. L’obligation de fournir des correctifs de securite dans les meilleurs delais suppose une chaine de compilation, de test et de deploiement qui soit operationnelle en permanence. Les organisations qui ne disposent pas d’un pipeline CI/CD mature risquent de se retrouver dans l’incapacite de publier un correctif dans un delai raisonnable.

6. Cartographier les obligations croisees. Si votre organisation est egalement soumise a NIS 2 ou traite des donnees personnelles, les obligations de notification se cumulent. Il est essentiel de cartographier ces obligations et de definir des processus coordonnes afin d’eviter les oublis ou les contradictions dans les communications adressees aux differentes autorites.

Conclusion

Les obligations de signalement des vulnerabilites du Cyber Resilience Act representent un changement de paradigme pour les fabricants de produits numeriques en Europe. Le delai de 24 heures pour l’alerte precoce, en particulier, impose une reactivite qui ne peut etre atteinte sans une preparation rigoureuse.

L’entree en application de ces obligations de signalement est prevue pour le 11 septembre 2026, soit avant l’application complete du CRA fixee au 11 decembre 2027. Les fabricants disposent donc d’un temps limite pour mettre en place les processus, les outils et les equipes necessaires.

La gestion des vulnerabilites ne peut plus etre traitee comme un sujet purement technique releve de l’equipe securite. C’est desormais une obligation juridique, assortie de delais contraignants et de sanctions significatives, qui doit etre integree dans la gouvernance de l’entreprise.

Pour aller plus loin, consultez notre analyse complete du Cyber Resilience Act et nos guides sur la gestion des fuites de donnees et la notification des violations de donnees.