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.
In this article
- Résumé
- Qu'est-ce qui Déclenche le Signalement CRA ?
- Ce que Signifie « Activement Exploité »
- Délais de Signalement
- Où Signaler
- Checklist de Préparation Interne
- Pièges Courants
- Exemptions pour les PME
- Intégration avec les Processus Existants
- Checklist de Préparation au Signalement ENISA
- Comment CRA Evidence Aide
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
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.
Sujets traités dans cet article
Articles connexes
Les caméras intelligentes sont-elles des produits...
Les caméras de sécurité connectées sont classifiées comme Produits...
11 minCybersecurity Act 2 de l'UE : Interdictions dans la...
Le 20 janvier 2026, l'UE a proposé de remplacer entièrement le Cybersecurity...
12 minClassification des produits CRA : Votre produit est-il...
Guide pratique pour déterminer la catégorie CRA de votre produit. Inclut des...
6 minDoes 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.