EAP-TLS vs. PEAP: Welches Authentifizierungsprotokoll ist das richtige für Ihr Netzwerk?

Ein umfassender technischer Vergleich der Authentifizierungsprotokolle EAP-TLS und PEAP, der Sicherheitsarchitektur, Bereitstellungskomplexität und Compliance-Auswirkungen behandelt. Dieser Leitfaden bietet umsetzbare Entscheidungsrahmen für IT-Führungskräfte im Gastgewerbe, Einzelhandel, bei Veranstaltungen und im öffentlichen Sektor, die die richtige 802.1X-Authentifizierungsmethode für ihre Unternehmens-WiFi-Infrastruktur auswählen müssen.

📖 6 Min. Lesezeit📝 1,341 Wörter🔧 2 Beispiele❓ 3 Fragen📚 9 Schlüsselbegriffe

🎧 Diesen Leitfaden anhören

Transkript anzeigen

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.

Wichtigste Erkenntnisse

✓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.

Zusammenfassung für Führungskräfte

Die Wahl des richtigen Authentifizierungsprotokolls ist eine kritische architektonische Entscheidung, die sowohl die Sicherheitslage als auch den Betriebsaufwand beeinflusst. Für IT-Manager, Netzwerkarchitekten und CTOs, die in komplexen Umgebungen tätig sind – wie dem Gastgewerbe , Einzelhandel , Stadien und Organisationen des öffentlichen Sektors – bestimmt die Wahl zwischen EAP-TLS und PEAP oft das Gleichgewicht zwischen kompromissloser Sicherheit und Bereitstellungsfähigkeit.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) gilt weithin als Goldstandard für die Unternehmens-WiFi-Sicherheit und basiert auf gegenseitiger zertifikatbasierter Authentifizierung. PEAP (Protected Extensible Authentication Protocol) hingegen kapselt die standardmäßige passwortbasierte Authentifizierung in einem verschlüsselten TLS-Tunnel, was die Bereitstellungskomplexität erheblich reduziert.

Dieser technische Referenzleitfaden bietet einen herstellerneutralen, architektonischen Tiefenblick in beide Protokolle. Wir untersuchen ihre Betriebsmechanismen, bewerten die Bereitstellungskomplexitäten und geben umsetzbare Empfehlungen, um sicherzustellen, dass Ihre Netzwerkinfrastruktur moderne Sicherheitsstandards – einschließlich PCI DSS und GDPR-Konformität – erfüllt und gleichzeitig eine nahtlose Konnektivität für Ihre Benutzer aufrechterhält.

Technischer Tiefenblick: Protokollarchitektur

Um eine fundierte Entscheidung treffen zu können, ist es unerlässlich, die zugrunde liegenden Mechanismen zu verstehen, wie diese Protokolle das 802.1X-Authentifizierungsframework sichern. Beide Protokolle verwenden einen RADIUS-Server zur Bearbeitung von Authentifizierungsanfragen, aber ihre Methoden zur Identitätsvalidierung unterscheiden sich grundlegend. Für ein grundlegendes Verständnis der RADIUS-Infrastruktur verweisen wir auf unseren Leitfaden zu Was ist RADIUS? Wie RADIUS-Server WiFi-Netzwerke sichern .

EAP-TLS: Gegenseitige Zertifikatsauthentifizierung

EAP-TLS basiert auf dem Prinzip der gegenseitigen Authentifizierung. Sowohl das Client-Gerät (Supplikant) als auch der Authentifizierungsserver (RADIUS) müssen gültige digitale Zertifikate vorlegen, um eine Verbindung herzustellen.

Der Handshake: Wenn ein Gerät versucht, sich zu verbinden, präsentiert der RADIUS-Server sein Zertifikat dem Client. Der Client validiert dieses Zertifikat anhand seiner vertrauenswürdigen Root-Zertifizierungsstellen (CAs). Sobald der Server verifiziert ist, präsentiert der Client sein eigenes einzigartiges Zertifikat dem Server. Wenn beide Zertifikate gültig und nicht widerrufen wurden – geprüft über CRL oder OCSP – wird eine sichere TLS-Sitzung aufgebaut und der Netzwerkzugriff gewährt.

Diese gegenseitige Verifizierung macht EAP-TLS hochresistent gegen den Diebstahl von Anmeldeinformationen, Wörterbuchangriffe und Man-in-the-Middle (MitM)-Angriffe. Da keine Passwörter übertragen werden, können kompromittierte Benutzeranmeldeinformationen nicht zum Eindringen in das Netzwerk verwendet werden.

PEAP: Tunnelbasierte Passwortauthentifizierung

PEAP wurde als besser einsetzbare Alternative zu EAP-TLS entwickelt, die die Notwendigkeit clientseitiger Zertifikate eliminiert und dennoch robuste Sicherheit bietet.

Tunnelaufbau: Der RADIUS-Server präsentiert sein Zertifikat dem Client. Der Client validiert den Server und baut einen verschlüsselten TLS-Tunnel auf. Innerhalb dieses sicheren Tunnels führt der Client eine standardmäßige passwortbasierte Authentifizierung – typischerweise MSCHAPv2 – gegen einen Identitätsanbieter wie Active Directory durch. Der RADIUS-Server validiert die Anmeldeinformationen und gewährt Zugriff.

Obwohl PEAP bei korrekter Konfiguration hochsicher ist, hängt es davon ab, dass Benutzer starke Passwörter verwenden. Entscheidend ist, dass, wenn das Gerät eines Benutzers nicht zur Validierung des Serverzertifikats konfiguriert ist, ein nicht autorisierter Access Point Anmeldeinformationen abfangen kann. Dies ist kein theoretisches Risiko; es ist ein gut dokumentierter Angriffsvektor, der in realen Penetrationstests verwendet wird.

Dimension	EAP-TLS	PEAP
Sicherheitsniveau	Sehr hoch — gegenseitige Zertifikatsauthentifizierung	Hoch — verschlüsselter Tunnel, nur Serverzertifikat
Anmeldeinformationen	Digitale Client- und Serverzertifikate	Benutzername und Passwort (innerhalb des TLS-Tunnels)
Bereitstellungskomplexität	Höher — erfordert PKI und MDM	Niedriger — integriert sich in bestehende Verzeichnisdienste
Am besten geeignet für	Unternehmenseigene Geräteflotten, regulierte Branchen	BYOD-Umgebungen, Organisationen ohne PKI
Client-Zertifikat erforderlich	Ja	Nein
PCI DSS / GDPR-Eignung	Ausgezeichnet — bevorzugt für Umgebungen mit hohen Compliance-Anforderungen	Gut — konform bei erzwungener Servervalidierung

Implementierungsleitfaden: Bereitstellungsstrategien

Der Hauptunterschied zwischen EAP-TLS und PEAP liegt in ihrer Bereitstellungskomplexität und dem Lebenszyklusmanagement.

EAP-TLS bereitstellen

Die Implementierung von EAP-TLS erfordert eine robuste Public Key Infrastructure (PKI) zur Ausstellung, Verwaltung und zum Widerruf von Zertifikaten für jedes Gerät im Netzwerk. Mobile Device Management (MDM)- oder Enterprise Mobility Management (EMM)-Lösungen sind praktisch obligatorisch, um die Zertifikatsbereitstellung für Endpunkte im großen Maßstab zu automatisieren. IT-Teams müssen die Zertifikatslebenszyklen verwalten, Verlängerungen vor dem Ablauf handhaben und den sofortigen Widerruf für verlorene Geräte oder ausscheidende Mitarbeiter sicherstellen. EAP-TLS eignet sich am besten für Unternehmensnetzwerke mit unternehmenseigenen Geräten, stark regulierte Umgebungen wie das Gesundheitswesen oder Finanzwesen sowie Zero-Trust-Architekturen.

PEAP bereitstellen

PEAP ist deutlich einfacher bereitzustellen, da es bestehende Identitätsspeicher – Active Directory, LDAP oder Cloud-Verzeichnisse – nutzt, ohne Client-Zertifikate zu erfordern. Ein RADIUS-Server mit einem gültigen Serverzertifikat (idealerweise feiner öffentlichen CA) und die Integration mit Ihrem bestehenden Verzeichnisdienst sind für den Start ausreichend. Der Betriebsaufwand ist minimal: Benutzer authentifizieren sich mit ihren standardmäßigen Unternehmenszugangsdaten. Es gelten Richtlinien zur Passwortrotation, die zu einem geringen Helpdesk-Aufwand führen können, wenn Benutzer vergessen, ihre WiFi-Profile nach einer Passwortänderung zu aktualisieren. PEAP eignet sich am besten für BYOD-Umgebungen, den Bildungssektor und Organisationen ohne etablierte PKI- oder MDM-Infrastruktur.

Best Practices und Industriestandards

Unabhängig vom gewählten Protokoll ist die Einhaltung von Industriestandards zur Risikominderung unerlässlich.

Serverzertifikatsvalidierung erzwingen: Die häufigste Schwachstelle bei PEAP-Implementierungen sind falsch konfigurierte Client-Geräte, die das Zertifikat des RADIUS-Servers nicht validieren. Dies ermöglicht Angreifern, nicht autorisierte Access Points einzurichten und Anmeldeinformationen abzugreifen. Die IT muss Gruppenrichtlinien oder MDM-Profile verwenden, um eine strikte Servervalidierung auf jedem Endpunkt zu erzwingen.

RADIUS-Redundanz implementieren: Die Authentifizierung ist ein kritischer Pfad. Stellen Sie sicher, dass Ihre RADIUS-Infrastruktur hochverfügbar ist. Cloud-basierte RADIUS-Lösungen können lokale Single Points of Failure reduzieren. Die architektonischen Überlegungen zur Ausfallsicherheit verteilter Netzwerke werden ausführlicher in Die wichtigsten SD WAN-Vorteile für moderne Unternehmen erörtert.

Integration mit modernen Identitätsanbietern: Für öffentlich zugängliche Orte kann die Nutzung einer robusten Guest WiFi -Plattform, die als sicherer Identitätsanbieter fungiert, den Zugang optimieren und gleichzeitig die Sicherheit gewährleisten. Die Connect-Lizenz von Purple bietet beispielsweise einen kostenlosen Identitätsanbieter für Dienste wie OpenRoaming und überbrückt die Lücke zwischen Unternehmenssicherheit und nahtlosem Gast-Onboarding.

Netzwerksegmentierung nach der Authentifizierung: Eine erfolgreiche 802.1X-Authentifizierung sollte keinen uneingeschränkten Zugriff auf das gesamte Unternehmenssubnetz gewähren. Verwenden Sie dynamische VLAN-Zuweisungsrichtlinien, um Benutzer in geeignete Netzwerksegmente mit eingeschränkten ACLs zu platzieren.

Fehlerbehebung & Risikominderung

Beim Management von 802.1X-Netzwerken müssen IT-Teams auf gängige Fehlerursachen vorbereitet sein.

Zertifikatsablauf (EAP-TLS): Wenn das CA-Zertifikat oder das RADIUS-Serverzertifikat abläuft, schlagen alle Authentifizierungen gleichzeitig fehl. Implementieren Sie eine aggressive Überwachung und Alarmierung für Zertifikatsgültigkeitsdauern – setzen Sie Alarme 90, 30 und 7 Tage vor dem Ablaufdatum.

Supplikanten-Fehlkonfiguration (PEAP): Das Versäumnis, das Serverzertifikat zu validieren, ist ein kritisches Risiko. Überprüfen Sie regelmäßig die Endpunktkonfigurationen, um sicherzustellen, dass die „Serverzertifikatsvalidierung“ strikt durchgesetzt wird. Nehmen Sie dies als Standardpunkt in Ihre Sicherheits-Audit-Checkliste auf.

RADIUS-Timeout-Probleme: Hohe Latenzzeiten zwischen dem Wireless Controller und dem RADIUS-Server oder zwischen dem RADIUS-Server und Active Directory können EAP-Timeouts und Authentifizierungsfehler verursachen. Sorgen Sie für eine robuste Konnektivität und ziehen Sie lokale RADIUS-Proxys für verteilte Standorte in Betracht. Dies ist besonders relevant für Multi-Site Transport - und Einzelhandelsimplementierungen.

Angriffe durch Rogue Access Points: Führen Sie regelmäßige Wireless-Sicherheitsbewertungen durch, um Rogue APs zu erkennen. Wireless Intrusion Detection Systems (WIDS), die in Ihre Access Point-Infrastruktur integriert sind, können eine kontinuierliche Überwachung bieten.

ROI & Geschäftsauswirkungen

Die Entscheidung zwischen EAP-TLS und PEAP hat erhebliche geschäftliche Auswirkungen, die über die technische Architektur hinausgehen.

EAP-TLS erfordert höhere anfängliche Investitionsausgaben (CapEx) für PKI- und MDM-Lösungen sowie laufende Betriebsausgaben (OpEx) für die Zertifikatsverwaltung. Es bietet jedoch das höchste Maß an Risikominderung gegen zugangsdatenbasierte Sicherheitsverletzungen, die zu verheerenden finanziellen und reputativen Schäden führen können. Für Einrichtungen, die sensible Daten verarbeiten oder unter strenger regulatorischer Compliance arbeiten, wird der ROI von EAP-TLS durch vermiedene Kosten für Sicherheitsverletzungen und optimierte Compliance-Audits realisiert. Eine einzige zugangsdatenbasierte Sicherheitsverletzung in einer Einzelhandels- oder Gastgewerbeumgebung kann Millionen an Sanierungskosten, behördlichen Bußgeldern und Markenschäden verursachen.

PEAP bietet eine schnellere Wertschöpfung und geringere Implementierungskosten. Es ist äußerst effektiv für Umgebungen, in denen das Hauptziel ein sicherer, verschlüsselter Zugang ohne den Overhead der Geräteverwaltung ist. Durch die Integration von PEAP mit einer umfassenden WiFi Analytics -Lösung können Einrichtungen den Zugang sicher verwalten und gleichzeitig wertvolle operative Erkenntnisse aus den Netzwerknutzungsdaten gewinnen – die Authentifizierungsinfrastruktur wird mit messbaren Geschäftsergebnissen wie Verweildaueranalyse, Besucherfrequenzmustern und Wiederkehrerquoten verbunden.

Schlüsselbegriffe & Definitionen

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.

Fallstudien

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.

Implementierungshinweise: 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.

Implementierungshinweise: 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.

Szenarioanalyse

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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.