Règlement sur la cyberrésilience : 24 h, ENISA SRP, sept. 2026

Le Règlement sur la cyberrésilience (Cyber Resilience Act, règlement (UE) 2024/2847) fait du signalement des vulnérabilités et des incidents une obligation ferme et limitée dans le temps pour les fabricants. À partir du 11 septembre 2026, l'Article 14 du CRA vous impose de signaler les vulnérabilités activement exploitées et les incidents graves dans les 24 heures, avec une notification détaillée sous 72 heures, un rapport final sous 14 jours pour les vulnérabilités (à compter de la disponibilité d'une mesure corrective ou d'atténuation), et un rapport final sous un mois pour les incidents graves. Le canal de signalement est la plateforme unique de signalement ENISA (SRP), prévue pour être opérationnelle d'ici le 11 septembre 2026, qui achemine votre soumission simultanément vers votre CSIRT coordinateur désigné et vers l'ENISA. Manquez le délai et les sanctions prévues à l'Article 64 s'appliquent : jusqu'à 15 000 000 € ou 2,5 % du chiffre d'affaires annuel mondial, selon le montant le plus élevé.

La plateforme ENISA SRP dans le cadre du CRA

Le CRA avait besoin d'un canal unique parce que l'Article 14(1) oblige les fabricants à notifier « simultanément au CSIRT désigné comme coordinateur, conformément au paragraphe 7 du présent article, et à l'ENISA ». Sans la SRP, cela aurait pu impliquer de déposer le même rapport auprès de plusieurs CSIRT nationaux. L'Article 16 résout cette tension : l'ENISA établit et exploite la plateforme, et « la gestion et la maintenance quotidiennes de cette plateforme unique de signalement sont assurées par l'ENISA » (Art. 16(1)).

L'architecture est simple. Vous soumettez une seule fois à la SRP via le point final électronique de votre CSIRT coordinateur. Le CSIRT et l'ENISA reçoivent la notification simultanément. En vertu de l'Article 16, le CSIRT coordinateur est ensuite chargé de diffuser la notification aux CSIRT des autres États membres où votre produit est mis sur le marché. La diffusion secondaire relève de la responsabilité du CSIRT, pas de la vôtre.

La SRP est prévue pour être opérationnelle d'ici le 11 septembre 2026, conformément à la FAQ ENISA SRP. Une période de test est attendue avant cette date ; aucune fenêtre spécifique n'a été publiée. L'ENISA a lancé un appel d'offres pour la mise en oeuvre sous la référence ENISA/2025/OP/0001 (contrat de 4 ans), avec une clôture en mars 2025. Le prestataire n'a pas été divulgué publiquement. Aucune URL d'inscription n'a été publiée. Consultez la page SRP de l'ENISA pour suivre les mises à jour.

Déclencheurs du signalement CRA

Le Règlement sur la cyberrésilience définit deux catégories soumises à 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

Des incidents de sécurité qui :

• Portent atteinte à la sécurité de votre produit
• Compromettent votre environnement de développement d'une façon affectant la sécurité du produit
• Provoquent une interruption de service généralisée pour les utilisateurs
• Aboutissent à une compromission généralisée

Les deux catégories déclenchent la même obligation d'alerte précoce, mais présentent des fenêtres différentes pour le rapport final.

Sens de « activement exploitée » au titre du CRA

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 désigne une utilisation malveillante réelle.

Scénarios : signalement requis ou non

Le standard de la croyance raisonnable

Vous n'avez pas besoin d'une preuve légale de l'exploitation. Le standard est celui de la croyance raisonnable fondée sur les éléments disponibles :

• Comportements 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é
• 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.

Délais de signalement

Vulnérabilités et incidents suivent tous deux un modèle de signalement par étapes.

Chronologie d'une vulnérabilité activement exploitée

DÉCOUVERTE → 24 HEURES → 72 HEURES → MESURE DISPONIBLE → 14 JOURS
    |           |           |               |                 |
    |           |           |               |                 \-- Rapport final
    |           |           |               \-- Le compteur redémarre
    |           |           \-- Notification détaillée
    |           \-- Alerte précoce
    \-- Le compteur démarre

Chronologie d'un incident grave

DÉCOUVERTE → 24 HEURES → 72 HEURES → 1 MOIS
    |           |           |           |
    |           |           |           \-- Rapport final
    |           |           \-- Notification d'incident
    |           \-- Alerte précoce
    \-- Le compteur démarre

Pour les incidents graves, le délai d'un mois est ancré à la notification d'incident de 72 heures, et non à la découverte (Art. 14(4)(c)).

Contenu de chaque rapport

Alerte précoce (24 heures)

Informations minimales pour alerter les autorités :

• Votre identité (fabricant)
• Identification du ou des produits affectés
• Brève description de la vulnérabilité ou de l'incident
• Évaluation initiale de la gravité
• Exploitation 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 signalant qu'un événement grave est en cours.

Notification détaillée (72 heures)

Deux obligations distinctes s'appliquent à 72 heures. La notification de vulnérabilité à 72 heures (Art. 14(2)(b)) concerne les vulnérabilités activement exploitées ; la notification d'incident à 72 heures (Art. 14(4)(b)) concerne les incidents graves. Informations élargies pour l'évaluation :

• Détails techniques de la vulnérabilité
• Versions et configurations affectées
• Méthode d'exploitation (si connue)
• Statut actuel des mesures d'atténuation
• Estimation du calendrier de remédiation
• Utilisateurs affectés connus ou portée estimée
• Coordination avec d'autres parties (autres fabricants, CSIRT)

Rapport final (14 jours pour les vulnérabilités / un mois pour les incidents)

Pour les vulnérabilités activement exploitées, 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 ou de la notification de 72 heures. Analyse complète après remédiation :

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

Fondement juridique CRA : Articles 14, 16, 64

Article 14 du CRA : l'obligation de signalement

L'Article 14 établit l'obligation de signalement et son calendrier pour tous les fabricants de produits comportant des éléments numériques. Il prévoit notamment : « Le fabricant notifie toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il a connaissance simultanément au CSIRT désigné comme coordinateur, conformément au paragraphe 7 du présent article, et à l'ENISA. » (Art. 14(1)).

L'Article 14(7) fixe la règle de routage. Vous soumettez au CSIRT de l'État membre où votre organisation a son établissement principal, c'est-à-dire là où les décisions relatives à la cybersécurité des produits sont principalement prises. Pour les fabricants établis hors de l'UE, la cascade s'applique : État membre de votre mandataire, puis importateur, puis distributeur, puis pays présentant la plus grande concentration d'utilisateurs. Si vous disposez de plusieurs mandataires, la cascade désigne l'État membre où le mandataire couvre le plus grand nombre de produits.

Article 16 du CRA : le mandat de la plateforme

L'Article 16(1) impose à l'ENISA d'établir la SRP et d'en assurer la gestion quotidienne. Les États membres peuvent également mettre en place des points finaux nationaux interfacés avec la SRP (Art. 16(1)). En vertu de l'Article 16(2), les CSIRT peuvent, dans des circonstances particulièrement exceptionnelles, différer la diffusion des notifications aux autres États membres pour protéger des opérations de sécurité en cours ; cette faculté appartient au CSIRT, pas à vous. L'Article 16(5) impose à l'ENISA et au réseau des CSIRT d'élaborer conjointement les spécifications techniques de la SRP. L'Article 16(6) traite de l'articulation avec la divulgation coordonnée des vulnérabilités : la diffusion d'une vulnérabilité faisant l'objet d'une divulgation coordonnée peut être différée avec le consentement du fabricant.

Où soumettre un rapport au titre de l'Article 14 du CRA

Plateforme unique de signalement ENISA (SRP)

La SRP n'est pas opérationnelle en avril 2026. La plateforme est prévue pour être opérationnelle d'ici le 11 septembre 2026 (selon la FAQ ENISA). Une période de test est attendue avant cette date ; aucune date spécifique n'a été publiée. Aucune URL d'inscription n'a été publiée. Consultez la page SRP de l'ENISA pour suivre les mises à jour.

Ce qui est confirmé :

• Plateforme web pour les soumissions
• Formulaires de signalement standardisés
• Une soumission via la SRP ENISA est acheminée simultanément vers votre CSIRT coordinateur désigné et vers l'ENISA (Art. 14(1))

Ce que les fabricants peuvent faire dès maintenant :

• Préparer des modèles de rapport en utilisant la structure ci-dessous
• Identifier votre CSIRT coordinateur (voir ci-dessous)
• Définir les voies d'escalade internes et les personnes autorisées à signaler

CSIRT nationaux

En vertu de l'Article 14(7) du Règlement (UE) 2024/2847, vous soumettez une seule fois via la SRP au CSIRT de l'État membre où votre organisation a son établissement principal. L'établissement principal désigne le lieu où les décisions relatives à la cybersécurité des produits sont principalement prises.

Si vous êtes établi hors de l'UE, le CSIRT concerné est celui de l'État membre de votre mandataire dans l'UE. En l'absence de mandataire, la cascade se reporte sur votre importateur, puis votre distributeur, puis le pays comptant la plus grande concentration d'utilisateurs.

Vous n'êtes pas tenu de notifier chaque CSIRT dans chaque pays où votre produit est vendu. En vertu de l'Article 16, l'ENISA achemine la notification vers les CSIRT des pays de commercialisation après votre soumission. Cette étape ne relève pas de la responsabilité du fabricant.

Pour les produits présents dans plusieurs États membres

Une seule soumission à la SRP couvre votre obligation de signalement. Vous pouvez recevoir des demandes de suivi de plusieurs autorités nationales, mais il n'existe qu'une seule voie de soumission.

Se préparer au signalement au titre de l'Article 14 du CRA

Conseil : Pré-approuvez les modèles de notification et établissez des voies d'escalade 24/7 maintenant. On ne rédige pas de modèles pendant un délai de 24 heures.

N'attendez pas septembre 2026. Construisez vos processus dès 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

E-mail dédié surveillé 24/7 (ou avec un 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 la gravité (< 24 heures)
   - Score CVSS (ou équivalent)
   - Évaluation de l'impact métier
   - Probabilité d'exploitation

4. Décision de signalement (IMMÉDIAT si exploitation confirmée)
   - Ce cas requiert-il une notification ENISA ?
   - Si oui, lancer le compteur de 24 heures

3. Voies d'escalade

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

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 ni 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 clairement définie
• 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 LA 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
[ ] Atténuation en cours
[ ] Correctif en développement

CONTACT POUR SUIVI :
Nom :
E-mail :
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 17 h, un chercheur 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 ou 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 vos fournisseurs externes de renseignement sur les menaces ?

Pièges courants dans le signalement CRA

Attendre la certitude

Problème : vouloir une preuve légale avant de signaler.

Réalité : le compteur de 24 heures démarre dès que vous disposez d'une croyance raisonnable. Attendre la certitude, c'est manquer le délai.

Solution : signalez tôt. Vous pourrez mettre à jour en indiquant « plus considéré comme exploité » dans la notification détaillée si les éléments ne le confirment pas.

Confondre divulgation coordonnée et signalement

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

Réalité : la divulgation coordonnée des vulnérabilités (CVD) et le signalement au titre de l'Article 14 du CRA sont deux processus distincts.

• CVD : comment vous gérez les rapports de chercheurs et convenez des délais de divulgation
• Signalement CRA : notification obligatoire lorsqu'une exploitation se produit

Solution : votre processus CVD doit inclure un point de contrôle : « Y a-t-il des preuves d'exploitation ? » Si oui, lancez le signalement CRA en parallèle du CVD.

Point unique de défaillance

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

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

Solution : plusieurs signaleurs autorisés, délégation claire, chaîne de contact d'urgence.

Absence de relation avec les CSIRT

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

Réalité : nouer des relations en amont fluidifie la réponse aux incidents.

Solution : prenez contact avec votre CSIRT national maintenant. Pour les fabricants français, l'ANSSI (via le CERT-FR) publie des ressources sur la coordination des incidents. Comprenez leurs processus. Rejoignez tout programme de sensibilisation des fabricants.

Exemptions pour les micro-entreprises et petites entreprises

Information : les micro-entreprises et petites entreprises sont exemptées des amendes spécifiques au délai de l'alerte précoce de 24 heures, mais doivent tout de même signaler. Il s'agit d'un allègement de sanction, pas d'une exemption de signalement.

Les micro-entreprises et petites entreprises bénéficient d'un certain allègement en vertu de l'Article 64(10) :

Exemption de délai de notification : exemptées des amendes pour non-respect des délais d'alerte précoce de 24 heures prévus aux Articles 14(2)(a) et 14(4)(a). Le délai de notification détaillée de 72 heures (Articles 14(2)(b) et 14(4)(b)) n'est pas couvert. Son non-respect peut entraîner des amendes quelle que soit la taille de l'entreprise.

Toujours requis :

• Le signalement (simplement non sanctionné pour le délai de 24 heures)
• Toutes les autres obligations CRA
• Les rapports finaux

Définition : s'applique aux micro-entreprises (moins de 10 salariés, chiffre d'affaires annuel ou bilan jusqu'à 2 millions EUR) et aux petites entreprises (moins de 50 salariés, chiffre d'affaires annuel ou bilan jusqu'à 10 millions EUR). Les entreprises moyennes (jusqu'à 250 salariés) ne sont pas couvertes par cette exemption.

Cette exemption couvre uniquement la sanction liée au délai de l'alerte précoce de 24 heures. Tous les fabricants, y compris les micro-entreprises, doivent mettre en place des capacités de signalement.

Intégration avec les processus existants

Si vous disposez déjà d'une réponse aux incidents

Intégrez le signalement CRA à votre processus existant.

PROCESSUS IR EXISTANT          INTÉGRATION CRA
---------------------------------------------
Détection
    |
Triage -------------------> Vérifier : exploitation d'un produit CRA ?
    |                             |
Confinement                       +- OUI : lancer le compteur 24 h
    |                             |        soumettre l'alerte précoce
Investigation                     |
    |                             |
Remédiation --------------> Notification détaillée 72 h
    |
Récupération
    |
Leçons apprises ----------> Rapport final 14 j / 1 mois

Si vous avez des obligations NIS 2

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

• NIS 2 : incidents au niveau organisation ou service
• CRA : vulnérabilités et incidents au niveau produit

Ces obligations peuvent se chevaucher. Un seul incident peut requérir :

• une notification NIS 2 à l'autorité compétente
• une notification CRA à l'ENISA/CSIRT via la SRP

L'articulation entre les canaux de signalement NIS 2 et Article 14 du CRA n'a pas été confirmée dans des orientations définitives. Toute affirmation selon laquelle la SRP assurerait le routage pour les deux régimes doit être traitée comme non confirmée jusqu'à publication d'orientations définitives par l'ENISA ou la Commission (voir « Points encore ouverts » ci-dessous).

Checklist de préparation au signalement ENISA

CHECKLIST PRÉPARATION SIGNALEMENT ENISA

AVANT LE 11 SEPTEMBRE 2026 :

CANAUX ET CONTACTS
[ ] security.txt publié et à jour
[ ] Formulaire de signalement de vulnérabilités disponible
[ ] E-mail sécurité surveillé (définir le SLA : ____ heures)
[ ] Contact CSIRT national identifié
[ ] Inscription à la 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

LORSQU'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 vers le signaleur autorisé

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

DANS LES 72 HEURES
[ ] Notification détaillée soumise
[ ] Statut d'atténuation mis à jour
[ ] Communication client lancée (le cas échéant)

DANS LES 14 JOURS À COMPTER DE LA DISPONIBILITÉ D'UNE MESURE CORRECTIVE OU D'ATTÉNUATION (vulnérabilité) / UN MOIS (incident)
[ ] Rapport final soumis
[ ] Leçons apprises documentées
[ ] Améliorations de processus identifiées

Points encore ouverts

Plusieurs points qui influent sur la mise en oeuvre concrète du signalement au titre de l'Article 14 du CRA restent non résolus à la date de rédaction.

Comment CRA Evidence gère le signalement au titre de l'Article 14 du CRA

CRA Evidence est conçu autour du calendrier de signalement de l'Article 14. Les données clés requises pour vos soumissions à la SRP sont déjà structurées dans la plateforme au moment où une vulnérabilité ou un incident est identifié.

• Horodatage de connaissance au titre de l'Article 14 du CRA : chaque vulnérabilité est enregistrée contre un produit avec l'horodatage de connaissance, le déclencheur qui lance le compteur de 24 heures au titre de l'Article 14. Le champ discovered_at alimente les champs de délai ENISA, de sorte que le début du compteur est capturé dès qu'une vulnérabilité entre dans le système.
• Correspondance de versions de produit liée au SBOM : les CVE entrants et les preuves d'exploitation sont rattachés à des versions spécifiques de produit via le pipeline d'ingestion SBOM, de sorte que le champ des versions affectées d'un rapport CRA Article 14 est pré-rempli à partir des composants déjà présents dans votre SBOM.
• Pré-remplissage des champs du rapport CRA : le dossier technique (Annexe VII), les coordonnées du fabricant (dénomination légale, adresse, contact), la classe de produit (par défaut / importante classe I et II / critique) et la période de support sont déjà structurés dans le système, prêts à alimenter les champs d'alerte précoce et de notification à 72 heures de la SRP.
• Piste d'audit des preuves CRA : chaque étape, du triage interne à la notification CRA externe, est enregistrée avec l'acteur et l'horodatage, ce que demandent les contrôles des autorités de surveillance du marché. Les transitions de triage et les notifications ENISA (alerte précoce, notification détaillée, rapport final) sont toutes couvertes.
• Données de routage CSIRT dans le profil fabricant : l'État membre du CSIRT et les coordonnées du mandataire (nom, adresse, État membre) sont enregistrés dans le profil fabricant, de sorte que les informations clés pour le routage CSIRT au titre de l'Article 14 du CRA et la représentation des fabricants non établis dans l'UE sont disponibles au moment de la notification.

Découvrez comment la plateforme gère les délais de l'Article 14 : CRA Evidence signalement ENISA.

Prochaines étapes

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.