EAP-TLS vs. PEAP : Quel protocole d'authentification convient le mieux à votre réseau ?

Une comparaison technique complète des protocoles d'authentification EAP-TLS et PEAP, couvrant l'architecture de sécurité, la complexité du déploiement et les implications en matière de conformité. Ce guide fournit des cadres de décision exploitables pour les responsables informatiques des secteurs de l'hôtellerie, du commerce de détail, de l'événementiel et du secteur public qui doivent choisir la bonne méthode d'authentification 802.1X pour leur infrastructure WiFi d'entreprise.

📖 6 min de lecture📝 1,341 mots🔧 2 exemples❓ 3 questions📚 9 termes clés

🎧 Écouter ce guide

Voir la transcription

EAP-TLS vs PEAP: Which Authentication Protocol Is Right for Your Network?
A Purple Technical Briefing

[INTRODUCTION — approximately 1 minute]

Welcome to the Purple Technical Briefing. I'm your host, and today we're getting into one of the most consequential decisions you'll make when designing or upgrading your enterprise wireless infrastructure: the choice between EAP-TLS and PEAP for your 802.1X authentication framework.

If you're an IT manager, network architect, or CTO responsible for a hotel group, a retail estate, a stadium, or a public-sector organisation, this decision affects your security posture, your compliance standing, and the day-to-day operational overhead your team carries. So let's cut straight to it.

Both EAP-TLS and PEAP are 802.1X authentication methods. They both rely on a RADIUS server to handle authentication requests, and they both provide significantly stronger security than a shared WPA2 passphrase. But the way they verify identity is fundamentally different — and that difference has major implications for how you deploy, manage, and scale your network.

[TECHNICAL DEEP-DIVE — approximately 5 minutes]

Let's start with EAP-TLS — Extensible Authentication Protocol Transport Layer Security.

EAP-TLS is the gold standard of enterprise WiFi authentication. The defining characteristic is mutual certificate authentication. What that means in practice is this: when a device tries to connect to your network, the RADIUS server presents a digital certificate to the device. The device checks that certificate against its trusted Certificate Authorities. But here's the critical difference from PEAP — the device then presents its own certificate back to the server. The server validates that client certificate, and only if both certificates are valid and trusted does the network grant access.

There are no passwords involved. None. The authentication is entirely certificate-based. This makes EAP-TLS extraordinarily resistant to credential theft, dictionary attacks, and Man-in-the-Middle attacks. You simply cannot steal a password that doesn't exist in the authentication flow.

Now, the trade-off is deployment complexity. To run EAP-TLS at scale, you need a Public Key Infrastructure — a PKI — to issue, manage, and revoke certificates for every single device on your network. You also need a Mobile Device Management solution to push those certificates silently to endpoints. If you're running a corporate estate with Microsoft Intune or Jamf, this is entirely manageable. If you're not, EAP-TLS becomes a significant undertaking.

The other operational consideration is certificate lifecycle management. Certificates expire. If your RADIUS server certificate expires, every single device on your network will fail to authenticate simultaneously. That's a catastrophic outage. Certificate monitoring and renewal processes are non-negotiable.

Now let's look at PEAP — Protected Extensible Authentication Protocol.

PEAP was designed to address the deployment complexity of EAP-TLS while still providing robust security. The key insight behind PEAP is this: you only need the server to have a certificate. The client does not need one.

Here's how it works. The RADIUS server presents its certificate to the client device. The client validates the server — just as in EAP-TLS. This establishes an encrypted TLS tunnel. Inside that tunnel, the client then performs standard password-based authentication, typically using MSCHAPv2, against your identity store — Active Directory, LDAP, Google Workspace, whatever you're using.

The password never travels in plaintext. It's always protected inside the encrypted tunnel. So PEAP is genuinely secure — provided it's configured correctly.

And that's where we need to talk about the most common and most dangerous misconfiguration in PEAP deployments. If a client device is not configured to strictly validate the RADIUS server's certificate, an attacker can set up a rogue access point with the same network name, present a fraudulent certificate, and the device will happily connect. The attacker then captures the MSCHAPv2 authentication exchange, which can be cracked offline. This is not a theoretical attack — it's a well-documented technique used in real-world penetration tests.

The fix is straightforward: use Group Policy, MDM profiles, or onboarding tools to enforce strict server certificate validation on every client device. But the operational reality is that in BYOD environments, ensuring this configuration is consistently applied across thousands of unmanaged personal devices is genuinely difficult.

Let me give you a concrete comparison. Consider a 500-location retail chain. They have corporate-owned tablets and handheld scanners, all managed through Microsoft Intune. EAP-TLS is the right call. Intune pushes certificates automatically. If a scanner is lost, IT revokes its certificate and it's off the network within minutes — no password resets, no shared passphrase changes across 500 stores. The security is absolute.

Now consider a large conference centre running WiFi for 3,000 staff members on their personal devices. No MDM. Staff use Google Workspace. PEAP integrated with Google Secure LDAP is the pragmatic choice. Staff authenticate with their standard credentials. The IT team provides onboarding documentation to configure certificate validation. It's deployable in days, not months.

The architecture underpinning both protocols is the same three-component 802.1X model: the supplicant — that's the client device — the authenticator, which is your access point or switch, and the RADIUS server. The authenticator acts as a gatekeeper, blocking all traffic until the RADIUS server signals that authentication has succeeded.

[IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes]

So what are the practical recommendations?

First: if you have an MDM solution and corporate-owned devices, deploy EAP-TLS. The initial investment in PKI and certificate management pays dividends in reduced risk and simplified compliance audits. For regulated environments — healthcare, finance, public sector — this is not optional. It's the architecture your auditors expect to see.

Second: if you're running a BYOD environment or you don't have MDM infrastructure, deploy PEAP. But do not skip the server certificate validation configuration. Use onboarding tools, network access control portals, or MDM profiles where possible to enforce this. Treat it as a mandatory deployment step, not an optional hardening measure.

Third: regardless of which protocol you choose, build RADIUS redundancy into your architecture. Authentication is a critical path. A single RADIUS server failure means nobody gets on the network. Cloud-hosted RADIUS solutions can provide resilience without the overhead of managing redundant on-premises infrastructure.

Fourth: segment your network post-authentication. A successful 802.1X authentication should not grant unrestricted access to your entire corporate network. Use VLAN assignment policies to place users in appropriate network segments with appropriate access controls.

The common pitfalls to avoid: certificate expiration causing mass authentication failures in EAP-TLS deployments; client devices not validating server certificates in PEAP deployments; and RADIUS timeout issues caused by high latency between the wireless controller and the authentication server — particularly relevant in geographically distributed estates.

[RAPID-FIRE Q&A — approximately 1 minute]

Let me run through a few questions I hear frequently.

Can I run both EAP-TLS and PEAP on the same network? Yes. Many organisations run EAP-TLS for corporate devices on one SSID and PEAP for BYOD or guest access on a separate SSID, with appropriate network segmentation between them.

Does WPA3 change this decision? WPA3 Enterprise mandates 192-bit security mode for high-security deployments, which aligns with EAP-TLS. WPA3 Personal uses SAE instead of PSK, but for enterprise 802.1X deployments, the EAP method selection remains relevant.

Is PEAP compliant with PCI DSS? Yes, when correctly configured with server certificate validation enforced. However, for environments handling cardholder data, EAP-TLS is increasingly the recommended approach in security assessments.

What about OpenRoaming? OpenRoaming uses certificate-based authentication under the hood, aligning with EAP-TLS principles. Platforms like Purple can act as an identity provider for OpenRoaming, enabling seamless, secure roaming across venues without re-authentication.

[SUMMARY AND NEXT STEPS — approximately 1 minute]

To summarise: EAP-TLS is the highest-security option, eliminating passwords entirely through mutual certificate authentication. It requires PKI and MDM infrastructure but provides the strongest compliance posture and the most granular device-level access control. PEAP is the pragmatic choice for BYOD and environments without certificate management infrastructure, providing strong encrypted authentication using existing credentials — but only when server certificate validation is rigorously enforced.

The decision framework is straightforward: if you manage your devices, use EAP-TLS. If your users bring their own devices, use PEAP — but configure it properly.

For your next steps: audit your current authentication configuration, assess your PKI and MDM readiness, and review your RADIUS infrastructure for redundancy and latency. If you're deploying or upgrading guest WiFi alongside your corporate network, consider how a platform like Purple can integrate with your authentication framework to provide both security and actionable analytics from your network.

Thanks for listening to the Purple Technical Briefing. Until next time.

Points clés à retenir

✓EAP-TLS offers the highest level of enterprise WiFi security through mutual certificate authentication, completely eliminating passwords from the authentication flow.
✓PEAP provides robust security by tunnelling standard password authentication within an encrypted TLS session, requiring only a server-side certificate.
✓EAP-TLS is the correct choice for corporate-managed device environments where a PKI and MDM infrastructure exist — particularly in regulated industries such as healthcare, finance, and public sector.
✓PEAP is the pragmatic choice for BYOD environments and organisations lacking automated certificate management capabilities, provided server certificate validation is rigorously enforced.
✓The primary and most exploited vulnerability in PEAP deployments is the failure to enforce strict server certificate validation on client devices — this must be treated as a mandatory configuration step.
✓Both protocols require a robust, highly available RADIUS infrastructure; a single RADIUS server failure creates a complete authentication outage.
✓Integrating secure 802.1X authentication with a platform like Purple enables venues to combine enterprise-grade security with actionable WiFi analytics and seamless guest onboarding.

Résumé Exécutif

Le choix du bon protocole d'authentification est une décision architecturale critique qui a un impact sur la posture de sécurité et les frais opérationnels. Pour les responsables informatiques, les architectes réseau et les CTO opérant dans des environnements complexes — tels que l' Hôtellerie , le Commerce de détail , les stades et les organisations du secteur public — le choix entre EAP-TLS et PEAP dicte souvent l'équilibre entre une sécurité à toute épreuve et la faisabilité du déploiement.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) est largement considéré comme la référence en matière de sécurité WiFi d'entreprise, reposant sur une authentification mutuelle basée sur des certificats. PEAP (Protected Extensible Authentication Protocol), à l'inverse, encapsule l'authentification standard basée sur un mot de passe dans un tunnel TLS chiffré, réduisant considérablement la complexité du déploiement.

Ce guide de référence technique offre une analyse architecturale approfondie et neutre des deux protocoles. Nous explorons leurs mécanismes opérationnels, évaluons les complexités de déploiement et fournissons des recommandations exploitables pour garantir que votre infrastructure réseau respecte les normes de sécurité modernes — y compris la conformité PCI DSS et GDPR — tout en maintenant une connectivité fluide pour vos utilisateurs.

Analyse Technique Approfondie : Architecture des Protocoles

Pour prendre une décision éclairée, il est essentiel de comprendre les mécanismes sous-jacents par lesquels ces protocoles sécurisent le cadre d'authentification 802.1X. Les deux protocoles utilisent un serveur RADIUS pour gérer les requêtes d'authentification, mais leurs méthodes de validation d'identité diffèrent fondamentalement. Pour une compréhension fondamentale de l'infrastructure RADIUS, consultez notre guide sur Qu'est-ce que RADIUS ? Comment les serveurs RADIUS sécurisent les réseaux WiFi .

EAP-TLS : Authentification Mutuelle par Certificat

EAP-TLS fonctionne sur le principe de l'authentification mutuelle. Le périphérique client (demandeur) et le serveur d'authentification (RADIUS) doivent tous deux présenter des certificats numériques valides pour établir une connexion.

L'établissement de la connexion (Handshake) : Lorsqu'un appareil tente de se connecter, le serveur RADIUS présente son certificat au client. Le client valide ce certificat par rapport à ses autorités de certification racine (CAs) de confiance. Une fois le serveur vérifié, le client présente son propre certificat unique au serveur. Si les deux certificats sont valides et n'ont pas été révoqués — vérifié via CRL ou OCSP — une session TLS sécurisée est établie et l'accès au réseau est accordé.

Cette vérification mutuelle rend EAP-TLS très résistant au vol d'identifiants, aux attaques par dictionnaire et aux attaques de l'homme du milieu (MitM). Étant donné qu'aucun mot de passe n'est transmis, les identifiants utilisateur compromis ne peuvent pas être utilisés pour violer le réseau.

PEAP : Authentification par Mot de Passe Tunnelisée

PEAP a été développé comme une alternative plus facile à déployer à EAP-TLS, éliminant le besoin de certificats côté client tout en offrant une sécurité robuste.

Établissement du tunnel : Le serveur RADIUS présente son certificat au client. Le client valide le serveur, établissant un tunnel TLS chiffré. Au sein de ce tunnel sécurisé, le client effectue une authentification standard basée sur un mot de passe — généralement MSCHAPv2 — auprès d'un fournisseur d'identité tel qu'Active Directory. Le serveur RADIUS valide les identifiants et accorde l'accès.

Bien que PEAP soit hautement sécurisé lorsqu'il est correctement configuré, il repose sur le maintien de mots de passe forts par les utilisateurs. Il est crucial de noter que si l'appareil d'un utilisateur n'est pas configuré pour valider le certificat du serveur, un point d'accès malveillant peut intercepter les identifiants. Ce n'est pas un risque théorique ; c'est un vecteur d'attaque bien documenté utilisé lors de tests d'intrusion réels.

Dimension	EAP-TLS	PEAP
Niveau de sécurité	Très élevé — authentification mutuelle par certificat	Élevé — tunnel chiffré, certificat de serveur uniquement
Type d'identifiant	Certificats numériques client et serveur	Nom d'utilisateur et mot de passe (dans le tunnel TLS)
Complexité du déploiement	Plus élevée — nécessite une PKI et un MDM	Plus faible — s'intègre aux services d'annuaire existants
Idéal pour	Parcs d'appareils d'entreprise, industries réglementées	Environnements BYOD, organisations sans PKI
Certificat client requis	Oui	Non
Conformité PCI DSS / GDPR	Excellent — préféré pour les environnements à haute conformité	Bon — conforme lorsque la validation du serveur est appliquée

Guide d'Implémentation : Stratégies de Déploiement

La principale divergence entre EAP-TLS et PEAP réside dans leur complexité de déploiement et leur gestion du cycle de vie.

Déploiement d'EAP-TLS

L'implémentation d'EAP-TLS nécessite une infrastructure à clé publique (PKI) robuste pour émettre, gérer et révoquer les certificats de chaque appareil sur le réseau. Les solutions de gestion des appareils mobiles (MDM) ou de gestion de la mobilité d'entreprise (EMM) sont pratiquement obligatoires pour automatiser le provisionnement des certificats aux terminaux à grande échelle. Les équipes informatiques doivent gérer les cycles de vie des certificats, en gérant les renouvellements avant l'expiration et en assurant une révocation rapide pour les appareils perdus ou les employés partants. EAP-TLS est le mieux adapté aux réseaux d'entreprise avec des appareils appartenant à l'entreprise, aux environnements hautement réglementés tels que la Santé ou la finance, et aux architectures de confiance zéro.

Déploiement de PEAP

PEAP est nettement plus facile à déployer car il s'appuie sur les magasins d'identité existants — Active Directory, LDAP ou annuaires cloud — sans nécessiter de certificats clients. Un serveur RADIUS avec un certificat de serveur valide (idéalement fd'une AC publique) et l'intégration avec votre service d'annuaire existant sont suffisantes pour commencer. Les frais généraux opérationnels sont minimes : les utilisateurs s'authentifient avec leurs identifiants d'entreprise standard. Les politiques de rotation des mots de passe s'appliquent, ce qui peut entraîner une légère surcharge pour le support technique lorsque les utilisateurs oublient de mettre à jour leurs profils WiFi après un changement de mot de passe. Le PEAP est mieux adapté aux environnements BYOD, aux secteurs de l'éducation et aux organisations sans infrastructure PKI ou MDM établie.

Bonnes pratiques et normes de l'industrie

Quel que soit le protocole choisi, le respect des normes de l'industrie est non négociable pour atténuer les risques.

Appliquer la validation du certificat de serveur : La vulnérabilité la plus courante dans les déploiements PEAP est la mauvaise configuration des appareils clients qui ne valident pas le certificat du serveur RADIUS. Cela permet aux attaquants de configurer des points d'accès non autorisés et de collecter des identifiants. Les équipes informatiques doivent utiliser des stratégies de groupe ou des profils MDM pour appliquer une validation stricte du serveur sur chaque point d'extrémité.

Mettre en œuvre la redondance RADIUS : L'authentification est un chemin critique. Assurez-vous que votre infrastructure RADIUS est hautement disponible. Les solutions RADIUS basées sur le cloud peuvent atténuer les points de défaillance uniques sur site. Les considérations architecturales pour la résilience des réseaux distribués sont abordées plus en détail dans Les avantages clés du SD WAN pour les entreprises modernes .

Intégrer avec des fournisseurs d'identité modernes : Pour les lieux ouverts au public, l'exploitation d'une plateforme Guest WiFi robuste qui agit comme un fournisseur d'identité sécurisé peut simplifier l'accès tout en maintenant la sécurité. La licence Connect de Purple, par exemple, fournit un fournisseur d'identité gratuit pour des services comme OpenRoaming, comblant le fossé entre la sécurité de niveau entreprise et l'intégration fluide des invités.

Segmentation du réseau post-authentification : Une authentification 802.1X réussie ne doit pas accorder un accès illimité à l'ensemble du sous-réseau d'entreprise. Utilisez des politiques d'attribution dynamique de VLAN pour placer les utilisateurs dans des segments de réseau appropriés avec des ACL restreintes.

Dépannage et atténuation des risques

Lors de la gestion des réseaux 802.1X, les équipes informatiques doivent être préparées aux modes de défaillance courants.

Expiration du certificat (EAP-TLS) : Si le certificat de l'AC ou le certificat du serveur RADIUS expire, toutes les authentifications échoueront simultanément. Mettez en œuvre une surveillance et des alertes agressives pour les périodes de validité des certificats — définissez des alertes à 90, 30 et 7 jours avant l'expiration.

Mauvaise configuration du demandeur (PEAP) : Ne pas valider le certificat du serveur est un risque critique. Vérifiez régulièrement les configurations des points d'extrémité pour vous assurer que la "Validation du certificat de serveur" est strictement appliquée. Incluez cela comme un élément standard dans votre liste de contrôle d'audit de sécurité.

Problèmes de délai d'attente RADIUS : Une latence élevée entre le contrôleur sans fil et le serveur RADIUS, ou entre le serveur RADIUS et Active Directory, peut entraîner des délais d'attente EAP et des échecs d'authentification. Assurez une connectivité robuste et envisagez des proxys RADIUS locaux pour les sites distribués. Ceci est particulièrement pertinent pour les déploiements multi-sites de Transport et de vente au détail.

Attaques de points d'accès non autorisés : Effectuez des évaluations périodiques de la sécurité sans fil pour détecter les points d'accès non autorisés. Les systèmes de détection d'intrusion sans fil (WIDS) intégrés à votre infrastructure de points d'accès peuvent assurer une surveillance continue.

ROI et impact commercial

La décision entre EAP-TLS et PEAP a des implications commerciales significatives au-delà de l'architecture technique.

EAP-TLS nécessite un CapEx initial plus élevé pour les solutions PKI et MDM, ainsi qu'un OpEx continu pour la gestion des certificats. Cependant, il offre le plus haut niveau d'atténuation des risques contre les violations basées sur les identifiants, qui peuvent entraîner des dommages financiers et de réputation dévastateurs. Pour les lieux traitant des données sensibles ou opérant sous une stricte conformité réglementaire, le ROI d'EAP-TLS est réalisé grâce aux coûts de violation évités et aux audits de conformité simplifiés. Une seule violation basée sur les identifiants dans un environnement de vente au détail ou d'hôtellerie peut coûter des millions en remédiation, en amendes réglementaires et en dommages à la marque.

Le PEAP offre un délai de rentabilisation plus rapide et des coûts de mise en œuvre inférieurs. Il est très efficace pour les environnements où l'objectif principal est un accès sécurisé et chiffré sans la surcharge de la gestion des appareils. En intégrant le PEAP à une solution complète de WiFi Analytics , les lieux peuvent gérer l'accès de manière sécurisée tout en extrayant des informations opérationnelles précieuses des données d'utilisation du réseau — reliant l'infrastructure d'authentification à des résultats commerciaux mesurables tels que l'analyse du temps de présence, les schémas de fréquentation et les taux de visiteurs récurrents.

Termes clés et définitions

EAP (Extensible Authentication Protocol)

An authentication framework defined in IEEE 802.1X that provides the transport mechanism for various authentication methods over network access infrastructure.

EAP is the umbrella framework; EAP-TLS and PEAP are specific methods that run within it. IT teams encounter EAP when configuring RADIUS policies and wireless supplicant profiles.

Supplicant

The client device — laptop, smartphone, scanner, or IoT device — that initiates the authentication request to join the network.

IT teams must ensure supplicants are correctly configured, particularly regarding certificate validation, to prevent Man-in-the-Middle attacks. Supplicant configuration is the most common source of PEAP vulnerabilities.

Authenticator

The network device — typically a wireless access point or managed switch — that blocks all traffic from the supplicant until the RADIUS server confirms successful authentication.

The authenticator acts as the gatekeeper, passing EAP messages between the supplicant and the RADIUS server without processing the authentication itself.

RADIUS Server

Remote Authentication Dial-In User Service. The centralised server that receives authentication requests from the authenticator, validates credentials against an identity store, and returns an Access-Accept or Access-Reject response.

The RADIUS server is the brain of the 802.1X architecture. High availability and low latency between the RADIUS server and the identity store (Active Directory, LDAP) are critical for reliable authentication.

PKI (Public Key Infrastructure)

The framework of roles, policies, hardware, and software needed to create, manage, distribute, and revoke digital certificates.

A robust PKI is an absolute prerequisite for deploying EAP-TLS successfully at scale. Without PKI, certificate lifecycle management becomes unmanageable and creates significant operational risk.

MDM (Mobile Device Management)

Software used by IT to monitor, manage, and secure corporate mobile devices, including the ability to push configuration profiles, certificates, and policies silently to enrolled devices.

MDM is critical for EAP-TLS deployments to automate the silent provisioning of client certificates to end-user devices. Microsoft Intune, Jamf, and VMware Workspace ONE are common MDM platforms.

Mutual Authentication

A security process where both parties in a communications link authenticate each other before data is exchanged — as opposed to one-way authentication where only one party is verified.

The defining feature of EAP-TLS. Mutual authentication ensures the client knows it is talking to the legitimate network server, and the server knows it is talking to an authorised client device.

MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2)

A password-based authentication protocol commonly used as the inner authentication method within PEAP tunnels. It uses a challenge-response mechanism to avoid transmitting passwords in plaintext.

MSCHAPv2 hashes can be captured and cracked offline if the PEAP tunnel is compromised by a rogue access point. This is why server certificate validation in PEAP is non-negotiable.

OpenRoaming

A WiFi federation standard that allows users to automatically and securely connect to participating networks across different venues and operators without re-authenticating, using certificate-based authentication.

Purple acts as a free identity provider for OpenRoaming under its Connect licence, enabling venues to offer seamless, secure connectivity that aligns with EAP-TLS certificate authentication principles.

Études de cas

A national retail chain with 500 locations needs to secure corporate network access for store managers' tablets and handheld inventory scanners. They currently use a shared WPA2-PSK across all sites. They have Microsoft Intune deployed for device management.

Deploy EAP-TLS. Since the organisation already utilises Microsoft Intune, the heavy lifting of certificate deployment is already solved. Configure Intune to push unique client certificates to all corporate-owned tablets and scanners via a SCEP or PKCS certificate profile. The wireless infrastructure is reconfigured to use 802.1X pointing to a central or cloud-based RADIUS server (such as Microsoft NPS or a cloud RADIUS service). The RADIUS server is configured to accept authentication only from devices presenting certificates issued by the organisation's internal CA. Post-authentication, dynamic VLAN assignment places devices into the appropriate store operations segment.

Notes de mise en œuvre : This approach eliminates the massive security risk of a shared PSK across 500 locations — a compromised PSK in one store would previously have exposed every site. With EAP-TLS, if a scanner is lost or stolen, IT simply revokes its specific certificate via the PKI, instantly killing its network access without affecting any other devices. EAP-TLS is the optimal choice here because the MDM infrastructure makes certificate lifecycle management scalable. The key risk to monitor is certificate expiration — ensure automated renewal policies are configured in Intune.

A large conference centre needs to provide secure WiFi for 3,000 internal staff using their own personal devices (BYOD). They use Google Workspace for corporate identity but do not manage staff personal phones or laptops.

Deploy PEAP (specifically PEAP-MSCHAPv2 or EAP-TTLS/PAP against Google Secure LDAP). The IT team sets up a RADIUS server integrated with Google Workspace Secure LDAP. Staff members connect to the 'Staff_WiFi' SSID using their standard Google Workspace email and password. The IT team provides onboarding documentation — ideally via a captive portal or network onboarding tool — instructing staff to configure their devices to trust the specific RADIUS server certificate and to validate the server's domain name. A separate guest SSID is maintained for event attendees, managed through Purple's Guest WiFi platform for analytics and access control.

Notes de mise en œuvre : EAP-TLS is unfeasible here because the organisation does not have MDM control over personal devices to push certificates. PEAP provides a secure, encrypted tunnel for authentication using existing credentials, making it highly deployable for BYOD scenarios while still protecting against eavesdropping. The critical operational step is the onboarding process — the IT team must ensure every staff member's device is correctly configured to validate the server certificate. Failure to do so is the single greatest risk in this deployment.

Analyse de scénario

Q1. A university IT department is deploying secure WiFi across campus for 20,000 students. Students bring their own laptops and smartphones running a mix of Windows, macOS, iOS, and Android. The IT director insists on maximum security and proposes EAP-TLS. What is your architectural recommendation?

💡 Astuce :Consider the operational overhead of certificate management on unmanaged, personally-owned devices across a heterogeneous device estate.

Afficher l'approche recommandée

Advise against EAP-TLS for this specific use case. While EAP-TLS offers the highest security, deploying and managing 20,000+ client certificates on unmanaged student devices without an MDM solution will create an insurmountable support burden. Students change devices frequently, and the onboarding process for certificate installation across iOS, Android, Windows, and macOS is complex without MDM automation. Recommend PEAP (or EAP-TTLS) integrated with the university's student directory service. Ensure robust onboarding tools are used to configure student devices to strictly validate the server certificate. Optionally, deploy EAP-TLS on a separate SSID for staff devices that are university-managed, creating a tiered security architecture.

Q2. During a security audit, a penetration tester successfully harvests user credentials from your PEAP-secured wireless network by setting up a rogue access point broadcasting the same SSID. What is the root cause of this vulnerability, and what is the remediation?

💡 Astuce :Think about what happens during the TLS tunnel establishment phase in PEAP, and what the client device is — or is not — checking.

Afficher l'approche recommandée

The root cause is supplicant misconfiguration. The client devices are not configured to strictly validate the RADIUS server's digital certificate. When the rogue AP presented a fraudulent certificate, the client devices blindly trusted it, established the TLS tunnel with the attacker, and transmitted the MSCHAPv2 authentication exchange. The attacker can crack this offline. The remediation is threefold: (1) enforce strict server certificate validation via Group Policy or MDM profiles on all client devices; (2) specify the exact expected RADIUS server domain name in the supplicant configuration to prevent acceptance of certificates from other domains; (3) deploy a Wireless Intrusion Detection System (WIDS) to detect and alert on rogue access points.

Q3. A healthcare provider is upgrading its network to support mobile nursing workstations that access patient records. These workstations are corporate-owned, strictly managed by IT via Microsoft Intune, and the environment must comply with healthcare data protection regulations. Should they deploy PEAP or EAP-TLS?

💡 Astuce :Evaluate the regulatory environment, the level of device control, and the sensitivity of the data being accessed.

Afficher l'approche recommandée

Deploy EAP-TLS without hesitation. The healthcare environment requires strict compliance and maximum security against credential theft — a compromised password in a healthcare network can expose patient records and trigger significant regulatory penalties under GDPR and sector-specific data protection requirements. Because the devices are corporate-owned and strictly managed via Microsoft Intune, deploying client certificates is operationally feasible and can be fully automated. EAP-TLS provides the necessary mutual authentication to ensure only authorised, corporate-managed devices can access the clinical network. Additionally, EAP-TLS simplifies compliance audits — auditors reviewing the network architecture will see a certificate-based, passwordless authentication system that is inherently more defensible than password-based alternatives.