802.1X proves the client. It proves the network only if someone ticked the box.

A writeup published on dev.to states the asymmetry at the centre of enterprise Wi-Fi plainly: 802.1X is very good at proving who the client is, and it proves who the network is only if the client was configured to check, and that configuration is one screen most deployments skip ^[1]. That gap is not an exotic failure mode. It is the entire operating premise of the credential-harvesting rogue access point.

Start with what is being replaced. Home Wi-Fi is a shared secret: everyone who knows the passphrase derives the same key material, and the access point cannot tell one person from another ^[2]. Enterprise Wi-Fi swaps that for a per-user exchange with three parties: the supplicant on the device, the authenticator (the AP or switch, which passes only authentication traffic until the exchange succeeds), and a RADIUS authentication server holding the user database. The access point is a relay. It never sees the credential and never decides anything ^[3].

What runs between supplicant and server is EAP (RFC 3748), which is not an authentication method but a container; the method inside is negotiated, and that choice is where guarantees diverge ^[4]. There are certificate-based methods, where the client holds a private key, and tunnelled password methods, where the client holds something a person can type. The second family is far more common and carries the deployment problem ^[5].

The password inside that tunnel is usually MS-CHAPv2, a challenge-response protocol from the dial-up era. In 2012 Moxie Marlinspike and David Hulton showed its security reduces to a single DES operation ^[6]: the NT hash is split into three chunks that each encrypt the same challenge, the third chunk is padded with five zero bytes and is therefore trivially recoverable, and what remains is one exhaustive DES keyspace search, which purpose-built hardware turned into a bounded, predictable job ^[7]. Since then the honest summary is that a captured MS-CHAPv2 exchange yields the NT hash, and the NT hash is the credential ^[8].

PEAP survives that because the MS-CHAPv2 exchange happens inside a TLS tunnel, so an observer on the air sees ciphertext ^[9]. Which puts all the weight on two fields. A correctly configured PEAP client pins the certificate authority that signed the RADIUS server certificate and the expected server name on it; pinning only the CA is not enough when the CA is public, because anyone can get a certificate from it ^[10]. Blank those fields and the client accepts any certificate, completes a tunnel with whoever answered, and hands over an MS-CHAPv2 exchange for a domain account ^[11]. Tools that automate this have existed for over a decade, and the attack needs nothing from the user beyond being in range of a stronger signal with a matching network name ^[12]. The rogue authenticator ends up with what the real one never had: the credential itself ^[1].

Platforms have been removing the option to be wrong. Android 11 dropped the "do not validate" choice for enterprise networks, requiring either a specified CA certificate with a domain or explicit use of the system trust store with a domain ^[13]. WPA3-Enterprise in 192-bit mode requires server certificate validation and constrains cipher suites ^[14]. Configuration profiles, whether from MDM or a provisioning tool such as the one eduroam publishes, exist mainly so the CA and server name fields are never left to the person joining ^[15].

Two things to watch on your own estate. First, how devices actually onboard: if users join by typing a network name and a password, the certificate check is not happening on some fraction of them, and that fraction is where credentials leave ^[16]. Second, the leg behind the access point, where the authenticator talks to the server over RADIUS (RFC 2865), a 1997 protocol running over UDP ^[17]. Fixing the supplicant screen does not touch it.