Le signalement de vulnérabilité prévu par le Cyber Resilience Act (CRA) n’est plus une échéance lointaine. Depuis le 11 septembre 2026, c’est une obligation active. Si un attaquant exploite une faille de votre objet connecté, de votre application ou de votre cloud, vous avez 24 heures pour prévenir les autorités européennes. La plupart des dirigeants de PME industrielles savent que le CRA existe. Pourtant, très peu savent qui doit cliquer sur quel bouton, dans quel délai.
Chez Playmoweb, nous concevons et maintenons des produits connectés depuis plus de 12 ans, firmware, application mobile et backend compris. Nous avons déjà détaillé les obligations générales dans notre article sur le Cyber Resilience Act et les obligations des fabricants. Celui-ci est plutôt un mode opératoire : qui est concerné, quoi signaler, dans quels délais. Il détaille aussi ce qu’il faut avoir préparé pour tenir 24 heures.
Sommaire
Le CRA vise les « produits comportant des éléments numériques ». Autrement dit, tout matériel ou logiciel connecté à un réseau ou à un autre appareil. Ses solutions de traitement à distance sont également couvertes. Capteur industriel, passerelle LoRa, application qui pilote une machine, cloud qui stocke les mesures : tout entre dans le périmètre.
L’obligation de signalement (article 14) pèse sur le fabricant. Mais la définition est plus large qu’on ne le croit. En effet, est fabricant celui qui développe le produit. C’est aussi celui qui le fait concevoir ou développer par un tiers et le commercialise sous son nom ou sa marque. Prenons la PME qui confie son objet connecté à une agence comme la nôtre, puis le vend sous sa propre marque. Au sens du CRA, c’est donc elle le fabricant : c’est elle qui notifie, pas son prestataire.
L’importateur et le distributeur ont des obligations plus légères mais réelles. Ils doivent informer le fabricant sans retard dès qu’ils ont connaissance d’une vulnérabilité. Ils doivent également alerter sans attendre les autorités de surveillance du marché si le produit présente un risque de cybersécurité important. Par ailleurs, celui qui modifie substantiellement un produit ou le revend sous sa marque bascule dans les obligations du fabricant.
Dernier point, souvent mal compris : le CRA n’attend pas le 11 décembre 2027 pour les produits déjà en circulation. Certes, l’article 69 exempte des exigences essentielles les produits mis sur le marché avant cette date. Toutefois, il précise que les obligations de signalement s’appliquent à tous les produits déjà sur le marché. Par exemple, un boîtier vendu en 2021 dont une faille est exploitée en octobre 2026 doit être signalé.
Deux événements déclenchent l’obligation. D’abord, la vulnérabilité activement exploitée. C’est une faille dont on a des preuves fiables qu’un acteur malveillant l’a exploitée sans l’autorisation du propriétaire du système. En revanche, une faille découverte en interne doit être corrigée, pas signalée au titre de l’article 14. Ensuite, l’incident grave touchant la sécurité du produit. Il s’agit soit d’une atteinte à la confidentialité, l’intégrité, l’authenticité ou la disponibilité des données, soit d’une introduction de code malveillant.
Le point d’entrée est unique : la plateforme de signalement de l’ENISA, la Single Reporting Platform (SRP). Elle a ouvert le 11 septembre 2026. Vous y déposez une seule notification. Elle est alors transmise simultanément à l’ENISA et au CSIRT coordinateur du pays de votre établissement principal. Cet établissement est celui où les décisions de cybersécurité sont prises. Pour une entreprise française, c’est donc le CERT-FR de l’ANSSI, qui relaie aux autres pays où le produit est vendu.
Les délais courent à partir du moment où vous avez connaissance de l’événement, pas du moment où il s’est produit.
| Événement | Alerte précoce | Notification | Rapport final | Contenu attendu |
|---|---|---|---|---|
| Vulnérabilité activement exploitée | 24 h après prise de connaissance | 72 h | Au plus tard 14 jours après la mise à disposition d’un correctif | Produit concerné, nature de l’exploitation, États membres touchés, mesures correctives, gravité |
| Incident grave | 24 h, en indiquant si une cause malveillante est suspectée | 72 h, avec première évaluation et mesures d’atténuation | Un mois après la notification à 72 h | Description détaillée, type de menace, cause racine, mesures appliquées |
L’alerte à 24 heures est volontairement sommaire : « nous avons un problème sur tel produit, voici les pays concernés ». Le détail arrive à 72 heures, puis l’analyse de fond dans le rapport final.
Une obligation passe souvent sous le radar : l’article 14 impose aussi d’informer les utilisateurs concernés sans retard. Ce message indique les mesures qu’ils peuvent prendre. Sinon, le CSIRT peut le faire à votre place, ce qui est rarement bon pour l’image.
Tenir 24 heures se joue avant l’incident. Voici l’enchaînement que nous mettons en place avec nos clients industriels.
1. Organiser la veille des vulnérabilités. Vous ne pouvez pas signaler ce que vous ignorez. C’est pourquoi quelqu’un, en interne ou chez votre prestataire, doit suivre les alertes de sécurité sur les composants du produit. Cela inclut notamment le système embarqué, les bibliothèques Bluetooth, les SDK cloud et les frameworks de l’application. Cette veille doit être outillée (alertes automatiques sur les CVE de vos dépendances) et nommée : un responsable, un suppléant.
2. Tenir l’inventaire des composants logiciels (SBOM). Le CRA exige un SBOM dans un format lisible par machine, couvrant au minimum les dépendances de premier niveau. Autrement dit, c’est la liste versionnée des bibliothèques du firmware, de l’app et du backend, mise à jour à chaque release. Sans SBOM, la question « sommes-nous concernés ? » prend des jours au lieu de minutes.
3. Ouvrir un canal de remontée. Chercheurs, clients, installateurs et distributeurs doivent pouvoir vous signaler une faille. Le CRA impose d’ailleurs une adresse de contact et une politique de divulgation coordonnée. Ajoutez un canal interne : tout signalement reçu par le support, un commercial ou le prestataire doit atterrir chez le responsable sécurité dans l’heure. En effet, c’est là que l’horloge des 24 heures démarre.
4. Décider de la notification. Toute faille ne se signale pas. Qualifiez vite : preuves d’exploitation réelle ? Impact sur la sécurité du produit ? La décision revient à une personne désignée à l’avance. Elle dispose d’un modèle de notification pré-rempli et d’un compte SRP déjà créé. Horodatez la prise de connaissance et la décision, car c’est ce que les autorités regarderont.
5. Corriger et déployer à distance. Le rapport final attend un correctif. Vous devez donc pouvoir produire une mise à jour de sécurité, la tester et la distribuer sans délai et gratuitement. Elle doit ensuite rester disponible au moins dix ans. Cela suppose un OTA fiable sur le firmware, une chaîne de publication maîtrisée pour l’application et un déploiement automatisé côté cloud. Nous détaillons cette dimension dans notre guide pour piloter un projet IoT de A à Z.
Un produit connecté a trois couches, chacune avec ses prérequis.
Firmware. C’est le maillon le plus souvent défaillant. Il faut d’abord un OTA signé, avec retour arrière si la mise à jour échoue. Il faut ensuite un numéro de version lisible à distance pour savoir quelle partie du parc est touchée. À l’inverse, un firmware flashé en usine et jamais mis à jour rend l’étape 5 impossible. Vous pouvez alors signaler la faille, mais pas la corriger. Notre comparatif BLE, LoRa, Matter et cellulaire revient sur les contraintes de mise à jour de chacun.
Application mobile. C’est souvent le point d’entrée d’une attaque (clés en dur, API mal protégée, Bluetooth non chiffré). Prévoyez une chaîne de release capable de sortir un correctif en quelques jours. Ajoutez un SBOM des SDK tiers et un mécanisme pour forcer la mise à jour des versions vulnérables. Avec Kotlin Multiplatform, un correctif de logique métier se déploie une seule fois pour iOS et Android. Cela compte lorsque chaque heure est chronométrée.
Cloud et backend. Là où sont les données, donc là où se jouent les incidents graves. Il faut une journalisation centralisée, des alertes sur les comportements anormaux, des sauvegardes testées et la capacité à isoler un composant compromis. Sinon, vous ne saurez pas à 24 heures si l’incident est grave, ni à 72 heures quoi écrire. Notre offre DevOps et cloud couvre cette instrumentation.
Enfin, les trois couches ont un point commun : la période de support. Le CRA impose de traiter les vulnérabilités pendant au moins cinq ans, ou la durée d’utilisation attendue si elle est plus courte. Il faut aussi l’annoncer à l’acheteur. Par conséquent, vos contrats de maintenance doivent couvrir cette durée.
En cadrant ces sujets avec des PME industrielles, nous retrouvons les mêmes angles morts.
Parlons budget, avec prudence, car ce qui suit est une estimation Playmoweb.
Pour un produit existant et déjà maintenu, le volet signalement représente quelques jours à quelques semaines de travail. Il couvre le SBOM, la veille outillée, la procédure écrite, les comptes SRP, les modèles de notification et un exercice à blanc. Selon le nombre de composants et la maturité de l’équipe, cela donne un ordre de grandeur de 5 à 20 k€. Ensuite, veille et traitement des failles s’intègrent dans la maintenance annuelle. Nous la chiffrons entre 15 et 25 % du coût initial par an.
Le budget change toutefois d’échelle quand il faut construire ce qui manque. Les cas typiques : ajouter un OTA signé, instrumenter un backend sans journalisation, reprendre une application aux dépendances figées depuis trois ans. Comptez alors 10 à 30 k€ par brique manquante, davantage si le matériel doit évoluer. C’est le diagnostic que nous menons dans un audit technique avant de chiffrer.
Côté sanctions, le règlement place l’article 14 dans la tranche la plus élevée, celle des exigences essentielles. Cette tranche va jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel, le montant le plus élevé étant retenu. Les manquements des importateurs et distributeurs relèvent quant à eux d’une tranche à 10 millions ou 2 %. Enfin, les informations fausses ou incomplètes fournies aux autorités relèvent d’une tranche à 5 millions ou 1 %. Cependant, les autorités tiennent compte des mesures prises pour limiter les dégâts : un signalement rapide et documenté pèse dans la balance. Le dispositif national d’application se met en place en France. En revanche, le plafond est fixé par le règlement.
Deux « non », et le sujet mérite un cadrage avant le premier incident, plutôt qu’après. Nous accompagnons les fabricants avec notre équipe développement IoT, du diagnostic du produit existant jusqu’à l’OTA et la procédure de signalement.
Votre produit connecté est-il prêt à tenir 24 heures ? Contactez-nous pour un échange gratuit et sans engagement. 👉 playmoweb.com/nous-contacter