Zero trust : ce que ça veut dire concrètement, et par où commencer sans
tout refaire

Trois devis sur le bureau, trois logos différents, et le même mot en titre sur chacun : "Zero Trust". Le premier vend un agent à poser sur les postes, le deuxième un proxy devant les applications, le troisième une licence annuaire avec des règles conditionnelles. Le RSSI qui les compare finit par se poser la question qu'il aurait dû se poser avant d'ouvrir les enveloppes : lequel des trois est le zero trust ? Aucun. L'idée reçue tenace, entretenue par ceux qui ont un produit à vendre, est que le zero trust s'achète. Il se décide. C'est une façon d'organiser qui accède à quoi, à partir de quel poste, pendant combien de temps, et surtout avec quelle preuve. Les produits n'en couvrent chacun qu'une brique.

L'ANSSI l'a écrit dès 2021 dans son avis scientifique et technique sur le modèle Zero Trust : c'est "un concept d'architecture dédié au renforcement de la sécurité d'accès aux ressources et aux services et non pas une technologie en soi, a fortiori ce n'est pas une solution logicielle tout-en-un commerciale". La phrase a cinq ans et les plaquettes commerciales ne l'ont toujours pas lue. Ce qu'elle ne règle pas, en revanche, c'est la situation du RSSI aux trois devis : un SI de quinze ans qu'on ne peut pas jeter, des utilisateurs qui travaillent de chez eux depuis 2020, et une architecture à construire par morceaux.

D'où vient le zero trust, et qui l'a formalisé

Le concept est plus vieux que le mot. La NIST SP 800-207 fait remonter la généalogie aux travaux du Jericho Forum en 2004 sur la "dé-périmétrisation". Le terme lui-même a été forgé par John Kindervag, alors analyste chez Forrester, que le cabinet date de 2009. Google a ensuite montré que ça tournait à l'échelle avec BeyondCorp, décrit en 2014 dans la revue ;login: : les applications internes passent derrière un proxy qui vérifie l'utilisateur et son poste, et l'intranet privilégié disparaît.

Le texte de référence arrive en août 2020. La SP 800-207, signée Scott Rose et Oliver Borchert (NIST), Stu Mitchell et Sean Connelly (DHS), donne la définition que tout le monde recopie depuis : "une collection de concepts et d'idées conçus pour réduire l'incertitude dans l'application de décisions d'accès précises, au moindre privilège et par requête, face à un réseau considéré comme compromis". La dernière clause fait tout le travail, puisqu'elle pose comme point de départ ce que la plupart des architectures posent comme scénario du pire.

L'ANSSI a complété son avis de 2021 par un guide en juin 2025, ANSSI-PA-111, Modèle Zero Trust : les fondamentaux. Son glossaire contient la définition la plus utile du lot : le niveau de confiance implicite est celui qu'on accorde à un sujet hors de tout contexte, et "dans le modèle théorique du Zero Trust, le niveau de confiance implicite est considéré comme nul". Tout le reste découle de cette phrase.

Les principes du zero trust, sans le marketing

La SP 800-207 énonce sept principes. Microsoft les compresse en trois (vérifier explicitement, moindre privilège, supposer la compromission), ce qui se retient mieux mais perd des nuances. Cinq d'entre eux changent quelque chose dans un SI existant.

• Le réseau ne vaut pas confiance. Principe 2 du NIST : une requête venue de l'intérieur du périmètre historique doit satisfaire les mêmes exigences qu'une requête venue de n'importe quel réseau tiers. Être sur le LAN ou dans le tunnel VPN ne donne aucun droit en soi.
• Vérifier explicitement, à chaque session. L'accès est accordé par session et par ressource (principe 3). Avoir été authentifié pour une application ne vaut pas autorisation pour la suivante. L'ANSSI ajoute que les authentifications et autorisations doivent être réévaluées régulièrement, pas seulement à l'ouverture.
• Moindre privilège, sur les droits et sur la visibilité. Le NIST précise que le principe s'applique aussi à ce que le sujet peut voir. Une application que vous n'avez pas le droit d'utiliser ne devrait même pas répondre à votre ping.
• Une politique dynamique, nourrie par l'état du poste. Le principe 4 fait entrer dans la décision l'identité, mais aussi la version des logiciels installés, l'heure, la localisation et le comportement observé. Le principe 5 en tire la conséquence : aucun actif n'est digne de confiance par nature, et un poste non géré ou vulnérable peut se voir refuser toute connexion.
• Supposer la compromission. C'est la clause "face à un réseau considéré comme compromis" de la définition. Si un attaquant est déjà dedans, la seule chose qui compte est ce qu'il peut atteindre depuis là où il est.

Les principes 6 et 7, moins cités parce qu'ils coûtent cher, attendent une gestion des identités et des actifs en place, avec MFA, et une collecte continue sur l'état des actifs et du trafic. L'inventaire et la journalisation font partie des sept principes.

L'architecture NIST : policy engine, policy administrator, PEP

La SP 800-207 décrit trois composants logiques, séparés pour qu'on puisse les auditer un par un. Le policy engine (PE) prend la décision finale d'accorder, refuser ou révoquer un accès, en combinant la politique de l'entreprise et des signaux externes (état du poste, renseignement sur la menace, journaux). Le policy administrator (PA) exécute cette décision : il ouvre ou coupe le chemin de communication, et génère le jeton ou l'identifiant de session. Le policy enforcement point (PEP) est le point de passage physique ou logique entre le sujet et la ressource. Le PE et le PA vivent dans le plan de contrôle, le PEP dans le plan de données, une séparation que l'ANSSI reprend dans PA-111.

Ce découpage donne la grille de lecture des devis : un ZTNA est d'abord un PEP, un annuaire avec règles conditionnelles est d'abord un PE, un agent de posture est une source de signaux. Le NIST ajoute que la zone de confiance implicite, celle où tout le monde est réputé de confiance une fois passé le PEP, doit être aussi petite que possible. Un PEP unique en entrée de datacenter, avec tout le reste à plat derrière, reproduit le périmètre qu'on prétendait abandonner.

ZTNA contre VPN, identité, posture, micro-segmentation

Le ZTNA répond à une autre question que le VPN

Un VPN répond à la question "êtes-vous autorisé à rejoindre le réseau ?". Une fois le tunnel monté, vous êtes sur le réseau, avec tout ce que ses tables de routage laissent voir. Un ZTNA (zero trust network access) répond à une autre question : "êtes-vous autorisé à joindre cette application, depuis ce poste, maintenant ?". L'utilisateur n'est jamais sur le réseau, l'application n'a pas d'adresse joignable depuis Internet, et un connecteur sortant fait le pont.

Le ZTNA réduit ce qu'un compte volé peut atteindre. Sur le code de l'application elle-même, son effet est nul. L'ANSSI recommande par ailleurs de laisser les postes d'administration hors du modèle zero trust, avec un tunnel IPsec non contournable vers un SI d'administration dédié. Le VPN change de rôle, il ne meurt pas.

L'identité devient le périmètre, donc l'annuaire devient critique

Quand la décision d'accès ne dépend plus de l'adresse IP mais de qui vous êtes, l'annuaire devient l'actif le plus sensible du SI. L'avis de 2021 est net : les référentiels d'identité "doivent être assainis avec une politique stricte de mise à jour lors des arrivées, départs et mobilités". Un compte de stagiaire parti depuis deux ans, toujours actif, reste une porte d'entrée, à ceci près qu'il ouvre maintenant des applications exposées sur Internet.

Sur l'authentification, le NIST fait de la MFA un composant attendu, et l'ANSSI conseille de privilégier des certificats issus d'une IGC de confiance ou des jetons FIDO. Les codes par SMS, qu'elle ne cite même pas, restent le facteur le plus facile à détourner. Les passkeys, dérivées des standards FIDO, sont présentées par la FIDO Alliance comme résistantes à l'hameçonnage par construction, la clé privée ne quittant jamais l'appareil. Ce qu'un attaquant contourne selon le facteur choisi est détaillé dans l'article sur l'authentification multifacteur.

La posture du terminal, ou pourquoi l'agent finit par revenir

Le principe 5 du NIST demande d'évaluer la posture de sécurité du poste à chaque demande d'accès, ce qui veut dire la version de l'OS, le chiffrement du disque, la présence de l'EDR et les correctifs appliqués. Il faut donc un agent, ou une intégration avec l'outil de gestion de flotte. Le BYOD s'y heurte : un poste personnel dont on ignore l'état est un actif non géré, que le NIST autorise à traiter différemment, jusqu'au refus de toute connexion. Le ReCyF va dans le même sens pour les entités essentielles : seules les ressources matérielles gérées par l'entité ou son prestataire se connectent au SI.

La micro-segmentation, la partie qu'on repousse

Segmenter, on sait faire depuis les VLAN. Micro-segmenter, c'est autre chose : l'ANSSI décrit des groupes de ressources "qui ont une signification métier", avec un filtrage des flux entre groupes "indépendant des adresses IP", via une couche d'abstraction comme des tags ou des VXLAN. Le serveur de paie ne parle qu'à sa base et à son annuaire, le poste du comptable n'atteint que le frontal de paie, quel que soit le sous-réseau. C'est le chantier le plus long, parce qu'il exige de connaître les flux légitimes avant de bloquer les autres.

Ce que les éditeurs vendent sous le mot zero trust

Quatre offres reviennent dans presque tous les appels d'offres, et elles ne ressemblent pas les unes aux autres. Les situer sur le schéma du NIST suffit à voir quelle part du problème chacune prend en charge.

Zscaler Private Access est un ZTNA au sens strict : il négocie des connexions individuelles entre un utilisateur autorisé et une application donnée, les utilisateurs ne sont jamais sur le réseau et les applications jamais exposées sur Internet. Sur le schéma, c'est un PEP distribué, avec une part de PE pour la segmentation utilisateur-vers-application. Cloudflare Access, dans la gamme Cloudflare One, joue le même rôle devant des applications web ou des réseaux raccordés par tunnel : des politiques en refus par défaut, alimentées par un fournisseur d'identité et des contrôles de posture. Tailscale est différent : un réseau maillé chiffré sur WireGuard, où chaque appareil est authentifié via un fournisseur d'identité (Entra ID, Google Workspace, GitHub, Okta) et où les droits sont écrits dans une politique d'accès. Un réseau privé à appartenance nominative, proche du modèle "enclave" du NIST, plutôt qu'un proxy applicatif. Microsoft Entra Conditional Access, enfin, est présenté par Microsoft comme son moteur de politique zero trust : des règles si-alors qui combinent utilisateur, localisation, état de l'appareil, application et risque de connexion pour exiger une MFA, un poste conforme, ou bloquer. Un PE quasi pur, qui s'appuie sur les PEP de Microsoft et des applications fédérées, et qui suppose une licence Entra ID P1, P2 si l'on veut les signaux de risque.

Les échecs typiques d'un projet zero trust

Les projets échouent rarement sur le composant acheté. Ils échouent sur ce qu'il y a devant et derrière lui.

Le ZTNA devant une application truffée d'IDOR. Le proxy fait son travail : identité vérifiée, MFA passée, poste conforme, session nominative. Puis l'utilisateur légitime change /api/factures/4812 en /api/factures/4811 et lit la facture d'un autre client. Le PEP n'a rien à dire : la session est autorisée, et l'autorisation objet par objet n'a jamais été sa responsabilité. Le zero trust contrôle qui parle à l'application. Ce qu'elle accepte de dire relève du contrôle d'accès applicatif, celui que décrit l'article sur la sécurité des API et le BOLA. Un projet qui met un ZTNA devant une application sans l'avoir testée protège une faille derrière une porte blindée.

La surface externe oubliée. Le ZTNA est en place, et le concentrateur VPN historique tourne toujours, parce que deux prestataires s'en servent encore. L'interface d'administration du pare-feu répond en HTTPS sur son adresse publique, avec son certificat auto-signé de 2019. Un sous-domaine jenkins-old pointe sur une machine que personne n'a éteinte. Rien de tout cela n'est derrière le PEP, donc rien de tout cela n'est couvert par la politique. C'est le point de contact entre le zero trust et la surface d'attaque : une politique d'accès ne s'applique qu'aux ressources qu'elle connaît, et le shadow IT est, par définition, ce qu'elle ne connaît pas. Le NIST le dit sans détour dans sa section sur la migration : la démarche est particulièrement difficile s'il existe des déploiements de shadow IT inconnus.

Zero trust, NIS2 et ReCyF : où les textes se recoupent

Le mot "zero trust" n'apparaît pas dans la directive (UE) 2022/2555. Ce que son article 21, paragraphe 2, impose ressemble pourtant beaucoup à ses principes : le point (i) exige "la sécurité des ressources humaines, des politiques de contrôle d'accès et la gestion des actifs", sans le moindre tempérament, et le point (j) "l'utilisation de solutions d'authentification à plusieurs facteurs ou d'authentification continue [...] selon les besoins". La réserve ne porte donc que sur le point (j). Le rapprochement du contrôle d'accès et de la gestion des actifs dans une même phrase rejoint la logique du NIST, puisqu'on ne contrôle pas l'accès à ce qu'on n'a pas recensé.

En France, la déclinaison opérationnelle est le ReCyF et ses objectifs de sécurité, en version de travail 2.5 du 17 mars 2026. Quatre de ses objectifs recoupent un projet zero trust. L'objectif 1 impose le recensement des systèmes d'information. L'objectif 7 demande aux entités essentielles de cloisonner leurs SI "en zones de sécurité cohérentes" et de contrôler les communications entre ces zones, avec des sous-systèmes regroupant des ressources "ayant des niveaux de sensibilité, d'exposition et de sécurité homogènes" : c'est la micro-segmentation, dans un vocabulaire d'auditeur. L'objectif 8 couvre les accès distants, avec une MFA reposant sur au moins un facteur de connaissance pour les entités essentielles (mesure 8.3-EE). L'objectif 10, gestion des identités et des accès, exige des comptes individuels, l'attribution des droits selon le besoin opérationnel, la désactivation des comptes inutiles dans un délai fixé par la politique (l'exemple donné est sept jours) et une revue des comptes et des droits au moins annuelle.

La logique d'ensemble, qui relie ces objectifs à une gouvernance, une analyse de risques et un référentiel de contrôles, est celle de la GRC en cybersécurité. Le zero trust y occupe une case, celle de l'architecture d'accès.

Feuille de route zero trust : par où commencer sans tout refaire

Le NIST et l'ANSSI convergent : la bascule complète est "peu envisageable" pour un SI hérité, et la plupart des organisations fonctionneront longtemps en mode hybride. La section 7.3 de la SP 800-207 fixe l'ordre : identifier les acteurs, les actifs, les processus clés et leurs risques, formuler la politique pour un candidat, choisir les solutions, déployer et surveiller, étendre. Cette séquence se découpe en six chantiers, avec en regard le contrôle qui dit si l'étape a vraiment abouti.

Le premier chantier est celui qu'on sous-estime, parce qu'il ne s'achète pas. L'inventaire interne (CMDB, gestion de flotte, annuaire) donne la moitié du tableau. L'autre moitié, celle que verra l'attaquant, se construit depuis Internet par découverte d'actifs : énumération DNS, journaux de Certificate Transparency, plages d'adresses, bannières de services. La confrontation des deux listes est le premier livrable utile d'un projet zero trust, avant le moindre devis, et c'est le rôle d'un EASM, dont le fonctionnement est décrit dans l'article qu'est-ce que la gestion de surface d'attaque externe.

Une précision : own2pwn ne déploie pas de ZTNA, ne configure pas d'annuaire et ne remplace pas l'intégrateur qui portera le projet. Il intervient sur deux points de la colonne de droite, la mesure continue de la surface externe par l'EASM et le pentest de l'application publiée, celui qui trouve l'IDOR derrière le PEP.

À retenir

• Le zero trust est une architecture de décision d'accès, définie par la NIST SP 800-207 d'août 2020 et reprise par l'ANSSI en 2021 puis en 2025. Ce n'est ni une technologie ni un produit, et tout éditeur n'en vend qu'un composant.
• Trois composants logiques : le policy engine décide, le policy administrator exécute, le policy enforcement point applique. Un ZTNA est d'abord un PEP, un annuaire à règles conditionnelles est d'abord un PE.
• Le ZTNA réduit le mouvement latéral d'un compte volé. Il ne corrige aucune faille de l'application qu'il protège : un IDOR derrière un PEP reste un IDOR.
• NIS2 n'emploie pas le mot, mais l'article 21.2 (i) et (j) et les objectifs 1, 7, 8 et 10 du ReCyF exigent l'inventaire, le cloisonnement, la MFA et la gestion des identités qui en sont le socle.
• L'ordre qui tient : inventaire, identité, MFA, segmentation, accès applicatif, monitoring, en mode hybride et périmètre par périmètre. La surface externe mesurée depuis Internet est le test de réalité : ce qui répond encore hors du PEP n'est couvert par aucune politique.

Vous avez un ZTNA en cours de déploiement, ou déjà en place, et vous voulez savoir ce qui répond encore à côté ? L'EASM own2pwn inventorie votre surface externe en continu, sans agent ni accès à votre SI, et vous rend la liste que votre politique d'accès ne connaît pas encore.

Questions fréquentes sur le zero trust