EAP-TLS vs PEAP: Certificates or Passwords for Wi-Fi

PEAP with MSCHAPv2 lets any device that can type a password onto the corporate network, and that convenience is exactly what an evil twin access point exploits when clients do not validate the RADIUS server. EAP-TLS removes the password altogether, but it replaces a help desk problem with a PKI problem: every device needs a certificate that is issued, renewed and revoked on time. This guide compares the two methods as a decision, not a feature list: the threat model of each, how each fails in real deployments, what Windows Credential Guard changes, the true lifecycle cost of certificates, and a migration path through MDM and SCEP. It is written for network, identity and endpoint engineers who own an 802.1X estate and need to decide whether PEAP can stay. For building EAP-TLS end to end, see the 802.1X and EAP-TLS Enterprise Wi-Fi Guide; this page goes deeper on the choice and the move.

Key takeaways

The short answer is EAP-TLS for managed devices. PEAP-MSCHAPv2 is acceptable only as a time-boxed migration path or for a narrow set of devices that cannot hold a certificate, on a separate SSID.
PEAP is only as strong as the client's server validation. A client that accepts any certificate will hand an MSCHAPv2 exchange to a rogue access point, and that exchange reduces to the strength of the user's password.
Credential Guard has already decided for many Windows estates. Microsoft blocks single sign-on for MS-CHAP when Credential Guard is on, which it is by default on eligible Windows 11 22H2 and later Enterprise and Education devices, and recommends moving to certificate-based methods.
EAP-TLS shifts risk to certificate operations. Expired RADIUS server certificates, unrevoked device certificates and weak enrolment controls are the new failure modes, so budget for PKI monitoring before cutover.
Migrate by ring, then remove the password path. Running EAP-TLS and PEAP on the same SSID indefinitely gives attackers the weaker path; set a retirement date and enforce it in RADIUS policy.

The short answer and the comparison table

Both methods run inside 802.1X and both use TLS. The difference is what proves the client's identity. In EAP-TLS (EAP type 13, RFC 5216, updated for TLS 1.3 by RFC 9190) both the server and the client present certificates and the handshake itself is the authentication. In PEAP, a Microsoft-defined method, only the server presents a certificate; it builds a TLS tunnel and an inner method runs inside it. On Windows that inner method is either EAP-MSCHAP v2 (shown as "Secure password") or EAP-TLS. Most real PEAP deployments use MSCHAPv2, so in this guide "PEAP" means PEAP-MSCHAPv2 unless stated.

Dimension	EAP-TLS	PEAP-MSCHAPv2
Client credential	Device or user certificate with Client Authentication EKU (1.3.6.1.5.5.7.3.2)	Directory username and password
Server credential	RADIUS server certificate with Server Authentication EKU (1.3.6.1.5.5.7.3.1)	Same
What an evil twin can capture	Nothing reusable: the client's private key never leaves the device	An MSCHAPv2 challenge and response that can be attacked offline to recover the password
Phishing and spraying exposure	None for the Wi-Fi credential	Password spraying (T1110.003) against RADIUS and reuse of the same password elsewhere
Credential Guard on Windows	Not blocked	Single sign-on blocked; users prompted and cannot save credentials
WPA3-Enterprise 192-bit mode	The only EAP method Microsoft documents as allowed	Not allowed
Main operational burden	PKI: enrolment, renewal, revocation, trust distribution	Passwords: resets, lockouts, change propagation to cached Wi-Fi profiles
Identity privacy	Client certificate encrypted under TLS 1.3; RFC 9190 makes anonymous outer identity mandatory to support	Real identity inside the tunnel; outer identity configurable

The wider set of EAP methods (EAP-TTLS, TEAP, EAP-FAST) is covered in the Wi-Fi Security Guide. How 802.1X relates to the RADIUS back end is in 802.1X vs RADIUS.

PEAP-MSCHAPv2: threat model and how it fails

Architecture in words: the supplicant associates, the access point relays EAP to RADIUS, the RADIUS server sends its certificate, the client builds a TLS tunnel to it, and inside the tunnel the client answers an MSCHAPv2 challenge using a hash of the user's password. RADIUS checks the response against the directory, often through Active Directory and NTLM. The tunnel exists to protect MSCHAPv2, because MSCHAPv2 on its own is weak.

Why MSCHAPv2 is the weak core. RFC 2759, an Informational document from January 2000, defines the NT-Response: the password is hashed with MD4, the 16-byte hash is zero-padded to 21 bytes, split into three 7-byte DES keys, and each key encrypts the same 8-byte challenge. Breaking the response therefore reduces to recovering DES keys, and the result is the NT hash, which is password-equivalent in many Windows contexts. Microsoft Security Advisory 2743314 (August 2012) acknowledged that published code could decrypt credentials from a captured MS-CHAP v2 handshake, and its main mitigation was to encapsulate MS-CHAP v2 inside PEAP. Microsoft's Credential Guard documentation now states that MSCHAPv2 Wi-Fi and VPN connections are subject to attacks similar to those on NTLMv1.

How the tunnel is bypassed. The PEAP tunnel only helps if the client refuses to build it to the wrong server. The attack (ATT&CK T1557 Adversary-in-the-Middle, in the context of T1669 Wi-Fi Networks) is an evil twin broadcasting the corporate SSID with its own RADIUS server and a self-signed or publicly issued certificate. A client that accepts the certificate completes the tunnel to the attacker and performs MSCHAPv2 inside it. The attacker now holds a challenge and response to attack offline (T1110.002 Password Cracking). The user sees, at most, a certificate prompt they have learnt to accept.

Where server validation breaks in practice:

Validation switched off: on Windows, Microsoft warns that disabling "Verify the server's identity by validating the certificate" exposes users to severe security risk. It is still found in hand-built profiles and old Group Policy objects.
No server names configured: if "Connect to these servers" is empty, Windows only checks that the certificate chains to a trusted root. If the trusted root list is also empty, any certificate from any root in the device store is accepted, which includes public CAs an attacker can obtain a certificate from.
Users allowed to decide: without "Don't prompt user to authorize new servers or trusted certification authorities", a user can click through to the attacker. Microsoft recommends selecting it.
Unmanaged and BYOD devices: a phone joined by typing a username and password usually has no pinned CA or server name, and on some platforms trust is taken on first use. These are the devices most easily lured.
Same password everywhere: the Wi-Fi password is normally the AD password, so a cracked Wi-Fi credential is a domain credential (T1078.002 Domain Accounts) that may also work on VPN and webmail.

Controls if PEAP must stay for a while: enforce server validation by policy with exact server names and a single pinned private root; restrict PEAP to a separate SSID and VLAN with minimal access; run wireless intrusion detection for rogue access points broadcasting your SSID; lock out and alert on repeated RADIUS failures; require strong, unique passwords; and never allow the same inner method inside and outside the tunnel, which Microsoft calls out explicitly (for example, not offering both PEAP-TLS and EAP-TLS).

EAP-TLS: threat model and how it fails

Architecture in words: the client holds a private key, ideally non-exportable in a TPM or secure enclave, and a certificate from an enterprise CA. During the TLS handshake the client validates the RADIUS server's certificate and proves possession of its own key. RADIUS validates the client chain, checks revocation and maps the certificate to an account or device record for authorisation. No reusable secret crosses the air. RFC 5216 requires peers and servers to support certificate revocation lists and recommends OCSP; RFC 9190 adds mandatory OCSP stapling support on the server for TLS 1.3 and caps resumption tickets at seven days.

What an attacker targets instead:

The enrolment path: if anyone can request a Client Authentication certificate (an open SCEP challenge, a permissive certificate template), the attacker enrols their own device. This is T1649 Steal or Forge Authentication Certificates territory and is the most important EAP-TLS control.
Exportable keys: a certificate whose private key can be exported from a lost or compromised laptop moves to an attacker's machine. Require TPM-backed or hardware-backed keys where the platform supports them.
Revocation that is not checked: a stolen device keeps network access until its certificate expires if RADIUS does not check a current CRL or OCSP responder, or if the leaver process never revokes.
Weak authorisation on top of strong authentication: RFC 9190 is explicit that the EAP-Response/Identity is unauthenticated, so authorisation must use certificate contents. Policies that trust the outer identity string, or any certificate from the corporate root, grant access too broadly.

How EAP-TLS fails operationally: the RADIUS server certificate expires and every client fails at once; a new server certificate is issued from a different intermediate the clients do not trust; certificate chains grow large enough to cause fragmentation problems on some access points; device certificates fail to renew because a device has been offline past its renewal window; and the CRL distribution point is unreachable from the RADIUS server, which then fails closed or, worse, is configured to ignore revocation. Each of these is predictable and monitorable, which is the real advantage over password failure modes.

Server validation still matters with EAP-TLS. A client that does not validate the server will not leak a password, but it can be associated with a rogue network. Configure the same server name and root pinning for both methods.

What Credential Guard changes

Microsoft's Credential Guard considerations page is the clearest vendor statement on this choice. When Credential Guard is enabled, single sign-on is blocked for MS-CHAP, WDigest and NTLMv1: these protocols still work if the user is prompted for credentials, but saved credentials cannot be used. For Wi-Fi and VPN, Microsoft recommends moving from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2 to certificate-based authentication such as PEAP-TLS or EAP-TLS, and states that Credential Guard does not block certificate-based authentication.

Credential Guard is enabled by default on eligible devices upgraded to Windows 11 version 22H2 or later and on Windows Server 2025, covering Enterprise and Education licences and some Pro licences that meet the hardware requirements, unless an organisation explicitly disabled it. The practical effect on a PEAP-MSCHAPv2 estate is a wave of password prompts, broken machine authentication before logon where it relied on cached user credentials, and pressure to disable Credential Guard to make Wi-Fi work. Disabling a credential theft protection to keep a weaker Wi-Fi method is the wrong trade. Treat the Windows 11 rollout as the migration trigger.

Certificate lifecycle burden, honestly costed

The argument for staying on PEAP is usually PKI effort. It is real, and it is mostly a one-time build plus monitoring.

Lifecycle stage	EAP-TLS work	PEAP-MSCHAPv2 equivalent
Issuance	Enterprise CA template or cloud PKI; autoenrolment for domain devices, SCEP or PKCS profiles through MDM for the rest	None beyond the account
Trust distribution	Push the private root (and intermediates) to every client through a trusted certificate profile or Group Policy	Same, and just as necessary for server validation
Server certificate	Server Authentication EKU, DNS name in SAN, renewal tracked well before expiry	Same
Renewal	Automatic through autoenrolment or MDM; offline devices are the exception to manage	Password expiry and resets, with stale cached Wi-Fi credentials causing lockouts
Revocation	Revoke on device loss and retirement; RADIUS checks CRL or OCSP	Disable the account, which also removes all other access
Help desk	Certificate missing or expired tickets, usually fixed by re-syncing MDM	Password reset and lockout tickets, and Credential Guard prompts

For Windows RADIUS on Network Policy Server, Microsoft documents the template requirements: the server certificate needs a subject name, the Server Authentication EKU and the server's DNS name in the SAN; client certificates need the Client Authentication EKU with the UPN (user certificates) or the device FQDN (computer certificates) in the SAN. For Intune-managed devices, a SCEP deployment with a Microsoft CA needs an Enterprise CA, an NDES server and the Certificate Connector for Microsoft Intune, with NDES not on the CA or a domain controller, plus a trusted certificate profile that delivers the root. Intune also supports PKCS certificates and third-party CA integration. NPS-specific hardening is in the Network Policy Server Security guide.

Where identity fits: a Wi-Fi device certificate is a machine credential, a non-human identity with an owner, a lifetime and a revocation trigger. Inventory it alongside other machine certificates rather than leaving it to the network team alone. See the RADIUS Security Guide for the RADIUS shared secrets that sit behind both methods.

When to use each

Choose EAP-TLS when: devices are corporate-managed through Group Policy or MDM; Windows 11 with Credential Guard is in scope; the network gives access to internal systems; you need WPA3-Enterprise 192-bit mode; or regulators and auditors expect phishing-resistant device authentication on internal networks.
Tolerate PEAP-MSCHAPv2 when: a defined group of devices genuinely cannot enrol certificates, the SSID is segregated with internet-only or tightly limited access, every client profile pins the server name and root, and there is a dated retirement plan.
Consider PEAP-TLS only when: an existing RADIUS policy or legacy supplicant requires the PEAP wrapper. It uses certificates inside the tunnel and is treated by Microsoft as certificate-based, but do not offer it alongside EAP-TLS on the same network.

Small versus large organisations. A small organisation with Microsoft 365 and Intune can run EAP-TLS with a cloud or MDM-integrated CA and a cloud RADIUS service, avoiding on-premises NDES. A large organisation with mixed platforms usually needs SCEP or ACME-style enrolment per platform, a dedicated onboarding portal for BYOD, and OCSP for revocation at scale. In both, the server certificate renewal date is the single biggest outage risk and belongs in a monitored calendar.

Worked scenario: a 4,000-device migration

An organisation runs one corporate SSID with PEAP-MSCHAPv2 on two NPS servers. Its Windows 11 upgrade enables Credential Guard and users start receiving Wi-Fi password prompts. A wireless assessment also finds that its Android and macOS profiles do not specify server names.

Decide the target: EAP-TLS with machine certificates for Windows (autoenrolment) and SCEP certificates through Intune for macOS, iOS and Android. User certificates are added only where per-user VLAN assignment needs them.
Fix server validation first: before any certificate rollout, push profiles that pin the private root and exact RADIUS server names on every platform, with user trust prompts disabled. This closes the evil twin exposure on PEAP immediately.
Build PKI: a dedicated Wi-Fi client template with Client Authentication EKU, non-exportable keys and a one-year lifetime; a new server certificate with a two-year lifetime and a renewal alert at 60 days; CRL publication reachable from NPS.
Pilot: IT staff on each platform receive the EAP-TLS profile while keeping PEAP as fallback. Monitor NPS events 6272 (access granted) and 6273 (access denied) with the authentication type recorded.
Expand by ring: 10 percent, then 50 percent, then all managed devices, holding each ring until denial rates match the pilot.
Retire PEAP: once EAP-TLS carries nearly all managed authentications, move remaining PEAP devices to a separate restricted SSID, then remove MSCHAPv2 from the corporate network policy entirely.
Roll back plan: keep the disabled PEAP policy intact for 30 days to bridge a PKI outage for a defined group.

Migration path through MDM and SCEP

Inventory supplicants: list every device class on 802.1X, its management channel and whether it can store a certificate in hardware. Printers, scanners and IoT often need a separate answer, such as their own certificates or MAC authentication bypass on a restricted VLAN; see 802.1X vs MAB.
Deploy trust: a trusted certificate profile for the root on each platform, and Wi-Fi profiles that set "Certificate server names" and "Root certificates for server validation" in Intune, or the equivalent fields in other MDMs.
Issue client certificates: SCEP or PKCS profiles in MDM, Group Policy autoenrolment for domain-joined Windows. Protect the SCEP endpoint: per-request challenges from MDM rather than a static password.
Configure RADIUS: a network policy for EAP-TLS that constrains issuer and EKU, maps certificates to device or user groups, and checks revocation. Order it above the PEAP policy.
Test: renewal on an offline device, revocation of a test device, server certificate replacement in a lab, and roaming between access points.
Cut over and remove: retire the PEAP policy on a date announced in advance, and alert on any MSCHAPv2 authentication attempt afterwards.

Detection and measurement

Log every RADIUS decision with the EAP type, the certificate issuer and serial (for EAP-TLS) and the calling station.

Share of authentications by method: EAP-TLS versus MSCHAPv2 per week, trending to 100 percent for managed devices.
Profiles without server pinning: number of devices whose Wi-Fi profile lacks server names or a pinned root, target zero.
Days to RADIUS certificate expiry: alert at 60 and 30 days.
Revocation latency: hours from device loss report to certificate revocation and to the first denied attempt.
Rogue SSID detections: access points broadcasting the corporate SSID that are not in the managed inventory.
Certificate renewal failure rate: devices with expired or near-expired Wi-Fi certificates.

Common failure patterns

Leaving PEAP enabled on the corporate SSID after migration: the attacker simply chooses the password path.
Disabling Credential Guard to silence Wi-Fi prompts: trades a credential theft protection for a deprecated method.
Trusting any certificate from the corporate root: RADIUS policies that do not constrain issuer, template or EKU let any internal certificate onto the network.
Static SCEP challenge passwords: anyone who learns the value can enrol a device and receive a valid Wi-Fi certificate.
Server certificate renewal treated as a routine ticket: a new certificate from a different chain, or one missed by a week, causes a site-wide outage that pushes teams back to PEAP.
Unpinned BYOD profiles: the devices most exposed to evil twins are the ones nobody manages; give them an onboarding flow or a separate network.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-18, AC-18(1)	Wireless access with authentication and encryption
NIST SP 800-53 Rev 5	IA-3, IA-3(1)	Device authentication, cryptographic bidirectional authentication (EAP-TLS)
NIST SP 800-53 Rev 5	IA-5(2), SC-17	Public key-based authentication and PKI certificates
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.IR-01	Credential management, authentication of users and hardware, network access protection
MITRE ATT&CK	T1669, T1557, T1110.002, T1110.003	Wi-Fi initial access, adversary-in-the-middle, password cracking and spraying (PEAP exposure)
MITRE ATT&CK	T1649	Certificate theft or forgery (EAP-TLS enrolment and key protection)

Practitioner checklist

Pin exact RADIUS server names and a private root in every Wi-Fi profile, and disable user trust prompts, before anything else.
Confirm Credential Guard status across Windows 11 devices and plan the move off MSCHAPv2 rather than disabling it.
Build a dedicated Wi-Fi client certificate template with Client Authentication EKU and non-exportable keys.
Protect enrolment: MDM-issued per-request SCEP challenges, restricted template permissions.
Constrain RADIUS policy by issuer and EKU, map certificates to devices, and check revocation.
Track the RADIUS server certificate expiry with alerts at 60 and 30 days.
Roll out EAP-TLS by ring with PEAP as fallback, then set and enforce a PEAP retirement date.
Move devices that cannot hold certificates to a segregated SSID or VLAN.
Alert on any MSCHAPv2 authentication after cutover and on rogue access points broadcasting the SSID.

Standards and references

Related NHI Mgmt Group resources: 802.1X and EAP-TLS Enterprise Wi-Fi Guide · Wi-Fi Security Guide · 802.1X Authentication Troubleshooting Guide · WPA2 vs WPA3

EAP-TLS vs PEAP: Certificates or Passwords for Enterprise Wi-Fi