Si vous gérez un SSID pour le personnel avec un mot de passe partagé, vous connaissez déjà le scénario. Quelqu'un s'en va et le mot de passe devrait changer, mais ce n'est pas le cas. Un prestataire externe est ajouté pour un projet de courte durée et conserve l'accès plus longtemps que prévu. Le helpdesk continue de traiter des tickets d'utilisateurs qui ont oublié quel réseau rejoindre, ou qui ont saisi le bon mot de passe sur la mauvaise invite, ou qui se sont retrouvés bloqués après une rotation de mot de passe.
Les organisations ne conservent pas les mots de passe WiFi partagés par plaisir. Elles les conservent parce qu'ils sont faciles à expliquer et rapides à déployer. Le problème est que la commodité opérationnelle du premier jour devient une dette technique dès le sixième mois. L'authentification par certificat WiFi résout ce problème en remplaçant un secret réutilisable par une identité d'appareil que le réseau peut vérifier automatiquement.
La fin du problème des mots de passe WiFi partagés
Un lundi matin classique ressemble à ceci. Les services généraux ont ouvert un nouvel espace, de sorte que le mot de passe WiFi a été partagé à d'autres personnes. Un employé est parti, un fournisseur est toujours sur site, et quelqu'un a écrit le mot de passe sur un tableau blanc dans une salle informatique parce que "cela aide pendant la configuration". À l'heure du déjeuner, le réseau fonctionne toujours, mais personne ne peut dire avec certitude quels appareils devraient s'y trouver.
C'est tout le problème des PSK et des portails captifs. Ils facilitent l'accès au départ, mais le rendent difficile à contrôler avec le temps. L'identifiant est partagé, copié dans des notes, enregistré sur des appareils non gérés et conservé bien au-delà du moment où il aurait dû être supprimé. Si vous évaluez les compromis de sécurité et d'exploitation, ce comparatif entre WPA2 Enterprise vs PSK constitue un cadre utile.
Ce qui change lorsque les mots de passe disparaissent
Avec l'authentification par certificat, l'utilisateur ne saisit aucun mot de passe WiFi. L'appareil est provisionné avec sa propre identité, et la connexion s'établit automatiquement en arrière-plan. Cela transforme immédiatement le modèle de support.
Au lieu de demander "Qui connaît le mot de passe ?", vous demandez "Cet appareil doit-il avoir accès ?". C'est une bien meilleure question. Elle lie l'accès à un terminal géré, à un statut d'utilisateur, ou aux deux.
Un changement concret s'opère dans trois domaines :
- Le départ des collaborateurs devient précis. Vous révoquez l'accès d'un seul appareil ou d'un seul utilisateur au lieu de changer le mot de passe pour tout le monde.
- Le support technique est simplifié. Les utilisateurs n'ont plus à faire de choix manuels lors de la connexion, ce qui réduit les risques d'erreur de configuration.
- La politique de sécurité devient applicable. Vous pouvez exiger des appareils gérés pour l'accès interne et maintenir les appareils personnels ou invités sur un canal distinct.
Les mots de passe partagés se propagent de manière informelle dans l'organisation. Pas les certificats. Ils restent rattachés à l'identité de l'appareil que vous avez émise.
Pourquoi cette approche s'impose sur le terrain
La plus grande amélioration ne réside pas dans le renforcement de la cryptographie, bien que ce soit le cas. Le gain le plus important réside dans la simplification du modèle opérationnel. Un réseau destiné au personnel devrait fonctionner comme un badge d'accès à un bureau, et non comme un tableau noir de pub avec le code du jour.
C'est pourquoi le WiFi basé sur les certificats a tendance à s'imposer une fois que les équipes le déploient correctement. Il élimine toute une catégorie de frictions tout en offrant aux équipes de sécurité une chose qu'elles obtiennent rarement avec les configurations WiFi héritées : un contrôle individuel et auditable.
Comment fonctionne l'authentification par certificat en coulisses
La façon la plus simple de comprendre l'authentification par certificat WiFi est de cesser de penser aux mots de passe pour penser à l'accès aux bâtiments.
Un mot de passe WiFi partagé est comme un code de porte écrit sur le mur. Quiconque le connaît peut entrer, et une fois qu'il a fui, vous devez le changer pour tout le monde. Un réseau basé sur les certificats fonctionne plutôt comme un bureau sécurisé avec des badges d'identification, un réceptionniste et une liste centrale d'émetteurs de badges de confiance.
Les éléments clés
Voici la correspondance pratique.
| Composant | Analogie avec le monde réel | Rôle |
|---|---|---|
| 802.1X | Processus d'accès à la porte d'entrée | Contrôle la façon dont un appareil demande l'accès |
| EAP-TLS | Routine d'inspection des badges | Définit comment l'identité est vérifiée à l'aide de certificats |
| Certificat | Badge d'identification inviolable | Prouve que l'appareil possède une identité émise |
| Serveur RADIUS | Poste de sécurité | Vérifie l'identité présentée et renvoie une autorisation ou un refus |
| Autorité de certification | Bureau de délivrance des badges | Signe les certificats auxquels le réseau accepte de faire confiance |
| Point d'accès | Porte ou tourniquet | Transmet l'authentification à RADIUS, puis ouvre l'accès au réseau |
Dans les environnements d'entreprise et du secteur public au Royaume-Uni, la base technique est le protocole 802.1X/EAP-TLS. L'appareil présente un certificat X.509 à un serveur d'authentification basé sur RADIUS, qui vérifie ce certificat par rapport à une autorité de certification de confiance avant d'accorder l'accès, la clé privée ne quittant jamais l'appareil, comme décrit dans cette présentation de l'authentification par certificat WiFi . La même source note que le Cyber Assessment Framework v3.1 2023 du NCSC souligne que l'authentification forte et l'assurance d'identité forte sont des contrôles fondamentaux pour les services critiques, ce qui explique précisément pourquoi l'accès basé sur les certificats apparaît constamment dans les discussions sur le modèle zero-trust au Royaume-Uni.
Ce qui se passe réellement lors de la connexion
Le handshake semble complexe jusqu'à ce qu'on le réduise à une simple séquence de vérifications.
L'appareil rejoint le SSID.
Il n'envoie pas de mot de passe. Il lance un échange 802.1X.Le point d'accès transmet la demande.
Le point d'accès ne prend pas la décision de confiance seul. Il relaye l'authentification vers le serveur RADIUS.Le serveur prouve son identité à l'appareil.
L'appareil vérifie le certificat du serveur pour s'assurer que le client interagit uniquement avec un service d'authentification de confiance.L'appareil présente son propre certificat.
C'est le badge numérique. La clé privée reste sur l'appareil et est utilisée pour prouver la possession du certificat.Le serveur RADIUS valide la chaîne de certificats.
Il vérifie si le certificat a été émis par une autorité de certification de confiance et si la politique autorise cet appareil sur ce réseau.L'accès est accordé.
Si les vérifications réussissent, le serveur RADIUS renvoie son approbation et le point d'accès laisse l'appareil accéder au réseau.
Pourquoi l'authentification mutuelle est essentielle
Le WiFi basé sur mot de passe ne pose généralement qu'une seule question : connaissez-vous le secret ? Le protocole EAP-TLS en pose deux. Le réseau est-il vraiment celui qu'il prétend être, et l'appareil est-il réellement celui auquel nous avons délivré une identité ?
Règle pratique : Si vos appareils clients ne valident pas le certificat du serveur RADIUS, vous conservez la complexité du WiFi d'entreprise sans bénéficier du modèle de confiance complet.
Cette vérification mutuelle est la raison majeure pour laquelle le WiFi basé sur certificat est plus performant dans les environnements réglementés et sensibles à la sécurité. Il transforme l'accès sans fil, qui n'est plus un simple exercice de secret partagé, en un véritable processus de vérification d'identité.
Les avantages de sécurité inégalés du passage au sans mot de passe
L'argument le plus fort en faveur du WiFi basé sur certificat n'est pas abstrait. Il est visible dans le comparatif avant - après des incidents quotidiens.
Avec un mot de passe partagé, un seul identifiant divulgué peut transformer le nettoyage en un véritable casse-tête. Vous devez modifier la clé du SSID, mettre à jour les appareils portables, reconfigurer le matériel de la salle de conférence et espérer que personne n'a copié l'ancien mot de passe dans une configuration enregistrée quelque part. Avec les certificats, le rayon d'impact est réduit car l'accès est lié à une identité spécifique émise, et non à un secret partagé par tous.
Si vous évaluez des alternatives opérationnelles aux mots de passe, le passwordless WiFi est la bonne approche. Son principal avantage n'est pas la nouveauté. C'est le contrôle.
Avant et après la perte d'un appareil
Avant l'authentification par certificat, la perte d'un ordinateur portable impose un choix difficile : conserver le mot de passe partagé et accepter le risque, ou le modifier et perturber tous les utilisateurs légitimes.
Après l'authentification par certificat, la réponse est plus ciblée. Vous révoquez la confiance de cet appareil et ne perturbez aucun autre utilisateur. C'est à cela que doit ressembler un accès sans fil mature.
Avant et après une invite de type phishing
Le WiFi basé sur mot de passe habitue les utilisateurs à faire confiance aux invites de saisie. Si un appareil détecte un SSID familier, de nombreux utilisateurs saisiront ce qui leur est demandé. Cette habitude est difficile à défendre à grande échelle.
Le WiFi basé sur certificat modifie le comportement du client. L'appareil s'authentifie avec son identité installée plutôt que de demander à l'utilisateur de fournir un secret. Cela exclut l'humain de la partie du flux de travail la plus sujette aux erreurs.
Quelques améliorations directes font généralement toute la différence :
- Confiance par appareil plutôt que confiance de groupe. Un certificat appartient à un point de terminaison unique, pas à tout un service.
- Audit plus clair. Vous pouvez lier les décisions d'accès aux identifiants émis et aux événements du cycle de vie.
- Meilleur alignement zero-trust. Le réseau peut exiger une identité vérifiée avant d'accorder un accès interne.
- Moins de dommages collatéraux. Un problème unique n'impose pas une réinitialisation générale des mots de passe.
Pourquoi les réseaux frauduleux deviennent plus difficiles à exploiter
Un réseau de type "evil twin" repose sur la confusion. Il imite un SSID légitime et attend que les appareils ou les utilisateurs s'y connectent par erreur. L'authentification par certificat rend cette attaque plus difficile car le client doit valider le côté serveur de l'échange avant de continuer.
Cela ne signifie pas que la conception est infaillible par défaut. Cela signifie que le déploiement doit être effectué correctement. Si les équipes ignorent les paramètres de confiance des certificats, acceptent n'importe quel certificat de serveur ou intègrent des appareils avec des instructions vagues, elles annulent ces avantages.
Le passwordless WiFi est aussi fort que ses ancres de confiance et son processus d'enrôlement. Le handshake est solide. Un onboarding bâclé ne l'est pas.
L'idée générale est simple. Les secrets partagés propagent les risques horizontalement. Les certificats maintiennent la confiance rattachée à un point d'extrémité connu, ce qui est exactement là où une politique de réseau sans fil moderne devrait commencer.
Maîtriser le cycle de vie et le provisionnement des certificats
La plupart des projets de WiFi par certificat qui échouent n'échouent pas parce que le protocole EAP-TLS est défaillant. Ils échouent parce que le cycle de vie a été traité comme une tâche de configuration unique.
Délivrer un certificat est la partie la plus facile. Le maintenir à jour, le remplacer avant son expiration, le révoquer si nécessaire et prouver que les bons appareils disposent des bons profils, c'est là que se manifeste la maturité opérationnelle. Si vous gérez correctement le cycle de vie, le WiFi par certificat devient plus calme que le WiFi basé sur mot de passe. Si vous le gérez mal, le jour de l'expiration se transforme en crise pour le centre de services.
Commencer par la méthode d'enrôlement
Il existe plusieurs modèles de provisionnement viables, mais ils ne se valent pas.
Le provisionnement géré par MDM ou UEM est généralement l'option la plus propre pour les parcs d'équipements gérés. Des outils comme Microsoft Intune, Jamf et Workspace ONE peuvent déployer ensemble les charges utiles de certificats, les racines de confiance et les paramètres WiFi. Cela réduit l'action de l'utilisateur et rend le renouvellement pratique.
La délivrance basée sur SCEP ou EST est utile lorsque vous souhaitez un enrôlement automatisé lié à un flux de travail PKI. Ces protocoles aident les appareils à demander des certificats de manière structurée sans dépendre d'une manipulation manuelle des fichiers. Ils conviennent particulièrement lorsque l'équipe PKI et l'équipe des points d'extrémité sont alignées.
Le provisionnement manuel a toujours sa place pour les projets pilotes, les petits environnements, les appareils spécialisés ou les exceptions étroitement contrôlées. Ce n'est pas la solution idéale pour la plupart des organisations à long terme.
Une comparaison simple aide à y voir plus clair :
| Méthode de provisionnement | Idéal pour | Faiblesse courante |
|---|---|---|
| MDM/UEM | Ordinateurs portables, mobiles et tablettes gérés | Dépend d'une bonne couverture de la gestion des appareils |
| SCEP ou EST | Délivrance automatisée en entreprise | Nécessite une discipline de conception PKI |
| Installation manuelle | Groupes pilotes et cas marginaux | Ne passe pas à l'échelle et favorise les problèmes d'expiration |
La discipline du cycle de vie importe plus que le premier déploiement
Le modèle d'authentification basé sur les certificats GovWifi du gouvernement britannique est un bon exemple de réalité opérationnelle. Chaque appareil géré est équipé d'une chaîne de certificats unique, puis s'authentifie automatiquement auprès des réseaux GovWifi à proximité sans saisir de mot de passe, car l'appareil présente son certificat au serveur RADIUS et l'accès n'est accordé qu'après la validation réussie du certificat, comme décrit dans le guide d'authentification des appareils GovWifi . Ce même guide est lucide quant au compromis : les organisations doivent comprendre la PKI et maintenir les certificats TLS à jour et sécurisés.
C'est sur ce dernier point que se concentrent les équipes expérimentées. Le point faible n'est généralement pas le handshake. C'est la gestion du cycle de vie.
À quoi ressemble une bonne gestion du cycle de vie
Les déploiements réussis reposent généralement sur quatre habitudes dès le départ :
- Renouvellement automatique : les appareils se renouvellent avant l'expiration avec un chevauchement suffisant pour éviter les interruptions brutales.
- Workflow de révocation : les équipes de sécurité et des terminaux savent exactement comment invalider un appareil perdu, volé ou retiré du service.
- Gestion du magasin de confiance : les certificats racines et intermédiaires sont distribués de manière cohérente sur toutes les plateformes.
- Mise hors service : les appareils retirés perdent leurs certificats et leurs profils WiFi dans le cadre du processus de départ.
Le certificat en lui-même n'est pas le produit. Le produit est un cycle de vie fonctionnel autour de ce certificat.
Ce qui ne fonctionne pas bien en pratique
Quelques anti-patterns apparaissent de manière récurrente :
- « Nous les renouvellerons plus tard. » L'expiration n'est pas un problème futur. Elle fait partie de la conception initiale.
- Des équipes distinctes sans processus partagé. Les équipes PKI, terminaux et réseau possèdent chacune un tiers de la vérité, et personne ne possède le parcours complet.
- Les exceptions manuelles qui deviennent la norme. Les installations ponctuelles se transforment en un parc non géré.
- Aucun test de révocation. Les équipes supposent que la révocation fonctionne car la PKI la prend en charge, mais ne vérifient jamais comment le réseau se comporte.
Les environnements les plus stables traitent l'authentification par certificat WiFi comme une infrastructure d'identité des terminaux, et non comme une simple fonctionnalité de l'SSID. Cet état d'esprit évite la plupart des pannes évitables.
Intégrer l'authentification WiFi avec votre fournisseur d'identité
Une fois le WiFi basé sur les certificats en place, l'étape de maturité suivante est évidente. Arrêtez de traiter l'accès sans fil comme un îlot distinct et connectez-le au système d'identité qui régit déjà les utilisateurs, les groupes et l'état des appareils.
Cela signifie lier la politique d'accès réseau à un fournisseur d'identité tel que Microsoft Entra ID, Google Workspace ou Okta. En pratique, le réseau sans fil cesse d'être un problème d'authentification autonome pour devenir une autre expression de votre modèle d'identité existant.
Pourquoi cela change la donne opérationnelle
Sans intégration avec l'IdP, l'accès au WiFi vit souvent dans un processus parallèle. Un utilisateur est créé dans l'annuaire, puis quelqu'un approuve séparément l'accès de l'appareil, crée un profil ou ajoute une règle dans une console réseau. C'est dans cette duplication que s'immiscent les retards et les incohérences.
Avec l'intégration, l'annuaire devient la source unique de vérité. Lorsque les RH intègrent une nouvelle recrue, le cycle de vie du compte peut déclencher l'enrôlement de l'appareil et l'attribution du profil. Lorsque quelqu'un s'en va, ce même événement d'identité peut supprimer l'accès sans attendre une tâche réseau manuelle.
Cela vous apporte de la cohérence là où les choses ont habituellement tendance à s'écarter :
- Le statut de l'utilisateur et l'accès WiFi restent alignés
- L'appartenance à un groupe peut piloter la politique d'accès
- La conformité de l'appareil peut influencer l'accès au SSID interne
- Le départ de l'entreprise devient immédiat plutôt que géré par ticket
Le rôle des plateformes
Vous pouvez construire cela de plusieurs manières. Certaines organisations connectent RADIUS, PKI et MDM directement et conservent le plan de contrôle en interne. D'autres utilisent des services gérés dans le cloud pour simplifier cette infrastructure.
Une option managée telle que RADIUS-as-a-Service peut réduire la charge opérationnelle liée à l'exploitation d'une infrastructure d'authentification sur site, tout en liant la politique d'accès aux systèmes d'annuaire. Ce modèle a tendance à séduire lorsque l'équipe réseau souhaite des contrôles d'accès basés sur des certificats sans avoir à gérer une autre plateforme de serveurs.
Le choix de conception pratique
La question de conception n'est pas de savoir "Mon WiFi peut-il utiliser des certificats ?" mais plutôt "Quels événements d'identité doivent accorder, modifier ou supprimer l'accès ?"
Un modèle logique ressemble souvent à ceci :
| Événement d'identité | Résultat réseau |
|---|---|
| Arrivée d'un utilisateur | L'appareil attribué reçoit le bon profil WiFi |
| Changement de rôle de l'utilisateur | La politique basée sur le groupe ajuste les droits de VLAN, d'ACL ou de SSID |
| Appareil non conforme | L'accès interne est limité ou supprimé |
| Départ de l'utilisateur | L'accès est révoqué dans le cadre du processus de départ |
Si votre IdP décide déjà de qui peut accéder à la messagerie, aux SaaS et au VPN, il devrait également influencer qui peut se connecter à votre WiFi interne.
Lorsque les équipes effectuent cette transition, le WiFi cesse d'être une corvée opérationnelle isolée. Il s'intègre au contrôle d'accès basé sur l'identité, ce qui est sa véritable place.
Bonnes pratiques de déploiement et de migration
Les migrations les plus fluides sont rarement les plus rapides. Elles sont progressives, observables et sans surprise. C'est une excellente chose.
Passer d'un accès par PSK ou par Captive Portal à un WiFi basé sur des certificats ne doit pas se faire par une bascule brutale du jour au lendemain. Commencez par valider la chaîne de confiance, le comportement des clients et les mécanismes du cycle de vie avec une architecture parallèle. En pratique, cela se traduit généralement par un SSID dédié au personnel pour les appareils pilotes, un groupe d'enrôlement restreint et des options de retour arrière claires.
Déployer par étapes
Une séquence simple fonctionne parfaitement dans la plupart des environnements :
Mettre en place un SSID pilote
Limitez-le à l'équipe informatique, à la sécurité et à un petit groupe d'utilisateurs clés. Validez le déploiement des profils, le comportement d'itinérance et les modes d'échec.Tester l'ensemble du cycle de vie, pas seulement la première connexion
Le renouvellement, la révocation, le remplacement des certificats et le départ des utilisateurs doivent tous être testés. Un succès au premier jour ne garantit pas la viabilité du système.Étendre par classe d'appareils
Commencez par les ordinateurs portables et les mobiles gérés. Réservez les équipements spécialisés et les plateformes complexes pour les phases ultérieures.Retirer l'accès existant progressivement
Laissez aux utilisateurs le temps de migrer. Ne supprimez la dépendance au mot de passe partagé qu'une fois que le parcours géré est totalement stable.
Concevoir pour la révocation dès le premier jour
L'authentification par certificat WiFi basée sur EAP-TLS utilise une validation mutuelle des certificats. Le client vérifie le certificat du serveur RADIUS, et le serveur RADIUS vérifie la signature, l'émetteur, l'expiration et le statut de révocation du certificat client avant de délivrer un Access-Accept, comme l'explique ce guide du certificat WiFi EAP-TLS . Ce même guide précise que la configuration de la CRL ou d'OCSP est nécessaire, et que l'OCSP est obligatoire pour les déploiements à haute sécurité et faible latence.
Cela a une conséquence pratique. La sécurité et la latence sont directement liées à la gestion de la révocation. Si les vérifications de révocation sont négligées, vous risquez de vous retrouver avec des décisions de confiance obsolètes ou des ralentissements importants.
Une liste de contrôle utile pour la planification :
- Choisissez votre modèle de révocation tôt. Ne remettez pas les décisions concernant la CRL ou l'OCSP à plus tard lorsque les utilisateurs seront déjà connectés.
- Automatisez le renouvellement des certificats. Un renouvellement géré par MDM ou UEM est indispensable dans un déploiement d'envergure.
- Validez la confiance du certificat serveur sur les clients. Un client qui ignore cette vérification fragilise l'ensemble de l'architecture.
- Mesurez le comportement lors de la connexion pendant les tests. Surveillez les délais inhabituels qui pourraient révéler des problèmes de révocation ou d'infrastructure PKI.
Note de terrain : L'authentification par certificat WiFi est autant un projet d'opérations PKI qu'un projet réseau.
Gérer proprement les appareils incompatibles avec le 802.1X
Certains terminaux existants, appareils embarqués et plateformes IoT spécifiques ne prendront pas en charge le 802.1X basé sur certificat de manière gérable. Prétendre le contraire ne fait que ralentir le projet.
Pour ces appareils, utilisez une stratégie distincte et contenez-la de manière stricte. L' iPSK peut constituer une passerelle pratique pour les appareils nécessitant des identifiants uniques mais ne pouvant pas utiliser l'authentification par certificat complète. L'essentiel est d'éviter que les exceptions ne contaminent la configuration destinée au personnel. Maintenez ces appareils sur des chemins de politique isolés avec un accès plus restreint.
Simplifier l'intégration pour les utilisateurs
Un bon WiFi par certificat est souvent invisible pour l'utilisateur. Un mauvais WiFi par certificat lui impose un PDF, trois demandes de validation de confiance et un numéro d'assistance.
Pour les appareils gérés, l'objectif d'intégration est d'avoir zéro point de décision. Le certificat, la chaîne de confiance et le profil WiFi doivent être livrés ensemble. Pour le BYOD, utilisez un flux de travail distinct avec un langage clair et des limites explicites concernant l'accès accordé à ces appareils.
Cas d'usage réels et scénarios avancés
La valeur de l'authentification par certificat est plus facile à apprécier lorsqu'elle est déployée dans des environnements réels plutôt que sur des schémas de laboratoire.
Dans un hôpital, la question n'est pas de savoir si le personnel peut se souvenir d'un mot de passe. L'enjeu est de savoir si les appareils cliniques gérés, les stations de travail sur roulettes et les terminaux spécialisés peuvent se connecter de manière cohérente sans partager d'identifiants communs. L'accès basé sur certificat s'adapte à ce modèle car la décision de confiance suit l'identité de l'appareil plutôt qu'un secret qui a tendance à se propager.
Dans un commerce ou un établissement hôtelier, le modèle est légèrement différent. Les appareils du personnel ont besoin d'un accès interne sécurisé, tandis que l'accès invité doit rester simple et segmenté. C'est là que la conception réseau axée sur l'identité commence à porter ses fruits. Un même lieu peut prendre en charge un accès réservé au personnel sécurisé par certificat et une expérience invité distincte conçue pour une intégration plus facile.
Là où cela fonctionne particulièrement bien
- Bureaux d'entreprise : Les ordinateurs portables et téléphones gérés se connectent automatiquement, et l'accès peut suivre la politique de l'annuaire et de l'appareil.
- Établissements de santé : Les mots de passe partagés disparaissent des chariots, des tablettes et des zones de travail cliniques.
- Campus éducatifs : Les appareils gérés par le personnel et l'institution peuvent se connecter sans invites répétées à travers les différents bâtiments.
- Sites industriels et denses en IoT : Les appareils prenant en charge les certificats bénéficient de contrôles d'identité renforcés, tandis que le matériel non compatible est isolé via des chemins d'exception.
Scénarios avancés à planifier
Les propriétés multi-locataires, les résidences étudiantes et les grands sites événementiels ont souvent besoin d'une double approche. L'expérience réseau doit sembler simple pour l'utilisateur, tandis que l'application des règles sous-jacentes reste stricte. Les certificats s'avèrent utiles pour le personnel et les appareils gérés car ils préservent la confiance par appareil, même lorsque l'environnement lui-même est hautement partagé.
Passpoint et OpenRoaming s'intègrent également naturellement dans cette réflexion globale, en particulier pour l'accès invité et les visites récurrentes. Ils diffèrent de l'authentification interne EAP-TLS du personnel, mais partagent le même principe : réduire les frictions au moment de la connexion tout en améliorant la confiance et la cohérence en arrière-plan.
Les déploiements les plus solides n'essaient pas d'imposer une seule méthode à chaque appareil et à chaque public. Ils combinent l'authentification par certificat pour les appareils devant être gérés, un accès invité segmenté pour les visiteurs et une gestion contrôlée des exceptions pour le matériel hérité.
Si vous envisagez de ne plus utiliser de mots de passe WiFi partagés, Purple est une option à évaluer aux côtés de vos infrastructures PKI, MDM, RADIUS et de gestion des identités existantes. Elle se concentre sur l'accès WiFi basé sur l'identité pour le personnel, les invités et les environnements multi-locataires, y compris les modèles d'accès sans mot de passe, l'authentification gérée dans le cloud et l'intégration avec les plateformes d'annuaire.
