Pendant des années, la sécurité embarquée était perçue comme un « luxe » – un élément ajouté lorsque le temps et le budget le permettaient, ou une fois que le produit atteignait une certaine ampleur. Cette époque est révolue. Aujourd’hui, la sécurité des systèmes embarqués est indispensable, et les ingénieurs qui la traitent comme un détail devront repenser leurs systèmes, corriger des failles évitables ou voir leurs produits figurer dans des listes de vulnérabilités.
 
Embedded World diffuse ce message depuis plusieurs éditions, et la réalité s’impose de plus en plus clairement. Quand presque tous les microcontrôleurs, nœuds capteurs, appareils électroménagers, contrôleurs industriels, wearables et sous-systèmes automobiles sont connectés — directement ou indirectement — la surface d’attaque devient l’Internet mondial. Mettre un microcontrôleur en production sans contrôles de sécurité appropriés en 2026 équivaut à expédier un PC en 1999 avec le partage de fichiers ouvert à tous et sans pare-feu.

Il s’agit d’une réaction pragmatique à un secteur où les attaques de la chaîne logistique logicielle, les altérations du firmware et les flottes IoT compromises sont devenues routinières. Le secteur embarqué doit désormais garantir les mêmes propriétés que les grands systèmes informatiques classiques : confidentialité, intégrité, authenticité et résilience. La différence ? Les systèmes embarqués doivent offrir ces garanties avec des budgets énergétiques contraints, très peu de mémoire et des durées de vie de plusieurs décennies.



Si les ingénieurs n'en font pas une priorité dès le début, ils devront consacrer beaucoup plus d’efforts à corriger ces problèmes plus tard.

embedded security is no longer optional
La sécurité embarquée n’est plus optionnelle.

Le modèle de menace s’élargit : tout communique avec tout

Il y a dix ans, un microcontrôleur 8 bits exécutant quelques boucles de contrôle n’attirait l’attention d’aucun expert en cybersécurité. Il communiquait probablement sur un bus série simple et était caché derrière une passerelle. Aujourd’hui, ce même type d’appareil peut dialoguer avec :
 
  • Un module sans fil IP
  • Un service cloud
  • Plusieurs SDK fournisseurs et bibliothèques tierces
  • Des applications mobiles via Bluetooth LE
  • Un bootloader sur l’appareil qui accepte des mises à jour sur le terrain

En d’autres termes, il n’est plus isolé. Même les conceptions minimalistes à bas coût ont des chemins vers l’extérieur, parfois indirectement via d’autres sous-systèmes.

Dès que la connectivité est présente, les vecteurs d’attaque informatiques classiques apparaissent :
  • Mises à jour de firmware usurpées
  • Vol d’identifiants
  • Fuites par canaux auxiliaires
  • Exécution de code à distance via des paquets mal formés
  • Manipulation de la chaîne logistique (outils de développement compromis, bibliothèques piégées, binaires altérés)

Ce ne sont pas des hypothèses. Des déploiements IoT industriels, des appareils grand public et même des ECU automobiles ont été compromis via des mises à jour de firmware, des ports de débogage et des applications compagnons peu sûres.

Le plus grand changement : les attaquants ne s’intéressent plus à la valeur d’un appareil isolé. Qui craint vraiment qu’un pirate allume son lave-vaisselle à distance ? Personne, mais les botnets, DDoS et attaques latérales font que même une ampoule connectée vaut la peine d’être compromise.

Quand chaque nœud est un point d’entrée potentiel, les équipes d’ingénierie ne peuvent plus supposer qu’un appareil est trop simple ou obscur pour être visé.

Le matériel rattrape (presque) enfin son retard

Bonne nouvelle : les fournisseurs de silicium se sont réveillés. La plupart des nouveaux microcontrôleurs et SoC sont désormais dotés de fonctions autrefois réservées aux processeurs haut de gamme :
 
  • Boot sécurisé
  • Root of Trust matériel
  • Stockage de clés embarqué (PUFs, blocs HSM, zones OTP)
  • Zonage d’exécution isolé (ARM TrustZone-M, RISC-V PMP)
  • Accélérateurs cryptographiques
  • Détection d’altération et couches actives de protection (sur certains MCU sécurisés)

Le problème, ce n’est pas le manque de fonctionnalités, mais que beaucoup d’équipes n’activent ou n’utilisent pas ces fonctions. Les quatre raisons les plus courantes :
 
  • Les fonctions de sécurité compliquent le développement. Elles demandent des chaînes de provisionnement et de signature qui n’existent pas dans le flow de mise en route standard.
  • La documentation est souvent fragmentée ou spécifique au fournisseur. Le boot sécurisé sur une variante Cortex-M33 ne fonctionne pas comme sur une autre.
  • La sécurité apparaît comme une « charge supplémentaire » quand les délais sont serrés. Les fonctions sont reportées à la « phase deux », qui n’arrive jamais.
  • Il manque une culture sécurité unifiée. Firmware, électronique, DevOps et cloud traitent la sécurité comme un SEP (« quelqu’un d’autre s’en occupe »).

Le silicium est prêt. Les processus, souvent non.

Ce qu’exige le contexte actuel

Une bonne sécurité embarquée ne repose plus sur des fonctions individuelles, mais sur une confiance de bout en bout :

Une base matérielle de confiance
  • Bootloader ROM immuable
  • Firmware signé
  • Voies de mise à jour vérifiées

Identités sécurisées par appareil
  • Clés cryptographiques uniques
  • Authentification basée sur certificats
  • Clés qui ne quittent jamais le MCU

Résistance à l’exploitation
  • Unités de protection mémoire
  • Renforcement par le compilateur
  • Réduction de la surface d’attaque du firmware

Protection des données en stockage et en transit
  • Flash chiffré sur puce
  • TLS ou canaux sécurisés équivalents

Un workflow de développement sécurisé
  • Builds reproductibles
  • Infrastructure de signature contrôlée
  • Analyse des vulnérabilités des dépendances

Gestion du cycle de vie
Le point essentiel : la sécurité n’est plus un ajout. C’est un processus continu couvrant la conception, la fabrication, le déploiement et la maintenance.

Où les ingénieurs rencontrent le plus d’obstacles

Dans tous les secteurs — des projets amateurs aux installations industrielles — on retrouve toujours les mêmes écueils :

Chaînes de boot sécurisées incomplètes

Les développeurs signent le bootloader de premier niveau mais laissent l’image applicative non signée. Ou ils s’appuient sur des clés de débogage laissées actives en production.

Clés faibles ou réutilisées

Un nombre étonnant d’appareils sont encore livrés avec :
  • des clés privées partagées sur toute une gamme de produits !
  • des identifiants codés en dur
  • des clés symétriques dans le firmware

Dès qu’une fuite se produit, toute la flotte devient vulnérable.

Mises à jour OTA sans vérification d’intégrité

Même en 2026, certains appareils téléchargent encore des mises à jour en HTTP sans vérification de signature ! Cela reste le vecteur d’attaque le plus simple pour l’IoT.

Excès de confiance dans la « sécurité par l’obscurité »

Firmware fermé, MCU rares, protocoles propriétaires et autres techniques d’obfuscation ne protègent plus personne. Les attaquants rétro-ingénierent régulièrement des architectures obscures.

Pas de plan de maintenance long terme

Les produits durent 10 à 20 ans. Les fournisseurs survivent à trois à cinq cycles produits. Les backends cloud disparaissent ou changent. Les plans de sécurité ne tiennent presque jamais compte de cela.

Mesures pratiques pour les ingénieurs

La sécurité n’est intimidante que lorsqu’on veut tout faire d’un coup. Le meilleur conseil : l’intégrer dès la conception, pas après coup.

Commencez par une root of trust matérielle

Si le MCU ou le SoC prend en charge le boot sécurisé, activez-le dès le début. Mettez en place la signature du firmware et le workflow de provisionnement avant même d’écrire une ligne de code applicatif. Cela évite le syndrome « on sécurisera plus tard ».

Des clés uniques par appareil, pas de secrets partagés

Les MCU modernes offrent un stockage sécurisé des clés précisément pour cela. Générez des identifiants uniques en fabrication ou au premier démarrage, idéalement créés dans l’appareil.

Réduisez la surface d’attaque firmware

Désactivez les périphériques, piles de communication et interfaces de débogage inutilisées. Minimisez le code tiers. Chaque pilote inutilisé reste un vecteur d’attaque potentiel.

Imposez des mises à jour authentifiées

Les mises à jour doivent toujours nécessiter à la fois la sécurité du transport (TLS, DTLS, etc.) et la vérification cryptographique de l’image.

Modélisez les menaces dès le début

Pas besoin d’une analyse de 50 pages — juste une discussion structurée de 30 minutes :
 
  • Qu’est-ce qu’un attaquant peut voir ?
  • Qu’est-ce qu’il peut contrôler ?
  • À quoi pourrait-il accéder physiquement ?
  • Que se passe-t-il s’il obtient cela ?

Vous repérerez les failles de conception avant qu’elles ne deviennent des problèmes structurels.

Documentez votre plan de sécurité

Si votre équipe n’est pas capable d’expliquer comment les clés sont stockées, comment les mises à jour sont authentifiées et comment fonctionne la chaîne de démarrage, alors votre appareil n’est pas sécurisé — il a juste de la chance, pour l’instant.

Pourquoi la sécurité anticipée fait gagner du temps (et de l’argent)

On voit souvent la sécurité comme une perte de temps coûteuse. En réalité, des implémentations économiques et mal pensées coûtent beaucoup plus cher : les systèmes non sécurisés sont très onéreux.
 
  • Rappels dus à des firmwares compromis
  • Patches d’urgence sous pression
  • Perte de clients après des incidents
  • Problèmes réglementaires (en particulier dans le médical, l’industriel ou l’IoT grand public)
  • Durée de vie réduite des produits faute de corrections possibles après coup

Un petit investissement dans la sécurité et l’architecture en début de cycle évite des années de reprises et de « firefighting ».

Autre avantage : des appareils sûrs restent utiles plus longtemps. Quand le matériel peut faire confiance à son firmware et à sa chaîne de mise à jour, vous pouvez ajouter des fonctions, des correctifs ou de nouveaux workflows même des années après le lancement.

La nouvelle responsabilité des ingénieurs embarqués

Le changement est simple : tout appareil avec firmware est désormais un système à risque. Les ingénieurs construisent de la confiance, plus seulement des fonctionnalités. Que vous travailliez sur de petits Cortex-M0+, des SoC Linux puissants ou les nouvelles plateformes RISC-V, les attentes sont les mêmes.

La communauté, le marché et, de plus en plus, la loi attendent un comportement sûr par défaut.

C’est le contexte de notre dossier spécial Embedded World 2026. Le salon reflète une transition industrielle globale : de « la sécurité en option » à « la sécurité en infrastructure ». L’époque où les MCU étaient vus comme de simples blocs de contrôle isolés est révolue. Ce sont des nœuds d’un système mondial et leur sécurité compte bien au-delà de leur fonction immédiate.

Sécurisez votre avenir

La sécurité embarquée n’est pas aussi « sexy » que les nouveaux accélérateurs d’IA ou les radios ultra-basse consommation, mais elle décide si votre produit survivra sur le terrain, restera digne de confiance et évitera de finir dans le prochain incident IoT majeur.

Si vous développez des systèmes embarqués aujourd’hui, la sécurité fait désormais partie du métier — ce n’est plus un accessoire optionnel.