ZTNA pour la défense : proxy d'identité et moteur de politique

Le VPN de périmètre est le principal contrôle d'accès distant des réseaux de défense depuis trois décennies. Un utilisateur s'authentifie à la passerelle VPN, un tunnel s'établit et l'utilisateur obtient un accès étendu au niveau réseau aux ressources à l'intérieur du périmètre. Ce modèle a été conçu pour un monde où les applications étaient hébergées dans un seul centre de données et où les utilisateurs se connectaient depuis des sites contrôlés par l'organisation. Dans un environnement de défense moderne — où les charges de travail s'étendent du cloud souverain à la périphérie tactique et aux enclaves classifiées isolées, et où les utilisateurs se connectent depuis des appareils gérés et semi-gérés en plusieurs lieux — l'architecture VPN introduit un risque que ses concepteurs n'avaient jamais anticipé. L'accès réseau zero trust (ZTNA) est le remplacement architectural : un accès au niveau application négocié par un proxy conscient de l'identité, conditionné à la vérification continue de qui se connecte et de l'appareil utilisé. Cet article examine la mécanique d'ingénierie du ZTNA pour la défense : comment les signaux d'identité et d'appareil sont collectés et évalués, comment le moteur de politique produit des décisions d'accès et comment déployer le ZTNA sur tout le spectre, des réseaux non classifiés aux enclaves classifiées isolées.

Pourquoi le VPN historique échoue pour le zero trust de défense

Le problème fondamental du VPN dans un contexte de zero trust n'est pas le chiffrement — les tunnels VPN sont sains sur le plan cryptographique. Le problème est ce que le VPN accorde une fois le chiffrement établi. Quand un utilisateur s'authentifie auprès d'une passerelle VPN et que le tunnel monte, l'appareil de l'utilisateur reçoit une adresse réseau à l'intérieur de l'enclave de défense et peut atteindre toute ressource de ce sous-réseau dépourvue de pare-feu distinct au niveau de l'hôte. Le VPN a réalisé un unique événement d'authentification à l'établissement du tunnel et a pris une décision de confiance implicite et soutenue : cet utilisateur et cet appareil peuvent accéder au segment réseau complet pendant toute la durée de la session.

Confiance implicite après authentification. L'authentification VPN est un portail, pas une évaluation continue. Une fois le portail franchi, la confiance n'est plus réévaluée jusqu'à la fin de la session ou l'expiration du délai. Si le compte de l'utilisateur est compromis en cours de session, si l'appareil est infecté par un logiciel malveillant pendant la session, ou si l'utilisateur laisse l'appareil sans surveillance avec un tunnel actif, le VPN continue de fournir un accès au niveau de l'enclave jusqu'à ce qu'un administrateur termine manuellement la session ou que le tunnel expire. Dans un environnement de défense où les sessions s'étendent souvent sur une journée de travail complète, cela représente une fenêtre étendue de risque non détecté.

Rayon d'explosion d'un réseau plat. Un VPN place l'utilisateur sur un segment de réseau. La connectivité est-ouest plate au sein de ce segment signifie qu'une session VPN compromise peut atteindre non seulement l'application visée par l'utilisateur, mais aussi chaque service, base de données et interface de gestion du sous-réseau. L'attaquant qui vole un identifiant VPN obtient une tête de pont avec la même portée réseau que l'utilisateur légitime — ou plus large, car la politique VPN restreint rarement le trafic intra-sous-réseau. C'est le problème du rayon d'explosion : la compromission d'un seul identifiant expose tout le segment de réseau plat.

Incapacité à appliquer une politique d'accès fine. La politique d'accès VPN est grossière : un utilisateur est soit autorisé à se connecter à un profil VPN, soit non. Le profil peut attribuer un VLAN ou un sous-réseau, mais l'application d'une politique par application, par ressource ou par action dans le tunnel n'est pas une capacité du VPN. Le contrôle d'accès dans le tunnel est délégué au propre mécanisme d'authentification de chaque application — dont la rigueur peut varier considérablement au sein du portefeuille applicatif. Le ZTNA déplace la politique d'accès vers un moteur de politique centralisé qui applique des règles cohérentes à toutes les applications, évaluées à chaque demande d'accès plutôt qu'une seule fois à l'établissement de la session. Le concept lié de microsegmentation zero trust de défense traite le mouvement latéral dans le réseau après la décision d'accès, en complément de la couche ZTNA au périmètre.

Architecture ZTNA : modèles par proxy et par agent de terminal

Les implémentations ZTNA se divisent en deux motifs architecturaux principaux selon la façon dont l'interception du trafic est réalisée : le modèle par proxy inverse (sans client) et le modèle par agent de terminal. Les deux modèles partagent une structure logique commune — un point d'application de politique, un courtier d'identité, un service de confiance des appareils et un proxy de session — mais diffèrent par l'endroit où l'interception se produit et par le niveau de visibilité sur l'appareil qu'ils peuvent atteindre.

ZTNA par proxy inverse (sans client)

Dans le modèle par proxy inverse, aucun logiciel n'est installé sur le terminal. Le service ZTNA publie un point de terminaison proxy — typiquement une URL dans le domaine de l'organisation — placé devant chaque application protégée. L'utilisateur navigue vers l'URL du proxy dans un navigateur, s'authentifie à travers le courtier d'identité (en présentant des identifiants CAC/PIV et en complétant la MFA) et reçoit un jeton de session de courte durée. Le proxy valide le jeton à chaque requête et transmet au backend de l'application les requêtes authentifiées et autorisées. L'appareil de l'utilisateur n'est jamais placé sur le réseau de l'application ; seul le proxy dispose d'un chemin réseau vers le backend.

La contrainte principale du modèle sans client est la couverture des protocoles : il fonctionne naturellement pour les applications HTTPS et peut traiter RDP et SSH via des clients navigateur (passerelles RDP/SSH HTML5), mais ne prend pas en charge les protocoles TCP/UDP arbitraires ni les applications à client lourd communiquant par protocoles propriétaires. La visibilité sur la confiance de l'appareil est aussi plus limitée sans agent : le proxy peut inspecter les certificats clients TLS et les chaînes user-agent du navigateur, mais ne peut vérifier l'état de santé EDR ni l'attestation TPM sans l'aide d'un agent local.

ZTNA par agent de terminal

Le modèle par agent installe un démon léger sur le terminal géré. L'agent fonctionne en continu, intercepte le trafic destiné aux adresses des applications protégées (via une carte réseau virtuelle locale ou un filtre de paquets au niveau de l'OS), effectue localement les vérifications de confiance de l'appareil et établit un tunnel chiffré vers le bord de service ZTNA. Le trafic des applications protégées traverse ce tunnel plutôt qu'Internet ouvert ou un VPN. Le backend de l'application reçoit les connexions du proxy ZTNA plutôt que directement du terminal — l'adresse réseau du backend n'est jamais exposée au terminal.

Le ZTNA par agent prend en charge tout protocole d'application, permet des signaux riches de confiance des appareils (intégration EDR, attestation TPM, conformité des correctifs) et autorise le routage en tunnel partagé où seul le trafic des applications protégées traverse le tunnel ZTNA tandis que le trafic Internet général sort directement. Pour les terminaux gérés de défense, le modèle par agent est le choix standard, car les exigences de posture d'appareil pour l'accès aux applications classifiées ne peuvent pas être satisfaites sans la visibilité au niveau d'un agent local.

ZTNA livré depuis le cloud ou ZTNA sur site

Le ZTNA livré depuis le cloud exécute le plan de contrôle et le proxy de session dans un service cloud mutualisé. Ce modèle convient aux programmes non classifiés où les applications sont hébergées dans des environnements cloud commerciaux ou gouvernementaux. Pour les programmes classifiés — IL4, IL5 et IL6 isolé — le plan de contrôle ZTNA doit être déployé dans le périmètre agréé. Le ZTNA sur site place le moteur de politique, le courtier d'identité et le proxy de session à l'intérieur de l'enclave classifiée. Le trafic applicatif ne sort jamais du périmètre classifié. Les dépendances externes du plan de contrôle — validation de certificats, requêtes de santé EDR, recherches auprès du fournisseur d'identité — doivent toutes se résoudre dans le réseau agréé sans accès à Internet.

Signaux d'identité : qui se connecte

Les décisions d'accès ZTNA sont conditionnées par l'identité de l'utilisateur qui se connecte. Pour le personnel de défense, la vérification d'identité s'ancre sur le titre physique délivré par le système du personnel de l'organisation — la carte à puce CAC ou PIV — et est enrichie par les attributs de rôle et de groupe issus de l'annuaire.

Vérification des certificats CAC/PIV

La CAC (Common Access Card) et la carte PIV (Personal Identity Verification) portent un certificat d'identité X.509 émis par la PKI agréée de l'organisation. La vérification de certificats ZTNA comprend : la présentation du certificat au courtier d'identité ZTNA via l'authentification client TLS ; la validation de la chaîne de certificats par rapport à l'ancre de confiance agréée (les CA racine et intermédiaires du magasin de confiance de l'organisation) ; la vérification du certificat auprès de la liste de révocation des certificats (CRL) ou du répondeur OCSP pour confirmer qu'il n'a pas été révoqué ; et l'extraction du nom distinctif du sujet ou de l'UPN du certificat pour identifier le principal utilisateur.

La disponibilité des CRL et d'OCSP dans un environnement isolé est un point de défaillance opérationnelle fréquent. Si le point de distribution des CRL n'est joignable que depuis le réseau non classifié et que le déploiement ZTNA se trouve sur un réseau classifié, les vérifications de révocation échouent ou expirent. Les déploiements ZTNA isolés exigent un proxy de mise en cache des CRL dans le périmètre classifié, qui synchronise périodiquement les mises à jour des CRL via le mécanisme de transfert inter-domaines.

Authentification multifacteur pour l'accès ZTNA

La saisie du code PIN de la CAC satisfait l'exigence MFA « quelque chose que vous possédez plus quelque chose que vous savez » pour la plupart des programmes. Cependant, les applications désignées comme très sensibles peuvent exiger un facteur supplémentaire au-delà de la CAC — un code TOTP, une notification push vers une application d'authentification enregistrée ou une clé de sécurité matérielle. Le moteur de politique ZTNA peut appliquer des exigences de palier MFA par application : CAC-PIN standard pour les applications générales, CAC-PIN plus TOTP pour les applications sensibles de commandement et un flux d'approbation hors bande à durée limitée pour l'accès administratif privilégié. Cette hiérarchisation MFA par application est inatteignable avec une politique VPN plate.

Intégration du fournisseur d'identité : LDAP et Active Directory

L'authentification par certificat identifie le principal utilisateur mais ne porte ni le rôle ni l'appartenance aux groupes actuels — ceux-ci sont gérés dans l'annuaire et peuvent changer indépendamment de l'émission des certificats. Le moteur de politique ZTNA interroge le fournisseur d'identité — LDAP ou Active Directory — au moment de chaque demande d'accès pour résoudre les appartenances aux groupes et les attributions de rôles actuelles de l'utilisateur. Les attributs résolus deviennent des entrées de politique : un utilisateur doit être membre du groupe Active Directory « analysts-secret » pour accéder à l'application classifiée d'analytique, quel que soit ce que dit son certificat. Si l'utilisateur est retiré du groupe dans Active Directory, sa prochaine demande d'accès à l'application d'analytique est refusée par le moteur de politique ZTNA, sans nécessiter de révocation de certificat ni de changement de politique VPN. Ce contrôle d'accès fondé sur les attributs, adossé à des requêtes d'annuaire en temps réel, est une capacité fondamentale de la gouvernance d'identité que les organisations de défense appliquent pour resserrer le cycle de vie du contrôle d'accès.

Signaux de confiance des appareils : quel appareil se connecte

L'identité de l'utilisateur est une condition nécessaire mais insuffisante pour l'accès dans un modèle ZTNA de défense. Un utilisateur légitime sur un appareil compromis ou non conforme présente un risque que l'identité seule ne peut pas atténuer. L'évaluation de la confiance des appareils collecte et évalue des signaux sur l'appareil qui se connecte, indépendamment de l'affirmation d'identité de l'utilisateur.

Certificat d'appareil

Le premier signal de confiance d'appareil est le certificat machine : un certificat émis par la PKI des appareils de l'organisation vers le terminal au moment de son enrôlement. Le certificat machine prouve que l'appareil a été enrôlé par un système MDM ou de gestion des appareils autorisé et qu'il était alors un actif géré. L'agent ZTNA présente le certificat d'appareil avec le certificat utilisateur à l'établissement de la session. Le moteur de politique valide la chaîne du certificat d'appareil par rapport à l'ancre de confiance de la PKI des appareils, vérifie l'état de révocation et confirme que l'identifiant d'appareil du certificat correspond à l'identité d'appareil enregistrée dans l'inventaire MDM.

État de santé EDR

L'agent de détection et réponse sur les terminaux (EDR) qui s'exécute sur l'appareil maintient une évaluation en temps réel de l'état de menace de l'appareil. L'agent ZTNA interroge l'agent EDR local ou l'API de la plateforme de gestion EDR pour une attestation de santé : l'agent EDR fonctionne-t-il, sa base de renseignements sur les menaces est-elle à jour, et y a-t-il des menaces actives en quarantaine ou en cours de remédiation ? Un appareil dont la base de signatures EDR est périmée est effectivement aveugle aux familles de menaces récentes — la politique ZTNA doit traiter un tel appareil comme non conforme et soit refuser l'accès, soit le restreindre à un palier d'accès limité en attendant la mise à jour EDR. Un événement de quarantaine de menace active pendant une session déclenche un événement d'évaluation continue qui peut entraîner la suspension immédiate de la session.

Vérification de conformité des correctifs

Le niveau de correctifs du système d'exploitation et des applications est interrogé depuis la plateforme MDM ou depuis l'inventaire local des correctifs installés de l'agent ZTNA. Le moteur de politique ZTNA compare l'état des correctifs de l'appareil à un minimum défini : par exemple, toutes les CVE critiques et de haute gravité publiées au cours des 30 derniers jours doivent être corrigées avant que l'accès aux applications classifiées ne soit permis. Les appareils en retard de correctifs sont redirigés vers un avis de remédiation plutôt que vers l'application demandée. La vérification de conformité couvre aussi les applications tierces de l'inventaire logiciel géré de l'appareil — un navigateur web ou un lecteur PDF non corrigé sur un appareil géré représente un vecteur d'exploitation, même si l'OS est entièrement corrigé.

Attestation matérielle via TPM 2.0

Pour les terminaux gérés de défense équipés d'un module TPM 2.0, l'agent ZTNA peut demander une citation d'attestation TPM — une mesure signée cryptographiquement de la chaîne de démarrage de l'appareil, produite par le TPM et vérifiable par rapport à un manifeste de référence connu comme sain. L'attestation prouve que l'appareil a démarré depuis une image de micrologiciel et d'OS autorisée et que la chaîne de démarrage n'a pas été altérée depuis la dernière attestation. Ce contrôle sert à détecter les logiciels malveillants de bas niveau — rootkits et bootkits qui persistent sous l'OS et que ne détecterait pas un agent EDR au niveau OS. L'attestation TPM exige que le plan de contrôle ZTNA détienne un manifeste de référence pour chaque modèle d'appareil du parc géré ; le manifeste est renseigné pendant l'enrôlement de l'appareil et mis à jour lorsque des changements autorisés de micrologiciel sont déployés.

Moteur d'évaluation continue des politiques

Le moteur de politique est le cœur décisionnel de l'architecture ZTNA. Il reçoit les demandes d'accès — du proxy de session quand un utilisateur initie une connexion, et de la boucle d'évaluation continue pendant toute la session active — et renvoie une décision d'accès : autoriser, refuser ou exiger une authentification renforcée (step-up) avant d'autoriser.

Politique sous forme de code avec OPA et Rego

Les déploiements ZTNA de défense gagnent à exprimer la politique d'accès sous forme de code plutôt qu'en règles configurées dans une interface graphique. Open Policy Agent (OPA) avec le langage de politique Rego est le cadre dominant pour ce motif. Une politique Rego pour le ZTNA encode déclarativement toutes les conditions d'accès : les groupes d'utilisateurs requis, le niveau minimal de conformité de l'appareil, les heures d'accès permises, le palier MFA requis et le seuil de score de risque. Les politiques sont versionnées dans un dépôt source, examinées via le même processus de contrôle des changements que le code applicatif, et déployées vers le moteur OPA par un pipeline CI/CD. Chaque changement de politique a un auteur, un dossier de revue, un horodatage de déploiement, et peut être ramené à une version antérieure par une simple inversion de pipeline. Cette auditabilité est un avantage matériel par rapport aux règles de pare-feu par application qui s'accumulent sans contrôle de version.

Décisions d'accès sensibles au contexte

Les décisions de politique ZTNA peuvent intégrer des signaux contextuels au-delà de l'identité et de la confiance des appareils. La politique d'horaire d'accès restreint l'accès aux applications sensibles à des fenêtres de travail définies, réduisant la fenêtre d'exposition à un usage détourné d'identifiants hors des heures normales de travail. La politique de géolocalisation ou de source réseau — d'où l'utilisateur se connecte — peut être évaluée par le moteur de politique : une application classifiée peut ne permettre l'accès que depuis des points de sortie réseau gérés par l'organisation ou depuis des lieux d'accès distant spécifiquement approuvés. L'intégration d'un score de risque permet au moteur de politique de consommer un signal de risque numérique produit par une plateforme d'analyse comportementale des utilisateurs et entités (UEBA) : si le schéma d'accès de l'utilisateur des 24 dernières heures a produit un score de risque d'anomalie élevé, le moteur relève le seuil d'accès et exige une MFA renforcée avant d'autoriser l'accès aux applications sensibles.

Réévaluation des risques de session

Le contrôle d'accès traditionnel décide au démarrage de la session et n'y revient pas. L'évaluation continue ZTNA réévalue la décision d'accès pendant toute la session, à un intervalle d'interrogation configurable. La boucle d'évaluation interroge le fournisseur d'identité sur les changements d'état du compte (verrouillage de compte ou révocation de groupe depuis le début de la session), la plateforme EDR sur les nouveaux événements de menace sur l'appareil, le service de conformité des appareils sur les changements de statut des correctifs et le service de notation des risques sur les changements de score d'anomalie. Quand un changement franchit un seuil de politique, le moteur répond proportionnellement : une hausse de risque modérée déclenche un défi MFA renforcée sans terminer la session ; un événement critique — verrouillage de compte, menace EDR active, révocation de certificat — déclenche la terminaison immédiate de la session. Le modèle d'évaluation continue fait qu'un attaquant qui compromet un appareil en cours de session affronte une fenêtre de détection bornée par l'intervalle d'interrogation plutôt que par toute la durée de la session. Les mêmes principes qui régissent les programmes de gestion des accès privilégiés de défense — accès juste-à-temps, enregistrement de session et réévaluation des risques en temps réel — s'appliquent directement à la conception de l'évaluation continue ZTNA pour les sessions à haut privilège.

ZTNA pour réseaux classifiés : déploiement IL4/IL5

Les services ZTNA commerciaux livrés depuis le cloud opèrent dans une infrastructure mutualisée non autorisée pour les charges de travail classifiées. Les programmes de défense opérant aux niveaux d'impact IL4 (renseignements non classifiés contrôlés) et IL5 (systèmes de sécurité nationale) exigent un modèle de déploiement ZTNA qui maintient les opérations du plan de contrôle et le trafic applicatif dans le périmètre agréé.

ZTNA sur site pour environnements classifiés isolés

Un déploiement ZTNA sur site pour un réseau classifié réplique les composants fonctionnels d'un service ZTNA cloud à l'intérieur de l'enclave classifiée. Le moteur de politique, le courtier d'identité, le proxy de session et le service de confiance des appareils sont tous déployés comme charges de travail de calcul sur site — soit sur du matériel dédié, soit dans le cluster Kubernetes classifié. Toutes les dépendances du plan de contrôle se résolvent dans l'enclave : le fournisseur d'identité est l'instance Active Directory classifiée, la console de gestion EDR est déployée sur site, l'autorité de certification et le service de CRL opèrent dans l'isolement, et aucun appel d'évaluation de politique ne sort du périmètre du réseau classifié.

Le défi opérationnel propre au ZTNA isolé est la distribution des mises à jour de politique. Dans un service ZTNA cloud, les changements de politique sont déployés centralement et se propagent en quelques secondes. Dans un environnement isolé, les mises à jour de politique doivent être acheminées par le mécanisme autorisé de transfert de logiciel — typiquement un processus de transfert de supports à travers le périmètre d'accréditation. Cela signifie que les changements de politique ZTNA exigent une planification à l'avance et ne peuvent pas être appliqués avec la latence inférieure à la minute disponible dans les déploiements cloud. Le processus de contrôle des changements de la politique ZTNA isolée doit tenir compte de ce délai, et les changements de politique d'urgence (par exemple, la révocation immédiate de l'accès d'un utilisateur compromis) doivent disposer d'un chemin accéléré dans le processus de contrôle des changements défini dans le plan de sécurité du programme.

Conception d'un proxy ZTNA inter-domaines

Certains cas d'usage de défense exigent que des utilisateurs d'un réseau de classification inférieure accèdent à une vue spécifique et filtrée de données produites par un système de classification supérieure — une image opérationnelle assainie, un résumé de renseignement déclassifié ou un flux de données en lecture seule. Un proxy ZTNA inter-domaines y répond en combinant le contrôle d'accès ZTNA avec l'inspection de contenu inter-domaines à la frontière de classification. Le proxy reçoit la demande d'accès de l'utilisateur depuis le réseau non classifié, vérifie l'identité et la confiance de l'appareil auprès du moteur de politique ZTNA non classifié, puis interroge l'application classifiée au nom de l'utilisateur à travers la solution inter-domaines. Le composant CDS inspecte le contenu de la réponse de l'application, applique les règles de diffusion propres à la classification des données et filtre ou caviarde les éléments non autorisés pour une diffusion au demandeur non classifié. Seule la réponse filtrée est renvoyée à la session de l'utilisateur sur le réseau non classifié. Le proxy doit être agréé dans le cadre des ATO des deux réseaux et de l'autorisation inter-domaines, l'architecture ZTNA + CDS étant explicitement décrite comme un contrôle combiné.

Migration du VPN historique vers le ZTNA

La migration VPN-vers-ZTNA dans un programme de défense est une transition opérationnelle qui doit préserver la continuité d'accès aux applications critiques pour la mission tout en resserrant progressivement le contrôle d'accès. Une stratégie de migration par phases qui fait tourner VPN et ZTNA en parallèle pendant la période de transition est l'approche standard.

Stratégie de migration par phases

La migration se déroule en trois phases. Dans la première, l'infrastructure ZTNA est déployée et validée pour l'intégration d'identité et de confiance des appareils, mais aucune application n'est intégrée et les utilisateurs continuent d'accéder à toutes les applications par VPN. Un groupe pilote — typiquement l'équipe informatique et sécurité — teste l'accès ZTNA à une application de faible criticité pour valider le flux de bout en bout avant d'impliquer les utilisateurs de mission. Dans la deuxième phase, les applications sont intégrées au ZTNA par ordre de priorité. Pendant cette phase, le VPN reste disponible en repli pour les applications non encore intégrées. Les utilisateurs sont formés au portail d'accès ZTNA et à l'agent avant que leurs applications principales ne passent au ZTNA. Dans la troisième phase, une fois toutes les applications du périmètre intégrées et l'accès validé par la population pilote, l'accès VPN est révoqué pour la population d'utilisateurs migrée. La passerelle VPN reste disponible uniquement pour les applications exclues du périmètre ZTNA (s'il y en a) pendant la phase finale, puis est décommissionnée quand les applications restantes achèvent leur intégration.

Séquence d'intégration des applications

Les applications sont intégrées au ZTNA dans une séquence conçue pour minimiser le risque et tirer les leçons des premières intégrations avant d'aborder les cas complexes. Commencez par les portails et tableaux de bord internes — des applications HTTPS à interfaces navigateur qui fonctionnent naturellement avec le ZTNA par proxy inverse et qui ont de larges populations d'utilisateurs capables de donner un retour rapide. Passez ensuite aux applications de productivité : interfaces web de messagerie, portails de gestion documentaire, wikis internes. Abordez ensuite les catégories qui exigent le modèle par agent : serveurs Windows accédés par RDP, systèmes Linux accédés par SSH, applications C2 ou de mission à client lourd. Réservez pour la fin les intégrations les plus complexes : applications à mécanismes d'authentification non standards, systèmes temps réel de haute criticité, et toute application qui repose aujourd'hui sur un contrôle d'accès VPN par IP plutôt que sur une authentification de couche application.

Formation des utilisateurs aux schémas d'accès ZTNA

L'expérience utilisateur du ZTNA diffère matériellement de celle du VPN. Les utilisateurs habitués au VPN se connectent une fois en début de journée et accèdent transparentment à toutes les applications le reste de la journée. Avec le ZTNA, l'utilisateur accède aux applications par le portail ZTNA ou via des connexions interceptées par l'agent, et peut rencontrer des défis MFA renforcée dans la journée si l'évaluation continue détecte un changement de risque. La formation doit couvrir trois changements de comportement. Premièrement, le portail d'accès : où naviguer pour trouver les applications et comment s'authentifier par CAC. Deuxièmement, l'agent : comment l'agent ZTNA apparaît dans la barre système, ce que signifient ses indicateurs d'état et comment signaler les problèmes. Troisièmement, l'authentification renforcée : à quoi ressemble un défi MFA en cours de session (pour que les utilisateurs ne prennent pas une invite légitime pour une tentative d'hameçonnage) et comment le compléter. Les programmes qui investissent dans la formation des utilisateurs avant d'intégrer le premier utilisateur de mission constatent des volumes de tickets au support nettement plus faibles et une adoption plus rapide que les programmes qui déploient le ZTNA sans plan de formation.