EAP Methods
802.1X authentication for enterprise Wi-Fi
EAP is a framework, not a protocol. It defines how authentication data moves between a supplicant (client) and an authentication server (RADIUS), tunnelled through an authenticator (AP or switch). The actual security depends entirely on which EAP method runs inside the framework. Choosing the wrong method leaves your network open to credential theft, Evil Twin attacks, and MITM.
Three roles, one handshake
802.1X authentication involves three entities. The EAP framework runs between supplicant and authentication server. The authenticator (AP) transports EAP messages but does not participate in the authentication decision.
The client device. Runs the EAP peer (client-side) software. On Wi-Fi: the STA (station). Examples: Windows 802.1X supplicant, iOS native supplicant, wpa_supplicant on Linux.
The AP or switch. Passes EAP messages between supplicant and RADIUS server. Makes port access decision based on RADIUS Access-Accept or Access-Reject. Does not see credentials.
RADIUS server (FreeRADIUS, Cisco ISE, Microsoft NPS, Aruba ClearPass). Runs EAP server logic, validates credentials or certificates, returns Access-Accept with MPPE keys for PMK derivation.
802.1X - EAPOL exchange
Client associates to AP. RSNA begins. Port is blocked for all traffic except EAPoL.
Client sends EAPOL-Start (optional) or AP sends EAP-Request/Identity to trigger the exchange.
Client sends its identity (username or anonymous outer identity for tunnel methods). AP forwards to RADIUS in Access-Request.
RADIUS responds with EAP-Request specifying the method type (TLS, PEAP, TTLS, FAST). Client must support that method to continue.
TLS handshake, certificate exchange, inner authentication - depends on EAP method. Multiple RADIUS Access-Challenge / EAP-Response pairs.
RADIUS sends Access-Accept with EAP-Success and Master Session Key (MSK). AP derives PMK from MSK. 4-Way Handshake begins to derive PTK.
AP unblocks the controlled port. Client has network access. Total time: 200-500ms for PEAP, under 100ms for EAP-TLS with session resumption.
EAP-TLS - Certificate on both sides
EAP-TLS is the most secure EAP method and the hardest to roll out. Both the client and the RADIUS server present X.509 certificates. No passwords cross the wire. The certificate chain is what enforces mutual auth - a rogue AP cannot impersonate your RADIUS server without the CA private key. A stolen password does nothing without the client cert to go with it.
PKI on both sides
- Certificate Authority (CA) - internal PKI (Microsoft ADCS, EJBCA, etc.) or cloud PKI
- Server certificate on RADIUS - signed by the CA, presented to all clients
- Client certificate on every device - issued per device or per user, enrolled via SCEP, EST, or MDM
- CA certificate distributed to all clients - clients must trust the CA to validate the server cert
- CRL or OCSP - certificate revocation mechanism to invalidate stolen device certs
What EAP-TLS prevents
- No password to steal - certificate private key never leaves the device (TPM-bound on modern devices)
- No Evil Twin risk - client validates server certificate; rogue AP cannot present a valid cert without the CA private key
- No credential stuffing - compromised username/password has no attack surface
- No MITM - TLS mutual auth prevents any interception of the session
- Session resumption - TLS session tickets allow re-authentication in under 50ms (critical for FT roaming)
EAP-TLS message sequence
PEAP - Server certificate, client password
PEAP wraps an inner EAP method inside a TLS tunnel built with only a server-side certificate. The client authenticates with a username and password - MSCHAPv2 in almost every deployment. No client certificate required. That's why it's in most enterprise Wi-Fi networks: AD credentials work straight away, no PKI rollout needed.
TLS with server certificate
PEAP first establishes a TLS tunnel using only the RADIUS server's certificate.
The outer identity (sent before the tunnel) is typically anonymous@domain
to hide the real username from passive observers.
PEAP-MSCHAPv2 (default)
Inside the TLS tunnel, the client authenticates using MSCHAPv2: a challenge-response protocol that uses the user's password (hashed as NT hash). The password is never sent in plaintext - the hash is used to respond to a server challenge.
PEAP-MSCHAPv2 is vulnerable if the client does not validate the server certificate. A rogue AP can present any certificate and downgrade the session. Clients must be configured to validate the server cert and pin the CA. Without this, Evil Twin attacks can capture MSCHAPv2 handshakes and crack NT password hashes offline.
Client configuration - the critical steps
Enable certificate validation and pin the specific CA root certificate. Without this, the client accepts any RADIUS server certificate - the fundamental PEAP vulnerability.
Configure the RADIUS server FQDN (e.g., radius.contoso.com) that the client expects in the server certificate CN or SAN. Prevents certificate substitution attacks.
Set outer identity to anonymous@domain to protect the username from passive capture before the TLS tunnel is established.
TLS session tickets reduce re-authentication time during roaming. Requires RADIUS server support for EAP session caching. Useful for 802.11r FT environments.
EAP-TTLS
Tunneled Transport Layer Security. Architecturally identical to PEAP: server certificate establishes TLS tunnel, inner method runs inside. The key difference is inner method flexibility.
EAP-TTLS is common in Linux and Android environments where PEAP-MSCHAPv2 compatibility with Active Directory is not required. It supports PAP inner authentication, which allows RADIUS to forward credentials to any backend (LDAP, SQL, OTP) without requiring NT hash storage.
- Native support on Linux (wpa_supplicant), macOS, and Android
- Requires Microsoft supplicant add-on or third-party on Windows
- PAP inner method: simpler backend integration, credentials sent in plaintext inside the TLS tunnel
- Preferred for non-Windows environments or mixed directory infrastructure
EAP-FAST
Flexible Authentication via Secure Tunneling. Cisco's replacement for LEAP. Designed for environments that cannot deploy certificates but need stronger security than LEAP. Uses Protected Access Credentials (PACs) instead of certificates.
- No server certificate required - reduces PKI overhead
- PAC must be securely distributed - provisioning complexity trades off against cert management
- Vulnerable if PAC is compromised - similar risk profile to PEAP without cert validation
- Cisco-specific - limited support on non-Cisco infrastructure
- Declining use - most environments prefer PEAP or EAP-TLS over EAP-FAST today
Deprecated and insecure EAP methods
Cisco proprietary, no TLS tunnel, MS-CHAPv1. Vulnerable to dictionary attacks and ASLEAP tool. Deprecated since 2003. Found in legacy Cisco deployments only.
No TLS tunnel, one-way auth only (server not authenticated), no key derivation. Defined in RFC 3748 as a baseline - universally considered insufficient for Wi-Fi.
PEAP is sound but clients that skip server certificate validation are open to Evil Twin. Common misconfiguration in BYOD deployments. Audit client profiles.
SIM card-based authentication. Used in carrier Wi-Fi offload and Passpoint (802.11u) environments. Not common in enterprise deployments. Secure but infrastructure-heavy.
EAP method selection matrix
WPA3-Enterprise and EAP-TLS
WPA3-Enterprise in standard mode supports the same EAP methods as WPA2-Enterprise. WPA3-Enterprise 192-bit mode mandates EAP-TLS with specific cryptographic requirements: