Enterprise 802.1X Deployment Guide

802.1X is a port-based network access control standard (IEEE 802.1X), not an authentication method itself. It defines three roles: the supplicant (the client device), the authenticator (the access point or switch, which blocks all traffic except EAP until authentication succeeds), and the authentication server (typically a RADIUS server). The actual authentication exchange runs inside EAP (Extensible Authentication Protocol), encapsulated over the air as EAPOL (EAP over LAN) between supplicant and AP, then re-encapsulated as RADIUS between the AP and the authentication server.

Once authentication succeeds, the AP and client derive the Pairwise Master Key from the EAP exchange and proceed through the standard 802.11i 4-way handshake (or SAE-based derivation in WPA3-Enterprise) to establish session keys. The EAP method chosen determines how the client actually proves its identity — this is the decision with the most security impact in the whole design.

The three EAP methods you'll realistically choose between for enterprise Wi-Fi are EAP-TLS, PEAP, and EAP-TTLS. They differ mainly in what the client authenticates with and how much PKI operational overhead you're willing to take on.

• •EAP-TLS: mutual certificate-based authentication. Both the client and RADIUS server present X.509 certificates; there is no password to phish or crack. This is the strongest option and the one recommended for WPA3-Enterprise 192-bit mode, but it requires a working PKI to issue, distribute and revoke client certificates — typically via an internal CA integrated with MDM/Intune/Jamf for automated enrollment.
• •PEAP (Protected EAP): establishes a TLS tunnel using a server-side certificate only, then runs an inner authentication method — almost always MSCHAPv2 — inside that tunnel using the user's password. Widely supported and simple to deploy since only the server needs a certificate, but security depends entirely on clients actually validating the server certificate; if that validation is disabled or user-bypassable, PEAP is vulnerable to credential-harvesting rogue APs.
• •EAP-TTLS: similar to PEAP — server-side TLS tunnel, no client certificate required — but the inner method is more flexible (PAP, CHAP, MSCHAPv2, or even EAP methods) and can carry credentials against a wider variety of backend identity stores. Functionally comparable security posture to PEAP; the choice between the two often comes down to backend directory compatibility and client OS support.

PEAP and EAP-TTLS's security rests on the client validating the RADIUS server's TLS certificate against a trusted root and confirming the server identity (common name / SAN) before sending credentials through the tunnel. If a client is configured to accept any certificate, or a user is trained to click through a certificate warning, an attacker running a rogue AP with the same SSID can present their own certificate, complete the TLS handshake, and harvest the MSCHAPv2 exchange — which is crackable offline given enough compute, and outright reveals the NTLM-equivalent hash in some derivations.

This is a configuration and client-provisioning problem, not a flaw unique to PEAP/TTLS as a protocol, but it's the single most common real-world 802.1X weakness in the field. The fix is enforcing server certificate validation and pinning the expected server identity in the client profile — ideally pushed via MDM so users are never presented with a trust decision at all.

A minimal hostapd.conf fragment for an AP acting as the 802.1X authenticator, pointing at a RADIUS server:

interface=wlan0
ssid=CORP-SECURE
country_code=US
ieee80211w=2

# WPA2/WPA3-Enterprise
wpa=2
wpa_key_mgmt=WPA-EAP WPA-EAP-SHA256
rsn_pairwise=CCMP
ieee8021x=1

# RADIUS authentication server
auth_server_addr=10.10.5.20
auth_server_port=1812
auth_server_shared_secret=REPLACE_WITH_STRONG_SECRET

# RADIUS accounting (optional but recommended)
acct_server_addr=10.10.5.20
acct_server_port=1813
acct_server_shared_secret=REPLACE_WITH_STRONG_SECRET

# Reauthentication interval (seconds)
wpa_group_rekey=3600
eap_reauth_period=3600

The corresponding server-side eap.conf fragment defining PEAP with an MSCHAPv2 inner method, and the client (NAS) entry for the AP:

eap {
    default_eap_type = peap
    timer_expire     = 60

    tls-config tls-common {
        private_key_file = /etc/raddb/certs/server.key
        certificate_file = /etc/raddb/certs/server.pem
        ca_file          = /etc/raddb/certs/ca.pem
        cipher_list      = "HIGH"
        tls_min_version  = "1.2"
    }

    peap {
        tls = tls-common
        default_eap_type = mschapv2
    }

    tls {
        tls = tls-common
    }
}

For EAP-TLS deployments, plan the PKI before the network: certificate lifetime (short-lived certs reduce exposure but increase renewal/enrollment load), automated enrollment via SCEP or MDM-managed profiles, and a working revocation path — OCSP or CRL checked by the RADIUS server — so a lost or decommissioned device's certificate actually stops working rather than remaining valid until expiry.

For PEAP/TTLS deployments, the equivalent hardening is: distribute the trusted root CA and expected server identity via managed device profiles (never rely on manual user setup), disable any option that lets a user proceed past a certificate mismatch, and enforce strong password policy plus account lockout on the identity backend, since MSCHAPv2 inside the tunnel is still ultimately a password-based proof.

• •Use unique NAS shared secrets per AP or AP group, not a single secret across the whole deployment — a compromised AP shouldn't compromise RADIUS trust for every other AP.
• •Enable RADIUS accounting for session visibility and forensic capability (start/stop records, session duration, bytes transferred).
• •Segment authenticated clients by RADIUS-assigned VLAN (via Tunnel-Private-Group-ID attributes) so role-based network access is enforced at the AP, not left to downstream ACLs alone.
• •Set conservative session and re-authentication timers so a revoked certificate or disabled account is actually cut off promptly rather than remaining connected until the next full re-auth.
• •Test the rogue-AP scenario yourself before attackers do — confirm managed clients actually reject an untrusted RADIUS certificate rather than prompting the user.