À partir du 11 septembre 2026, les fabricants CRA doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement ENISA. Ce guide explique ce qui déclenche un signalement, comment fonctionnent les délais de 24 heures, 72 heures, 14 jours et 1 mois, et où s'insèrent la CVD, VEX et l'information des utilisateurs.
Résumé
- Le signalement urgent commence le 11 septembre 2026 : les deux flux utilisent une alerte 24 h et une notification 72 h ; le rapport final est dû 14 jours après la disponibilité d'une mesure corrective ou d'atténuation pour les vulnérabilités, et dans le mois suivant la notification 72 h pour les incidents graves.
- Une seule soumission via l'ENISA SRP : la plateforme route le rapport vers le CSIRT coordonnateur et le rend accessible à l'ENISA.
- L'exploitation active exige des preuves fiables qu'un acteur malveillant a exploité la vulnérabilité dans un système sans autorisation ; une divulgation, un PoC public ou une démonstration de chercheur ne suffit pas à elle seule.
- La politique CVD est obligatoire : écrite, publiée, appliquée et reliée au seuil de signalement lorsque le triage constate une exploitation active.
- VEX soutient les décisions de signalement en documentant si une CVE dans un composant SBOM affecte réellement le produit.
- Les sanctions sont traitées dans le guide enforcement : un signalement tardif ou absent peut créer une exposition sérieuse ; consultez sanctions et enforcement CRA pour les niveaux et exceptions PME.
Le modèle de signalement en pratique : alerte initiale, notification détaillée, rapport final et renvoi vers l'enforcement.
Ce qui doit être signalé
Le signalement CRA comporte deux flux d'événements obligatoires et une obligation d'information des utilisateurs. L'obligation incombe au fabricant du produit comportant des éléments numériques mis sur le marché de l'UE :
- Signaler toute vulnérabilité activement exploitée dans le produit simultanément au CSIRT coordonnateur et à l'ENISA, selon la cadence 24 h / 72 h / 14 j.
- Signaler tout incident grave ayant un impact sur la sécurité du produit selon la cadence 24 h / 72 h / 1 mois.
- Informer les utilisateurs concernés de la vulnérabilité ou de l'incident et des mesures correctives, sans retard injustifié.
Cette page couvre aussi deux contrôles adjacents qui alimentent la décision de signalement : la politique CVD obligatoire et les preuves d'applicabilité comme VEX. Aucune de ces obligations n'a de seuil de taille. Les microentreprises et petites entreprises bénéficient seulement d'une exception étroite pour l'alerte 24h ; elles ne sont pas exemptées du signalement.
La plateforme unique de signalement ENISA (SRP)
La SRP est le canal unique pour les signalements CRA obligatoires de vulnérabilités et d'incidents. Elle existe parce que le fabricant doit notifier le CSIRT coordonnateur et l'ENISA via une plateforme unique, plutôt que déposer séparément dans chaque État membre où le produit est disponible. L'ENISA établit et gère la plateforme.
Fonctionnement pratique :
- Vous soumettez une seule fois, via le point d'entrée électronique du CSIRT désigné comme coordonnateur.
- La soumission est adressée au CSIRT coordonnateur et accessible simultanément à l'ENISA, sauf application du mécanisme exceptionnel de retard de diffusion.
- Le CSIRT coordonnateur diffuse ensuite la notification aux CSIRT des autres États membres où le produit a été mis à disposition. Cette diffusion secondaire relève du CSIRT, pas du fabricant.
- La règle de retard permet à un CSIRT de retarder la diffusion pour des motifs de cybersécurité justifiés dans des circonstances exceptionnelles. La divulgation coordonnée peut aussi permettre un retard avec le consentement du fabricant.
État en juin 2026 : la SRP doit être opérationnelle au 11 septembre 2026, avec une période de test préalable. L'ENISA indique qu'elle fournira le manuel d'accès et d'enregistrement ainsi que les supports de formation et d'exercice pendant juin 2026 ; les modalités d'enregistrement sont donc encore en cours de publication. L'ENISA indique également qu'aucune API SRP ne sera fournie à ce stade : prévoyez la préparation au signalement autour de la soumission via la plateforme plutôt que par automatisation. Pour les mécanismes d'enregistrement, voir l'intégration à la SRP ENISA. Suivez la page de la Commission sur le signalement CRA et la page ENISA SRP avant de vous appuyer sur une étape d'enregistrement précise.
À préparer maintenant : identifier votre CSIRT coordonnateur, préapprouver les modèles d'alerte 24 h, notification 72 h et rapport final pour les deux flux, et définir une astreinte hors horaires. Les modèles et processus ne doivent pas être improvisés pendant que l'horloge de 24 heures tourne.
Délais de signalement en détail
Les vulnérabilités et les incidents graves suivent tous deux un modèle par étapes. Les délais divergent au stade du rapport final.
Calendrier de signalement
| Étape | Vulnérabilité | Incident grave | Point de départ |
|---|---|---|---|
| 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 disponibilité d'une mesure corrective ou d'atténuation | 1 mois après la notification d'incident à 72 h | Point de départ différent selon le flux |
| Information des utilisateurs | Sans retard injustifié | Sans retard injustifié | Information utilisateur |
Contenu de chaque soumission
Alerte précoce (24 heures). L'alerte précoce est une alerte, pas une analyse complète. Pour les vulnérabilités, elle doit être transmise sans retard injustifié et dans les 24 heures suivant la prise de connaissance, et indiquer, le cas échéant, les États membres où le fabricant sait que le produit a été mis à disposition. Pour les incidents graves, elle doit au moins indiquer si l'incident est soupçonné d'être causé par des actes illicites ou malveillants. Les modèles internes peuvent ajouter version, gravité, périmètre d'impact et propriétaire, mais ce sont des champs opérationnels, pas tous des minima juridiques.
Notification détaillée (72 heures). Deux obligations distinctes existent à ce stade. La notification de vulnérabilité à 72 h concerne les vulnérabilités activement exploitées et fournit des informations générales sur le produit, l'exploit, la vulnérabilité, les mesures prises, les mesures pour les utilisateurs et la sensibilité le cas échéant. La notification d'incident à 72 h concerne les incidents graves et fournit des informations générales sur l'incident, une première évaluation, les mesures prises, les mesures pour les utilisateurs et la sensibilité le cas échéant.
Rapport final. Pour les vulnérabilités, le délai de 14 jours commence lorsqu'une mesure corrective ou d'atténuation est disponible, non à la découverte ni à la notification 72 h. Le rapport final doit au moins inclure description, gravité et impact de la vulnérabilité, informations disponibles sur les acteurs malveillants, et détails de la mise à jour de sécurité ou d'autres mesures correctives. Pour les incidents graves, le délai d'un mois part de la notification 72 h et le rapport final doit au moins inclure une description détaillée, gravité et impact, type de menace ou cause probable, et mesures d'atténuation appliquées ou en cours.
- Prise de connaissance du fabricant. L'horloge de 24 h démarre lorsque le fabricant prend connaissance de preuves fiables d'exploitation active.
- +24 h alerte précoce. Soumettre l'alerte initiale via l'ENISA Single Reporting Platform.
- +72 h notification détaillée. Ajouter détails techniques, versions affectées, état d'exploitation et mesures d'atténuation.
- Mesure disponible. Pour les vulnérabilités, le délai du rapport final démarre ici, pas à la découverte.
- +14 j rapport final. Soumettre les éléments finaux requis pour le flux vulnérabilité ou incident grave.
Les incidents graves suivent les mêmes étapes initiales de 24h et 72h ; le rapport final est dû dans le mois suivant la notification 72h.
Champs de données du modèle de signalement SRP
La FAQ SRP de l'ENISA (Q16) liste les champs attendus à chaque étape de signalement. L'ENISA précise que ces champs seront obligatoires (directement issus de la CRA ou par conséquence logique) ou facultatifs ; ils sont donc à traiter comme provisoires jusqu'à ce que la plateforme soit définitive. Codes : X obligatoire, O facultatif, C repris de l'étape précédente par défaut ou mis à jour, A automatisé (non affiché au soumettant), I obligatoire si l'information est disponible.
| # | Champ | 24h | 72h | Final |
|---|---|---|---|---|
| Champs communs | ||||
| 1 | Type de notification (vulnérabilité / incident) | X | C | C |
| 2 | Niveau de notification (24h / 72h / final) | X | X | X |
| 3 | Heure de signalement, 24h | A | A | A |
| 4 | Heure de signalement, 72h | A | A | A |
| 5 | Heure de signalement, final | A | A | A |
| 6 | Déclarant | A | A | A |
| 7 | Fabricant | X | C | C |
| 8 | Produit | X | C | C |
| 9 | Type de produit (par défaut / important / critique) | O | C | C |
| 10 | Catégorie de produit (si le type est important ou critique) | O | C | C |
| 11 | États membres où le produit est disponible | I | C | C |
| 12 | Titre | X | C | C |
| Vulnérabilité | ||||
| v13 | Identifiant CVE | O | C | C |
| v14 | Identifiant EUVD | O | C | C |
| v15 | Informations générales, notamment : | O | X | C |
| v16 | a. Nature générale de la vulnérabilité | O | X | C |
| v17 | b. Nature générale de l'exploitation | O | X | C |
| v18 | Mesures correctives ou d'atténuation prises | O | X | C |
| v19 | Mesures correctives ou d'atténuation que les utilisateurs peuvent prendre | O | X | C |
| v20 | Sensibilité estimée de l'information | O | I | C |
| v21 | Date à laquelle une mesure corrective ou d'atténuation est devenue disponible | O | O | X |
| v22 | Description complète de la vulnérabilité, notamment : | O | O | X |
| v23 | a. Gravité de la vulnérabilité | O | O | X |
| v24 | b. Impact de la vulnérabilité | O | O | X |
| v25 | Acteur malveillant ayant exploité ou exploitant la vulnérabilité | O | O | I |
| v26 | Détails sur la mise à jour de sécurité ou les mesures correctives | O | O | X |
| Incident | ||||
| i13 | Incident soupçonné d'être causé par des actes illicites ou malveillants | X | C | C |
| i14 | Informations générales sur la nature de l'incident | O | X | C |
| i15 | Date et heure de détection de l'incident | O | X | C |
| i16 | Date et heure de survenance de l'incident | O | X | C |
| i17 | Évaluation initiale de l'incident | O | X | C |
| i18 | Mesures correctives ou d'atténuation prises | O | X | C |
| i19 | Mesures correctives ou d'atténuation que les utilisateurs peuvent prendre | O | X | C |
| i20 | Sensibilité estimée de l'information | O | I | C |
| Description détaillée de l'incident, notamment : | O | O | X | |
| i21 | a. Gravité de l'incident (critères ci-dessous) | O | O | X |
| i23 | b. Impact de l'incident | O | O | X |
| i24 | Type de menace ou cause probable | O | O | X |
| i25 | Mesures d'atténuation appliquées et en cours | O | O | X |
Critères de gravité (i22) : un incident est grave s'il (1) affecte ou est susceptible d'affecter la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions sensibles ou importantes ; ou (2) a conduit ou est susceptible de conduire à l'introduction ou à l'exécution d'un code malveillant dans le produit ou dans le réseau et les systèmes d'information d'un utilisateur.
Source : FAQ ENISA SRP, Q16.
Ce qui déclenche une obligation de signalement
Le signalement CRA a deux catégories de déclenchement : vulnérabilités activement exploitées et incidents graves ayant un impact sur la sécurité du produit.
1. Vulnérabilités activement exploitées
Une vulnérabilité activement exploitée est une vulnérabilité du produit pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire du système. Le fabricant doit aussi avoir pris connaissance de cette exploitation avant que l'horloge de signalement démarre.
Ce n'est pas la même chose qu'une divulgation publique, un PoC publié ou une démonstration en laboratoire. Ces signaux relèvent de la gestion des vulnérabilités et du triage CVD sauf s'ils créent des preuves fiables d'exploitation malveillante contre un système réel.
2. Incidents graves
Un incident grave est un incident ayant un impact sur la sécurité du produit qui répond à l'un des critères suivants :
- il affecte ou peut affecter la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou fonctions sensibles ou importantes ; ou
- il a conduit ou peut conduire à l'introduction ou à l'exécution d'un code malveillant dans le produit ou dans le réseau et les systèmes d'information d'un utilisateur.
Scénarios signalables et non signalables
| Scénario | Signalable ? | Pourquoi |
|---|---|---|
| Un chercheur signale une vulnérabilité en privé | Non | Pas de preuve d'exploitation ; traiter via CVD |
| PoC publié sur GitHub | Non | La publication n'est pas une exploitation |
| Un client signale une activité compatible avec une exploitation | Évaluer | Signaler si les preuves sont assez fiables pour montrer l'exploitation active |
| Vulnérabilité détectée en exploitation réelle | Oui | Preuve fiable d'usage malveillant |
| Composant SBOM avec CVE connue exploitée | Évaluer | Signalable seulement si l'exploitation affecte votre produit |
| Produit ciblé par des acteurs nommés | Oui | Preuve directe d'exploitation |
| Malware générique utilisant une classe de vulnérabilités présente dans votre produit | Évaluer | Seulement si votre implémentation précise est affectée |
Connaissance et preuves
La définition CRA parle de preuves fiables, pas de certitude forensique. Les preuves utiles peuvent inclure télémétrie d'exploitation, rapports de compromission clients, renseignement de menace nommant votre produit ou journaux montrant un comportement d'exploitation. Si les preuves ne sont pas encore fiables, gardez l'événement en triage CVD ou incident ; lorsqu'elles le deviennent, l'horloge de 24 h démarre à la prise de connaissance par le fabricant.
Entrée CVD et seuil de signalement
La politique CVD est le processus d'entrée qui transforme les rapports externes en triage structuré. Lorsque ce triage produit des preuves fiables d'exploitation active, l'horloge de signalement urgent tourne en parallèle avec la remédiation et la divulgation coordonnée. La politique est obligatoire pour tout produit avec éléments numériques, sans seuil de taille. Une page CVD publique et un fichier security.txt sous /.well-known/security.txt sont la façon pratique de rendre le canal découvrable.
Pour la politique CVD elle-même, voir le guide CRA sur la divulgation coordonnée des vulnérabilités. Pour la place de CVD dans le cycle plus large, voir gestion des vulnérabilités CRA.
VEX et applicabilité des vulnérabilités
VEX est une déclaration structurée et lisible par machine indiquant si une vulnérabilité dans un composant SBOM affecte réellement un produit donné.
| État | Signification |
|---|---|
not_affected |
La vulnérabilité existe dans le composant mais n'affecte pas ce produit. Une justification est attendue. |
affected |
La vulnérabilité affecte ce produit. Action et recommandation 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. |
Pour le signalement, la question clé est applicabilité plus exploitation active. Une vulnérabilité affected appuyée par des preuves fiables d'exploitation active peut déclencher l'alerte 24 h. Une vulnérabilité not_affected avec justification solide soutient une décision de non-signalement. La CRA ne nomme pas VEX, mais VEX est une façon pratique de conserver cette justification. Voir le guide d'implémentation VEX.
Allègement pour petits fabricants
Les microentreprises et petites entreprises (définies comme comptant moins de 50 salariés et un chiffre d'affaires annuel ou un bilan total ne dépassant pas 10 millions d'euros ; microentreprises : moins de 10 salariés, 2 millions d'euros) sont exemptées de sanctions uniquement pour le non-respect de la première alerte 24h. L'allègement ne couvre que cette première étape.
Toujours requis, sans allègement PME :
- La notification détaillée à 72h.
- Le rapport final à 14 jours pour les vulnérabilités et le rapport final à 1 mois pour les incidents graves.
- La politique CVD.
- Les autres obligations de sécurité produit, y compris la base sans vulnérabilité exploitable connue.
Les moyennes entreprises ne sont pas couvertes. C'est une exception étroite de sanction, pas un régime de signalement réduit. La structure complète est dans sanctions et enforcement CRA.
Erreurs fréquentes
- Attendre la certitude forensique. Des preuves fiables suffisent ; la CRA n'exige pas une enquête complète avant l'alerte précoce.
- Confondre CVD et signalement urgent. Un rapport de chercheur est une entrée CVD ; le signalement urgent commence avec des preuves fiables d'exploitation active.
- Point de défaillance unique. Une seule personne autorisée, indisponible le week-end, ne suffit pas.
- Premier contact CSIRT pendant l'incident. Établissez la relation et le routage avant que l'horloge tourne.
- Pas de politique CVD publiée. Un document interne ne suffit pas.
- Pas de décision d'applicabilité. Sans VEX ou équivalent, il est difficile de défendre qu'une CVE connue n'est pas exploitable dans votre produit.
- Traiter la SRP comme un problème futur. Modèles, astreintes et relations CSIRT doivent exister avant septembre 2026.
Questions fréquentes
Quand les obligations CRA de signalement commencent-elles ?
Le signalement obligatoire CRA des vulnérabilités et incidents commence le 11 septembre 2026. À partir de cette date, les fabricants doivent utiliser la plateforme ENISA SRP pour l'alerte 24 h, la notification 72 h et les rapports finaux. Les obligations plus larges de sécurité produit s'appliquent à partir du 11 décembre 2027.
Qu'est-ce que l'ENISA SRP ?
La SRP est le canal unique pour les signalements CRA obligatoires et les signalements volontaires ; l'ENISA indique que la fonctionnalité de signalement volontaire est activée après le 11 septembre 2026. Le fabricant soumet une fois via le point d'entrée du CSIRT coordonnateur ; la notification est accessible simultanément à l'ENISA sauf mécanisme exceptionnel de retard. Suivez la page de la Commission et la page ENISA SRP.
Une politique CVD est-elle obligatoire ?
Oui. Chaque fabricant CRA doit disposer d'une politique CVD et d'un canal pratique de réception. security.txt n'est pas nommé dans la CRA, mais c'est un moyen pratique de publier l'adresse de contact exigée par les obligations de gestion des vulnérabilités.
Qu'est-ce que VEX et est-il nécessaire ?
VEX n'est pas obligatoire par son nom, mais un enregistrement d'applicabilité est très utile pour documenter les états not_affected, affected, fixed ou under_investigation. Voir le guide VEX.
Quelles amendes en cas de retard ou d'absence de signalement ?
Un signalement tardif ou absent peut créer une exposition sérieuse ; seules les microentreprises et petites entreprises ont une exception étroite pour la première alerte 24h. Voir sanctions et enforcement CRA pour la structure complète.
Où soumettre si le produit est vendu dans plusieurs États membres ?
Soumettez une seule fois via le point SRP de votre CSIRT coordonnateur. Pour un fabricant UE, c'est l'État membre où les décisions de cybersécurité produit sont principalement prises. Sans établissement principal dans l'Union, utilisez la chaîne mandataire, importateur, distributeur, concentration d'utilisateurs.
L'horloge de 24 heures s'arrête-t-elle le week-end ?
Non. Les délais courent en temps calendaire. La couverture week-end et jours fériés est donc une exigence opérationnelle.
Comment le signalement CRA interagit-il avec NIS 2 ?
Les deux régimes peuvent s'appliquer au même événement, mais ce ne sont pas la même obligation. La CRA est au niveau produit et passe par la SRP ; NIS 2 est au niveau entité/service et suit le canal national NIS 2.