Depuis le 11 septembre 2026, l’article 14 du règlement (UE) 2024/2847, le Cyber Resilience Act (CRA), que la version française appelle « règlement sur la cyberrésilience », impose aux fabricants une alerte précoce sous 24 heures lorsqu’une vulnérabilité de l’un de leurs produits est activement exploitée.
Pour les équipes sécurité, la question est d’abord opérationnelle : combien de temps faut-il pour passer de la découverte d’une vulnérabilité à sa qualification, à sa correction, puis à la vérification de cette correction ? Et une faille trouvée pendant un pentest doit-elle, elle aussi, être notifiée ?
L’essentiel
- Depuis le 11 septembre 2026, un fabricant qui prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave affectant l’un de ses produits doit envoyer une alerte précoce sous 24 heures, puis une notification sous 72 heures, via la plateforme unique de signalement de l’ENISA. Si son établissement principal dans l’Union est en France, la notification parvient au CERT-FR de l’ANSSI, en même temps qu’à l’ENISA.
- L’obligation vaut aussi pour les produits mis sur le marché avant le 11 décembre 2027.
- Une faille découverte en pentest n’a pas à être notifiée tant qu’aucune preuve fiable n’indique qu’un acteur malveillant l’a exploitée : elle n’est alors pas « activement exploitée » au sens du règlement.
- À partir du 11 décembre 2027, les fabricants devront soumettre régulièrement leurs produits à des « tests et examens de sécurité efficaces » (annexe I), sans méthode ni fréquence imposées. Le pentest est l’un des moyens d’y répondre.
Ce qui s’applique depuis le 11 septembre 2026
L’essentiel du CRA s’appliquera à partir du 11 décembre 2027, mais son article 14, qui organise la notification des vulnérabilités activement exploitées et des incidents graves, s’applique depuis le 11 septembre 2026 (article 71). Il vise les fabricants de produits comportant des éléments numériques, matériels comme logiciels, y compris ceux déjà sur le marché (article 69, paragraphe 3). Les délais courent dès que le fabricant prend connaissance de la vulnérabilité ou de l’incident :
| Échéance après prise de connaissance | Vulnérabilité activement exploitée | Incident grave |
|---|---|---|
| 24 heures | Alerte précoce | Alerte précoce |
| 72 heures | Notification : produit concerné, nature de l’exploitation, mesures prises | Notification : nature de l’incident, évaluation initiale, mesures prises |
| Rapport final | Au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation | Dans un délai d’un mois après la notification |
Un incident est grave lorsqu’il compromet, ou peut compromettre, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou lorsqu’il a conduit, ou peut conduire, à introduire ou à exécuter du code malveillant dans le produit ou dans les systèmes d’information de ses utilisateurs (article 14, paragraphe 5).
Les notifications passent par la plateforme unique de signalement (Single Reporting Platform), dont l’ENISA a mis en service une première version le 11 septembre 2026. Elles parviennent simultanément à l’ENISA et au CSIRT coordinateur de l’État membre où le fabricant a son établissement principal : en France, le CERT-FR de l’ANSSI. Le fabricant doit aussi informer les utilisateurs touchés et leur indiquer les mesures à prendre pour en limiter les effets (article 14, paragraphe 8).
Et si j’édite un SaaS ?
Le CRA couvre les produits, pas les services : un SaaS utilisé uniquement dans un navigateur, sans produit associé, n’est pas concerné (considérant 12 et lignes directrices de la Commission). Les services en nuage relèvent de la directive NIS2, qui ne vise en principe que les fournisseurs d’au moins 50 salariés, ou dont le chiffre d’affaires et le total de bilan dépassent chacun 10 M€ ; un État membre peut toutefois y soumettre une entité plus petite dans des cas limités (article 2, paragraphe 2). En dessous de ce seuil, ni le CRA ni NIS2 ne s’appliquent en principe directement à votre SaaS, mais vos clients soumis à NIS2 peuvent vous imposer des exigences de sécurité par contrat.
Un service en ligne relève en revanche du CRA s’il constitue le « traitement de données à distance » d’un produit, c’est-à-dire un logiciel développé par le fabricant, ou sous sa responsabilité, sans lequel le produit ne peut pas remplir l’une de ses fonctions (article 3, point 2). Le considérant 11 cite l’exemple d’une application mobile qui appelle une API développée par le fabricant.
Une faille trouvée en pentest doit-elle être notifiée sous 24 heures ?
Non, tant qu’il n’existe pas de preuve fiable qu’un acteur malveillant l’a exploitée. Trois textes l’établissent, du plus contraignant au moins contraignant :
- La définition de l’article 3, point 42. Une vulnérabilité activement exploitée est « une vulnérabilité pour laquelle il existe des preuves fiables qu’elle a été exploitée par un acteur malveillant dans un système sans l’autorisation du propriétaire du système ». Un pentest est mené avec cette autorisation, par un prestataire qui n’a rien d’un acteur malveillant.
- Le considérant 68. « Les vulnérabilités qui sont découvertes sans intention malveillante pour les besoins d’essais, d’enquêtes, de correction ou de divulgation de bonne foi […] ne devraient pas faire l’objet de notifications obligatoires. »
- La FAQ des services de la Commission. Une zero-day découverte par un laboratoire qui teste le produit pour le compte du fabricant, sans preuve d’une exploitation malveillante antérieure, n’est pas soumise à la notification obligatoire. Il en va de même pour une zero-day remontée par un programme de bug bounty. Le fabricant peut toujours la notifier volontairement (article 15).
Il reste à qualifier vite chaque faille : un pentest en établit l’exploitabilité et l’impact, là où un scan de vulnérabilités s’arrête à la détection ; la recherche de traces d’exploitation relève de l’analyse des journaux ou d’une levée de doute.
Quand une faille de pentest devient-elle « activement exploitée » ?
Un pentest peut révéler qu’un attaquant est passé avant : webshell, compte inconnu, indicateurs de compromission. S’il existe des preuves fiables qu’un acteur malveillant a exploité la faille, elle devient activement exploitée. Les 24 heures courent dès que le fabricant en a connaissance : selon la Commission, dès qu’une évaluation initiale, menée sans attendre, lui donne un degré raisonnable de certitude (lignes directrices, point 213). Prévoyez donc dans la convention de pentest une remontée immédiate de toute trace de compromission, vers un contact côté client joignable même hors heures ouvrées.
Ce que le CRA exige en matière de tests de sécurité
Le CRA n’impose ni pentest ni fréquence de test. Son annexe I, partie II, applicable à partir du 11 décembre 2027, oblige en revanche les fabricants à :
- recenser et documenter les vulnérabilités et les composants de leurs produits, avec une nomenclature des logiciels (SBOM) couvrant au moins les dépendances de niveau supérieur ;
- gérer et corriger « sans retard » les vulnérabilités, y compris par des mises à jour de sécurité ;
- soumettre régulièrement leurs produits à des « tests et examens de sécurité efficaces » ;
- publier une description des vulnérabilités corrigées dès la diffusion de la mise à jour de sécurité, sauf report dûment justifié ;
- appliquer une politique de divulgation coordonnée des vulnérabilités ;
- faciliter le partage d’informations sur les vulnérabilités, notamment en fournissant une adresse de contact pour les signaler ;
- diffuser les mises à jour de sécurité de manière sécurisée, sans retard et gratuitement, sauf accord contraire avec un utilisateur professionnel pour un produit sur mesure.
Ces obligations courent pendant toute la période d’assistance, qui dure au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps (article 13, paragraphe 8).
Le CRA n’impose pas de corriger une vulnérabilité en 24 heures : ce délai ne vaut que pour l’alerte précoce, et l’obligation de corriger « sans retard » ne s’appliquera qu’à partir du 11 décembre 2027.
Le règlement ne dit ni comment tester ni à quel rythme. Pour la Commission, tester régulièrement ne veut pas dire répéter la même campagne à intervalle fixe, mais revoir les tests au gré des nouvelles menaces, des nouvelles vulnérabilités et des modifications du produit, puis les exécuter, non-régression comprise (lignes directrices, points 238 à 240).
Le pentest est l’un des moyens de répondre au volet « tests », et un pentest avec accès au code source peut aussi nourrir le volet « examens ». Sa valeur tient à l’exploitation : un scanner signale qu’un composant est potentiellement vulnérable, un pentester établit ce qu’un attaquant peut réellement en obtenir, et cette preuve permet de prioriser vite. Chez Mobeta, nos tests d’intrusion associent exploitation manuelle et agents IA développés en interne ; chaque résultat est validé par un pentester.
Exemple : une faille de contrôle d’accès sur une caméra connectée
Un fabricant commercialise une caméra connectée, pilotée par une application mobile et une API cloud qu’il développe. Sans cette API, la caméra perd l’une de ses fonctions, le visionnage à distance : c’est donc un « traitement de données à distance » au sens du CRA. Un pentest de l’application mobile et de son API révèle une faille de contrôle d’accès : un utilisateur connecté peut voir les flux vidéo d’un autre compte.
Le rapport documente la faille, sa criticité, la preuve d’exploitation, l’impact et les recommandations. Tant qu’aucune preuve fiable n’indique qu’un acteur malveillant l’a exploitée, aucune notification n’est obligatoire. Si les journaux de l’API montrent des accès illégitimes aux flux d’autres comptes, la faille devient activement exploitée et le délai de 24 heures s’applique. Ces accès sont aussi une violation de données personnelles, que le responsable du traitement doit notifier sous 72 heures à la CNIL ou à l’autorité compétente, sauf risque improbable pour les personnes (article 33 du RGPD).
Restent les questions que le rapport ne tranche pas : la faille a-t-elle été corrigée ? Le correctif fonctionne-t-il ? Une régression peut-elle la réintroduire ? Combien de temps s’est-il écoulé avant sa correction, et qui peut prouver qu’elle n’est plus exploitable ?
Du rapport de pentest au suivi continu des vulnérabilités
Un rapport de pentest décrit un périmètre à un instant donné, alors que le CRA demande de gérer les vulnérabilités pendant toute la période d’assistance. Le cycle « audit, rapport, corrections, contre-audit » convient à une application qui évolue peu, pas à un produit livré chaque semaine : nouvelles versions et API, configurations modifiées, dépendances devenues vulnérables, correctifs qui introduisent une faiblesse ou réintroduisent une faille.
Compter les vulnérabilités découvertes ne suffit donc plus : il faut mesurer combien de temps elles restent exploitables. Le pentest en continu, ou PTaaS (Pentest as a Service), combine pour cela des pentests réguliers, l’automatisation des contrôles reproductibles, le suivi des vulnérabilités et la revérification des corrections. C’est le principe de notre offre de pentest en continu, où l’automatisation laisse au pentester ce qui exige son expertise : exploitation, logique métier, enchaînement de vulnérabilités, qualification de l’impact.
Entre deux pentests : tester, vérifier, tracer
1. Tester en continu
Tester les actifs tout au long de l’année, et pas seulement le temps d’un audit, permet de repérer une faille apparue avec une nouvelle version, une configuration modifiée ou un correctif sans attendre le prochain pentest, de quoi réduire le temps de détection et le taux de réintroduction. C’est aussi une façon de tester le produit régulièrement, comme l’exigera l’annexe I à partir du 11 décembre 2027. Comme en pentest, une faille trouvée ainsi n’a pas à être notifiée tant qu’aucune preuve fiable n’indique qu’un acteur malveillant l’a exploitée.
2. Réduire le délai de remédiation
Une vulnérabilité n’est pas corrigée quand un développeur passe son ticket en « Done », mais quand le correctif empêche effectivement son exploitation. La revérification ferme cette boucle et raccourcit le délai de remédiation : quand le scénario d’exploitation peut être rejoué, le développeur vérifie lui-même son correctif, sans attendre un contre-audit. Elle demande parfois de descendre jusqu’au code pour comprendre ce qu’un correctif change réellement, comme nous l’avons fait en comparant les versions vulnérable et corrigée de VMware vCenter (article en anglais).
3. Garder une traçabilité exploitable
L’annexe I demande de recenser et de documenter les vulnérabilités des produits. Un suivi dispersé entre un PDF, des tickets Jira et des e-mails documente bien la découverte d’une vulnérabilité, beaucoup moins son devenir. Un historique centralisé des vulnérabilités, des correctifs et des revérifications facilite ce travail.
Chez Mobeta, nous outillons ces trois pratiques avec Rigma, la plateforme que nous éditons : test continu des actifs, suivi centralisé des vulnérabilités, y compris celles relevées par un autre prestataire, revérification automatique des corrections et attestation d’audit tenue à jour. Rigma ne prouve pas à elle seule la conformité au CRA.
Quels indicateurs suivre pour préparer le CRA ?
L’enjeu est de raccourcir tout le cycle : découvrir, comprendre, prioriser, corriger, vérifier. Cinq indicateurs permettent de le mesurer :
- Temps de détection : combien de temps une vulnérabilité reste-t-elle présente avant d’être identifiée ?
- Temps de qualification : combien de temps faut-il pour établir son exploitabilité et son impact réel ?
- Temps de remédiation (MTTR, mean time to remediate) : quel délai sépare la découverte d’une vulnérabilité du déploiement de son correctif ?
- Temps de revérification : combien de temps faut-il pour confirmer que le correctif fonctionne ?
- Taux de réintroduction : combien de vulnérabilités déjà corrigées réapparaissent dans les nouvelles versions ?
Suivis dans le temps, ces indicateurs font passer la sécurité offensive d’une logique de production de rapports à une logique de réduction continue de l’exposition.
Comment se préparer concrètement au Cyber Resilience Act ?
Inutile d’attendre décembre 2027 : l’obligation de signalement s’applique déjà, y compris aux produits commercialisés depuis des années. Une première démarche peut consister à :
- identifier les produits qui entrent dans le champ du CRA, y compris leurs solutions de traitement de données à distance ;
- cartographier leurs composants et leurs dépendances ;
- formaliser le circuit interne de remontée d’une vulnérabilité ou d’un incident ;
- désigner qui qualifie l’impact et qui décide de notifier ;
- créer à l’avance un compte EU Login, avec authentification multifacteur, pour chaque personne habilitée à notifier (l’inscription sur la plateforme se fait au moment de la première notification et prend quelques minutes, selon l’ENISA), et organiser une astreinte capable d’envoyer une alerte précoce sous 24 heures, week-end compris ;
- prévoir dans les conventions de pentest une clause de remontée immédiate des traces de compromission ;
- organiser des tests de sécurité réguliers et fixer des délais internes de remédiation selon la criticité ;
- systématiser la revérification des corrections ;
- préparer l’information des utilisateurs concernés.
L’objectif est moins de montrer qu’un pentest a eu lieu que de savoir répondre à une question plus exigeante : que se passe-t-il dans les heures et les jours qui suivent la découverte d’une vulnérabilité critique ?
Sources
- EUR-Lex – Règlement (UE) 2024/2847 (Cyber Resilience Act), texte officiel en français
- Commission européenne – FAQ sur la mise en œuvre du CRA
- Commission européenne – Obligations de signalement du CRA
- Commission européenne – Lignes directrices sur l’application du CRA, C(2026) 5252, 27 juillet 2026
- ENISA – Lancement de la plateforme unique de signalement
- ENISA – FAQ de la plateforme unique de signalement
- ANSSI – Questions fréquentes sur le CRA
Ces techniques s’appliquent
à votre périmètre ?
Un échange de 30 min avec nos pentesters certifiés pour cadrer votre exposition. Sans engagement.
