All three methods run inside 802.1X with a RADIUS server making the decision. The differences are what credential the client presents and how well that credential survives attack.
Comparison table
| EAP-TLS | PEAP-MSCHAPv2 | EAP-TTLS/PAP | |
|---|---|---|---|
| Client credential | X.509 client certificate | Username + password (MSCHAPv2 inside TLS tunnel) | Username + password (PAP inside TLS tunnel) |
| Server certificate required | Yes | Yes | Yes |
| Client certificate required | Yes | No | No |
| PKI needed | Full (client cert issuance, e.g. SCEP via MDM) | Server cert only | Server cert only |
| Password store requirements | None — no passwords involved | Server needs NT hash (NTLM-style) of the password | Server sees the cleartext password inside the tunnel — works with any store that can verify it (hash, LDAP bind, OTP) |
| Credential-theft resistance | Strongest: nothing phishable or replayable; key can be TPM-bound and non-exportable | Weak against evil-twin APs when server validation is lax — MSCHAPv2 exchange is crackable offline once captured | Same evil-twin exposure, and a rogue server that terminates TLS receives the cleartext password |
| Depends on client validating server cert | Yes, but a failure exposes no reusable credential | Critically — misconfigured clients hand attackers crackable material | Critically — misconfigured clients hand attackers the password itself |
| Entra-only (no AD / no NT hashes) | Yes — the natural fit; certificates via Intune SCEP/PKCS | No — MSCHAPv2 needs NT hashes, which cloud-only Entra ID does not expose | Partially — PAP lets the RADIUS server verify against non-NTLM stores, but Entra ID has no password-verify API for RADIUS; requires a synced or separate credential store |
| Windows | Built in | Built in | Built in (Windows 8+; PAP as inner method) |
| macOS / iOS | Built in | Built in | Built in |
| Android | Built in | Built in (server CA validation mandatory on 11+) | Built in |
| Config at scale | MDM profile + certificate deployment (SCEP) | MDM profile or GPO; users can often self-connect | MDM profile; rarely pushed by Windows GPO |
| Typical use | Corporate-managed devices, passwordless Wi-Fi/wired, zero-trust environments | Legacy AD environments, BYOD with credentials | ISPs, education (eduroam), stores without NT hashes |
Practical guidance
- Managed devices: use EAP-TLS. Every mainstream OS supports it, MDM handles the certificate lifecycle, and there is no password to steal. This is also the only method that works cleanly in an Entra-only environment.
- If you must use a password method: enforce server-certificate validation and pin the expected server names/CA in the client profile. An 802.1X password method without strict validation is effectively broadcasting credentials to whoever stands up a rogue AP.
- PEAP-MSCHAPv2 end of life: it depends on NTLM-era password hashes, so it cannot follow you off Active Directory. Treat any new PEAP deployment as technical debt.
- EAP-TTLS/PAP's niche is real: because the inner credential arrives in cleartext inside the tunnel, the RADIUS server can check it against stores that PEAP cannot (salted hashes, LDAP binds, OTP). The trade-off is total dependence on tunnel integrity.
- Newer Android versions refuse profiles with "do not validate" server settings — a useful forcing function, but plan CA distribution before rollout.