Comment implémenter le Zero Trust sans perturber vos opérations

Au Royaume-Uni, 98 % des organisations affirment qu'elles prévoient de mettre en œuvre ou ont déjà mis en œuvre le zero trust, mais seulement 15 % signalent une mise en œuvre complète. L'écart n'est pas une question de sensibilisation. C'est une question d'exécution. Les recherches britanniques sur le zero-trust montrent que de nombreuses équipes ont commencé à planifier des projets de segmentation ou d'identité isolés sans connecter ces contrôles au sein d'un modèle d'exploitation unique.

La question pratique n'est pas de savoir si le zero trust est important, mais plutôt comment mettre en œuvre le zero trust sans interrompre les services en direct, frustrer les utilisateurs ou créer une énième collection de produits de sécurité déconnectés. La réponse consiste à séquencer la migration autour de l'identité, de l'état de l'appareil, du cycle de vie de l'annuaire, du WiFi sécurisé, de la segmentation et de la vérification continue.

Pourquoi la mise en œuvre du Zero Trust stagne dans les entreprises

51 % des organisations en sont encore au stade de la planification initiale, tandis que seulement 15 % revendiquent une mise en œuvre complète, et 80 % ont été confrontées à des obstacles techniques ou opérationnels. Le rapport sur les organisations britanniques montre l'écart entre le choix d'une orientation et l'exploitation des contrôles requis. Les équipes commencent souvent par des projets isolés, puis découvrent que l'identité, les appareils, les annuaires, les applications et les réseaux dépendent les uns des autres.

Le zero trust élimine la confiance inhérente aux systèmes, réseaux et services. Une connexion interne ne doit pas fournir un accès large. Un ancien compte ne doit pas conserver de permissions une fois que la personne ou le fournisseur n'en a plus besoin. Un service ne doit pas rester fiable indéfiniment parce qu'il a réussi un seul contrôle d'authentification.

Le National Cyber Security Centre du Royaume-Uni présente le zero trust comme une migration par étapes, et non comme l'achat d'un produit. Son guide d'architecture définit huit principes de conception, notamment des décisions d'accès basées sur l'identité et des communications protégées. La collection zero-trust du NCSC a été publiée en 2021, et ses conseils de mise en œuvre ont été enrichis en septembre de la même année. Les principes de conception d'architecture du NCSC sont utiles car ils obligent les équipes à stabiliser l'architecture et les décisions relatives à la confiance avant de choisir la technologie.

Le mode d'échec axé uniquement sur le produit

Le schéma d'échec commence généralement par l'achat d'une plateforme. Une équipe déploie un produit d'identité, un outil de segmentation ou une passerelle ZTNA, puis s'aperçoit que les comptes de service, les appareils non gérés, les applications existantes, l'authentification WiFi et le retrait des annuaires n'ont jamais été cartographiés.

Le résultat est une liste d'exceptions qui ne cesse de s'allonger. Les utilisateurs reçoivent des solutions de contournement, les administrateurs conservent des identifiants partagés et les équipes de sécurité ne peuvent pas savoir si la politique est appliquée de manière cohérente. Le WiFi expose rapidement cette faiblesse. La segmentation du réseau peut séparer le trafic, mais elle ne crée pas d'accès basé sur l'identité si les utilisateurs se connectent toujours via des mots de passe partagés ou si les appareils restent inconnus. Le WiFi sans mot de passe avec authentification par certificat, lié aux enregistrements d'appareils et au statut de l'annuaire, fournit à la politique un signal d'identité fiable. La révocation automatique de l'annuaire devrait ensuite supprimer l'accès lorsqu'un compte est désactivé, plutôt que d'attendre un nettoyage manuel.

Les contrôles de périmètre traditionnels ont toujours un rôle à jouer, mais ils ne peuvent pas répondre à toutes les questions d'accès. L'article sur les raisons de l'échec de la sécurité informatique traditionnelle explique comment les services cloud, l'accès distant et les appareils distribués affaiblissent l'hypothèse selon laquelle un réseau interne est automatiquement sécurisé.

Règle pratique : N'écrivez pas de politique d'application avant de savoir quelles dépendances d'identité, d'appareil, de WiFi et de service la politique pourrait interrompre.

Une migration exploitable suit cet ordre :

• Découvrez le parc : Identifiez les utilisateurs, les appareils, les applications, les services et les flux de données.
• Définissez les limites : Décidez quels réseaux et ressources nécessitent une isolation et quels chemins d'accès sont légitimes.
• Construisez le plan de contrôle : Connectez l'identité, le MFA, l'accès aux appareils basé sur des certificats, les vérifications de conformité et le cycle de vie de l'annuaire.
• Appliquez à la périphérie : Appliquez la politique aux applications, aux réseaux et au WiFi, et pas seulement aux sessions VPN.
• Observez et étendez : Commencez par des charges de travail contrôlées, examinez les décisions d'accès et étendez progressivement le modèle.

Cette séquence fait du zero trust un modèle opérationnel plutôt qu'une simple collection d'outils. Elle permet également aux équipes opérationnelles de préserver la disponibilité pendant que les contrôles d'identité, le WiFi sécurisé et la segmentation gagnent en maturité.

Poser les bases avec la découverte et les limites de confiance

Commencez par un inventaire qui reflète le fonctionnement réel de l'organisation, et non ce qu'indique le schéma réseau. Le NCSC recommande d'identifier les utilisateurs, les autorisations requises, les appareils et les services, puis de concevoir la gestion des identités et des accès en fonction de ces résultats. Le guide de migration du NCSC conseille également aux équipes de cartographier les dépendances héritées et de modéliser les menaces de l'architecture proposée avant le déploiement.

Le résultat doit être un catalogue actif, non un tableur statique. Enregistrez le propriétaire, l'objectif commercial, la méthode d'authentification, les dépendances, la sensibilité des données, les utilisateurs attendus et l'impact en cas de panne pour chaque ressource importante.

Créer quatre inventaires

Les utilisateurs et les identités passent en premier. Cela inclut les employés, les prestataires, les administrateurs privilégiés, les comptes de service et les identités d'automatisation. Séparez le statut professionnel d'une personne de son besoin d'accès. Un prestataire peut avoir besoin d'accéder à une application pour une période définie, tandis qu'un compte de service peut nécessiter une authentification machine sans connexion interactive.

Les appareils ont besoin de leur propre classification. Enregistrez les ordinateurs portables gérés, les appareils mobiles, les terminaux partagés, les imprimantes, les caméras, les systèmes de bâtiment et autres équipements IoT. Notez quels appareils prennent en charge les certificats, le chiffrement moderne et les rapports de posture. Les équipements existants ne peuvent souvent pas répondre aux exigences d'authentification du personnel, ils nécessitent donc une stratégie de confinement explicite plutôt qu'une exception non suivie.

Les applications et services doivent être cartographiés en fonction de leurs exigences d'identité et de transport. Documentez si chaque application prend en charge le SSO, le MFA, les protocoles modernes, les certificats, l'accès par proxy ou uniquement un identifiant et un mot de passe hérités. Identifiez les annuaires amont, les bases de données, les services DNS, les API et les dépendances de journalisation.

Les flux de données et les parcours métiers révèlent les limites de confiance. Cartographiez la façon dont un membre du personnel accède à un système clinique, comment un prestataire accède à un portail de maintenance, ou comment un terminal de point de vente communique avec les services approuvés. Un segment n'a pas de sens si une dépendance non documentée impose un accès sans restriction à travers celui-ci.

Définir les limites avant les politiques

Une limite de confiance doit répondre à trois questions : ce qui est protégé, qui a besoin d'accès et sous quelles conditions. Les conditions peuvent inclure l'assurance de l'identité, la santé de l'appareil, le contexte réseau, la sensibilité de l'application et l'approbation limitée dans le temps.

Le WiFi invité, l'IoT et les sites multi-locataires méritent une attention particulière. Les invités ne doivent jamais dépendre des identifiants réseau du personnel. Les appareils IoT doivent communiquer uniquement avec les services requis pour leur fonction. Les locataires peuvent partager une infrastructure physique tout en conservant une isolation logique et une gestion distincte des identités.

La sécurité du transport est importante à chaque frontière. Si l'équipe a besoin d'un rappel en langage clair sur les certificats, le chiffrement et la confiance des navigateurs, le guide d'Adwave Digital sur le SSL est une référence utile avant de documenter les hypothèses de transport applicatif et WiFi.

Terminez la phase de découverte par une modélisation des menaces. Testez ce qui se passe si un compte d'annuaire est compromis, si un appareil géré devient non conforme, si un certificat est révoqué, si un contrôleur sans fil est indisponible ou si un service hérité ne peut pas s'authentifier auprès du nouveau fournisseur d'identité. Ces scénarios de défaillance doivent orienter l'ordre de déploiement.

Faire de l'identité et de la posture des appareils votre plan de contrôle

Les décisions zero trust nécessitent une source unique de vérité. Dans la plupart des parcs informatiques, cela implique de sélectionner l'annuaire qui régit les personnes, les groupes et les événements du cycle de vie, tel que Microsoft Entra ID, Google Workspace ou Okta. Le choix de conception le plus important n'est pas seulement la marque. C'est la capacité de chaque système d'accès à consommer le même état d'identité et à réagir lorsque cet état change.

Un utilisateur qui quitte l'organisation doit perdre ses accès partout où cela compte. Un prestataire dont la mission se termine ne doit pas rester actif dans un système sans fil parce qu'un administrateur a oublié de supprimer un compte distinct. Le provisionnement et la révocation automatiques font des changements d'annuaire des contrôles opérationnels plutôt que des rappels administratifs.

Authentifier la personne et l'appareil

Commencez par le SSO et le MFA pour les applications professionnelles. Le MFA renforce l'assurance, tandis que le SSO réduit le nombre d'identifiants que les utilisateurs et les centres de services doivent gérer. Le NCSC recommande spécifiquement de concevoir l'IAM autour du MFA et d'envisager une authentification sans mot de passe lorsque cela est approprié. Les méthodes sans mot de passe peuvent améliorer à la fois la sécurité et l'ergonomie, mais elles nécessitent des procédures de récupération, des contrôles d'enregistrement des appareils et une assistance pour les utilisateurs qui perdent l'accès à leur authentificateur principal.

Pour le WiFi du personnel, l'authentification basée sur les certificats est généralement plus robuste sur le plan opérationnel que les mots de passe partagés. Avec le WPA2 ou le WPA3-Enterprise et le 802.1X, le réseau peut lier l'accès à une identité enregistrée ou à un certificat d'appareil. Cela évite d'avoir à distribuer une clé commune et permet une révocation précise.

La posture de l'appareil apporte la seconde moitié de la décision. Vérifiez si l'appareil est géré, chiffré, mis à jour, conforme et utilise un certificat approuvé. Un utilisateur valide sur un ordinateur portable non géré ne doit pas automatiquement recevoir le même accès que cet utilisateur sur un appareil d'entreprise sain.

L'identité prouve qui demande l'accès. La posture de l'appareil détermine si cette demande d'accès est suffisamment sûre pour être approuvée.

Concevoir les événements du cycle de vie, pas seulement la connexion

L'intégration doit créer l'identité dans l'annuaire, attribuer les bons groupes, enregistrer l'appareil et délivrer le certificat requis via un flux de travail automatisé. La désinscription doit désactiver l'identité, révoquer les sessions et les certificats, et supprimer l'accès au réseau sans attendre l'intervention d'un administrateur WiFi distinct.

Les prestataires ont besoin d'un parcours différent. Attribuez-leur une appartenance à un groupe au périmètre restreint, un processus d'expiration ou d'approbation, et un accès uniquement aux applications et aux segments de réseau requis par leur travail. Ne facilitez pas la vie des prestataires en les plaçant sur un réseau général destiné au personnel.

Les appareils hérités ont besoin d'être confinés. Lorsqu'une imprimante, un capteur ou un terminal spécialisé ne peut pas utiliser l'authentification basée sur des certificats, utilisez un segment dédié, des règles de pare-feu étroitement définies et un mécanisme d'identité contrôlé tel qu'une clé pré-partagée individuelle. Cela permet de garder l'exception visible et de limiter son rayon d'action.

Les équipes qui évaluent l'accès réseau lié à l'identité peuvent examiner le concept de réseau basé sur l'identité comme modèle de mise en œuvre. Le principe architectural reste le même, quelle que soit la plateforme : le statut de l'annuaire, la force de l'authentification et l'état de l'appareil doivent influencer conjointement la décision d'accès.

La segmentation et le WiFi sécurisé qui appliquent les politiques

La segmentation est nécessaire, mais elle ne peut pas à elle seule imposer un accès basé sur l'identité. 92 % des organisations britanniques interrogées déclarent segmenter leurs réseaux dans une certaine mesure, tandis que 98 % affirment qu'elles prévoient de mettre en œuvre ou ont déjà mis en œuvre le zero trust. L'étude menée au Royaume-Uni indique que le zonage du réseau est largement répandu, mais que l'assurance de l'identité, la vérification continue et l'application des politiques nécessitent encore une attention particulière.

Un VLAN sépare le trafic. Il ne décide pas si une personne, un appareil ou une session doit conserver son accès. Si un utilisateur passe d'un ordinateur portable conforme à un appareil non géré, l'appareil peut rester dans le même segment à moins que le système d'accès n'évalue à nouveau l'identité et la posture.

Comparer les niveaux de maturité

Zone de Contrôle	Implémentation Partielle	Maturité Zero Trust
Conception du réseau	Des VLAN ou de larges zones séparent les invités, le personnel et les appareils	Des politiques ultra-précises restreignent l'accès à des ressources et des flux spécifiques
Authentification WiFi	Mots de passe partagés, Captive Portals ou clés statiques	WPA2 ou WPA3-Enterprise, 802.1X et accès basé sur des certificats ou sur l'identité
Cycle de vie de l'utilisateur	Les administrateurs créent et suppriment les comptes manuellement	Les modifications d'annuaire provisionnent et révoquent l'accès automatiquement
Assurance de l'appareil	Un appareil se connecte s'il possède les bons identifiants réseau	L'état de santé de l'appareil et l'état du certificat influencent chaque décision d'accès
Réponse aux politiques	L'accès reste actif jusqu'à ce qu'une session ou un compte soit modifié manuellement	Les changements de contexte déclenchent une réévaluation, une restriction ou une révocation
Visibilité	Les journaux du contrôleur affichent les événements de connexion	Les événements d'identité, d'appareil, de politique et de ressource sont corrélés pour examen

Traiter le WiFi comme une limite d'identité

Le WiFi est souvent la première décision d'accès d'entreprise à laquelle un appareil est confronté. Attendre la fin du programme pour s'en préoccuper crée un écart entre la politique de l'annuaire et la connectivité physique.

Pour le personnel, utilisez WPA2 ou WPA3-Enterprise avec 802.1X, s'appuyant sur des certificats ou une autre méthode d'identité forte. Le WiFi sans mot de passe élimine les secrets partagés de l'expérience utilisateur, tandis que l'authentification par certificat lie la connectivité à une identité et un appareil enregistrés. Passpoint et OpenRoaming peuvent prendre en charge l'itinérance sécurisée en permettant à un appareil enregistré de s'authentifier sans saisir de mot de passe à plusieurs reprises.

L'objectif est d'obtenir une connectivité chiffrée et liée à l'identité dès le premier paquet. Un Captive Portal qui accorde un accès étendu après acceptation des conditions par l'utilisateur ne permet pas ce niveau de contrôle.

Pour un examen pratique de la sécurité WiFi d'entreprise, évaluez la distribution des certificats, l'intégration des fournisseurs d'identité, la gestion de la révocation et la compatibilité des contrôleurs. L'architecture doit fonctionner sur l'ensemble du parc, y compris les équipements Meraki, Aruba, Ruckus, Mist ou UniFi.

Les invités ont besoin d'une expérience et d'une politique distinctes. Offrez un accès internet sans les privilèges du personnel. Les appareils IoT nécessitent des politiques restreintes qui autorisent uniquement les destinations et les services requis pour leur fonctionnement.

Réévaluer l'accès en continu

Le NCSC met en avant la réévaluation continue, l'observabilité et la résilience comme des exigences zero-trust explicites. Ses conseils de mise en œuvre du ZTNA préconisent de modifier l'accès lorsque le contexte change, plutôt que de laisser les autorisations figées pour la durée d'une session.

L'intégration de l'annuaire doit prendre en charge la révocation automatique. Un compte désactivé, la suppression de l'appartenance à un groupe ou un certificat révoqué doivent déclencher des mises à jour de politiques de sécurité sans attendre l'intervention d'un administrateur WiFi distinct. Le résultat peut être une authentification renforcée, un transfert vers un réseau restreint, le blocage d'une application ou la révocation immédiate de l'accès.

La segmentation limite l'incident. L'identité, l'état de conformité de l'appareil et la télémétrie en temps réel déterminent si l'accès est maintenu. Cette combinaison comble le fossé entre la séparation réseau et un véritable contrôle basé sur l'identité.

Déployer la surveillance et vérifier chaque décision d'accès

Un déploiement sûr est contrôlé, observable et réversible. Ne commencez pas par appliquer une nouvelle politique à chaque utilisateur, site et catégorie d'appareil. Sélectionnez un groupe ou un site à faible risque qui contient tout de même assez de complexité réelle pour révéler les problèmes, puis validez le chemin d'accès avant de l'étendre.

Commencez en mode surveillance là où la technologie le permet. Capturez ce que la politique autoriserait et refuserait, comparez ces décisions avec les exigences de l'entreprise et examinez les dépendances inconnues. Le mode surveillance ne remplace pas l'application des règles. C'est un moyen d'éliminer les surprises évitables avant que l'application ne touche la production.

Utiliser une migration par étapes

Voici à quoi ressemble une séquence pratique :

1. Choisissez un pilote limité : Sélectionnez une application, un site ou un groupe d'utilisateurs à faible risque, disposant d'un responsable identifié et d'une procédure d'assistance claire.
2. Enregistrez la référence de base : Capturez les authentifications réussies et échouées, l'état de conformité de l'appareil, le statut du certificat, l'affectation réseau, le résultat de la politique et le comportement de l'application.
3. Testez les chemins de refus : Confirmez que le MFA échoué, les certificats révoqués, les identités désactivées dans l'annuaire et les appareils non conformes sont bien bloqués.
4. Appliquez de manière restrictive : Appliquez la politique au pilote, avec une condition de retour arrière documentée et un administrateur capable d'annuler le changement.
5. Déployez par dépendance : Ajoutez des groupes, des sites ou des services uniquement après que l'étape précédente présente des journaux stables et un processus d'assistance validé.

Le projet pilote doit inclure des tests de défaillance. Désactivez une identité de test, supprimez son adhésion à un groupe, marquez un appareil comme non conforme et révoquez son certificat. Confirmez que l'accès au réseau, l'accès aux applications et les sessions actives réagissent comme prévu.

Rendre la télémétrie utile

Collectez des événements qui expliquent les décisions, et pas seulement des événements qui prouvent qu'une connexion a eu lieu. Au minimum, corrélez l'identité requérante, l'identifiant de l'appareil, le résultat de l'authentification, l'état du certificat, le résultat de la posture, le segment réseau, la ressource de destination, la version de la politique et la décision finale.

Recherchez les schémas qui nécessitent une révision humaine :

• Utilisation d'identité suspecte : Un utilisateur accède à une ressource en dehors de son rôle habituel ou de son groupe approuvé.
• Changements de posture : Un appareil auparavant conforme perd son statut de gestion, de chiffrement ou de certificat.
• Échecs répétés : Des échecs d'authentification ou de posture surviennent sur plusieurs comptes ou emplacements.
• Exceptions aux politiques : Un appareil ou service hérité dépend à plusieurs reprises d'une règle générale.
• Délais de révocation : Une identité désactivée dans l'annuaire continue d'accéder au réseau ou aux applications.

Consultez la présentation des données et de la sécurité de Purple pour évaluer la manière dont une plateforme WiFi basée sur l'identité gère les données d'accès, les contrôles de sécurité et la visibilité opérationnelle. Quels que soient les outils choisis, les tableaux de bord doivent faciliter la prise de décision. Un journal d'événements que personne ne consulte ne permettra pas d'améliorer l'application des politiques.

Condition de retour en arrière : Annulez une politique lorsqu'elle bloque un parcours métier critique, crée une dépendance non sécurisée ou génère des échecs d'accès inexpliqués. Conservez les preuves, corrigez la conception et testez à nouveau. Ne laissez pas une exception d'urgence ouverte en permanence.

Protéger la disponibilité dans le cadre de la sécurité

Le zero trust dépend des annuaires, des services de certificats, des moteurs de politiques, des contrôleurs réseau et de la connectivité. Intégrez de la résilience dans chaque dépendance. Définissez ce qui se passe si le fournisseur d'identité est injoignable, si les certificats ne peuvent pas être validés, si un contrôleur échoue ou si un service de politique devient indisponible.

Utilisez la conception de services de secours avec précaution. Certains environnements nécessitent que les sessions existantes se poursuivent brièvement pendant une panne du service d'identité. D'autres doivent restreindre l'accès immédiatement pour les ressources sensibles. Le bon choix dépend de la ressource, du modèle de menace et des conséquences opérationnelles.

Communiquez avant de mettre en application. Indiquez aux utilisateurs ce qui va changer, les méthodes de connexion qu'ils utiliseront, le fonctionnement de l'enregistrement des appareils et la manière de signaler les erreurs. Suivez les thèmes récurrents du support technique et les analyses d'accès après chaque phase. La réduction de l'administration manuelle des comptes, la diminution des identifiants partagés et la révocation plus rapide sont les indicateurs concrets de l'amélioration du modèle opérationnel.

Votre liste de contrôle de mise en œuvre Zero Trust et étapes suivantes

Un plan de mise en œuvre réalisable devrait figurer à l'ordre du jour de la prochaine réunion d'architecture :

• Découvrir : Inventorier les personnes, les comptes de service, les appareils, les applications et les services.
• Cartographier les dépendances : Documenter les flux de données, les méthodes d'authentification, les contraintes héritées et les propriétaires opérationnels.
• Définir les limites : Séparer l'accès du personnel, des invités, de l'IoT et des locataires en fonction des besoins en ressources.
• Renforcer l'identité : Sélectionner une source de vérité d'annuaire, imposer la MFA et introduire le SSO.
• Adopter une authentification plus forte : Orienter les utilisateurs et les appareils éligibles vers un accès sans mot de passe et basé sur des certificats.
• Automatiser le cycle de vie : Provisionner à partir des groupes d'annuaires et révoquer l'accès lorsque les identités ou les certificats changent.
• Évaluer la posture : Vérifier la gestion, l'état de santé et la conformité avant d'accorder un accès sensible.
• Sécuriser le WiFi : Utiliser une authentification d'entreprise liée à l'identité au lieu de mots de passe partagés par le personnel.
• Contenir les appareils hérités : Placer les exceptions sur des segments restreints avec des politiques à portée limitée.
• Surveiller d'abord : Exécuter des politiques pilotes en mode observation, puis les appliquer avec des critères de retour en arrière.
• Vérifier en continu : Tester les accès refusés, les révocations, les changements de posture et les défaillances de service.
• Déployer de manière délibérée : Ajouter des sites et des charges de travail uniquement lorsque les journaux, la propriété et les processus de support sont prêts.

La décision de mise en œuvre la plus importante concerne le séquençage. Ne commencez pas par le produit le plus visible ou le segment de réseau le plus vaste. Commencez par un parcours que vous pouvez comprendre, mesurer et inverser. Pour l'hôtellerie et le commerce de détail, cela peut signifier séparer le personnel, les invités et les appareils opérationnels sur un site physique. Pour le secteur de la santé, cela peut signifier hiérarchiser les contrôles d'identité et d'appareils autour d'une application sensible. Pour le logement multilocataire, cela peut consister à fournir un accès résident simple tout en préservant l'isolation entre les locataires et les systèmes du bâtiment.

Choisissez une plateforme lorsqu'elle élimine un véritable obstacle à la migration. Si votre parc a besoin d'un WiFi sans mot de passe, d'un accès du personnel intégré à l'annuaire, d'une révocation automatique et d'une moindre dépendance vis-à-vis des serveurs RADIUS sur site, évaluez si une plateforme telle que Purple s'intègre dans l'architecture d'identité et de réseau existante. Liez cette décision à vos objectifs de contrôle, à vos exigences d'intégration et à votre responsabilité opérationnelle.

Mesurez les progrès grâce à des preuves concrètes, et non par de simples annonces de déploiement. Vous devez être en mesure d'identifier quelles identités ont accès, quels appareils sont approuvés, quelles politiques ont rejeté des requêtes, à quelle vitesse la révocation a pris effet et où subsistent les exceptions. C'est ainsi que le zero trust devient une véritable capacité opérationnelle plutôt qu'un projet de sécurité de plus resté au point mort.

---

Purple fournit un WiFi et des réseaux basés sur l'identité qui connectent le personnel et les appareils aux annuaires existants, prend en charge les accès sans mot de passe et par certificat, et peut automatiser le provisionnement et la révocation à mesure que le statut de l'annuaire change. Visitez Purple pour évaluer comment son authentification WiFi, sa posture d'appareil et ses intégrations réseau pourraient soutenir un déploiement progressif du zero-trust.