Signalement des vulnérabilités CRA : ce qui change pour les industriels depuis septembre 2026

Cyber Resilience Act : 24 heures chrono pour signaler vos failles

Jack Bauer avait 24 heures pour sauver le monde. Vous, depuis le 11 septembre 2026, vous avez 24 heures pour prévenir l'Europe quand une faille de votre produit est exploitée par un attaquant. Moins héroïque, je vous l'accorde, mais tout aussi stressant un vendredi à 18h avant de partir pour votre super week-end à Santorin.

Pour rappel pour les retardataires : Cyber Resilience Act (CRA), c'est le règlement européen qui impose des règles de sécurité à tous les produits qui contiennent du numérique : logiciels, objets connectés, machines avec un logiciel embarqué, capteurs... Jusqu'ici, beaucoup en parlaient comme d'un sujet pour "plus tard" avec en tête une échance pour le décembre 2027 (date où tout le règlement s'applique).

SAUF QUE, la première obligation du CRA s'applique depuis le 11 septembre 2026 : signaler les failles exploitées et les incidents graves.

Dans cet article, on laisse la théorie de côté et on va sur le terrain : ce qui a changé, ce que vous devez faire concrètement, les erreurs qu'on voit souvent chez les industriels, et comment préparer la suite. Ready ? Allez, on y va !

Qu'est-ce que l'obligation de signalement du CRA ?

Depuis cette date, tout fabricant d'un produit numérique vendu en Europe doit signaler deux types d'événements :

• Une faille activement exploitée : une faiblesse de votre produit qu'un attaquant a réellement utilisée. Par exemple, un pirate passe par le petit serveur web intégré à votre automate, ou par une passerelle de télémaintenance mal protégée, pour prendre la main sur des machines installées chez vos clients. Ce n'est pas une faille "théorique" trouvée en interne : c'est une faille qui sert déjà à attaquer.

  
  

• Un incident grave : un événement qui touche la sécurité de votre produit. Par exemple, un attaquant s'introduit dans le serveur qui distribue les mises à jour du logiciel embarqué de vos machines, ou vole la clé qui sert à signer ces mises à jour. Autre cas classique : votre outil de télémaintenance est piraté, et l'attaquant peut accéder aux équipements de tous vos clients d'un coup.

  
  

Attention à ne pas tout mélanger : un rançongiciel qui bloque la comptabilité de votre usine n'est pas un incident CRA, tant qu'il ne touche ni vos produits, ni leurs mises à jour. Le CRA s'intéresse à la sécurité de ce que vous vendez, pas à celle de vos bureaux (pour ça, il y a d'autres textes, comme NIS2).

Le signalement se fait sur une plateforme unique gérée par l'ENISA (l'agence européenne de cybersécurité), en service depuis le 11 septembre. Une seule déclaration suffit : elle est ensuite transmise aux autorités concernées, dont le CSIRT (l'équipe nationale de réponse aux incidents) de votre pays.

Et ce n'est pas tout : vous devez aussi prévenir vos clients touchés et leur dire comment se protéger (correctif, mesure temporaire, réglage à changer...).

Ok, jusque-là, rien de très sorcier. Là où ça se complique, c'est pour savoir si c'est vraiment votre problème.

Qui est concerné par le signalement CRA ? Même les produits déjà vendus

C'est la question qu'on entend le plus. Et c'est souvent là que les industriels tombent de leur chaise.

L'obligation de signalement ne vise pas seulement les nouveaux produits. Elle s'applique aussi aux produits déjà vendus et encore utilisés chez vos clients, même s'ils ont été mis sur le marché bien avant 2027. La machine livrée il y a trois ans, le boîtier connecté installé chez un client en 2024, le logiciel de supervision vendu avec votre ligne de production : tout ça entre dans le périmètre.

Vous êtes concerné si :

• vous fabriquez un produit qui contient du logiciel et qui peut se connecter (directement ou via un autre appareil) ;

• vous le vendez sous votre nom ou votre marque, même si vous ne l'avez pas conçu vous-même ;

• vous modifiez fortement un produit existant avant de le revendre (dans ce cas, le CRA vous considère comme fabricant).

  
  

Importateur ou distributeur ? Vous n'êtes pas tranquille pour autant : vous devez vérifier que le fabricant fait son travail, et réagir si ce n'est pas le cas.

Petit rappel qui calme : ne pas respecter ces obligations peut coûter jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial (le montant le plus élevé est retenu). On ne va pas vous faire peur avec les sanctions, mais disons que ça aide à fixer les priorités.

Délais de signalement CRA : 24 heures, 72 heures et rapport final

Le signalement se fait en trois temps, et le compteur démarre au moment où vous apprenez l'existence de la faille exploitée ou de l'incident.

Bonne nouvelle : une faille dont vous connaissiez déjà l'exploitation avant le 11 septembre n'a pas à être signalée après coup. Par contre, si vous l'apprenez après cette date, même pour une vieille faille, le chrono s'applique.

Petit détail repéré dans la FAQ de l'ENISA : pour l'instant, la plateforme affiche l'échéance des 72 heures 48 heures après votre alerte précoce, et non à partir du moment où vous avez su. Votre notification peut donc apparaître "en retard" alors qu'elle ne l'est pas. Pas de panique : c'est l'outil qui compte mal, pas vous (l'ENISA prévoit de corriger ça).

Comment signaler une vulnérabilité à l'ENISA ? Le scénario du vendredi soir

Passons au concret avec un exemple.

Vendredi, 17h40. Un client vous appelle : ses automates reliés à votre boîtier de supervision redémarrent tout seuls depuis midi. Votre technicien regarde à distance et trouve des connexions étranges venant de l'extérieur. En creusant, il découvre qu'une faille connue dans un composant open source de votre logiciel est utilisée par un attaquant.

Le chrono démarre à ce moment-là : dès que vous savez, vous avez 24 heures pour lancer l'alerte.

Ce qu'il faut avoir prévu avant ce fameux vendredi :

1. Une personne responsable (et son remplaçant) : qui décide que "oui, c'est une faille exploitée, on signale" ? Si la réponse est "le directeur technique, mais il est en congé", c'est un peu problématique...

2. Un accès prêt à la plateforme de l'ENISA : la connexion passe par un compte EU Login personnel, avec double authentification. Ce compte, vous pouvez le créer dès maintenant pour chaque personne qui signalera. L'inscription sur la plateforme elle-même, l'ENISA demande de la faire seulement au moment de signaler (elle prend quelques minutes). Deux détails qui comptent : la plateforme est pour l'instant en anglais uniquement, et il faut choisir le bon CSIRT, celui du pays où se prennent vos décisions de cybersécurité. En cas d'erreur, la déclaration peut être refusée et il faut tout refaire.

3. La liste des composants de vos produits : pour savoir en quelques minutes quels produits (et quels clients) utilisent le composant touché. C'est ce qu'on appelle le SBOM, une sorte de liste d'ingrédients de votre logiciel.

4. Un modèle de message pour vos clients : ce qui se passe, les produits touchés, ce qu'ils doivent faire en attendant le correctif.

5. Un circuit de décision court : technique, direction, juridique, communication. Qui valide quoi, et en combien de temps.

   
   

Et un point que beaucoup oublient : le même événement peut déclencher plusieurs signalements. Si des données personnelles sont touchées, il faut aussi prévenir la CNIL (RGPD, sous 72 heures). Si votre entreprise est elle-même soumise à NIS2, il y a aussi l'ANSSI. Trois textes, trois circuits, un seul vendredi soir. Autant avoir la fiche réflexe prête.

Signalement CRA : les 6 erreurs les plus fréquentes chez les industriels

Dans les analyses d'écarts que nous menons, on retrouve souvent les mêmes points faibles. Rien de honteux, mais autant les connaître :

1. "On ne sait pas vraiment ce qu'il y a dans notre logiciel." Les bibliothèques open source, les composants d'un sous-traitant, le module récupéré d'un ancien projet... Sans liste à jour, impossible de savoir vite si une faille vous touche.

2. Personne pour recevoir les alertes. Un chercheur en sécurité trouve une faille dans votre produit et veut vous prévenir. Il écrit à qui ? Au formulaire de contact commercial ? Le CRA demandera d'ailleurs d'avoir une adresse dédiée pour ça d'ici 2027.

3. "Activement exploitée", c'est flou pour tout le monde. Faute de règle écrite, chacun a son avis, et la décision traîne. Or pendant qu'on débat, les 24 heures tournent.

4. Le support client n'est pas dans la boucle. C'est souvent lui qui reçoit le premier signal ("mon équipement fait n'importe quoi"). S'il ne sait pas qu'il doit faire remonter l'info, vous perdez des heures, voire des jours.

5. Personne de disponible le week-end. Une attaque ne respecte pas les horaires de bureau (étonnant, non ?). Pas besoin d'une équipe de garde 24h/24, mais il faut au moins savoir qui appeler. Dans une PME sans responsable sécurité en interne, c'est souvent le rôle d'un RSSI externalisé.

6. Les vieux produits oubliés. Le parc installé depuis des années, plus mis à jour mais toujours en service, est souvent le plus exposé. Et comme on l'a vu, il est aussi concerné.

Les éditeurs SaaS sont-ils concernés par le CRA ?

Bonne nouvelle (ou presque). Un logiciel 100 % en ligne, utilisé uniquement dans un navigateur, n'est en général pas visé directement par le CRA. Il relève plutôt d'autres textes, comme NIS2. Mais attention aux "presque SaaS". Vous êtes probablement concerné si votre offre comprend aussi une application mobile ou un logiciel à installer sur ordinateur, un agent ou un connecteur installé chez le client, ou une version "sur site" (installée sur les serveurs du client). Idem si votre service en ligne est indispensable au fonctionnement d'un produit connecté : dans ce cas, il fait partie du produit. Le sujet est encore flou et les avis divergent. Notre conseil : faites vérifier votre cas plutôt que de supposer que vous êtes hors du champ.

Classification des produits CRA : préparer l'échéance de décembre 2027

Le signalement, c'est la première marche. La suivante arrive le 11 décembre 2027 : à cette date, tous les produits mis sur le marché devront respecter l'ensemble des exigences du CRA (sécurité dès la conception, mises à jour, documentation, marquage CE...).

Et là, une question devient centrale : dans quelle catégorie tombe votre produit ? Pour le signalement, la catégorie ne change rien : tout le monde signale.

En revanche, elle décide de qui vérifie votre conformité en 2027 (on vous fait un joli tableau)

Catégorie	Exemples de produits	Qui vérifie ?
Par défaut (la grande majorité des produits)	Capteur connecté, machine avec logiciel embarqué, application métier, jeu vidéo	Vous-même (auto-évaluation)
Importante, classe I	Routeur, modem, commutateur réseau, système d'exploitation, gestionnaire de mots de passe, VPN	Vous-même si vous appliquez les normes européennes officielles, sinon un organisme externe
Importante, classe II	Pare-feu, système de détection d'intrusion, hyperviseur	Un organisme externe (organisme notifié)
Critique	Carte à puce, élément sécurisé, passerelle de compteur intelligent	Un organisme externe, voire une certification européenne

La règle à retenir : c'est la fonction principale du produit qui compte. Une machine industrielle qui contient un petit module réseau reste en général dans la catégorie par défaut. Mais un routeur industriel que vous vendez comme tel passe en classe I.

Vous hésitez sur la catégorie de votre produit ? Faites le test avec notre outil de classification CRA (promis c'est gratuit).

Petit piège au passage : les normes européennes officielles qui permettront l'auto-évaluation en classe I sont encore en préparation. Si votre produit est dans cette catégorie, mieux vaut anticiper dès maintenant.

"Mon produit est dans la catégorie par défaut, j'ai rien à faire" Et non mon cher ami, attention au faux ami : "auto-évaluation" ne veut pas dire "rien à faire", ni "moins d'exigences".

Les règles sont exactement les mêmes que pour les autres catégories :

• analyse de risques du produit

• dossier technique

• liste des composants

• gestion des failles

• mises à jour pendant toute la durée de vie du produit.

  
  

La seule différence, c'est que personne ne vérifie avant vous. C'est vous qui signez la déclaration de conformité, et vous en répondez seul si les autorités contrôlent votre produit ou si un incident survient. Autrement dit, pas de correcteur pour vous dire ce qui manque avant la mise en vente. C'est justement là qu'un regard extérieur, comme un pré-audit CRA, fait la différence.

Et ISO 27001 dans tout ça ? Elle ne change rien à la catégorie de votre produit. C'est une très bonne base pour vos processus (gestion des risques, des incidents, des fournisseurs), mais elle ne remplace pas le travail sur le produit lui-même (on en reparle très vite dans un prochain article 😉)

Conformité CRA : par où commencer dès demain ?

Ne paniquez pas ! Vous n'avez pas besoin de tout révolutionner. Voici trois actions à lancer dès que vous pouvez :

1. Faites la liste de vos produits concernés, y compris les anciens encore utilisés chez vos clients. Pour chacun : qui le maintient, et de quoi il est fait.

2. Écrivez votre procédure de signalement sur une page : qui décide, qui se connecte à la plateforme, qui prévient les clients, et qui remplace qui.

3. Testez-la à blanc avec le scénario du vendredi soir. Vous verrez très vite où ça coince.

Ensuite, pour préparer 2027, l'étape logique est un état des lieux complet (analyse d'écarts). Il permet de classer vos produits, de mesurer l'écart avec les exigences du CRA et de construire un plan d'action réaliste. On a mis en place ça chez nos clients, des pré-audits CRA, en fonction du constat et de votre besoin, le pré-audit découle sur notre accompagnement à la mise en conformité réglementaire (CRA, NIS2, DORA...).

Conclusion : le Cyber Resilience Act (CRA) ça commence maintenant !

Le CRA a longtemps été présenté comme un sujet pour 2027. Le 11 septembre a changé la donne : la première obligation est là, et elle concerne déjà les produits qui tournent chez vos clients.

La bonne nouvelle, c'est que cette première étape ne demande pas un chantier de six mois. Une personne responsable, une procédure d'une page, une liste de composants à jour : avec ça, vous êtes en mesure de tenir les 24 heures.

Et ce travail n'est pas perdu. Savoir ce qu'il y a dans vos produits, gérer les failles, prévenir vos clients : ce sont aussi les bases des exigences de 2027. Chaque action lancée aujourd'hui vous fait donc avancer sur les deux échéances à la fois.

Jack Bauer découvrait toujours la menace au dernier moment. Vous, vous avez encore le choix de vous préparer avant

Sources

• ENISA, FAQ de la plateforme unique de signalement CRA (mise à jour du 17 septembre 2026) : délais, définitions, inscription, produits déjà vendus, langue de la plateforme

• Texte officiel du Cyber Resilience Act, règlement (UE) 2024/2847

• Commission européenne, page sur les obligations de signalement du CRA

• Notre Livre blanc CRA