Signalement des Vulnérabilités ENISA : Ce qui Déclenche le Délai de 24 Heures sous le CRA

Un guide pratique des obligations de signalement des vulnérabilités et incidents CRA à partir de septembre 2026. Couvre les déclencheurs, les délais et la préparation interne.

Équipe CRA Evidence
Auteur
11 février 2026
Mis à jour 25 février 2026, 00:00:00 TU
13 min de lecture
Signalement des Vulnérabilités ENISA : Ce qui Déclenche le Délai de 24 Heures sous le CRA
In this article

11 septembre 2026. À partir de cette date, vous avez 24 heures pour signaler les vulnérabilités activement exploitées à ENISA. Manquez le délai et faites face à des mesures d'application.

Ce guide couvre ce qui déclenche le signalement, ce que signifie vraiment « activement exploité », et comment préparer votre processus interne avant l'échéance.

Résumé

  • Septembre 2026 : Les obligations de signalement des vulnérabilités et incidents commencent
  • « Activement exploité » : Un acteur malveillant a utilisé la vulnérabilité pour affecter les utilisateurs
  • Délais : 24h alerte précoce → 72h notification détaillée → 14j rapport final (vulns) / 30j (incidents)
  • Signaler à : Plateforme Unique de Signalement ENISA + CSIRT national concerné
  • Préparez-vous maintenant : Processus de triage interne, voies d'escalade, modèles de rapport

Calendrier de signalement des vulnérabilités ENISA — 24 heures, 72 heures, 14 jours

Qu'est-ce qui Déclenche le Signalement CRA ?

Le CRA définit deux catégories nécessitant une notification obligatoire :

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é exploitée par un acteur malveillant
  • Affecte ou pourrait affecter les utilisateurs de votre produit

2. Incidents Graves

Incidents de sécurité qui :

  • Impactent la sécurité de votre produit
  • Compromettent votre environnement de développement de manière affectant la sécurité du produit
  • Causent une interruption de service significative aux utilisateurs
  • Résultent en une compromission généralisée

Les deux catégories déclenchent les mêmes délais de signalement mais ont des fenêtres de rapport final différentes.

Avertissement : Le compteur de 24 heures demarre a la CONNAISSANCE de l'exploitation active, pas a la confirmation. Si vous avez des preuves fiables, le compteur tourne deja.

Ce que Signifie « Activement Exploité »

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 que :

  • Une vulnérabilité rendue publique
  • Une preuve de concept publiée
  • Un chercheur démontrant l'exploitabilité

Cela signifie une utilisation malveillante réelle.

Scénarios à Signaler vs Non Signalables

Scénario À signaler ? Pourquoi
Un chercheur en sécurité signale une vulnérabilité en privé Non Pas d'exploitation, gérer via le processus CVD
Preuve de concept publiée sur GitHub Non Publication PoC ≠ exploitation
Un client signale une activité suspecte cohérente avec la vulnérabilité Oui Preuve d'exploitation
Vulnérabilité détectée comme exploitée dans la nature Oui Utilisation malveillante active
Un composant de votre SBOM a une vulnérabilité connue exploitée Évaluer Seulement si l'exploitation affecte votre produit
Votre produit est spécifiquement ciblé dans des attaques Oui Exploitation directe
Un malware générique utilise une classe de vulnérabilité que votre produit possède Évaluer Seulement si votre implémentation spécifique est affectée

Le Standard de « Croyance Raisonnable »

Vous n'avez pas besoin de preuve forensique de l'exploitation. Le standard est une croyance raisonnable basée sur les preuves disponibles :

  • Patterns d'accès inhabituels cohérents avec des techniques d'exploit connues
  • Rapports clients de compromission
  • Renseignements sur les menaces indiquant que votre produit est ciblé
  • Détection de code d'exploit conçu pour votre produit

En cas d'incertitude : Préférez signaler. Une alerte précoce prématurée qui s'avère infondée est bien meilleure qu'un délai manqué pour une exploitation réelle.

Délais de Signalement

Les vulnérabilités et incidents suivent tous deux un modèle de signalement par étapes :

Chronologie Vulnérabilité Activement Exploitée

DÉCOUVERTE → 24 HEURES → 72 HEURES → PATCH DISPONIBLE → 14 JOURS
    │           │           │            │                  │
    │           │           │            │                  └── Rapport Final
    │           │           │            └── Le compteur redémarre
    │           │           └── Notification Détaillée
    │           └── Alerte Précoce
    └── Le compteur démarre

Chronologie Incident Grave

DÉCOUVERTE → 24 HEURES → 72 HEURES → 1 MOIS
    │           │           │           │
    │           │           │           └── Rapport Final
    │           │           └── Notification Détaillée
    │           └── Alerte Précoce
    └── Le compteur démarre

Ce que Contient Chaque Rapport

Alerte Précoce (24 heures)

Information minimale pour alerter les autorités :

  • Votre identité (fabricant)
  • Identification du/des produit(s) affecté(s)
  • Brève description de la vulnérabilité/incident
  • Évaluation initiale de la gravité
  • Si l'exploitation est confirmée ou suspectée
  • Indication de la portée d'impact potentielle

Ce n'est pas une analyse complète. C'est une alerte que quelque chose de grave se passe.

Notification Détaillée (72 heures)

Information élargie pour l'évaluation :

  • Détails techniques de la vulnérabilité
  • Versions et configurations affectées
  • Méthode d'exploitation (si connue)
  • Statut actuel de mitigation
  • Estimation du calendrier de remédiation
  • Utilisateurs/portée affectés connus
  • Coordination avec d'autres parties (autres fournisseurs, CSIRTs)

Rapport Final (14 jours pour vulns / 30 jours pour incidents)

Analyse complète après remédiation :

  • Analyse des causes profondes
  • Description technique complète
  • Actions de remédiation prises
  • Leçons apprises
  • Mesures de prévention mises en place
  • Évaluation d'impact (utilisateurs affectés confirmés, exposition de données, etc.)

Où Signaler

Plateforme Unique de Signalement ENISA (SRP)

À partir de septembre 2026, ENISA exploitera un point d'entrée unique pour les notifications CRA.

Ce que nous savons :

  • Plateforme web pour les soumissions
  • Accès API pour le signalement automatisé (anticipé)
  • Routage simultané vers les CSIRTs nationaux concernés
  • Formulaires de signalement standardisés

VÉRIFIER AVEC SOURCE PRIMAIRE : Les spécifications exactes de la plateforme et l'URL en attente de publication ENISA.

CSIRTs Nationaux

Les rapports vont simultanément à :

  • ENISA (coordination au niveau UE)
  • CSIRT(s) national/nationaux où le produit est disponible

La SRP devrait gérer le routage automatiquement en fonction de votre déclaration de présence sur le marché.

Pour les Produits dans Plusieurs États Membres

Si votre produit est disponible dans plusieurs pays UE :

  • Une soumission à la SRP
  • La plateforme route vers tous les CSIRTs concernés
  • Vous pouvez recevoir des suivis de plusieurs autorités nationales

Checklist de Préparation Interne

Conseil : Pre-approuvez les modeles de notification et etablissez des voies d'escalade 24/7 MAINTENANT. Vous ne pouvez pas rediger des modeles pendant un delai de 24 heures.

N'attendez pas septembre 2026. Construisez vos processus maintenant.

1. Canaux de Réception des Vulnérabilités

Établissez des voies claires pour les signalements de vulnérabilités :

Fichier security.txt :

# https://votreproduit.com/.well-known/security.txt
Contact: mailto:security@votreentreprise.com
Contact: https://votreentreprise.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: fr
Canonical: https://votreentreprise.com/.well-known/security.txt
Policy: https://votreentreprise.com/security/policy

Formulaire web pour les rapports structurés

Email dédié surveillé 24/7 (ou avec SLA clair)

2. Processus de Triage Interne

Définissez comment les rapports sont évalués :

TRIAGE RÉCEPTION VULNÉRABILITÉ

1. Réception Initiale (< 4 heures)
   - Accuser réception
   - Assigner à un membre de l'équipe sécurité
   - Vérification initiale de validité

2. Triage Technique (< 24 heures)
   - Confirmer que la vulnérabilité existe
   - Déterminer les versions affectées
   - Évaluer l'exploitabilité
   - Vérifier les preuves d'exploitation active

3. Évaluation de Gravité (< 24 heures)
   - Score CVSS (ou équivalent)
   - Évaluation d'impact business
   - Probabilité d'exploitation

4. Décision de Signalement (IMMÉDIAT si exploitation confirmée)
   - Cela nécessite-t-il une notification ENISA ?
   - Si oui, déclencher le compteur de 24 heures

3. Voies d'Escalade

Définissez qui peut déclencher le signalement externe :

Rôle Autorité
Responsable Équipe Sécurité Peut initier l'alerte précoce
RSSI / Directeur Sécurité Doit approuver la notification détaillée
Juridique / Conformité Revue avant le rapport final
Sponsor Exécutif Escalade pour les cas ambigus

Principe clé : La personne qui découvre une exploitation potentielle doit pouvoir escalader immédiatement, 24/7.

4. Couverture Hors Heures Ouvrées

Le compteur de 24 heures ne s'arrête pas le week-end ou les jours fériés.

Options :

  • Rotation d'astreinte pour l'équipe sécurité
  • Service de surveillance avec autorité d'escalade
  • Chaîne de contact hors heures claire
  • Signaleurs pré-autorisés pouvant soumettre des alertes précoces

5. Modèles de Rapport

Préparez les modèles avant d'en avoir besoin :

Modèle d'Alerte Précoce :

ALERTE PRÉCOCE CRA ENISA

Fabricant : [Nom de l'Entreprise]
Date du Rapport : [Date/Heure UTC]
Type de Rapport : [ ] Vulnérabilité Activement Exploitée [ ] Incident Grave

PRODUIT(S) AFFECTÉ(S) :
- Nom du Produit :
- Version(s) :
- Catégorie de Produit :

RÉSUMÉ VULNÉRABILITÉ/INCIDENT :
[Brève description - 2-3 phrases]

STATUT D'EXPLOITATION :
[ ] Exploitation confirmée
[ ] Exploitation suspectée
Preuves : [Brève description des preuves]

ÉVALUATION INITIALE DE GRAVITÉ :
[ ] Critique [ ] Élevée [ ] Moyenne [ ] Faible
Base : [Score CVSS ou autre justification]

PORTÉE D'IMPACT POTENTIELLE :
- Utilisateurs affectés estimés :
- Portée géographique :
- Données à risque :

STATUT ACTUEL :
[ ] En cours d'investigation
[ ] Mitigation en cours
[ ] Patch en développement

CONTACT POUR SUIVI :
Nom :
Email :
Téléphone :

Ceci est une alerte précoce. Notification détaillée à suivre dans les 72 heures.

6. Testez Votre Processus

Effectuez des exercices de simulation avant septembre 2026 :

Scénario 1 : Vendredi 17h - Un chercheur en sécurité signale une vulnérabilité critique avec PoC

  • À quelle vitesse pouvez-vous évaluer le risque d'exploitation ?
  • Qui prend la décision de signalement le week-end ?

Scénario 2 : Un client signale une activité suspecte suggérant que votre produit était le point d'entrée

  • Comment rassemblez-vous les preuves pour confirmer/infirmer l'exploitation ?
  • Quel est votre seuil pour la « croyance raisonnable » ?

Scénario 3 : Les renseignements sur les menaces indiquent que votre produit est ciblé par un groupe APT

  • Avez-vous une visibilité sur l'exploitation réelle ?
  • Comment coordonnez-vous avec les fournisseurs externes de threat intel ?

Pièges Courants

Attendre la Certitude

Problème : Vouloir une preuve forensique avant de signaler.

Réalité : Le compteur de 24 heures démarre quand vous avez une croyance raisonnable. Si vous attendez la certitude, vous manquerez le délai.

Solution : Signalez tôt. Vous pouvez mettre à jour avec « plus considéré comme exploité » dans la notification détaillée si les preuves ne le confirment pas.

Confondre CVD et Signalement

Problème : Traiter les rapports de chercheurs comme des notifications ENISA.

Réalité : La divulgation coordonnée des vulnérabilités et le signalement ENISA sont des processus séparés.

  • CVD : Comment vous gérez les rapports de chercheurs, convenez des délais de divulgation
  • ENISA : Notification obligatoire quand une exploitation se produit

Solution : Le processus CVD devrait inclure un point de contrôle : « Y a-t-il des preuves d'exploitation ? » Si oui, déclencher le signalement ENISA parallèlement au CVD.

Point Unique de Défaillance

Problème : Une seule personne peut autoriser les signalements, et elle est injoignable.

Réalité : L'exploitation peut être découverte à tout moment. Week-ends. Jours fériés. 3h du matin.

Solution : Plusieurs signaleurs autorisés. Délégation claire. Chaîne de contact d'urgence.

Pas de Relation avec les CSIRTs

Problème : Premier contact avec votre CSIRT national lors d'un incident.

Réalité : Construire des relations en amont facilite la réponse aux incidents.

Solution : Engagez-vous avec votre CSIRT national maintenant. Comprenez leurs processus. Rejoignez tout programme de sensibilisation des fabricants.

Exemptions pour les PME

Info : Les PME sont exemptees des amendes specifiques aux delais pour les echeances de signalement ENISA, mais doivent toujours signaler. C'est un allegement de penalite, pas une exemption de signalement.

Les petites et moyennes entreprises bénéficient d'un certain allègement :

Exemption de délai de notification : Les PME sont exemptées des amendes spécifiquement liées aux délais de notification de 24 heures et 72 heures.

Toujours requis :

  • Le signalement (juste pas pénalisé pour les retards de délai)
  • Toutes les autres obligations CRA
  • Les rapports finaux

Définition : PME telle que définie dans la Recommandation UE 2003/361/CE (moins de 250 employés, chiffre d'affaires ≤ 50 millions EUR ou bilan ≤ 43 millions EUR).

Cette exemption ne concerne que les pénalités de délai. Les PME doivent tout de même établir des capacités de signalement.

Intégration avec les Processus Existants

Si Vous Avez Déjà une Réponse aux Incidents

Mappez le signalement CRA à votre processus existant :

PROCESSUS IR EXISTANT          INTÉGRATION CRA
───────────────────────────────────────────────
Détection
    
Triage ──────────────────→  Vérifier : Exploitation d'un produit CRA ?
                                 
Confinement                       ├─ OUI : Déclencher compteur 24h
                                         Soumettre alerte précoce
Investigation                     
                                 
Remédiation ──────────────→  Notification détaillée 72h
    
Récupération
    
Leçons Apprises ──────────→  Rapport final 14j/30j

Si Vous Avez des Obligations NIS 2

Certaines organisations ont à la fois des obligations NIS 2 et CRA :

  • NIS 2 : Incidents au niveau organisation/service
  • CRA : Vulnérabilités et incidents au niveau produit

Ceux-ci peuvent se chevaucher. Un seul incident peut nécessiter :

  • Notification NIS 2 à l'autorité compétente
  • Notification CRA à ENISA/CSIRT

La SRP ENISA est conçue pour gérer le routage pour les deux régimes le cas échéant.

Checklist de Préparation au Signalement ENISA

CHECKLIST PRÉPARATION SIGNALEMENT ENISA

AVANT SEPTEMBRE 2026 :

CANAUX & CONTACTS
[ ] security.txt publié et à jour
[ ] Formulaire de signalement de vulnérabilité disponible
[ ] Email sécurité surveillé (définir SLA : ____ heures)
[ ] Contact CSIRT national identifié
[ ] Inscription SRP ENISA (quand disponible)

PROCESSUS INTERNE
[ ] Critères de triage documentés
[ ] Checklist d'évaluation d'exploitation créée
[ ] Voie d'escalade définie (noms, contacts)
[ ] Signaleurs autorisés identifiés
[ ] Couverture hors heures établie

DOCUMENTATION
[ ] Modèle d'alerte précoce préparé
[ ] Modèle de notification détaillée préparé
[ ] Modèle de rapport final préparé
[ ] Documents de briefing interne prêts

TESTS
[ ] Exercice de simulation complété
[ ] Escalade hors heures testée
[ ] Revue des modèles complétée

QUAND UNE EXPLOITATION EST DÉTECTÉE :

IMMÉDIAT (dans les 4 heures)
[ ] Évaluation initiale : Est-ce activement exploité ?
[ ] Heure de début du compteur documentée : ____________
[ ] Escalade au signaleur autorisé

DANS LES 24 HEURES
[ ] Alerte précoce soumise à ENISA SRP
[ ] Confirmation de soumission reçue
[ ] Parties prenantes internes notifiées

DANS LES 72 HEURES
[ ] Notification détaillée soumise
[ ] Statut de mitigation mis à jour
[ ] Communication client initiée (si approprié)

DANS LES 14 JOURS (vulnérabilité) / 30 JOURS (incident)
[ ] Rapport final soumis
[ ] Leçons apprises documentées
[ ] Améliorations de processus identifiées

Comment CRA Evidence Aide

CRA Evidence inclut le support du flux de travail de signalement ENISA :

  • Suivi des délais : Compte à rebours automatique depuis la découverte
  • Modèles de rapport : Pré-remplis avec les détails de votre produit
  • Piste d'audit : Documentez votre chronologie et vos décisions
  • Intégration : Connectez l'analyse de vulnérabilités au flux de signalement

Soyez prêt pour septembre 2026 avec app.craevidence.com.

Calendrier : Decouvrez quand les obligations de signalement commencent dans notre calendrier de mise en oeuvre du CRA.

CVD : Mettez en place votre processus de reception des vulnerabilites avec notre modele de politique CVD.

Sanctions : Comprenez les consequences d'application dans notre guide des sanctions.


Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié familier avec les réglementations produits de l'UE.

Partager cet article

Articles connexes

Does the CRA apply to your product?

Répondez à 6 questions simples pour savoir si votre produit relève du champ d’application du Cyber Resilience Act de l’UE. Obtenez votre résultat en moins de 2 minutes.

Prêt à atteindre la conformité CRA ?

Commencez à gérer vos SBOMs et votre documentation de conformité avec CRA Evidence.