- Purple
- Enterprise WiFi security and authentication: a complete guide
- EAP-TLS vs. PEAP: Which Authentication Protocol Is Right for Your Network?
EAP-TLS vs. PEAP: Which Authentication Protocol Is Right for Your Network?
Decide which 802.1X method each device group on your network should use: EAP-TLS for corporate-owned devices you can enroll, PEAP with locked server certificate validation for personal and contractor devices, and a captive portal or OpenRoaming for guests. You can also plan a migration that runs both methods on one RADIUS service without downtime.
Video overview
Listen to this guide
View podcast transcript
Part of our core series: Enterprise WiFi Security Guide →
- Should you choose EAP-TLS or PEAP?
- How do EAP-TLS and PEAP differ in practice?
- How the EAP-TLS handshake works
- How the PEAP handshake works
- Why server certificate validation decides PEAP's security
- EAP-TLS vs PEAP side by side
- Two platform changes that tilt the decision
- When is EAP-TLS the right call?
- Worked scenario: a 30-property hotel group
- When is PEAP the right call?
- Worked scenario: a convention center with seasonal staff
- What do EAP-TLS and PEAP cost to run?
- Where EAP-TLS spends
- Where PEAP spends
- Watch the server certificate lifetime
- The cost of getting it wrong
- Worked scenario: a 120-store retailer
- What breaks each protocol, and how do you prevent it?
- Expired certificates
- Server validation left off
- RADIUS latency and single points of failure
- Rogue access points
- A flat network after authentication
- How do you decide for your properties?
- A four-step route to a decision
- Where does Purple fit?
- Frequently asked questions
- Is EAP-TLS more secure than PEAP?
- Does PCI DSS require EAP-TLS for wireless networks?
- Can we move from PEAP to EAP-TLS without downtime?
- Do we need an MDM to run EAP-TLS?
- What does EAP-TLS cost compared with PEAP?
- Will Purple work with the access points we already own?
- Should guests use EAP-TLS or PEAP?
- Is PEAP still safe to use in 2026?
EAP-TLS vs PEAP authentication decision tool
Evaluate your directory infrastructure, device ownership mix, and security compliance to determine the optimal 802.1X wireless protocol for your organisation.
Determines credential protocols supported at directory level.
Governs certificate provisioning capability without user intervention.
Sets threshold for password elimination and hardware TPM isolation.
EAP-TLS (Mutual Certificate-Based 802.1X)
Eliminate password-based attacks with cryptographic device certificates.
Evil Twin & MITM resistance
Immune to Evil Twin rogue APs: client and server each prove possession of a private key, so there is no reusable password for a rogue AP to capture.
Helpdesk & credential friction
0% password-related WiFi lockouts. Certificates renew silently in the background via MDM.
Microsoft Entra ID does not support legacy password hashing (NTLM/MSCHAPv2) natively. EAP-TLS with Microsoft Intune Cloud PKI / SCEP and Cloud RADIUS provides the direct native integration path.
Migrate your enterprise WiFi to certificate-based 802.1X
Connect with Purple technical architects to design your zero-trust wireless authentication, integrate Cloud RADIUS with Microsoft Entra ID, and eliminate credential exposure.
Choose EAP-TLS when you control the devices. Each device proves its identity with a certificate, so there is no password to phish or crack. Choose PEAP when you cannot issue certificates, such as on personal devices, and enforce server certificate validation on every client. Neither suits anonymous guests, so use a captive portal or OpenRoaming instead.
Should you choose EAP-TLS or PEAP?
Both protocols run inside IEEE 802.1X, the standard for port-based network access control. 802.1X makes a device prove who it is before the access point forwards its traffic. That proof travels as EAP (Extensible Authentication Protocol) messages to a RADIUS server, the service that approves or rejects each connection.
EAP-TLS and PEAP are two ways of carrying that proof. The difference is what the device presents.
- EAP-TLS is defined in RFC 5216 and updated for TLS 1.3 in RFC 9190. The server and the device each present a digital certificate. Identity rests on a private key that never leaves the device.
- PEAP (Protected EAP) asks only the server for a certificate. The device builds an encrypted tunnel to the server, then sends a username and password inside it, almost always with MSCHAPv2.
The short recommendation:
- Managed laptops, tablets, scanners and payment devices: EAP-TLS.
- Personal cell phones and contractor devices you cannot enroll: PEAP, with server certificate validation locked on.
- Guests, fans, passengers and shoppers: neither. Use a captive portal or OpenRoaming through Guest WiFi.
Most properties run both methods on one RADIUS service, separated by device ownership. The rest of this guide shows where that line falls and what each side costs to run.
How do EAP-TLS and PEAP differ in practice?
How the EAP-TLS handshake works
The RADIUS server sends its certificate first. The device checks it against a trusted root certificate authority (CA). The device then sends its own certificate and proves it holds the matching private key.
The server confirms the device certificate is valid and has not been revoked. It checks revocation with a certificate revocation list (CRL) or OCSP (Online Certificate Status Protocol, RFC 6960). Only then does the access point admit the device.
No password crosses the network at any point. A phished password cannot open the network, because the network never asks for one.
How the PEAP handshake works
The RADIUS server sends its certificate and the device validates it. The two sides build a TLS tunnel. Inside that tunnel, the device runs MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) against a directory such as Active Directory. If the credentials match, the device gets access.
Microsoft, Cisco and RSA Security developed PEAP together. It never became an IETF standard. Microsoft publishes the version most devices use in its MS-PEAP protocol specification.
Why server certificate validation decides PEAP's security
The tunnel protects the password only if the device checks who is at the other end. Skip that check, and an attacker can broadcast your network name from a rogue access point, known as an "evil twin". The device then completes MSCHAPv2 with the attacker and hands over a challenge and response.
In 2012, Microsoft Security Advisory 2743314 warned that unencapsulated MSCHAPv2 exchanges can be cracked. Microsoft's mitigation was to wrap them in PEAP with server certificate validation enforced. That remains the rule today.
EAP-TLS does not share this weakness. A device that reaches a rogue access point has no reusable password to give away.
EAP-TLS vs PEAP side by side
| EAP-TLS | PEAP (MSCHAPv2) | |
|---|---|---|
| What the device presents | Its own certificate and private key | Username and password inside a TLS tunnel |
| Certificates required | Server and every client device | Server only |
| Defining specification | IETF RFC 5216 and RFC 9190 | Microsoft MS-PEAP specification |
| Exposure to phished or reused passwords | None - no password exists | Full - the password is the credential |
| Evil twin exposure | Low - no reusable secret to capture | High if server validation is off |
| WPA3-Enterprise 192-bit mode | Supported | Not supported |
| Windows Credential Guard | Unaffected | Blocks saved MSCHAPv2 credentials |
| Infrastructure you need | RADIUS, PKI, MDM or onboarding tool | RADIUS, server certificate, directory |
| Revoking one lost device | Revoke that one certificate | Reset the account, affecting all that person's devices |
| Effect of a password change | None | Every stored WiFi profile needs updating |
| Best fit | Corporate-owned fleets, payment and clinical devices | Personal devices, contractors, properties without PKI |
Two platform changes that tilt the decision
Windows. Microsoft's Credential Guard documentation states that MSCHAPv2-based WiFi and VPN connections cannot use saved credentials when Credential Guard is on. Credential Guard is enabled by default on eligible Windows 11 Enterprise and Education devices from version 22H2. Microsoft recommends moving to certificate-based methods such as EAP-TLS.
Android. Recent Android versions removed the option to skip server certificate validation. PEAP profiles must now name a CA certificate and a server domain. That closes the evil twin gap, but it makes manual setup harder for staff.
When is EAP-TLS the right call?
Choose EAP-TLS when three conditions hold. You own the devices, you can push configuration to them, and a compromised password would cause real harm.
- Corporate-owned laptops managed through an MDM (mobile device management) platform such as Microsoft Intune.
- Point-of-sale terminals and handheld scanners on networks in scope for PCI DSS.
- Clinical tablets and carts in Healthcare, where a shared ward password is a standing risk.
- Back-office, front-desk and housekeeping devices in hotels.
- Networks built for WPA3-Enterprise 192-bit mode, which the WPA3 specification ties to EAP-TLS cipher suites.
Certificates also make offboarding precise. Revoke one certificate and one device loses access, while the person's other devices keep working. That maps cleanly to joiners, movers and leavers in your MDM and directory.
Store private keys as non-exportable, in the device's TPM (Trusted Platform Module) or secure enclave where the hardware supports it. A certificate that cannot be copied off the device cannot be reused elsewhere.
Worked scenario: a 30-property hotel group
The scenarios in this guide are composites of common deployments, not named customer results.
Situation. A hotel group runs 30 properties of about 200 rooms each. Back-office laptops, housekeeping tablets and front-desk PCs share one Staff WiFi network. Devices sign in with PEAP using a handful of shared Active Directory accounts. When a tablet goes missing, IT resets the shared password and reconfigures every device that uses it.
What was done. Every device was already enrolled in an MDM. The team stood up a cloud PKI (public key infrastructure, the system that issues and revokes certificates). They pushed device certificates using SCEP (Simple Certificate Enrollment Protocol, RFC 8894). The Staff WiFi profile then switched to EAP-TLS. PEAP stayed live on the same RADIUS service throughout the cutover. Dynamic VLAN assignment placed housekeeping tablets on a different segment from finance laptops.
Outcome. Shared WiFi accounts fell to zero. A lost tablet now costs one certificate revocation instead of a password reset across dozens of devices. Password rotation no longer breaks WiFi, because no WiFi password remains. More on hospitality networks is on our Hotels page.
When is PEAP the right call?
Choose PEAP when you cannot put a certificate on the device and the person signing in has a directory account.
- Staff on personal cell phones under a BYOD (bring your own device) policy, where MDM enrollment is not acceptable.
- Contractors, temporary event staff and agency workers with short-lived accounts.
- Real estate properties with Active Directory but no PKI, as an interim step towards EAP-TLS.
PEAP is acceptable for these cases only with three controls in place.
- Lock server certificate validation on every device. Name the trusted CA and the exact server name. Deploy it through Group Policy, an MDM profile or an onboarding tool, never by hand.
- Keep the server certificate predictable. Issue it from a CA your devices already trust, and keep the server name stable across renewals.
- Harden the directory password. PEAP is only as strong as the password inside the tunnel. Enforce length, and block known-compromised passwords at the directory.
Worked scenario: a convention center with seasonal staff
Situation. A city-center conference and events venue hires around 300 temporary staff each peak season. They use their own cell phones for rostering and radio apps. The venue cannot ask them to enroll personal cell phones in an MDM. Until then, a shared WPA2-Personal password hung on the staff room noticeboard.
What was done. IT created a directory account with an end date for each temporary worker. Staff WiFi moved to PEAP. A one-time onboarding profile fixed the CA and server name on each cell phone. Accounts disable automatically on the contract end date. Attendees stayed on a separate captive portal network.
Outcome. The shared password was retired. Leavers now lose access on their end date, not at the next password change. Every staff connection maps to a named account in the RADIUS logs, which the security team can audit after each event.
Got questions about your specific setup?
Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.
What do EAP-TLS and PEAP cost to run?
Neither protocol carries a license fee. Both are built into Windows, macOS, iOS, Android and ChromeOS. The cost sits in infrastructure and staff time.
| Cost line | EAP-TLS | PEAP |
|---|---|---|
| RADIUS service | Required | Required |
| RADIUS server certificate | Required, renewed on the CA's schedule | Required, renewed on the CA's schedule |
| PKI to issue client certificates | Required, on-premises or cloud | Not required |
| MDM or onboarding tool | Required beyond a pilot | Recommended, to enforce server validation |
| Client certificate renewals | Every device, on a schedule you set | None |
| WiFi password tickets | None | Lockouts and profile updates after each change |
| Audit evidence for wireless access | Certificate issuance and revocation logs | Account and password policy records |
Where EAP-TLS spends
EAP-TLS front-loads the cost. You pay for a PKI and the staff time to design certificate templates, enrollment and revocation. If you already run an MDM, much of the delivery cost is covered. After launch, the main recurring task is certificate renewal, which an MDM automates.
Where PEAP spends
PEAP starts cheaply but costs more as you go. Each password change can leave stale credentials on cell phones and laptops. Repeated failed attempts can then lock the account in Active Directory, which generates a helpdesk ticket. Those costs scale with headcount and password rotation frequency.
Watch the server certificate lifetime
If your RADIUS server certificate comes from a public CA, its lifetime is getting shorter. The CA/Browser Forum's Ballot SC-081 cuts maximum public TLS certificate lifetimes in stages. The limit falls to 200 days from March 2026 and to 47 days from March 2029. Many teams issue the RADIUS certificate from a private CA instead, which keeps renewals on their own schedule.
The cost of getting it wrong
IBM's Cost of a Data Breach Report 2024 put the global average breach cost at USD 4.88 million. Stolen or compromised credentials were among the most common initial attack vectors in that report. EAP-TLS removes WiFi passwords from the attack surface for every device it covers.
Worked scenario: a 120-store retailer
Situation. A retailer runs 120 stores with handheld scanners and mobile point-of-sale devices on PEAP. The devices share a service account. Each scheduled rotation of that account caused overnight authentication failures in stores where devices kept the old password.
What was done. IT moved scanners and payment devices to EAP-TLS, using the MDM it already ran. Each device received its own certificate. Store staff cell phones stayed on PEAP, on a separate VLAN with no route to the cardholder data environment.
Outcome. Rotation-day outages stopped, because in-scope devices no longer depended on a shared password. Revocation became per device rather than per store. Quarterly rogue access point checks under PCI DSS requirement 11.2.1 continued unchanged. See our Retail page for more on store networks.
What breaks each protocol, and how do you prevent it?
Expired certificates
If the CA certificate or the RADIUS server certificate expires, every authentication fails at once. This affects EAP-TLS and PEAP alike. Set alerts 90, 30 and seven days before each expiry date, and name an owner for every certificate.
Server validation left off
A PEAP profile that skips server validation hands credentials to any evil twin. Audit device profiles regularly and add the check to your security review. Remove any manual setup instructions that tell staff to tap "Don't validate".
RADIUS latency and single points of failure
Authentication sits on the critical path. High latency between controller, RADIUS server and directory causes EAP timeouts. Run RADIUS with redundancy, or use cloud RADIUS with more than one region. For distributed properties such as stations and rolling stock on Trains, place a local RADIUS proxy close to the access points.
Rogue access points
Use the wireless intrusion detection built into your access point platform to flag rogue devices continuously. If you take card payments, PCI DSS requirement 11.2.1 requires you to test for unauthorized access points at least every three months.
A flat network after authentication
A successful 802.1X login should not open the whole network. Use dynamic VLAN assignment, where RADIUS returns the VLAN (virtual LAN) for each device using the attributes defined in RFC 3580. Payment devices, staff cell phones and building systems then land on separate segments with their own access controls.
How do you decide for your properties?
Start from device ownership, not protocol preference. The matrix below maps common situations to a recommendation.
| Your situation | Recommended method | Why |
|---|---|---|
| Corporate laptops already in an MDM | EAP-TLS | Certificates deploy through tooling you already pay for |
| Payment terminals and scanners in PCI DSS scope | EAP-TLS | No shared password to rotate or leak |
| Clinical devices on hospital wards | EAP-TLS | Per-device revocation, no shared ward password |
| Staff personal phones, no MDM allowed | PEAP with locked server validation | Directory login without enrolling the phone |
| Seasonal and contract staff | PEAP with dated accounts | Access ends automatically on the contract end date |
| Smart TVs, printers and sensors without 802.1X | iPSK on a dedicated VLAN | Unique key per device, no 802.1X supplicant needed |
| Hotel guests, fans, passengers and shoppers | Captive portal or OpenRoaming | No directory account and no device to manage |
iPSK (identity pre-shared key, also called PPSK) gives each device or group its own WiFi key on one network name. Use it for devices that cannot run an 802.1X supplicant.
A four-step route to a decision
- Inventory devices by ownership. Split them into corporate-managed, personal, headless and guest.
- Check what you already run. An existing MDM makes EAP-TLS for managed devices a modest project.
- Set the target state. EAP-TLS for every managed device, PEAP only where enrollment is impossible.
- Migrate in place. Run both methods on one RADIUS service, move managed devices to EAP-TLS, then retire their PEAP profiles.
Where does Purple fit?
Purple is hardware-agnostic. We run as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. There is no rip and replace. Purple layers on top of the network you run today.
For staff and residents, Purple's Identity-Based Networks tie Staff WiFi and Multi-Family WiFi access to identity. They work through cloud RADIUS linked to Microsoft Entra ID, Okta or Google Workspace. Joiners, movers and leavers are then handled from the directory rather than by hand. Devices that cannot run 802.1X get iPSK.
For guests, Purple's Guest WiFi offers a captive portal, a web page shown before access, with conscious-choice opt-ins. It also supports OpenRoaming, the Wireless Broadband Alliance federation built on Passpoint (Hotspot 2.0). OpenRoaming lets returning devices join automatically over an encrypted connection. Purple's Connect plan includes an identity provider for OpenRoaming. WiFi Analytics then turns those connections into first-party data on dwell time and repeat visits.
Purple runs across 80,000+ live venues and handled 440 million logins in 2024 (Purple's own data). Purple is ISO 27001 certified, CCPA/CPRA compliant and Cyber Essentials certified.
Frequently asked questions
Is EAP-TLS more secure than PEAP?
Yes. EAP-TLS authenticates both sides with certificates, so there is no password to phish, guess or capture from a rogue access point. PEAP protects a password inside an encrypted tunnel. Its security depends on every device validating the server certificate. Configured well, PEAP is acceptable for personal devices. For corporate-owned devices, payment terminals and clinical equipment, EAP-TLS removes an entire class of credential attack.
Does PCI DSS require EAP-TLS for wireless networks?
No. PCI DSS v4.0 does not name an EAP method. It requires strong cryptography on wireless networks carrying cardholder data and quarterly checks for unauthorized access points under requirement 11.2.1. It also sets password controls wherever passwords are used. EAP-TLS takes WiFi passwords out of scope for in-scope devices, which shortens your evidence. PEAP can comply too, if server validation and password policy are enforced and documented.
Can we move from PEAP to EAP-TLS without downtime?
Yes. One RADIUS service can accept both methods on the same network name. Each device uses whichever method its profile specifies. Issue certificates and push the new EAP-TLS profile through your MDM, then watch RADIUS logs as devices switch over. When no managed devices still authenticate with PEAP, remove their PEAP profiles. Keep PEAP only for the personal devices you cannot enroll.
Do we need an MDM to run EAP-TLS?
For more than a handful of devices, yes in practice. Every device needs a certificate, a trusted CA and a WiFi profile. Each certificate must also be renewed before it expires. An MDM such as Microsoft Intune automates this through SCEP or a similar enrollment protocol. Without one, an onboarding tool can install certificates on personal devices, but manual installation does not scale beyond a pilot.
What does EAP-TLS cost compared with PEAP?
Neither protocol has a license fee. The difference is infrastructure and staff time. PEAP needs a RADIUS service, one server certificate and a directory you probably already run. EAP-TLS adds a PKI, in the cloud or on-premises, and an MDM to deliver and renew certificates. If you already pay for an MDM, the extra cost is mainly the PKI. In exchange, WiFi password resets and rotation lockouts disappear.
Will Purple work with the access points we already own?
Yes. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. All of these support 802.1X with an external RADIUS server. Your access points do not limit the choice between EAP-TLS and PEAP. There is no rip and replace: Purple layers on top of the network you run today.
Should guests use EAP-TLS or PEAP?
No. Both protocols assume a known person or a managed device, and hotel, stadium and station guests are neither. Use a captive portal for opt-ins and terms of use. Use OpenRoaming, built on Passpoint, so returning devices connect automatically over an encrypted link. Purple's Guest WiFi covers both, and the Connect plan includes an identity provider for OpenRoaming.
Is PEAP still safe to use in 2026?
Yes, within limits. PEAP with locked server certificate validation and strong directory passwords remains a reasonable choice for personal devices. Its role is shrinking on Windows, where Credential Guard blocks saved MSCHAPv2 credentials. Microsoft recommends certificate-based authentication instead. Plan EAP-TLS for every managed Windows device, and keep PEAP for the devices you do not control.
Key Definitions
IEEE 802.1X
The IEEE standard for port-based network access control. It requires a device to authenticate before the access point forwards its traffic, carrying the exchange as EAP messages to a RADIUS server.
Both EAP-TLS and PEAP run inside 802.1X, so the choice in this guide is which EAP method your 802.1X deployment uses, not whether to use 802.1X.
EAP-TLS
An EAP method defined in IETF RFC 5216 and updated for TLS 1.3 in RFC 9190. Server and device each present a digital certificate, and the device proves it holds a private key that never leaves it.
The recommended method for corporate-owned laptops, payment terminals, scanners and clinical devices, because no password crosses the network and one lost device costs one certificate revocation.
PEAP
Protected EAP, developed by Microsoft, Cisco and RSA Security and documented in Microsoft's MS-PEAP protocol specification rather than an IETF standard. Only the server presents a certificate; the device sends credentials inside a TLS tunnel.
The fallback for personal phones and contractor devices you cannot enroll. It is acceptable only with server certificate validation locked on and strong directory passwords.
MSCHAPv2
Microsoft Challenge Handshake Authentication Protocol version 2, the password-based inner method almost always used inside PEAP. Microsoft Security Advisory 2743314 (2012) warned that unencapsulated MSCHAPv2 exchanges can be cracked.
Its weakness is why server certificate validation decides PEAP's security, and why Windows Credential Guard now blocks saved MSCHAPv2 WiFi credentials.
RADIUS
The authentication service that receives EAP messages relayed by the access point and approves or rejects each 802.1X connection, optionally returning attributes such as the VLAN for the device.
One RADIUS service can accept EAP-TLS and PEAP on the same network name, which makes a zero-downtime migration possible. Run it with redundancy, because authentication sits on the critical path.
Evil twin
A rogue access point that broadcasts your network name. A PEAP client that skips server certificate validation completes MSCHAPv2 with it and hands over a challenge and response.
The main PEAP risk. Recent Android versions removed the option to skip validation, and PCI DSS requirement 11.2.1 requires quarterly checks for unauthorized access points.
OCSP and CRL
Online Certificate Status Protocol (RFC 6960) and the certificate revocation list, the two mechanisms a RADIUS server uses to confirm a client certificate has not been revoked during the EAP-TLS handshake.
Revocation checking is what makes per-device offboarding work: revoke one certificate and only that device loses access.
PKI
Public key infrastructure, the system that issues and revokes certificates, run on-premises or in the cloud. EAP-TLS needs it to issue a certificate to every client device.
The main front-loaded cost of EAP-TLS. If you already pay for an MDM, the PKI is most of the extra spend compared with PEAP.
SCEP
Simple Certificate Enrollment Protocol, specified in RFC 8894, used by MDM platforms such as Microsoft Intune to request and install device certificates automatically.
How certificates reach managed devices at scale and get renewed before expiry, which is why manual installation does not scale beyond a pilot.
Dynamic VLAN assignment
RADIUS returning a VLAN (virtual LAN) for each authenticated device using the tunnel attributes defined in RFC 3580, so the access point places the device on the right segment.
Stops a successful 802.1X login opening a flat network, keeping payment devices away from staff phones and out of reach of the cardholder data environment.
Windows Credential Guard
A Windows security feature that, per Microsoft's documentation, prevents MSCHAPv2-based WiFi and VPN connections using saved credentials. It is enabled by default on eligible Windows 11 Enterprise and Education devices from version 22H2.
A platform change that tilts the decision toward EAP-TLS for managed Windows fleets, as Microsoft recommends certificate-based methods.
iPSK
Identity pre-shared key, also called PPSK, which gives each device or group its own WiFi key on one network name without an 802.1X supplicant.
The right choice for smart TVs, printers and sensors that cannot run EAP-TLS or PEAP, placed on a dedicated VLAN.
Worked Examples
A 30-property hotel group runs back-office laptops, housekeeping tablets and front-desk PCs on one Staff WiFi network using PEAP with a handful of shared Active Directory accounts. Each lost tablet forces a shared password reset and reconfiguration of every device using it.
Every device was already enrolled in an MDM, so the team stood up a cloud PKI and pushed device certificates using SCEP (RFC 8894). The Staff WiFi profile then switched to EAP-TLS, while PEAP stayed live on the same RADIUS service throughout the cutover. Dynamic VLAN assignment placed housekeeping tablets on a different segment from finance laptops. Shared WiFi accounts fell to zero. A lost tablet now costs one certificate revocation instead of a password reset across dozens of devices, and password rotation no longer breaks WiFi because no WiFi password remains.
A city-center conference venue hires around 300 temporary staff each peak season. They use personal phones for scheduling and radio apps, cannot be asked to enroll them in an MDM, and have shared one WPA2-Personal password pinned to the staff room bulletin board.
IT created a directory account with an end date for each temporary worker and moved Staff WiFi to PEAP. A one-time onboarding profile fixed the trusted CA and server name on each phone, closing the evil twin gap without MDM enrollment. Accounts disable automatically on the contract end date, and attendees stayed on a separate captive portal network. The shared password was retired. Leavers lose access on their end date rather than at the next password change, and every staff connection maps to a named account in the RADIUS logs for audit after each event.
A 120-store retailer runs handheld scanners and mobile point-of-sale devices on PEAP with a shared service account. Every scheduled rotation of that account causes overnight authentication failures in stores where devices keep the old password.
IT moved scanners and payment devices to EAP-TLS through the MDM it already ran, giving each device its own certificate. Store staff phones stayed on PEAP, on a separate VLAN with no route to the cardholder data environment. Rotation-day outages stopped because in-scope devices no longer depended on a shared password, and revocation became per device rather than per store. Quarterly rogue access point checks under PCI-DSS requirement 11.2.1 continued unchanged, while removing WiFi passwords from in-scope devices shortened the evidence needed for audit.
Practice Questions
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?
Hint: Consider the operational overhead of certificate management on unmanaged, personally owned devices across a heterogeneous device estate.
View model answer
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?
Hint: Think about what happens during the TLS tunnel establishment phase in PEAP, and what the client device is - or is not - checking.
View model answer
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?
Hint: Evaluate the regulatory environment, the level of device control, and the sensitivity of the data being accessed.
View model answer
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 HIPAA 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 authorized, 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.
Frequently asked questions
What is the key difference between EAP-TLS and PEAP?
The fundamental difference is mutual authentication using digital certificates. EAP-TLS requires cryptographic X.509 certificates on both the RADIUS server and the client device, completely eliminating passwords and credential-based attacks. PEAP (typically PEAP-MSCHAPv2) only requires a digital certificate on the RADIUS server, while client devices authenticate using traditional usernames and passwords tunneled through an encrypted TLS session.
Why is PEAP-MSCHAPv2 considered vulnerable to credential theft and rogue AP attacks?
PEAP-MSCHAPv2 relies on the client device validating the RADIUS server certificate before transmitting credentials. In practice, unmanaged endpoints and misconfigured supplicants often fail to validate the server certificate or domain name. An attacker operating a rogue access point (Evil Twin) can present a fake certificate, capture the MSCHAPv2 challenge and response exchange, and crack the user password offline using cloud-based dictionary or rainbow table attacks.
Can EAP-TLS be deployed on unmanaged or BYOD devices?
Deploying EAP-TLS on unmanaged personal devices requires an automated onboarding workflow or captive portal onboarding assistant that provisions a short-lived or revocable client certificate. Because manual certificate installation is complex for non-technical users, organisations lacking an automated certificate onboarding mechanism often deploy EAP-TTLS with cloud directory credentials or WPA3-Enterprise with Passpoint profiles for BYOD fleets.
How does Microsoft Entra ID handle EAP-TLS compared to PEAP?
Microsoft Entra ID (formerly Azure AD) does not support legacy password-based authentication protocols like MSCHAPv2 because it does not store password hashes on-premises. As a result, native cloud Entra ID environments cannot directly authenticate PEAP-MSCHAPv2 without legacy hybrid domain controllers. EAP-TLS is the standard for Entra ID networks, pairing Microsoft Intune and Cloud PKI or SCEP with a cloud RADIUS server to authenticate devices based on verified directory identity.
What operational infrastructure is required to manage EAP-TLS client certificates?
EAP-TLS requires a Public Key Infrastructure (PKI) - either an on-premises Certificate Authority (such as AD CS) or a cloud PKI service - and a mobile device management (MDM) platform like Microsoft Intune, Jamf, or Workspace ONE to automatically issue, renew, and revoke certificates via SCEP (RFC 8894) or EST. The wireless network also requires an 802.1X-capable RADIUS server to validate incoming certificate chains and check revocation status via CRL or OCSP.
How does Cloud RADIUS simplify migrating from PEAP to EAP-TLS?
Cloud RADIUS eliminates the need to deploy and patch physical on-premises RADIUS servers (such as Windows Server NPS or FreeRADIUS clusters). Modern cloud RADIUS platforms integrate directly with cloud identity providers like Microsoft Entra ID, Okta, and Google Workspace, validate client certificates dynamically against issuing CAs, and assign role-based VLANs and access policies without on-premises hardware or VPN tunnels.
Sources
- IETF RFC 5216: The EAP-TLS Authentication Protocol
- IETF RFC 9190: EAP-TLS 1.3
- IETF RFC 3580: IEEE 802.1X RADIUS Usage Guidelines
- Microsoft Security Advisory 2743314
- Microsoft Learn: Credential Guard overview
- PCI Security Standards Council document library (PCI DSS v4.0)
- CA/Browser Forum
- IBM Cost of a Data Breach Report
Continue reading in this series
Microsoft Cloud PKI for WiFi: EAP-TLS certificate deployment with Intune and Entra ID
You will be able to decide whether Microsoft Cloud PKI, a Cloud PKI root or bring your own CA (BYOCA) fits your estate. You can then deploy EAP-TLS WiFi certificates to Intune-managed devices without NDES. The guide also covers making RADIUS trust the chain, revoking certificates through the CRL and fixing the eight most common failures.
Configuring 802.1X on Juniper Mist with cloud RADIUS
You will be able to configure a WPA2 or WPA3-Enterprise WLAN on Juniper Mist that authenticates against cloud RADIUS, decide between UDP RADIUS, RadSec and a Mist Edge proxy, and map RADIUS attributes to dynamic VLANs. You will also know where Mist's client insights timeline and Marvis show exactly where a failed authentication broke.
iOS and macOS 802.1X troubleshooting: a deployment checklist for Intune, Jamf and Entra ID
Use this checklist to diagnose why iPhones, iPads and Macs fail 802.1X on Intune or Jamf Pro. Each failure maps to one of four causes: server trust, identity certificate, macOS mode or Entra ID group scoping. You will confirm the cause from eapolclient and RADIUS logs, apply the fix and stage future certificate rotations.
Got questions about your specific setup?
Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.