Cybersécurité IoT industriel : rendre une flotte prête CRA

Un capteur industriel se sécurise rarement une seule fois : il est déjà sur le terrain, sur batterie, derrière des passerelles que personne ne contrôle vraiment, quand on découvre ce qui lui manque. La cybersécurité IoT industriel consiste alors à durcir une flotte existante sans la rappeler : authentifier chaque message, protéger les clés, signer les mises à jour, puis prouver tout cela au titre du Cyber Resilience Act (CRA), règlement (UE) 2024/2847.

Chez AESTECHNO, bureau d'études électronique à Montpellier, nous concevons le matériel et le firmware de ces capteurs et nous en tenons le registre de sécurité. Ce guide part de ce travail : ce qui se corrige par une OTA, ce qui exige un accès physique, et ce qui aurait dû être décidé avant la première unité. Pour le cadre réglementaire complet, voir notre guide de conformité Cyber Resilience Act.

Sommaire

• Que recouvre la cybersécurité IoT industriel pour une flotte ?
• Qu'impose déjà le CRA à une flotte en service ?
• Modèle de menace : la passerelle est un adversaire
• Comment authentifier chaque message sans chiffrer le lien radio ?
• Clés, secure element et port de debug
• OTA signée et anti-rollback : à décider avant la première unité
• Durcir une flotte déployée par étapes
• SBOM, CVE et registre de sécurité
• Retour terrain : une flotte de capteurs BLE sur batterie
• Checklist : rendre une flotte existante prête pour le CRA
• En résumé

Que recouvre la cybersécurité IoT industriel pour une flotte ?

La cybersécurité d'une flotte IoT industrielle désigne l'ensemble des mesures qui garantissent qu'un capteur déployé envoie des données authentiques, n'exécute que du firmware signé, garde ses clés hors d'atteinte et peut être corrigé à distance, pendant toute sa durée de vie et pas seulement le jour de sa mise sur le marché.

La différence avec la sécurité d'un produit neuf tient en un mot : l'existant. Un produit en conception peut encore changer de microcontrôleur, ajouter un secure element ou revoir son bootloader. Une flotte en service ne peut changer que ce que son firmware et son bootloader actuels permettent de changer à distance. Tout le reste demande un accès physique à chaque unité.

C'est pourquoi nous commençons toujours par la même question : parmi les défauts identifiés, lesquels se corrigent par une mise à jour OTA, lesquels exigent un passage sur site, et lesquels resteront acceptés jusqu'à la prochaine génération de matériel ? Pour un produit encore sur plan, notre guide pour sécuriser un produit IoT dès la conception couvre l'autre versant.

Qu'impose déjà le CRA à une flotte en service ?

Le Cyber Resilience Act impose aux fabricants de produits comportant des éléments numériques des exigences de sécurité tout au long du cycle de vie. Son article 14, l'obligation de signaler les vulnérabilités activement exploitées et les incidents graves, s'applique depuis le 11 septembre 2026, y compris aux produits mis sur le marché avant cette date.

Le calendrier du signalement est serré : une alerte précoce sous 24 h, une notification sous 72 h, puis un rapport final, via la plateforme unique de l'ENISA. Pour une flotte déjà vendue, cela suppose de savoir quels firmwares tournent sur le terrain, quels composants logiciels ils contiennent et comment pousser un correctif.

Les exigences essentielles de l'annexe I s'appliqueront à partir du 11 décembre 2027 aux produits mis sur le marché après cette date, ou modifiés de façon substantielle. Une mise à jour de sécurité seule n'en est pas une. Les sanctions atteignent jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial. Pour un capteur radio, la certification CE/RED et la norme EN 18031 s'ajoutent depuis août 2025.

Modèle de menace : la passerelle est un adversaire

Un modèle de menace décrit qui peut attaquer le système, depuis où, et avec quels moyens. Pour une flotte de capteurs industriels, le point de départ réaliste est simple : la passerelle, le smartphone de maintenance et le réseau sont des intermédiaires non fiables, capables de lire, retarder, rejouer ou modifier chaque message.

Cette hypothèse change l'architecture. Si le capteur remonte ses mesures par des passerelles tierces, partagées entre plusieurs organisations, chiffrer le lien radio ne protège rien : l'attaquant présumé est justement le pair de ce lien. Contrairement à une idée répandue, l'appairage Bluetooth Low Energy (BLE) en mode Just Works n'authentifie personne, et les modes qui authentifient exigent un code ou un canal annexe qu'un capteur sans écran n'a pas.

La protection doit donc vivre au-dessus du lien, de bout en bout entre le capteur et le serveur. La figure 1 résume les quatre familles de vecteurs que nous traitons : réseau, accès local, chaîne d'approvisionnement et canaux auxiliaires.

Une deuxième question tranche souvent le débat : faut-il de la confidentialité ? Une température, une vibration ou un niveau de cuve ne sont pas toujours secrets. En revanche, une mesure falsifiée peut déclencher une alarme, arrêter une ligne ou masquer une dérive. Dans notre pratique, l'exigence réelle se résume souvent à trois propriétés : authenticité, intégrité et fraîcheur. Les écrire noir sur blanc évite de concevoir un protocole de chiffrement complet là où une signature de message suffit.

Comment authentifier chaque message sans chiffrer le lien radio ?

L'authentification de message garantit qu'une donnée vient bien du capteur annoncé et n'a pas été modifiée en route. On l'obtient en ajoutant à chaque trame un code calculé avec une clé secrète propre au capteur, un HMAC, que seul le serveur sait vérifier.

Sur un projet récent, nous avons retenu une architecture en deux temps. D'abord une session établie par une signature Ed25519 : le capteur prouve son identité avec une clé privée qui ne quitte jamais la puce. Ensuite, chaque message porte un HMAC tronqué à quelques octets, parce que la charge utile d'une trame radio est comptée. Un compteur monotone, sauvegardé en mémoire non volatile, est inclus dans chaque calcul : un message rejoué porte un compteur déjà vu et il est refusé.

Pourquoi ce n'est pas une preuve à divulgation nulle

Ce n'est pas une preuve à divulgation nulle de connaissance (ZKP), même si le capteur prouve détenir une clé sans la révéler. Une ZKP est une construction cryptographique distincte, plus lourde, rarement justifiée sur un capteur sur batterie. Le couple signature de session plus HMAC répond au besoin avec des primitives éprouvées et bien outillées sur MCU.

Le point délicat est le compteur. Si sa zone de stockage devient illisible alors que la clé survit, un firmware naïf repart de zéro avec la même clé, et chaque message capturé auparavant redevient rejouable. Nous recommandons que ce cas échoue fermé : le capteur refuse les commandes, le signale au serveur, et la seule sortie est un nouveau provisionnement avec une nouvelle clé. Sur ce projet, nous avons reproduit ce défaut en simulation radio avant qu'il n'atteigne le banc, puis vérifié le correctif dans la même matrice de tests.

Clés, secure element et port de debug

Un secure element est une puce dédiée qui stocke les clés privées dans une mémoire protégée contre la lecture directe et les attaques physiques. Les microcontrôleurs récents offrent aussi un stockage de clés intégré, non exportable, qui rend un service comparable sans composant supplémentaire.

Dans les deux cas, le principe est le même : la clé privée est générée ou injectée en usine, elle signe sur place, et seule la clé publique sort. Les références courantes sont le Microchip ATECC608B, le NXP SE050, l'Infineon OPTIGA Trust M et le ST STSAFE-A110 ; le bon choix dépend de la pile logicielle et de ce que le MCU sait déjà faire. Contrairement au stockage en flash interne, une extraction de firmware ne compromet alors plus toute la flotte.

Le port de debug reste le trou le plus fréquent. Sur un audit hardware, nous avons trouvé un produit industriel déployé en série avec son port JTAG actif et non verrouillé : lecture de la flash avec un débogueur du commerce, extraction complète du firmware et des clés TLS. Contrairement à un serveur, ce défaut ne se corrige pas par un patch distant sur les unités déjà livrées. Nous recommandons de verrouiller le Joint Test Action Group (JTAG) et le Serial Wire Debug (SWD) en fin de production, et de documenter comment un capteur retourné en atelier est déverrouillé, effacé, puis reprovisionné.

Le stockage de clés pose aussi une question de procédé. L'ordre de provisionnement en usine (clé d'identité, clé de message, compteur initial) doit être testé comme une fonction du produit, avec un contrôle de flotte simple : chaque capteur doit annoncer qu'il possède ses clés. Notre passage du prototype à la série intègre ce contrôle au banc de test de production.

OTA signée et anti-rollback : à décider avant la première unité

Une mise à jour OTA signée est un firmware que le bootloader n'accepte qu'après avoir vérifié sa signature avec une clé publique stockée dans le capteur. MCUboot, le bootloader du Zephyr Project, gère nativement cette vérification, l'échange de slots et la confirmation après démarrage.

La signature ne suffit pas. Sans protection contre le retour en arrière, un attaquant peut réinstaller une version plus ancienne, correctement signée, qui contient une vulnérabilité connue. MCUboot propose un compteur de sécurité attaché à chaque image : le bootloader refuse toute image dont le compteur est inférieur à celui déjà installé.

Le piège est que ce réglage vit dans le bootloader, et que sur beaucoup de produits le bootloader ne se met pas à jour par OTA. Les unités flashées avant l'activation de l'anti-rollback restent alors sans protection jusqu'à leur prochain passage en atelier. Même remarque pour la protection en écriture du bootloader : si l'application peut réécrire la zone du bootloader, un firmware compromis peut s'installer durablement. Ces décisions se prennent avant la première unité livrée, pas après.

Le reste de la chaîne est connu : signature côté serveur de build, transport authentifié, écriture dans le slot inactif, échange atomique et confirmation par watchdog. Notre guide Zephyr, FreeRTOS ou Linux temps réel compare les piles qui le supportent, et notre article sur le CRA appliqué au Linux embarqué traite le cas des passerelles sous Linux.

Durcir une flotte déployée par étapes

Durcir une flotte par étapes consiste à déployer d'abord les contrôles de sécurité en mode observation, puis à les rendre bloquants une fois que toute la flotte est prête. On évite ainsi qu'une règle activée trop tôt coupe des capteurs mal provisionnés ou des outils de maintenance pas encore mis à jour.

Sur une flotte existante, une commande non signée n'est donc pas refusée le premier jour : elle est acceptée et comptée. Le serveur voit quels capteurs, quelles passerelles et quels outils envoient encore du trafic non authentifié. Quand ce compteur tombe à zéro et que chaque capteur annonce ses clés, la flotte est armée et le refus devient la règle. Malgré la tentation d'aller vite, nous recommandons de traiter cet armement comme un jalon de projet, avec ses propres critères de sortie.

Le tableau ci-dessous sert de matrice de décision : pour chaque défaut, il dit ce qui le corrige et ce que cela coûte sur une flotte en service.

Cette matrice explique pourquoi nous préférons une flotte imparfaite mais mesurée à une flotte réputée sûre. Un défaut accepté, écrit, avec sa raison et sa date de revue, est un défaut piloté. Le même défaut ignoré devient une vulnérabilité à signaler sous 24 h le jour où quelqu'un l'exploite.

SBOM, CVE et registre de sécurité

Un Software Bill of Materials (SBOM) est l'inventaire des composants logiciels d'un firmware : RTOS, bibliothèques, piles réseau et leurs versions. Le CRA en fait la base de la gestion des vulnérabilités, car on ne peut signaler ni corriger une faille dans un composant dont on ignore la présence.

Dans notre pratique, le SBOM n'est pas un livrable de fin de projet. Il est produit à chaque build au format SPDX, passé à un scanner de vulnérabilités comme Grype, et la chaîne échoue sur toute faille de sévérité haute. Un scan planifié tourne aussi sans aucun commit, parce que de nouvelles CVE apparaissent sur un code qui n'a pas changé.

Filtrer et prioriser les vulnérabilités

Le second filtre est souvent oublié : confronter les avis de sécurité du RTOS à ce qui est réellement compilé dans l'image. Une faille dans un pilote absent du binaire n'a pas la même priorité qu'une faille dans la pile radio utilisée. Nous complétons par une analyse statique (cppcheck en intégration continue) et, pour les pipelines CI/CD embarqués, par une règle simple : le déploiement n'a lieu que si l'ensemble des tests passe.

Comme le souligne Thierry Durand, expert cybersécurité embarquée chez Embedded Expertise, un scan CVE (Grype, Trivy) n'est que la première étape : le vrai travail consiste à piloter la remédiation, c'est-à-dire trier, prioriser selon le contexte d'exploitation, suivre l'état des corrections et justifier chaque exclusion. D'après lui, un projet embarqué peut faire remonter plus de 3000 CVE d'un scan SBOM ; sans priorisation, le rapport reste inexploitable.

Le registre de sécurité

D'où le registre de sécurité : une ligne par défaut, avec sa sévérité, son statut et sa décision. Sur notre dernier projet de flotte, le registre compte davantage de lignes côté serveur et broker MQTT que côté firmware. La sécurité d'une flotte ne s'arrête pas au capteur.

Retour terrain : une flotte de capteurs BLE sur batterie

Un retour terrain résume ce qu'un projet réel a appris et que la documentation ne disait pas. Celui-ci concerne une flotte de capteurs BLE sur batterie, dont les mesures transitent par des passerelles et des téléphones tiers jusqu'à un serveur, avec des mises à jour OTA signées MCUboot.

Sur ce projet récent, notre méthodologie a suivi trois étapes. D'abord un modèle de menace écrit, qui place l'attaquant au niveau de la passerelle et retire la confidentialité des exigences : ce choix a évité un protocole de chiffrement complet et laissé l'effort sur l'authentification. Ensuite une simulation radio de la flotte, qui rejoue les scénarios de panne (redémarrage, OTA, mémoire corrompue) avant le banc. Enfin un registre de sécurité revu à chaque version.

Ce que nous avons constaté

Contrairement à l'idée reçue selon laquelle la cryptographie est la partie difficile, nous avons constaté que les défauts sérieux se trouvaient aux frontières : un compteur qui ne survit pas à une corruption mémoire, un réglage de bootloader impossible à rattraper à distance, un outil de banc qui désactivait par défaut la vérification TLS du broker. Aucun ne relevait d'un mauvais algorithme.

Malgré la pression pour activer tous les contrôles d'un coup, nous recommandons l'armement par étapes décrit plus haut, et une règle de fin de production : aucune unité ne part sans clés provisionnées, port de debug verrouillé et anti-rollback actif. Ce que la flotte ne sait pas corriger seule doit être réglé avant qu'elle quitte l'atelier.

Checklist : rendre une flotte existante prête pour le CRA

Une checklist de mise en conformité d'une flotte rassemble les vérifications qui permettent de répondre, le jour d'un incident, aux trois questions du CRA : quels produits sont concernés, quel logiciel contiennent-ils, et comment les corriger. Elle se déroule dans l'ordre, de l'inventaire jusqu'à l'armement.

Chaque étape produit une preuve réutilisable dans le dossier technique du CRA : un inventaire daté, un modèle de menace signé, des SBOM archivés par version, des rapports de scan, un registre des décisions. Contrairement à une démarche de certification ponctuelle, ces preuves se mettent à jour à chaque version du firmware. Nous recommandons de les produire par le pipeline plutôt qu'à la main, pour qu'elles restent vraies le jour où un incident oblige à signaler sous 24 h.

• Inventorier la flotte : version de firmware et de bootloader de chaque capteur, remontée automatiquement.
• Écrire le modèle de menace : qui est non fiable (passerelle, téléphone, réseau), et quelles propriétés sont exigées.
• Générer un SBOM à chaque build et planifier un scan de vulnérabilités même sans nouveau commit.
• Authentifier chaque message de bout en bout, avec un compteur persistant qui échoue fermé.
• Vérifier la chaîne OTA : signature, anti-rollback, protection en écriture du bootloader.
• Verrouiller JTAG/SWD sur chaque unité qui sort de production.
• Armer par étapes : observer le trafic non signé, puis le refuser quand il tombe à zéro.
• Tenir un registre de sécurité et une procédure de signalement sous 24 h.

La version détaillée et imprimable est notre checklist Cyber Resilience Act. Pour un produit radio, complétez par la checklist certification CE/RED, et pour l'autonomie de ces capteurs, par notre guide power management embarqué.

En résumé

La cybersécurité IoT industriel d'une flotte déployée ne se joue pas sur le choix d'un algorithme, mais sur ce que la flotte sait corriger d'elle-même. Un capteur sur le terrain ne change que ce que son firmware et son bootloader actuels lui permettent de changer ; tout le reste coûte un passage en atelier. Le CRA ajoute une échéance concrète : savoir, à tout moment, quel logiciel tourne sur chaque unité et comment le corriger. Dans notre pratique, une flotte se sécurise par décisions écrites et par étapes mesurées, pas par une liste de technologies. Chaque décision a un propriétaire, une date et une preuve.

Les cinq points à retenir, de la réglementation jusqu'au pipeline :

• Le CRA s'applique déjà : signalement sous 24 h depuis le 11 septembre 2026, produits déjà vendus compris.
• La passerelle est un adversaire : authentifiez de bout en bout, pas sur le lien radio.
• Le compteur compte autant que la clé : un compteur perdu doit faire échouer fermé.
• Le bootloader se décide avant la première unité : anti-rollback et protection en écriture ne se rattrapent pas toujours.
• SBOM, scan planifié et registre transforment une liste de CVE en décisions suivies.

Les référentiels IEC 62443-4-2, ETSI EN 303 645 et l'OWASP IoT Top 10 donnent la méthode ; le travail consiste à l'outiller dans le produit et dans le pipeline.

Articles connexes

• Cyber Resilience Act : guide de conformité IoT, le cadre réglementaire, le calendrier et la classification des produits.
• Sécuriser un produit IoT de la conception au déploiement, le versant produit neuf de ce guide.
• CRA et Linux embarqué, pour les passerelles et produits sous Linux.
• LoRaWAN, NB-IoT, Sigfox, choisir la radio d'une flotte de capteurs.
• Maintenance prédictive IoT, l'usage industriel de ces capteurs.

FAQ : cybersécurité IoT industriel

Le CRA s'applique-t-il à des capteurs déjà vendus ?
Oui pour le signalement. L'article 14 du Cyber Resilience Act, qui impose de signaler les vulnérabilités activement exploitées et les incidents graves, s'applique depuis le 11 septembre 2026 à tous les produits concernés, y compris ceux mis sur le marché avant cette date. Les exigences essentielles de l'annexe I ne s'appliquent qu'aux produits mis sur le marché à partir du 11 décembre 2027, ou modifiés de façon substantielle. Une simple mise à jour de sécurité n'est pas une modification substantielle.

Faut-il chiffrer la liaison Bluetooth d'un capteur industriel ?
Pas forcément. Si les mesures transitent par des passerelles ou des téléphones tiers, l'attaquant présumé est le pair du lien radio, et le chiffrement du lien ne le protège pas. Le mode Just Works n'authentifie personne. Il vaut mieux authentifier chaque message de bout en bout, entre le capteur et le serveur, avec un HMAC et un compteur. Le chiffrement reste utile si la donnée elle-même est confidentielle, ce qu'il faut décider explicitement dans le modèle de menace.

Un HMAC tronqué est-il suffisamment sûr ?
Oui, à condition de dimensionner la troncature à la menace et de l'associer à un compteur. Un HMAC tronqué à quelques octets ne laisse qu'une chance infime de deviner un code valide pour un message donné, et le serveur peut limiter le nombre d'essais par capteur. Le compteur monotone inclus dans le calcul empêche de rejouer un message déjà vu. La troncature est un compromis classique quand la charge utile d'une trame radio est comptée.

Peut-on ajouter l'anti-rollback par une mise à jour OTA ?
Cela dépend du bootloader. Avec MCUboot, la protection contre le retour à une version plus ancienne repose sur un compteur de sécurité vérifié par le bootloader lui-même. Si le bootloader ne peut pas être mis à jour à distance, les capteurs flashés avant l'activation de cette option restent sans protection jusqu'à leur passage en atelier. C'est pourquoi nous recommandons de décider de l'anti-rollback et de la protection en écriture du bootloader avant la première unité livrée.

Secure element ou stockage de clés du microcontrôleur ?
Les deux protègent la clé privée d'une lecture directe. Un secure element comme l'ATECC608B, le SE050 ou l'OPTIGA Trust M ajoute une puce dédiée, résistante aux attaques physiques, utile quand le MCU n'offre pas de stockage protégé. Les microcontrôleurs récents intègrent un stockage de clés non exportable qui suffit souvent. Le critère décisif reste le même : la clé privée ne doit jamais quitter la puce, et le port de debug doit être verrouillé en production.

Par où commencer pour sécuriser une flotte existante ?
Commencez par l'inventaire : quelle version de firmware et de bootloader tourne sur chaque capteur, et quels composants logiciels contient chaque image, grâce à un SBOM. Écrivez ensuite le modèle de menace, puis classez chaque défaut selon qu'il se corrige par OTA, en atelier ou à la prochaine révision de carte. Déployez enfin les contrôles en mode observation avant de les rendre bloquants. Notre checklist Cyber Resilience Act suit cet ordre.