CRA : ce qu’il faut signaler depuis le 11 septembre 2026

Le Cyber Resilience Act (CRA), le règlement (UE) 2024/2847 sur la cyberrésilience, fixe des exigences de cybersécurité pour les logiciels et les produits connectés commercialisés dans l’Union européenne. La plupart de ses obligations, dont le marquage CE, s’appliqueront le 11 décembre 2027. Son article 14 s’applique en revanche depuis le 11 septembre 2026 (article 71) : un fabricant doit signaler les vulnérabilités activement exploitées de ses produits et les incidents graves qui touchent leur sécurité, avec une première alerte sous 24 heures. Cette obligation de signalement vaut aussi pour les produits déjà sur le marché.

La déclaration se fait en ligne. Le plus difficile est ailleurs : reconnaître en quelques heures qu’un événement doit être signalé, et avoir quelqu’un de prêt à le déclarer.

Qui doit signaler

L’obligation pèse sur le fabricant : celui qui développe un produit, ou le fait développer, et le commercialise sous son nom ou sa marque, que ce soit à titre payant, monétisé ou gratuit (article 3). Un importateur ou un distributeur qui commercialise un produit sous sa propre marque, ou le modifie substantiellement, devient fabricant à son tour (article 21).

Le règlement vise les logiciels et les matériels connectés fournis dans le cadre d’une activité commerciale (article 2). En pratique, il peut s’agir d’une application mobile ou de bureau, d’un agent, d’une extension de navigateur, d’une bibliothèque ou d’un kit de développement logiciel (SDK), d’un objet connecté et de son micrologiciel. S’y ajoute le service, développé par vous ou pour vous, qui fournit l’interface de programmation (API) ou la base de données dont l’un de ces produits a besoin pour assurer une de ses fonctions : c’est sa « solution de traitement de données à distance » (considérant 11). Nous détaillons ces situations sur notre page CRA.

Le cas du SaaS

Beaucoup d’entreprises tech éditent un logiciel en ligne (SaaS). Selon les lignes directrices de la Commission européenne du 27 juillet 2026, qui ne sont pas contraignantes, une application web utilisée uniquement dans un navigateur n’est pas un produit au sens du CRA, même sous la forme d’une application web progressive (PWA). Les services en nuage relèvent plutôt, selon la taille de leur fournisseur, de la directive NIS 2 sur la sécurité des réseaux et des systèmes d’information (considérant 12).

Tout change dès que vous livrez aussi une application installée, un agent, une extension ou une bibliothèque cliente qui dépend de votre API : ce logiciel est un produit, et la partie de votre service dont il a besoin est couverte avec lui. Seule cette partie est visée : les lignes directrices excluent vos systèmes internes, comme la gestion de la relation client (CRM) ou la chaîne d’intégration et de livraison continues.

Les produits déjà sur le marché aussi

Un produit mis sur le marché avant le 11 décembre 2027 n’est soumis aux autres exigences du CRA qu’en cas de modification substantielle (article 69). Le signalement fait exception : il vaut pour tous ces produits, quelle que soit leur ancienneté, selon l’article 69 rectifié le 2 juillet 2025.

Les lignes directrices ajoutent deux précisions. L’obligation survit à la période d’assistance, celle pendant laquelle vous devez traiter les vulnérabilités du produit. Et elle n’est pas rétroactive : une exploitation connue avant le 11 septembre 2026 n’a pas à être déclarée, mais une vulnérabilité connue avant cette date, dont vous apprenez l’exploitation après, doit l’être. Vos anciennes versions encore en circulation comptent donc.

Ce qu’il faut signaler

Une vulnérabilité activement exploitée

Une vulnérabilité est activement exploitée lorsqu’il existe des « preuves fiables » qu’un acteur malveillant l’a exploitée dans un système, sans l’autorisation de son propriétaire (article 3). Les vulnérabilités découvertes de bonne foi, lors d’essais ou de recherches, ne font pas l’objet d’une notification obligatoire (considérant 68). La FAQ de la Commission range dans ce cas une faille remontée par un programme de primes aux bogues (bug bounty) ou trouvée par un laboratoire qui teste le produit pour vous, tant que rien ne montre qu’elle a été exploitée.

Les constats d’un test d’intrusion se corrigent donc, mais ne se déclarent pas. Qu’un correctif existe ou non ne change rien : une vulnérabilité « jour zéro », pour laquelle il n’en existe pas encore, se déclare dès que vous avez des preuves fiables de son exploitation.

Les composants tiers suivent la même règle. Une vulnérabilité exploitée dans votre produit se déclare, même si elle provient d’une dépendance. Selon les lignes directrices, la déclaration n’est pas obligatoire si la faille n’a pas été exploitée dans votre produit, ou ne peut pas l’être, par exemple parce que le code vulnérable n’y est pas atteignable. Signalez-la tout de même au mainteneur du composant, et corrigez-la : l’article 13 l’exigera pour les produits mis sur le marché à partir du 11 décembre 2027.

Un incident grave touchant la sécurité du produit

Selon l’article 14, un incident est grave dans l’un de ces deux cas :

• il entache, ou peut entacher, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ;
• il a conduit, ou peut conduire, à l’introduction ou à l’exécution de code malveillant dans le produit ou dans les systèmes d’un utilisateur.

Le règlement ne fixe aucun seuil chiffré. Le considérant 68 vise un incident qui perturbe vos processus de développement, de production ou de maintenance au point de pouvoir accroître le risque pour vos utilisateurs. Il en donne un exemple : un attaquant parvient à glisser du code malveillant dans le canal par lequel vous diffusez vos mises à jour de sécurité. Concrètement, pensez à une chaîne de compilation compromise qui injecte du code dans vos versions, ou à des clés de signature dérobées qui permettraient de publier une fausse mise à jour.

Trois délais : 24 heures, 72 heures, puis le rapport final

Les délais courent à partir du moment où vous avez « eu connaissance » de l’événement. Selon la Commission, c’est le moment où, après une première évaluation menée sans attendre, vous avez un degré raisonnable de certitude que la vulnérabilité est exploitée ou que l’incident a compromis la sécurité du produit. Un simple soupçon ne déclenche donc pas le compte à rebours, mais il appelle une évaluation immédiate. Notez l’heure exacte de cette prise de connaissance, en temps universel coordonné (UTC) : le glossaire de la plateforme de déclaration de l’Agence de l’Union européenne pour la cybersécurité (ENISA) la demande dès la première étape.

L’article 14 prévoit trois étapes. Les deux premiers délais courent à partir de la prise de connaissance :

Dans les deux cas, l’alerte indique aussi les États membres où le produit est disponible. L’alerte et la notification doivent partir « sans retard injustifié » : 24 et 72 heures sont des plafonds, pas des objectifs. Le centre de réponse aux incidents de sécurité informatique (CSIRT) qui reçoit la notification peut en outre demander un rapport intermédiaire.

À qui et comment déclarer

Tout passe par la plateforme unique de signalement de l’ENISA, ouverte le 11 septembre 2026. Vous y choisissez le CSIRT coordinateur du pays de votre établissement principal, c’est-à-dire là où sont principalement prises les décisions de cybersécurité relatives à vos produits. Si cet établissement est en France, c’est le CERT-FR de l’Agence nationale de la sécurité des systèmes d’information (ANSSI), comme le rappelle sa foire aux questions sur le CRA.

L’ENISA reçoit la notification en même temps, et le CERT-FR la diffuse aux CSIRT des autres pays où le produit est disponible. Il peut aussi informer l’Agence nationale des fréquences (ANFR), chargée de la surveillance du marché.

Une seule notification suffit par événement, même pour un groupe présent dans plusieurs pays. Mais le choix du CSIRT compte : en cas d’erreur, la notification peut être invalidée et devra être déposée à nouveau (FAQ de l’ENISA). L’ENISA résume le dispositif dans une fiche en français.

Ce que la plateforme demande

À la date de publication de cet article, la plateforme en est à sa première version. Selon la FAQ de l’ENISA :

• Un compte EU Login par personne. EU Login est le service d’authentification de la Commission européenne. L’authentification multifacteur y est obligatoire, et chaque compte peut être créé dès maintenant.
• Une inscription au moment de déclarer. L’ENISA recommande de ne s’inscrire sur la plateforme qu’à la première notification : avec un compte EU Login actif, cela prend quelques minutes, et la validation de l’inscription par le CSIRT, menée en parallèle, n’empêche pas de déclarer.
• Une interface en anglais, sans API. Tout se saisit à la main.
• Un compte à rebours à vérifier. Pour la notification à 72 heures, la plateforme affiche une échéance fixée 48 heures après l’envoi de l’alerte. Calculez vos délais vous-même, à partir de l’heure de prise de connaissance.
• Pas d’autre canal en cas de panne. Si la plateforme est indisponible, déposez la notification à son retour. Si l’urgence l’exige, contactez directement le CERT-FR en attendant : la notification sur la plateforme restera due.

L’alerte précoce demande peu : le type d’événement, un titre, un résumé, le produit et ses versions, les États membres concernés, l’heure de prise de connaissance et, pour un incident, s’il pourrait être malveillant. Vous pouvez aussi indiquer la sensibilité des informations et demander que leur diffusion aux autres pays soit retardée : le CSIRT en décide, dans les cas prévus par le règlement délégué (UE) 2026/881.

Le simple fait de notifier n’accroît pas votre responsabilité, et les CSIRT coordinateurs fournissent un service d’assistance aux fabricants, en particulier aux petites et moyennes entreprises (article 17).

Prévenir vos utilisateurs

Vous devez aussi informer les utilisateurs touchés et, s’il y a lieu, tous les utilisateurs, en leur indiquant les mesures qu’ils peuvent prendre, le cas échéant dans un format structuré et lisible par machine (article 14). Selon la Commission, cette information reste proportionnée au risque : elle peut se limiter aux clients concernés, quitte à communiquer plus largement une fois la faille corrigée. Si vous ne le faites pas en temps utile, le CSIRT peut informer lui-même vos utilisateurs.

Ce qu’il faut mettre en place dès maintenant

Selon l’ANSSI, une équipe de réponse aux incidents de sécurité des produits (PSIRT) n’est pas obligatoire : vous êtes libre de votre organisation, dès lors que vous offrez à vos utilisateurs un point de contact unique et respectez vos obligations. Encore faut-il que cette organisation tienne des délais comptés en heures.

1. Un inventaire à jour. Listez vos produits, les versions encore utilisées, les pays où elles sont disponibles et les composants qu’elles intègrent. Commencez dès maintenant la nomenclature des logiciels (SBOM, pour Software Bill of Materials) que le CRA exigera en décembre 2027 : c’est elle qui vous dira quelles versions contiennent une dépendance exploitée.
2. Un point de contact. Clients et chercheurs doivent savoir où vous écrire. Pour que l’ANSSI puisse vous joindre, le CERT-FR recommande de publier vos coordonnées, par exemple dans un fichier « security.txt » sur votre site, et d’utiliser des adresses génériques, qui survivent aux départs et couvrent les absences.
3. Une qualification rapide. Une exploitation peut vous être signalée par un client, un chercheur, une autorité, un rapport de veille ou votre télémétrie. Le CRA n’oblige pas à surveiller ces canaux, précise la FAQ de la Commission, mais chaque signal doit être qualifié vite, alertes sur vos dépendances comprises. La faille est-elle exploitée, preuves à l’appui ? Touche-t-elle vos produits, et quelles versions ? L’incident est-il grave ? Consignez chaque réponse, même négative.
4. Une procédure écrite, avec des noms. Une page suffit : qui qualifie, qui décide, qui déclare (au moins deux personnes avec leur compte EU Login, pour couvrir les absences), où tenir la chronologie en UTC, quels modèles utiliser à chaque étape et pour prévenir les clients. Prévoyez aussi les autres régimes : au titre du règlement général sur la protection des données (RGPD), une violation de données personnelles qui présente un risque pour les personnes se notifie séparément à la Commission nationale de l’informatique et des libertés (CNIL), si possible sous 72 heures.
5. Un exercice. Rien ne l’impose, mais un scénario fictif, comme une mise à jour compromise, révèle vite un compte qui manque ou une version oubliée.

Ce qui s’ajoute le 11 décembre 2027

À cette date s’appliquent les exigences de gestion des vulnérabilités de l’annexe I, partie II :

• une nomenclature des logiciels couvrant au moins les dépendances de premier niveau ;
• des correctifs sans retard, séparés des évolutions fonctionnelles lorsque c’est techniquement possible ;
• des tests et examens de sécurité réguliers et efficaces ;
• la publication des vulnérabilités corrigées ;
• une politique de divulgation coordonnée des vulnérabilités et une adresse de contact pour les signaler ;
• des mises à jour diffusées de façon sécurisée, sans retard et gratuitement.

S’y ajoutent une période d’assistance d’au moins 5 ans, sauf si le produit est censé servir moins longtemps, et l’obligation de laisser chaque mise à jour de sécurité disponible au moins 10 ans (article 13). Viennent ensuite l’évaluation de la conformité et le marquage CE. Un produit déjà sur le marché à cette date n’y est soumis qu’en cas de modification substantielle.

La procédure de signalement construite aujourd’hui devient le cœur de cette gestion des vulnérabilités : même point de contact, même qualification, même chronologie. Pour les tests, « réguliers » ne veut pas dire répéter la même campagne à intervalle fixe, précise la Commission : la fréquence suit le risque. Un test d’intrusion applicatif peut faire partie de ces tests, et son rapport rejoindre la documentation technique. Le détail de ces exigences figure sur notre page consacrée au Cyber Resilience Act.

Ce que vous risquez

Un manquement à l’article 14 expose à une amende administrative pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (article 64). Ce sont des plafonds : chaque État membre fixe son régime de sanctions, et la taille de l’entreprise entre dans le calcul. En France, l’ANSSI indique que des mesures d’adaptation du droit national sont en préparation.

Les microentreprises et les petites entreprises ne s’exposent toutefois à aucune amende administrative pour le seul dépassement du délai de l’alerte à 24 heures (article 64, rectifié le 2 juillet 2025). Cette exception ne couvre ni la notification à 72 heures, ni le rapport final, ni l’information des utilisateurs. Une petite entreprise compte moins de 50 personnes et un chiffre d’affaires annuel ou un total de bilan d’au plus 10 millions d’euros, entreprises partenaires ou liées comprises (recommandation 2003/361/CE).

Ce que nous prenons en charge

Si personne ne porte la sécurité chez vous, nous tenons le rôle de responsable de la sécurité des systèmes d’information (RSSI) : c’est notre offre RSSI externalisé. Nous pilotons le signalement, la gestion des vulnérabilités et la documentation technique attendue pour décembre 2027, test d’intrusion inclus. Pour le signalement, nous fixons avec vous qui détecte, qui qualifie, qui déclare et qui prévient vos clients, puis rédigeons la procédure. Un workshop hebdomadaire d’une heure fait le point, avec un suivi en asynchrone entre deux workshops. Vos équipes gardent la main sur la technique.

Si vous avez déjà un RSSI ou une équipe sécurité, le pilotage leur revient avec notre offre Accompagnement à la conformité : nous qualifions vos produits et rédigeons avec eux les politiques et les procédures, dont celle de signalement. Si vous ne savez pas encore quels produits sont concernés, commencez par une analyse d’écart : elle les identifie et établit ce qui leur manque avant décembre 2027.

Questions fréquentes

Une faille trouvée lors d’un test d’intrusion doit-elle être signalée ?

Non, tant que rien ne montre qu’un acteur malveillant l’a exploitée. Il faut en revanche la corriger. L’article 15 prévoit un signalement volontaire, mais la plateforme de l’ENISA ne le propose pas encore.

Notre produit n’est plus maintenu : faut-il encore signaler ?

Oui. Selon la Commission, l’obligation continue après la fin de la période d’assistance, y compris pour les produits mis sur le marché avant décembre 2027. Vous devez aussi informer les utilisateurs touchés.

Par où commencer

Trois actions suffisent pour démarrer : lister vos produits et les versions en circulation, désigner les deux personnes chargées de la déclaration et créer leurs comptes EU Login, puis rédiger la procédure d’une page. Le reste se construit d’ici décembre 2027.

Pour vérifier si vos produits sont concernés et qui déclarerait quoi demain matin, parlons de votre projet CRA : si nos offres ne sont pas encore pertinentes pour vous, nous vous le dirons.