Le Zero Trust est aujourd’hui une référence dans la littérature cybersécurité, citée dans les briefings ANSSI, les plans gouvernementaux américains et les feuilles de route RSSI. Le problème : la notion est devenue commerciale. Beaucoup d’éditeurs vendent un produit étiqueté “Zero Trust” en oubliant que le modèle est, avant tout, une discipline d’architecture définie par le NIST.
Cet article propose une lecture pragmatique : ce qu’est Zero Trust, ce qu’il n’est pas, et cinq étapes pour le déployer sans casser un SI existant. La grille de référence est le NIST SP 800-207 [1], publication officielle de 2020 qui reste, en 2026, la définition de marché.
Zero Trust : la définition courte
Le NIST définit Zero Trust comme un ensemble de principes destinés à concevoir et exploiter un système d’information dans lequel aucune confiance n’est accordée par défaut, ni à l’utilisateur, ni à l’équipement, ni à la position réseau (interne ou externe).
Trois principes opérationnels en découlent :
- Chaque accès à une ressource est authentifié, autorisé et chiffré, indépendamment de la localisation source.
- La décision d’accès s’appuie sur un signal contextuel : identité, posture de l’équipement, sensibilité de la ressource, heure, géolocalisation, comportement.
- La politique est appliquée par un point de contrôle distinct (PEP, Policy Enforcement Point), piloté par un moteur de décision (PDP, Policy Decision Point).
Autrement dit : on ne dit plus “tu es dans le LAN, donc tu accèdes”. On dit “tu prouves qui tu es, depuis quoi, dans quel état, et la politique décide”. C’est une rupture avec le modèle de défense périmétrique en château fort.
Ce que Zero Trust n’est pas
Trois confusions reviennent en réunion.
Zero Trust n’est pas un produit. Aucun éditeur ne vend “du Zero Trust” en boîte. Un broker ZTNA, un IdP avec MFA, un EDR ou un service de micro-segmentation logicielle sont des composants qui s’intègrent dans une architecture Zero Trust. Acheter l’un d’eux ne suffit pas.
Zero Trust n’est pas un VPN nouvelle génération. Le ZTNA (Zero Trust Network Access) est souvent comparé au VPN. La différence de fond : un VPN ouvre un tunnel vers un réseau. Un ZTNA ouvre une connexion vers une ressource précise, après évaluation du contexte. Le VPN reste utile sur certains usages (réseaux opérationnels, sites distants), mais ne suffit pas.
Zero Trust n’est pas un projet ponctuel. Le modèle est une trajectoire. Le NIST SP 800-207 et les guides de l’ANSSI sur la sécurisation des accès distants [2] insistent sur le caractère itératif et continu. Aucun audit ne délivre un “label Zero Trust” : la maturité se mesure par périmètre, ressource par ressource.
Étape 1 : Inventaire des sujets et objets
Aucun contrôle d’accès n’est crédible sans inventaire. C’est l’étape la plus pénible et la plus négligée.
Quatre catégories à recenser :
- Identités : comptes utilisateurs (humains), comptes de service (non-humains), identités fédérées partenaires, comptes à privilèges. La CNIL rappelle régulièrement que l’authentification fiable suppose un référentiel d’identités à jour [3].
- Équipements : postes, serveurs, équipements réseau, IoT, mobiles BYOD ou managés. Pour chacun, statut de gestion (managé ou non), conformité à la baseline.
- Services et applications : SaaS, applications internes, API, environnements de développement. Pour chacun, propriétaire fonctionnel, criticité, données traitées.
- Données : classification (publique, interne, confidentielle, secrète), localisation, traitements associés.
Le livrable utile est une matrice “qui accède à quoi”, même incomplète. Cette matrice révèle systématiquement des anomalies : comptes de service partagés, accès dormants, applications oubliées. Ces anomalies sont la matière première du chantier Zero Trust.
Périmètre cible vs périmètre actuel : on cartographie d’abord le périmètre actuel (réseau plat, comptes à privilèges étendus, postes hétérogènes). On définit ensuite la cible (segmentation, IAM unifié, postes conformes). Le delta est le plan de transformation, sur 18 à 36 mois.
Étape 2 : Identité comme nouveau périmètre
Si la confiance n’est plus accordée par la position réseau, elle se reporte sur l’identité. C’est le cœur du Zero Trust.
Quatre briques fondamentales :
IAM unifié. Un référentiel d’identités unique (typiquement Active Directory + Entra ID, ou équivalent), couvrant 100 % des accès humains et machines. Tout compte non rattaché à ce référentiel est un risque non géré.
MFA universelle. Pas seulement pour les comptes à privilèges, pas seulement pour les accès distants. La CNIL insiste sur l’authentification forte généralisée pour les traitements sensibles [3]. Les facteurs résistants au phishing (FIDO2, passkeys) sont à privilégier dans les contextes à risque. MFA par SMS reste un palliatif, pas une cible.
Conditional access. L’accès n’est pas binaire : il est conditionné. Exemples : refus d’accès depuis un poste non conforme, MFA renforcée depuis un pays inhabituel, blocage des protocoles legacy. C’est ici que le contexte (signal) entre en jeu.
Gestion des comptes à privilèges (PAM). Tier 0 protégé, comptes administrateurs distincts des comptes utilisateurs, vault avec rotation, sessions enregistrées. Voir le glossaire IAM / PAM pour les définitions précises.
Sans cette étape, les suivantes sont impossibles. Une politique d’accès qui repose sur des identités floues n’a aucune valeur.
Comptes non-humains. Souvent les grands oubliés. Comptes de service applicatifs, comptes utilisés par les pipelines CI/CD, comptes d’intégration entre SaaS : leur nombre dépasse fréquemment le nombre de comptes humains dans les SI mûrs. Leur gestion est spécifique : pas de MFA possible (par définition), mais rotation automatique des secrets, scope limité, journalisation systématique, vérification de comportement. Les fuites récentes de secrets dans des dépôts publics (GitHub, GitLab) confirment que les comptes machines sont une cible privilégiée.
Identités fédérées et partenaires. Un fournisseur qui se connecte à votre SI dispose d’une identité quelque part. Soit on la gère dans son IdP via SAML/OIDC (préférable), soit dans le vôtre, soit en mode mixte. Toute fédération doit être documentée, contractualisée et révocable techniquement en moins d’une heure si le partenariat s’interrompt.
Étape 3 : Micro-segmentation et politique d’accès
L’objectif est de limiter la propagation latérale. En cas de compromission d’un endpoint, l’attaquant ne doit pas pouvoir atteindre l’ensemble du SI.
Trois niveaux de segmentation :
- Macro-segmentation (réseau) : séparer les zones de confiance (production, tests, postes utilisateurs, OT, DMZ) par des pare-feux.
- Micro-segmentation (logique) : à l’intérieur d’une zone, contrôler les flux entre charges de travail (machines virtuelles, conteneurs, applications). Souvent porté par un agent ou un overlay logiciel.
- Identity-based segmentation : l’accès à une ressource est gouverné par l’identité et le contexte, pas par l’adresse IP source.
Le principe directeur : moindre privilège. Chaque identité ne dispose que des droits strictement nécessaires à sa fonction. Les modèles RBAC (rôles) et ABAC (attributs) se complètent :
- RBAC : convient aux rôles stables (comptable, technicien support, développeur backend).
- ABAC : ajoute le contexte (heure, géolocalisation, sensibilité de la ressource), utile pour les accès exceptionnels et les ressources critiques.
La politique d’accès doit être lisible, versionnée et revue. Une politique de 5 000 règles non documentée vaut zéro. On commence par les ressources critiques (Tier 0, données régulées) et on étend par paliers.
Étape 4 : Postures de devices et chiffrement
L’identité ne suffit pas : l’équipement utilisé pour accéder à la ressource doit lui-même être de confiance.
Posture de l’équipement. Trois conditions minimales : système d’exploitation à jour, EDR actif et à jour, chiffrement disque activé. Pour les postes managés, ces conditions sont vérifiables via MDM ou via l’agent EDR. Pour le BYOD, c’est plus délicat : soit on conteneurise (Intune, MAM), soit on refuse l’accès aux ressources sensibles.
EDR et signal de posture. L’EDR ne sert pas seulement à détecter : il alimente le signal de confiance. Un poste avec EDR désactivé doit basculer en posture “non conforme” et perdre l’accès aux ressources sensibles, automatiquement. C’est l’intégration EDR-IAM qui rend cela possible.
Chiffrement at rest et in transit. Toute donnée sensible est chiffrée au repos (disque, base de données, sauvegarde) et en transit (TLS 1.2 minimum, idéalement TLS 1.3, mTLS sur les communications interservices). L’ANSSI publie des recommandations cryptographiques régulièrement mises à jour.
mTLS. Le mutual TLS (authentification mutuelle par certificats) devient une brique standard pour les communications service-à-service, en particulier dans les architectures conteneurisées. Il fournit un chiffrement et une authentification cryptographique sans dépendre de l’identité réseau.
Étape 5 : Observabilité et amélioration continue
Sans télémétrie, Zero Trust est une intention. Trois piliers :
Journalisation. Tous les accès, succès et échecs, sont journalisés et conservés selon les durées légales (RGPD, NIS2, secteur). Les journaux IAM, EDR, pare-feu et applicatifs sont centralisés dans un SIEM ou une plateforme XDR.
Détection d’anomalies. Comportements anormaux : volumes de téléchargement atypiques, accès à des ressources hors périmètre, échecs d’authentification en cascade, voyages impossibles. Les modèles de détection (UEBA) s’affinent dans le temps.
Revues trimestrielles. Tous les trois mois, audit de la politique d’accès : comptes dormants, droits accumulés (privilege creep), exceptions devenues permanentes, conformité de la posture. Une politique d’accès non revue se dégrade mécaniquement.
L’amélioration continue est intégrée à la gouvernance cyber : indicateurs (MFA coverage, EDR coverage, comptes à privilèges, temps moyen de révocation), revues de direction, plans d’action.
Indicateurs utiles. Une trajectoire Zero Trust se mesure par des indicateurs concrets, publiés mensuellement au comité de pilotage cyber :
- Taux de couverture MFA sur les comptes humains et machines.
- Taux de couverture EDR sur les endpoints managés.
- Nombre de comptes à privilèges actifs et taux de rotation des secrets.
- Délai moyen de révocation après départ d’un collaborateur.
- Nombre de ressources passées sous broker ZTNA versus exposées via VPN classique.
- Volume d’événements remontés par le SIEM, taux de faux positifs, temps moyen de détection (MTTD), temps moyen de remédiation (MTTR).
Ces indicateurs servent à objectiver la progression et à justifier les budgets. Sans mesure, la trajectoire reste un discours.
Boucle de retour avec les équipes opérationnelles. L’observabilité ne sert pas qu’à la sécurité. Les équipes applicatives, infrastructure et support consomment les mêmes journaux pour identifier les frictions utilisateurs (échecs d’authentification massifs sur une application mal configurée, par exemple). Cette mutualisation des journaux exige une politique d’accès aux logs, elle-même soumise au moindre privilège : les développeurs ne voient que les logs de leur périmètre, les administrateurs IT n’accèdent aux logs RH qu’avec un contrôle de séparation des rôles.
Articulation avec NIS2, DORA, ReCyF
La Directive NIS2 (Directive (UE) 2022/2555) [4] et le règlement DORA (Règlement (UE) 2022/2554) [5] n’imposent pas Zero Trust nommément. Ils imposent des résultats :
- Maîtrise des actifs et des accès (NIS2 art. 21).
- Authentification forte généralisée (NIS2 et DORA).
- Segmentation et chiffrement (NIS2 et DORA).
- Détection et réponse aux incidents (NIS2, DORA, ReCyF en France).
- Continuité d’activité et sauvegardes (DORA, particulièrement détaillé).
Zero Trust n’est pas la seule réponse possible, mais c’est une réponse cohérente, documentée, et reconnue internationalement. Pour les entités OIV/OSE/OES et les entités essentielles NIS2, démontrer une trajectoire Zero Trust facilite les contrôles ANSSI et les audits secteur. Voir également le futur cadre ReCyF (Résilience Cyber et Financière) en cours de transposition.
Pièges fréquents
Quatre échecs récurrents observés en audit :
Le big-bang. Annoncer “on passe en Zero Trust” en six mois est irréaliste. La transformation est itérative, périmètre par périmètre, ressource par ressource. Les organisations qui réussissent commencent par un cas d’usage cible (par exemple, accès des prestataires aux applications métier) et industrialisent ensuite.
L’oubli des serveurs legacy. Le Tier 0 (contrôleurs de domaine, hyperviseurs, sauvegardes) et les serveurs métier anciens (ERP, applications industrielles, automates) sont souvent exclus du chantier Zero Trust. C’est une erreur : ils restent la cible principale des ransomware. Les inclure exige des compromis (proxys, sauts d’authentification, segmentation périmétrique), mais ils sont indispensables.
Le périmètre non documenté. Une politique d’accès dont personne ne connaît les règles, ou dont les justifications historiques sont perdues, se transforme en magma ingérable. La règle : toute exception est documentée, datée, propriétaire identifié, revue annuelle obligatoire.
MFA seul = pas Zero Trust. Déployer la MFA universelle est une étape nécessaire mais insuffisante. Zero Trust suppose également posture des équipements, micro-segmentation, observabilité et politique conditionnelle. Communiquer “nous sommes en Zero Trust” parce qu’on a déployé MFA est une simplification dangereuse, en particulier vis-à-vis des assureurs cyber et des auditeurs.
La politique d’exception non bornée. Toute politique de sécurité génère des exceptions : un fournisseur historique sans MFA, une application legacy incompatible avec SSO moderne, une opération de maintenance ponctuelle. Sans cadrage, ces exceptions deviennent permanentes et minent la politique d’ensemble. La règle minimale : toute exception est tracée, datée, propriétaire identifié, justifiée techniquement, et soumise à revue annuelle obligatoire avec décision documentée (suppression, renouvellement, plan de remédiation).
L’absence de propriétaire de la trajectoire. Zero Trust n’est ni un sujet purement RSSI, ni un sujet purement DSI, ni un sujet purement métier. Sans propriétaire identifié au comité exécutif (souvent le RSSI rattaché à la direction générale ou un sponsor C-level), le sujet se dilue en sous-projets non coordonnés. Un programme Zero Trust crédible suppose une feuille de route, un budget annuel sanctuarisé, des indicateurs partagés et une revue trimestrielle au comité de direction.
Gouvernance et conduite du changement
Au-delà de la technique, deux dimensions sont structurantes pour la réussite.
La conduite du changement utilisateur. Le déploiement MFA, le durcissement des accès et la suppression de privilèges historiques génèrent inévitablement des frictions. La communication doit anticiper : pourquoi ces mesures, quels bénéfices (pour l’utilisateur lui-même, pas seulement pour l’entreprise), quel support disponible. Les déploiements brutaux génèrent des rejets durables et des contournements (mots de passe partagés, équipements personnels non managés).
L’articulation avec la chaîne d’approvisionnement. Les fournisseurs, prestataires et partenaires accèdent souvent à des ressources sensibles. Zero Trust impose de leur appliquer les mêmes règles : MFA, posture, segmentation, journalisation. Cela suppose de revisiter les contrats existants, d’imposer des clauses de sécurité minimales (cohérentes avec NIS2 article 21 sur la chaîne d’approvisionnement) et de prévoir un mécanisme de notification d’incident bilatéral.
À retenir
Zero Trust est un modèle d’architecture, codifié par le NIST SP 800-207, qui supprime la confiance implicite du réseau interne et reporte la décision d’accès sur l’identité, la posture et le contexte. Son déploiement utile passe par cinq étapes : inventaire, identité, micro-segmentation, postures, observabilité. Il s’inscrit dans la durée (18 à 36 mois pour une trajectoire crédible), répond aux exigences NIS2 et DORA sans s’y substituer, et exige une discipline de gouvernance plus qu’un investissement massif en outillage. Le piège principal reste la confusion avec un produit unique ou un projet ponctuel : Zero Trust est une posture permanente.
Sources
[1] NIST, Special Publication 800-207, Zero Trust Architecture, 2020. https://csrc.nist.gov/publications/detail/sp/800-207/final [2] ANSSI, Recommandations relatives à la sécurisation des systèmes d’intermédiation des accès distants. https://www.ssi.gouv.fr/ [3] CNIL, Sécurité : authentifier les utilisateurs. https://www.cnil.fr/fr/securite-authentifier-les-utilisateurs [4] Directive (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj [5] Règlement (UE) 2022/2554 (DORA). https://eur-lex.europa.eu/eli/reg/2022/2554/oj