CRA : comment préparer le reporting obligatoire des vulnérabilités avant septembre 2026 ?

À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques concernés par le Cyber Resilience Act devront signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits.

Pour une vulnérabilité activement exploitée, le calendrier est particulièrement court :

1. alerte initiale dans les 24 heures après en avoir pris connaissance ;
2. notification complète dans les 72 heures ;
3. rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation.

Ces délais ne pourront pas être gérés efficacement avec une procédure improvisée au moment de l’attaque.

Pour un éditeur logiciel ou SaaS concerné par le CRA, la préparation doit commencer en amont : critères de qualification, responsables désignés, circuit de validation court, informations techniques disponibles, preuves conservées et exercices réguliers.

L’objectif n’est pas seulement de savoir remplir une notification. Il faut être capable de détecter, qualifier, décider et documenter en moins de 24 heures.

Un éditeur SaaS est-il automatiquement concerné par le CRA ?

Non. Le simple fait de proposer un service SaaS ne signifie pas automatiquement que l’entreprise entre dans le champ du CRA.

Le règlement s’applique aux produits comportant des éléments numériques mis à disposition sur le marché européen, notamment des logiciels et matériels. Il peut aussi couvrir certaines solutions de traitement de données à distance lorsqu’elles sont intégrées à un produit et nécessaires à son fonctionnement.

Un éditeur doit donc vérifier précisément :

1. la nature de son produit ;
2. la manière dont il est commercialisé ;
3. son éventuelle composante logicielle installée ou distribuée ;
4. le rôle du traitement à distance ;
5. son statut dans la chaîne de valeur ;
6. les exclusions ou règles particulières applicables.

La Commission européenne travaille encore en 2026 sur des orientations concernant notamment les solutions de traitement de données à distance. Une analyse de périmètre doit donc précéder la mise en place du reporting.

Même lorsqu’un SaaS n’est pas directement concerné, la méthode présentée ici reste utile pour structurer la gestion des vulnérabilités et répondre aux attentes des clients ou partenaires soumis au CRA.

Que faudra-t-il déclarer à partir du 11 septembre 2026 ?

Le CRA distingue notamment deux situations :

1. une vulnérabilité activement exploitée contenue dans un produit ;
2. un incident grave ayant un impact sur la sécurité du produit.

Une vulnérabilité activement exploitée n’est pas simplement une faiblesse technique découverte dans le code ou publiée dans une base de vulnérabilités.

Elle suppose l’existence d’éléments fiables montrant qu’un acteur malveillant a exploité cette vulnérabilité dans un système sans l’autorisation de son propriétaire.

Il faut donc distinguer rapidement :

Cette qualification doit être documentée. Une vulnérabilité non déclarée doit pouvoir être réévaluée si de nouveaux éléments apparaissent.

Quels sont les délais de notification prévus par le CRA ?

Dans les 24 heures : l’alerte initiale

Le fabricant doit transmettre une alerte initiale dans les 24 heures après avoir pris connaissance de la vulnérabilité activement exploitée.

Cette première notification peut être réalisée alors que l’analyse technique est encore incomplète.

Elle doit permettre de signaler rapidement :

1. l’existence de la vulnérabilité ;
2. le produit ou les versions potentiellement concernés ;
3. la nature générale de l’exploitation ;
4. les premières mesures prises ;
5. les informations disponibles sur les États membres potentiellement concernés.

Le point essentiel est le déclenchement du délai : il commence lorsque l’entreprise prend connaissance de la situation.

Cette notion impose de définir clairement en interne à quel moment une information devient suffisamment crédible pour être escaladée.

Dans les 72 heures : la notification complète

Dans les 72 heures, l’entreprise doit fournir une notification plus détaillée.

Elle doit notamment préciser, dans la mesure des informations disponibles :

1. la nature de la vulnérabilité ;
2. les premières conclusions sur son exploitabilité ;
3. les produits et versions touchés ;
4. la gravité de la situation ;
5. les éventuels acteurs malveillants impliqués ;
6. les mesures correctives ou d’atténuation engagées ;
7. les informations utiles permettant d’évaluer l’impact.

La notification à 72 heures ne signifie pas que l’enquête doit être terminée. Elle doit cependant être suffisamment structurée pour permettre aux autorités de comprendre la situation.

Après la correction : le rapport final

Pour une vulnérabilité activement exploitée, le rapport final doit être transmis au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation.

Il doit notamment documenter :

1. la vulnérabilité ;
2. sa gravité et son impact ;
3. la cause racine, lorsqu’elle est connue ;
4. les produits et versions affectés ;
5. les modalités de correction ;
6. les mesures d’atténuation ;
7. les actions prises pour informer les utilisateurs ;
8. les enseignements tirés.

Pour un incident grave, le délai du rapport final est différent : il doit être transmis dans le mois suivant la notification à 72 heures.

Où les notifications devront-elles être envoyées ?

Les déclarations seront réalisées via la Single Reporting Platform, la plateforme unique de notification mise en place par l’ENISA.

La notification sera adressée au CSIRT de l’État membre dans lequel le fabricant possède son établissement principal. Sauf circonstance exceptionnelle, les informations seront également mises à disposition de l’ENISA.

La plateforme doit être opérationnelle au 11 septembre 2026, avec une phase de test prévue avant cette date.

Un éditeur ne doit donc pas attendre son premier incident pour découvrir :

1. qui créera le compte ;
2. quelles personnes seront autorisées à notifier ;
3. quelles coordonnées seront utilisées ;
4. qui assurera la continuité en cas d’absence ;
5. comment les déclarations seront validées et archivées.

Pourquoi une simple procédure documentaire ne suffira pas

Le principal risque est de rédiger une procédure CRA sans la relier aux opérations techniques.

Pour respecter le délai de 24 heures, plusieurs équipes doivent pouvoir travailler ensemble :

1. support client ;
2. SOC ou équipe de surveillance ;
3. développement ;
4. responsable produit ;
5. sécurité ;
6. juridique ;
7. direction ;
8. communication.

Une alerte peut provenir :

1. d’un chercheur en sécurité ;
2. d’un client ;
3. d’un fournisseur ;
4. d’une plateforme de bug bounty ;
5. d’un outil de détection ;
6. d’un dépôt de code ;
7. d’une alerte CERT ;
8. d’une publication publique ;
9. d’un composant open source.

Si ces canaux ne convergent pas vers un processus commun, l’entreprise peut perdre plusieurs heures avant même de commencer la qualification.

Le processus opérationnel à préparer avant septembre 2026

Étape 1 : confirmer le périmètre CRA de vos produits

Avant de construire le processus, l’éditeur doit recenser :

1. ses produits logiciels ;
2. leurs versions maintenues ;
3. leurs composants distribués ;
4. les services distants indispensables ;
5. les produits déjà mis sur le marché européen ;
6. les périodes de support ;
7. les personnes morales responsables.

Cette cartographie permet d’éviter une question critique pendant l’incident :

Ce produit est-il réellement soumis à l’obligation de notification ?

La réponse doit être préparée et validée avant septembre 2026.

Étape 2 : définir ce qui déclenche l’escalade CRA

Il faut formaliser des critères simples permettant de distinguer :

1. une vulnérabilité à traiter dans le processus habituel ;
2. une suspicion d’exploitation nécessitant une investigation urgente ;
3. une vulnérabilité activement exploitée susceptible d’être déclarée ;
4. un incident grave affectant la sécurité du produit.

Exemples de signaux d’escalade :

1. exploitation confirmée par un client ;
2. code d’exploitation utilisé dans une attaque réelle ;
3. compromission associée à la vulnérabilité ;
4. alerte crédible d’un CSIRT ou d’un fournisseur ;
5. exploitation observée dans les journaux ;
6. inscription dans une source reconnue d’exploitation active ;
7. communication d’un mainteneur confirmant l’exploitation.

Le processus doit aussi prévoir les situations incertaines. En cas de doute, une cellule réduite doit pouvoir se réunir immédiatement pour décider si le délai CRA a commencé.

Étape 3 : désigner les responsables

Le dispositif doit avoir un responsable principal et des suppléants.

La responsabilité ne doit pas reposer sur une seule personne.

Le CRA peut se déclencher la nuit, pendant un week-end ou durant une période de congés. Il faut donc prévoir un mécanisme d’astreinte ou d’escalade adapté au niveau de risque du produit.

Étape 4 : raccourcir le circuit de validation

Un processus classique de validation juridique, technique et managériale peut prendre plusieurs jours. Il doit être adapté à l’échéance de 24 heures.

Un circuit réaliste peut être organisé ainsi :

1. détection et création d’un dossier ;
2. qualification technique initiale ;
3. confirmation du périmètre CRA ;
4. décision de notification ;
5. validation courte par sécurité et juridique ;
6. soumission de l’alerte initiale ;
7. poursuite de l’investigation ;
8. notification à 72 heures ;
9. correction et communication ;
10. rapport final.

L’alerte initiale ne doit pas attendre la fin de l’analyse technique.

L’entreprise doit accepter qu’elle sera parfois transmise avec des informations provisoires, clairement identifiées comme telles.

Étape 5 : préparer des modèles de notification

La meilleure façon de gagner du temps est de préparer les champs à l’avance.

Modèle pour l’alerte sous 24 heures

1. date et heure de prise de connaissance ;
2. source du signalement ;
3. produit concerné ;
4. versions potentiellement affectées ;
5. description synthétique ;
6. exploitation active confirmée ou suspectée ;
7. impact connu ;
8. États membres potentiellement concernés ;
9. mesures immédiates prises ;
10. point de contact ;
11. informations encore en cours d’analyse.

Modèle pour la notification sous 72 heures

1. chronologie détaillée ;
2. nature et origine de la vulnérabilité ;
3. versions affectées et non affectées ;
4. analyse de gravité ;
5. modes d’exploitation observés ;
6. indicateurs de compromission ;
7. impact sur les utilisateurs ;
8. correctif ou mesure d’atténuation ;
9. communication réalisée ou prévue ;
10. prochaines étapes.

Modèle pour le rapport final

1. synthèse de l’événement ;
2. cause racine ;
3. chronologie complète ;
4. produits et versions concernés ;
5. impact réel ;
6. correctif publié ;
7. mesures temporaires ;
8. utilisateurs informés ;
9. délais de déploiement ;
10. actions d’amélioration ;
11. preuves associées.

Ces modèles doivent être compatibles avec les champs définitifs de la Single Reporting Platform dès qu’ils seront disponibles.

Étape 6 : organiser les informations techniques nécessaires

Le reporting CRA sera difficile si l’éditeur ne connaît pas précisément ses produits.

Il faut pouvoir retrouver rapidement :

1. les versions en production ;
2. les versions encore supportées ;
3. les composants concernés ;
4. les dépendances logicielles ;
5. les environnements touchés ;
6. les clients utilisant chaque version ;
7. les pays de commercialisation ;
8. les correctifs disponibles ;
9. les responsables techniques.

Une nomenclature logicielle ou SBOM peut faciliter cette analyse, notamment lorsqu’une vulnérabilité provient d’un composant tiers.

Mais disposer d’une SBOM ne suffit pas. Elle doit être actualisée, exploitable et reliée aux versions réellement distribuées.

Étape 7 : conserver les preuves du processus

La conformité ne reposera pas uniquement sur la notification envoyée.

L’éditeur doit conserver :

1. l’alerte d’origine ;
2. la date et l’heure de réception ;
3. les journaux et éléments techniques ;
4. les décisions de qualification ;
5. les personnes impliquées ;
6. les validations ;
7. les versions des notifications ;
8. les communications aux clients ;
9. les correctifs publiés ;
10. les tests réalisés ;
11. le rapport final ;
12. les actions d’amélioration.

La chronologie est particulièrement importante.

Elle doit permettre de démontrer :

1. quand l’entreprise a pris connaissance de la situation ;
2. quand elle a déclenché l’analyse ;
3. quand la décision de notifier a été prise ;
4. quand chaque déclaration a été envoyée ;
5. pourquoi certaines informations n’étaient pas encore disponibles.

Étape 8 : préparer la communication aux utilisateurs

La notification réglementaire ne remplace pas nécessairement l’information des utilisateurs.

L’éditeur doit prévoir :

1. les critères de communication ;
2. les canaux utilisés ;
3. les destinataires ;
4. le niveau de détail ;
5. les mesures immédiates recommandées ;
6. le calendrier de publication du correctif ;
7. les messages pour le support client ;
8. la coordination avec les partenaires.

La communication doit trouver un équilibre entre transparence et maîtrise du risque. Une publication trop détaillée avant le déploiement du correctif pourrait faciliter de nouvelles attaques.

Le circuit doit donc associer sécurité, produit, juridique et communication.

Étape 9 : tester le dispositif avant l’échéance

Une procédure non testée restera fragile.

Avant septembre 2026, un éditeur devrait organiser au minimum un exercice sur table simulant une vulnérabilité activement exploitée.

Exemple de scénario

Un chercheur informe le support qu’une vulnérabilité d’authentification permet de contourner certains contrôles. Quelques heures plus tard, un client transmet des journaux montrant une exploitation probable.

L’exercice doit vérifier :

1. le temps nécessaire pour transmettre l’alerte ;
2. la capacité à identifier les versions concernées ;
3. la disponibilité des responsables ;
4. la compréhension des critères CRA ;
5. la rapidité de validation ;
6. la qualité des informations disponibles à 24 et 72 heures ;
7. la préparation de la communication client ;
8. la conservation des preuves.

À la fin de l’exercice, un plan d’amélioration doit être produit avec un responsable et une échéance pour chaque action.

Exemple de chronologie opérationnelle

Ces délais internes doivent être plus courts que les délais réglementaires afin de conserver une marge en cas de difficulté.

Les documents à préparer dès maintenant

Un dispositif CRA opérationnel devrait contenir au minimum :

1. cartographie des produits concernés ;
2. analyse de périmètre CRA ;
3. procédure de gestion des vulnérabilités ;
4. procédure de notification CRA ;
5. critères de qualification ;
6. matrice des rôles ;
7. liste des contacts et suppléants ;
8. modèles de notification ;
9. inventaire des versions supportées ;
10. processus de communication client ;
11. registre des décisions ;
12. procédure de conservation des preuves ;
13. scénario d’exercice ;
14. historique des tests ;
15. plan de remédiation.

Le but n’est pas de produire une documentation excessive. Chaque document doit servir directement à respecter les délais ou à démontrer le fonctionnement du processus.

Les erreurs à éviter avant septembre 2026

Attendre la publication définitive de tous les guides

Certaines modalités continueront d’être précisées, mais les délais et les principales obligations sont déjà connus.

Il est possible de préparer les rôles, le circuit, les informations nécessaires et les exercices dès maintenant.

Confondre vulnérabilité connue et vulnérabilité activement exploitée

Toutes les vulnérabilités ne doivent pas être notifiées. Il faut disposer d’un processus de qualification documenté.

Faire partir le délai après validation de la direction

Le délai commence lorsque le fabricant prend connaissance de la situation, pas lorsque le comité de direction valide la déclaration.

Chercher une analyse parfaite avant l’alerte initiale

L’alerte sous 24 heures est précisément conçue pour permettre une notification rapide avant la fin de l’enquête.

Oublier les produits déjà commercialisés

Les obligations de reporting concernent aussi les produits avec éléments numériques déjà mis sur le marché de l’Union, y compris avant l’entrée en application générale du CRA en décembre 2027.

Ne pas prévoir les nuits et week-ends

Une exploitation active peut être découverte à tout moment. Le processus doit rester exécutable en dehors des horaires habituels.

Comment suivre la préparation du reporting CRA

La préparation peut être pilotée avec quelques indicateurs simples :

1. pourcentage de produits dont le périmètre CRA est confirmé ;
2. pourcentage de produits avec responsables désignés ;
3. nombre d’actions préparatoires en retard ;
4. date du dernier exercice ;
5. taux de documents validés ;
6. nombre d’écarts encore ouverts.

Ces indicateurs doivent servir à identifier les blocages, et non à produire un tableau de bord purement décoratif.

Là où CompliKey peut aider

La préparation au reporting CRA ne repose pas sur un seul document. Elle implique plusieurs mesures, responsables, échéances, preuves et actions de remédiation.

CompliKey permet de structurer cette préparation en centralisant :

1. les mesures CRA applicables ;
2. les responsables ;
3. les échéances ;
4. les procédures ;
5. les modèles de notification ;
6. les preuves des exercices ;
7. les écarts identifiés ;
8. les tâches de préparation ;
9. l’historique des réévaluations.

L’objectif n’est pas de remplacer la Single Reporting Platform ni de réaliser automatiquement la notification réglementaire.

Il est d’aider l’éditeur à vérifier que son dispositif est prêt avant septembre 2026 et que chaque obligation possède un responsable, une preuve et un plan de traitement.

En bref

À partir du 11 septembre 2026, les fabricants concernés devront signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits.

Pour une vulnérabilité activement exploitée :

1. alerte initiale sous 24 heures ;
2. notification complète sous 72 heures ;
3. rapport final au plus tard 14 jours après la disponibilité d’une correction ou d’une mesure d’atténuation.

Pour être prêt, un éditeur doit :

1. confirmer le périmètre CRA de ses produits ;
2. définir les critères de déclenchement ;
3. désigner les responsables et suppléants ;
4. préparer les modèles ;
5. raccourcir les validations ;
6. cartographier produits, versions et composants ;
7. conserver toutes les preuves ;
8. tester le processus avant septembre 2026.

FAQ

Quand les obligations de reporting du CRA entrent-elles en application ?

Elles s’appliquent à partir du 11 septembre 2026. Les principales autres obligations du CRA entreront en application le 11 décembre 2027.

Quel est le délai pour signaler une vulnérabilité activement exploitée ?

Une alerte initiale doit être envoyée dans les 24 heures après que le fabricant en a pris connaissance. Une notification plus complète doit suivre dans les 72 heures.

Quel est le délai du rapport final ?

Pour une vulnérabilité activement exploitée, le rapport final doit être transmis au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation.

Toutes les vulnérabilités doivent-elles être déclarées ?

Non. L’obligation vise notamment les vulnérabilités activement exploitées. Une vulnérabilité théorique ou simplement publiée ne déclenche pas automatiquement la notification.

Le CRA concerne-t-il tous les éditeurs SaaS ?

Non. L’applicabilité dépend de la qualification du produit, de son mode de mise à disposition et du rôle éventuel d’une solution de traitement de données à distance. Une analyse de périmètre est nécessaire.

Où les notifications seront-elles envoyées ?

Elles devront être transmises par l’intermédiaire de la Single Reporting Platform mise en place par l’ENISA.

Faut-il attendre septembre 2026 pour tester la plateforme ?

Non. L’ENISA prévoit une période de test avant son entrée en service. Les entreprises doivent préparer en parallèle leurs comptes, habilitations, contacts et processus internes.

Conclusion

Le reporting CRA ne sera pas seulement une obligation juridique. Il deviendra un test concret de la maturité de la gestion des vulnérabilités des éditeurs.

Respecter le délai de 24 heures suppose de savoir rapidement :

1. quel produit est concerné ;
2. si l’exploitation est réelle ;
3. qui décide ;
4. qui notifie ;
5. quelles informations fournir ;
6. quelles preuves conserver.

Les entreprises qui attendront leur première vulnérabilité activement exploitée pour organiser ce circuit prendront un risque important.

La priorité avant le 11 septembre 2026 est donc claire : transformer les délais réglementaires en un processus testé, documenté et exécutable, y compris lorsque les informations sont encore incomplètes.