CRA Notification de vulnérabilités : ENISA SRP, 24h/72h/14j

Le Règlement sur la cyberrésilience de l'UE (Règlement (UE) 2024/2847) fait du signalement des vulnérabilités une obligation juridique ferme et limitée dans le temps pour tout fabricant de produit comportant des éléments numériques. À partir du 11 septembre 2026, l'Article 14 impose de signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement ENISA (SRP) selon une cadence 24 heures / 72 heures / 14 jours, adossée à une politique obligatoire de divulgation coordonnée des vulnérabilités (CVD) au titre de l'Annexe I Partie II. Cette page est la référence canonique : ce que la loi exige, quand chaque délai démarre, ce qu'une politique CVD conforme doit contenir, comment VEX soutient l'obligation « aucune vulnérabilité exploitable connue », et quelles amendes prévues à l'Article 64 s'appliquent en cas de manquement au signalement.

Que requiert le CRA pour le signalement des vulnérabilités ?

L'Article 14 du Règlement sur la cyberrésilience est le coeur opérationnel du régime de gestion des incidents du règlement. Il impose trois obligations à tout fabricant de produit comportant des éléments numériques mis sur le marché européen :

1. Notifier toute vulnérabilité activement exploitée dans le produit simultanément au CSIRT coordinateur et à l'ENISA, selon la cadence 24 h / 72 h / 14 j (Art. 14(1), 14(2)).
2. Notifier tout incident grave affectant la sécurité du produit selon une cadence 24 h / 72 h / 1 mois (Art. 14(3), 14(4)).
3. Informer les utilisateurs du produit concerné de la vulnérabilité ou de l'incident et de toute mesure corrective, sans retard injustifié (Art. 14(8)).

L'Article 14 s'accompagne de deux autres obligations également couvertes par cette page : la politique CVD obligatoire au titre de l'Annexe I Partie II, et l'exigence « aucune vulnérabilité exploitable connue » au titre de l'Annexe I Partie I, qui explique pourquoi VEX compte pour un produit conforme au CRA. Aucune de ces obligations ne comporte de seuil de taille. Les PME bénéficient d'un allègement de sanction limité sur le délai de 24 heures (voir ci-dessous) mais ne sont pas exemptées du signalement.

La plateforme unique de signalement ENISA (SRP)

La SRP est le canal unique par lequel toute notification au titre de l'Article 14 transite. Elle existe parce que l'Article 14(1) oblige le fabricant à notifier simultanément le CSIRT coordinateur et l'ENISA, et 27 dépôts séparés seraient ingérables. L'Article 16(1) place la plateforme sous la responsabilité opérationnelle de l'ENISA : « la gestion et la maintenance quotidiennes de cette plateforme unique de signalement sont assurées par l'ENISA. »

Fonctionnement en pratique :

• Vous soumettez une seule fois, via le point final électronique du CSIRT désigné comme votre coordinateur au titre de l'Article 14(7).
• La soumission arrive simultanément au CSIRT coordinateur et à l'ENISA.
• Le CSIRT coordinateur diffuse ensuite la notification aux CSIRT des autres États membres où votre produit est mis sur le marché (Art. 16). Cette diffusion secondaire relève de la responsabilité du CSIRT, pas du fabricant.
• L'Article 16(2) permet à un CSIRT de différer la diffusion dans des circonstances particulièrement exceptionnelles. L'Article 16(6) permet un report lors d'une divulgation coordonnée avec le consentement du fabricant.

Situation en mai 2026 : la SRP est prévue pour être opérationnelle d'ici le 11 septembre 2026, conformément à la page SRP de l'ENISA. La mise en oeuvre a été mise en appel d'offres sous la référence ENISA/2025/OP/0001 (contrat de 4 ans), la clôture de l'appel ayant eu lieu en mars 2025. Le prestataire n'a pas été divulgué publiquement. Aucune URL d'inscription n'a été publiée. Une période de test est attendue avant le lancement ; aucune date spécifique n'a été annoncée. Les actes d'exécution au titre de l'Article 14 fixant les formats et la structure des notifications étaient encore en attente à la date de rédaction.

Ce que les fabricants doivent faire maintenant : identifier votre CSIRT coordinateur au titre de l'Article 14(7), rédiger et pré-approuver des modèles de rapport pour les soumissions à 24 h, 72 h et 14 j, et définir une rotation d'astreinte hors heures ouvrées. Les modèles et processus ne peuvent pas être rédigés pendant que le compteur de 24 heures tourne.

Délais de signalement en détail

Vulnérabilités et incidents graves suivent tous deux un modèle de signalement par étapes. Les délais diffèrent sur le volet du rapport final.

Calendrier de signalement au titre de l'Article 14

Étape	Vulnérabilité (Art. 14(2))	Incident grave (Art. 14(4))	Ancre du délai
Alerte précoce	24 heures	24 heures	Prise de connaissance par le fabricant
Notification détaillée	72 heures	72 heures	Prise de connaissance par le fabricant
Rapport final	14 jours après la disponibilité d'une mesure corrective ou d'atténuation	1 mois après la notification d'incident à 72 heures	Ancre différente selon la voie
Information des utilisateurs	Sans retard injustifié	Sans retard injustifié	Conformément à l'Art. 14(8)

Contenu de chaque soumission

Alerte précoce (24 heures). Informations minimales pour alerter les autorités : identité du fabricant, produit et version concernés, brève description, gravité initiale, exploitation confirmée ou suspectée, et indication de la portée d'impact. L'alerte précoce est une notification, pas une analyse.

Notification détaillée (72 heures). Deux obligations distinctes s'appliquent à cette étape. La notification de vulnérabilité à 72 heures au titre de l'Article 14(2)(b) concerne les vulnérabilités activement exploitées. La notification d'incident à 72 heures au titre de l'Article 14(4)(b) concerne les incidents graves. Dans les deux cas, la soumission développe l'alerte précoce avec les détails techniques, les versions et configurations affectées, la méthode d'exploitation (si connue), le statut actuel des mesures d'atténuation, le calendrier de remédiation, la portée connue des utilisateurs affectés, et toute coordination en cours avec d'autres parties.

Rapport final. Pour les vulnérabilités, le délai de 14 jours démarre « au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation » (Art. 14(2)(c)), et non à compter de la découverte ni de la notification à 72 heures. Pour les incidents graves, le délai d'un mois est ancré à la notification d'incident à 72 heures au titre de l'Article 14(4)(c). Le rapport final couvre la cause profonde, la description technique intégrale, les actions de remédiation prises, les mesures de prévention mises en oeuvre, et l'évaluation d'impact confirmée.

1. Prise de connaissance par le fabricant. Le compteur de 24 heures démarre dès que la croyance raisonnable d'une exploitation active est formée.
2. + 24 heures. Alerte précoce soumise via la SRP ENISA (Art. 14(2)(a)).
3. + 72 heures. Notification détaillée soumise avec les détails techniques, les versions affectées et le statut des mesures d'atténuation (Art. 14(2)(b)).
4. Mesure corrective ou d'atténuation disponible. Le compteur du rapport final de 14 jours démarre ici, pas à la découverte.
5. + 14 jours. Rapport final soumis : cause profonde, description technique intégrale, remédiation, impact confirmé (Art. 14(2)(c)).

Ce qui déclenche une obligation de signalement

L'Article 14 couvre deux catégories de déclencheurs.

1. Vulnérabilités activement exploitées

Une vulnérabilité dans votre produit qui :

• vous est connue (découverte en interne ou signalée de l'extérieur),
• a été utilisée par un acteur malveillant, et
• affecte, ou pourrait affecter, les utilisateurs du produit.

Le CRA définit une vulnérabilité activement exploitée comme une vulnérabilité où « un acteur malveillant utilise une faille ». Ce n'est pas la même chose qu'une divulgation publique, un proof-of-concept publié, ou un chercheur démontrant l'exploitabilité. Le déclencheur est une utilisation malveillante réelle.

2. Incidents graves

Des incidents de sécurité qui affectent la sécurité du produit, compromettent l'environnement de développement d'une manière qui affecte la sécurité du produit, causent une interruption de service généralisée pour les utilisateurs, ou aboutissent à une compromission généralisée.

Scénarios : signalement requis ou non

Scénario	À signaler ?	Pourquoi
Un chercheur signale une vulnérabilité en privé	Non	Pas de preuve d'exploitation ; traiter via le processus CVD
PoC publié sur GitHub	Non	La publication n'est pas une exploitation
Un client signale une activité cohérente avec la vulnérabilité	Oui	Seuil de croyance raisonnable atteint
Vulnérabilité détectée comme exploitée dans la nature	Oui	Utilisation malveillante active
Un composant dans votre SBOM présente un CVE connu exploité	Évaluer	Signalement requis uniquement si l'exploitation affecte votre produit (VEX est déterminant ici)
Votre produit est ciblé par des acteurs de la menace nommés	Oui	Preuve d'exploitation directe
Un logiciel malveillant générique utilise une classe de vulnérabilité présente dans votre produit	Évaluer	Uniquement si votre implémentation spécifique est affectée

Le standard de la croyance raisonnable

Une preuve forensique d'exploitation n'est pas requise. Le standard de l'Article 14 est la croyance raisonnable fondée sur les éléments disponibles : schémas d'accès inhabituels cohérents avec des techniques d'exploitation connues, signalements de compromission par des clients, renseignements sur les menaces indiquant que votre produit est ciblé, ou détection de code d'exploitation conçu pour votre produit. En cas d'incertitude, signalez. Une alerte précoce prématurée qui s'avère infondée vaut bien mieux qu'un délai manqué pour une exploitation réelle, et la notification à 72 heures peut mettre à jour l'évaluation.

Politique de divulgation coordonnée des vulnérabilités (CVD) : le lien avec l'Article 14

L'Annexe I Partie II point 5 du CRA exige des fabricants qu'ils « mettent en place et appliquent une politique de divulgation coordonnée des vulnérabilités ». La politique CVD est le mécanisme opérationnel qui transforme les signalements externes des chercheurs en flux de triage structuré et qui, lorsqu'une exploitation active est détectée pendant le triage, déclenche en parallèle le compteur de signalement de l'Article 14. L'obligation s'applique à tout produit comportant des éléments numériques, sans seuil PME ni seuil de taille. Le minimum livrable est une URL publique et un fichier security.txt sous /.well-known/security.txt (RFC 9116) afin que les signalements soient découvrables par les chercheurs que le règlement est précisément conçu pour canaliser.

Pour la politique CVD elle-même, y compris le contenu obligatoire, les conventions de fenêtre de divulgation, la formulation du safe harbour et les modèles de communication avec les chercheurs, consultez le guide CRA sur la divulgation coordonnée des vulnérabilités. Pour la place de la CVD parmi les autres obligations de l'Annexe I Partie II (SBOM, remédiation, mises à jour sécurisées, livraison gratuite), consultez la gestion des vulnérabilités CRA. Cette page se concentre sur la cadence de notification au titre de l'Article 14 qui se déclenche lorsque le triage confirme une exploitation active.

VEX : communiquer l'applicabilité des vulnérabilités

L'Annexe I Partie I exige que les produits CRA soient livrés sans vulnérabilités exploitables connues et avec une configuration sécurisée par défaut. Le scan de SBOM produit de longues listes de CVE sur les composants, dont la plupart ne sont pas réellement exploitables dans votre produit spécifique. VEX (Vulnerability Exploitability eXchange) est le mécanisme qui transforme ces résultats bruts en une position défendable « non affecté / affecté / corrigé / en investigation » par CVE, ce qu'attendent le règlement, les normes harmonisées en développement, et les marchés publics allemands sous BSI TR-03183 Partie 3.

Qu'est-ce que VEX

VEX est une déclaration structurée et lisible par machine indiquant si une vulnérabilité dans un composant affecte réellement un produit spécifique. Il répond à la question : « CVE-XXXX existe dans notre SBOM. Affecte-t-il notre produit, pourquoi ou pourquoi pas, et que doit faire l'utilisateur ? » Les quatre états principaux sont :

État	Signification
not_affected	La vulnérabilité existe dans le composant mais n'affecte pas ce produit (chemin de code vulnérable inaccessible, fonction non appelée, configuration atténuante, etc.). Une justification est attendue.
affected	La vulnérabilité affecte ce produit. Une action et une recommandation sont attendues.
fixed	La vulnérabilité était présente et a été corrigée dans cette version.
under_investigation	Statut pas encore déterminé ; évaluation en cours.

Lien avec le CRA

VEX n'est pas nommé dans le texte du CRA, mais c'est l'outil opérationnel derrière trois des clauses du règlement :

• Annexe I Partie I, aucune vulnérabilité exploitable connue. Une déclaration VEX not_affected avec une justification documentée est la preuve que vous avez évalué un CVE et conclu qu'il ne s'applique pas. Sans elle, chaque CVE dans votre SBOM est une présomption de responsabilité.
• Annexe I Partie II, gestion des vulnérabilités. VEX est la piste d'audit de la façon dont chaque CVE est passé de under_investigation à not_affected, affected ou fixed dans le temps.
• Article 14, déclencheurs de signalement. Une vulnérabilité marquée affected et connue pour être activement exploitée est précisément le déclencheur qui lance le compteur de 24 heures. Une vulnérabilité marquée not_affected avec une justification solide ne l'est pas.

Formats VEX

Deux formats comptent en pratique. CycloneDX VEX est intégré directement dans un SBOM CycloneDX sous vulnerabilities[].analysis. CSAF VEX est un document séparé en CSAF 2.0 (le format exigé par BSI TR-03183 Partie 3 pour les avis de sécurité, et le format que les CERT allemands publient et consomment par défaut). Les deux sont lisibles par machine et remplissent le même rôle opérationnel.

Une assertion VEX minimale en CycloneDX :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

La spécification CycloneDX 1.5 définit six états d'analyse (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), un vocabulaire plus fin que les quatre états d'OpenVEX (not_affected, affected, fixed, under_investigation) sur lesquels il se projette. BSI TR-03183 Partie 3 attend des déclarations VEX aux côtés des SBOMs pour les produits alignés CRA. Pour le tableau complet SBOM et BSI TR-03183, consultez le guide cluster SBOM.

Exemptions PME et obligations allégées

L'Article 64(10) prévoit un allègement de sanction limité pour les fabricants les plus petits. Il n'exempte personne du signalement.

Les micro-entreprises et les petites entreprises (définies comme ayant moins de 50 salariés et un chiffre d'affaires annuel ou un bilan jusqu'à 10 millions EUR ; micro-entreprises : moins de 10 salariés, 2 millions EUR) sont exemptées des amendes spécifiquement pour non-respect des délais d'alerte précoce de 24 heures au titre de l'Article 14(2)(a) et de l'Article 14(4)(a). L'allègement couvre uniquement les amendes liées au délai de la voie à 24 heures.

Toujours requis, sans allègement PME :

• La notification détaillée à 72 heures (Art. 14(2)(b) et 14(4)(b)).
• Le rapport final à 14 jours pour les vulnérabilités et le rapport final à 1 mois pour les incidents graves.
• La politique CVD au titre de l'Annexe I Partie II.
• Toutes les autres obligations CRA, y compris l'exigence « aucune vulnérabilité exploitable connue » au titre de l'Annexe I Partie I.

Les entreprises moyennes (jusqu'à 250 salariés) ne sont pas couvertes par l'allègement PME. L'exemption est un aménagement de sanction limité, pas un régime de signalement allégé.

Erreurs courantes

• Attendre la certitude forensique avant de lancer le compteur. L'Article 14 retient un standard de croyance raisonnable. Attendre la preuve fait manquer le délai.
• Confondre CVD et signalement au titre de l'Article 14. Un signalement de chercheur est une entrée CVD ; le signalement au titre de l'Article 14 est déclenché par des preuves d'exploitation active. La politique CVD doit contenir un point de contrôle explicite à cet effet.
• Point unique de défaillance dans l'escalade. Une seule personne autorisée à signaler, injoignable un vendredi soir. Le compteur de 24 heures ne s'arrête pas.
• Premier contact avec le CSIRT coordinateur lors d'un incident. Établissez la relation et le routage maintenant, pendant qu'aucun délai ne tourne.
• Pas de politique CVD publiée. L'obligation de l'Annexe I Partie II n'est pas satisfaite par un document interne.
• Pas de déclarations VEX. Chaque CVE dans votre SBOM est présumé exploitable tant que vous ne vous êtes pas exprimé. L'Annexe I Partie I est beaucoup plus difficile à défendre sans VEX.
• Traiter le lancement de la SRP comme un problème futur. Les modèles, les rotations d'astreinte et les relations avec les CSIRT doivent être en place avant septembre 2026, pas construits après.