Oui, mais seulement si on renonce à une illusion : un objet connecté ne devient pas “de confiance” parce qu’il est à l’intérieur du réseau. C’est précisément ce que Zero Trust refuse.
Le problème, c’est que l’IoT entre mal dans ce modèle par défaut : beaucoup d’objets n’ont pas de MFA, pas d’agent EDR, peu de journalisation, des firmwares opaques, et parfois des capacités de sécurité très limitées.
La vraie question n’est donc pas “peut-on faire du Zero Trust parfait avec l’IoT ?”. La vraie question est : comment appliquer les principes Zero Trust à des équipements souvent faibles, non administrables comme des postes, mais quand même dangereux s’ils sont compromis ?
1) Zero Trust ne commence pas par “faire confiance au device”
Dans une architecture Zero Trust, on ne part jamais du principe qu’un device est sûr “par nature”. On protège les ressources, pas le périmètre.
Pour l’IoT, cela change tout. Une caméra, une borne, un capteur ou une serrure connectée doivent être traités comme :
- des actifs à risque,
- à capacité de sécurité limitée,
- et potentiellement compromis.
Autrement dit : on n’essaie pas de “faire entrer l’IoT dans le cercle de confiance”. On construit le réseau en supposant qu’il n’y a pas de cercle de confiance.
2) Le premier pilier réaliste : l’identité minimale de l’objet
Le Zero Trust suppose qu’on sache à qui ou à quoi on parle. Pour l’IoT, cela commence par une identité device minimale : inventaire, empreinte, certificat, adresse attendue, type d’équipement, rôle métier.
En pratique, pour une intégration Zero Trust, il faut au minimum :
- identifier chaque objet de façon unique,
- savoir à quel service il est censé accéder,
- refuser les objets inconnus ou mal classés,
- et traiter les équipements non identifiés comme non fiables par défaut.
Si vous ne savez pas distinguer un capteur légitime d’un appareil inconnu branché sur le même segment, vous n’êtes pas en Zero Trust. Vous êtes en espérance.
3) La vraie colonne vertébrale : microsegmentation et contrôle de flux
L’IoT s’intègre à Zero Trust surtout par le réseau, pas par des agents lourds installés sur les objets. La logique la plus robuste consiste à microsegmenter et à réduire les communications au strict nécessaire.
Concrètement :
- un capteur ne parle qu’à sa passerelle,
- une caméra ne parle qu’à son NVR ou service autorisé,
- un automate ne parle qu’aux systèmes strictement nécessaires,
- un objet ne doit pas initier librement des flux vers tout le SI.
C’est là que le Zero Trust devient utile pour l’IoT : non pas en rendant l’objet “sain”, mais en limitant radicalement ce qu’il peut atteindre s’il est compromis.
4) L’IoT faible doit être compensé par l’environnement
C’est le point le plus important. Beaucoup d’objets connectés ne pourront jamais satisfaire les attentes d’un endpoint moderne : pas de journalisation riche, pas de détection locale, pas de posture dynamique sophistiquée.
Il faut donc compenser au niveau de l’architecture :
- NAC ou contrôle d’accès réseau,
- politiques par VLAN/SSID/sous-réseau,
- filtrage est-ouest,
- autorisations par rôle,
- passerelles de sécurité,
- surveillance de flux au niveau réseau.
Autrement dit : si le device ne peut pas prouver grand-chose, c’est l’environnement qui doit devenir strict.
5) Les prérequis non négociables : pas de Zero Trust avec un IoT structurellement médiocre
Il y a une limite dure : certains objets sont trop faibles pour entrer proprement dans une architecture moderne.
Si un objet n’offre pas au moins une partie de ces capacités — par exemple :
- mot de passe universel,
- absence de mécanisme de mise à jour sûr,
- impossibilité de désactiver des services,
- absence totale de visibilité sur son état —
alors il ne “s’intègre” pas à Zero Trust ; il devient un actif qu’on tolère à la marge, à isoler brutalement ou à remplacer.
6) Le modèle réaliste : confiance conditionnelle, jamais implicite
La bonne intégration Zero Trust de l’IoT ne consiste pas à dire “cet objet est approuvé, donc il peut circuler”. Elle consiste à dire :
- cet objet a une identité connue,
- il est dans un segment dédié,
- il n’a accès qu’à des ressources précises,
- son comportement attendu est limité,
- et s’il sort de ce cadre, on le coupe ou on le dégrade.
C’est une confiance conditionnelle et réversible, pas une confiance statique.
C’est aussi pour cela que le Zero Trust appliqué à l’IoT est moins une question de “technologie miracle” qu’une question de discipline :
- inventaire,
- classification,
- segmentation,
- politique réseau,
- et exigences minimales à l’achat.
Conclusion : oui, l’IoT peut entrer dans Zero Trust — mais pas comme un égal, comme un risque encadré
Oui, les objets connectés peuvent s’intégrer dans une architecture Zero Trust. Mais pas en les traitant comme des postes classiques, ni en espérant qu’ils se comportent comme des endpoints matures. Ils s’intègrent par compensation architecturale : identité minimale, segmentation stricte, accès réduit, surveillance réseau, et rejet des équipements trop faibles.
La bonne question n’est donc pas “peut-on faire confiance à l’IoT dans un modèle Zero Trust ?”. La bonne question est : comment construire un système où même un objet peu fiable n’a jamais assez de liberté pour mettre en danger le reste ?
