A financial analyst works remotely from a coffee shop several times a week, connecting their laptop to the shop's WPA2 PSK network. An attacker parks nearby with a laptop and a passive wireless adapter. The attacker waits — or sends a deauthentication frame to force the analyst's laptop to disconnect and reconnect. When the laptop reconnects, the WPA2 four-way handshake is captured.
The attacker drives away. Back home, they run a dictionary attack against the captured handshake using a GPU-accelerated cracking tool. The coffee shop's passphrase — "coffee2023!" — appears in a wordlist after four minutes. The attacker now has the passphrase.
Using the passphrase and recordings of the analyst's past traffic (the attacker also captured encrypted sessions from previous visits), the attacker decrypts the analyst's past wireless traffic. WPA2 PSK lacks forward secrecy: once the passphrase is known, every session that used keys derived from it can be decrypted retroactively.
The same attacker attempts the same technique against a WPA3-Personal network. They park nearby, capture the wireless handshake exchange, and return home with the captured frames.
Analyzing the frames, the attacker finds no crackable hash. During SAE, the client and access point exchanged Diffie-Hellman commit and confirm messages. Both sides independently derived the session key from the passphrase using the SAE algorithm — the session key was never transmitted across the network. The captured frames contain no value that can be subjected to offline brute-force.
To attempt to crack a WPA3-SAE network, the attacker would need to interact with the network in real time for every guess — an active attack that is detectable, rate-limitable, and far slower than GPU-accelerated offline cracking. The attack that worked in four minutes against WPA2 is not feasible against WPA3.
Additionally, even if the attacker somehow obtained the passphrase later (from a different source), previously recorded encrypted sessions cannot be decrypted. Each SAE session generated its own unique encryption key — forward secrecy means the session keys are gone once the session ends.
A law firm of 80 attorneys has a WPA2-Personal network with a single shared passphrase posted on a sign in the reception area. When a paralegal leaves, the IT team must change the passphrase — and tell all 80 attorneys the new one, update every device, and re-configure every printer and conference room device. This happens every few months. More critically, after a laptop was stolen, there was no way to remove that device's network access without changing the password for everyone.
The IT director migrates to WPA3-Enterprise with 802.1X and a RADIUS server integrated with Active Directory. Each attorney authenticates with their individual AD username and password. The 802.1X flow: the attorney's laptop (Supplicant) presents credentials to the access point (Authenticator), which forwards them to the RADIUS server (Authentication Server). RADIUS validates against AD and returns an Access-Accept with a VLAN assignment attribute. The AP opens the port.
When the next paralegal leaves: the IT team disables the AD account. The departed employee's credentials are immediately rejected by RADIUS. No one else's access is affected. The stolen laptop — if it can't produce valid credentials — is denied network access immediately. The passphrase-on-a-sign problem is eliminated entirely.
A pharmaceutical company's RADIUS server logs all wireless sessions via accounting: username, session start, session end, bytes transferred, and assigned VLAN. A security analyst reviewing the past month's logs notices an anomaly in the accounting data: a researcher's account shows wireless sessions between 02:00 and 04:00 on three consecutive nights — outside all normal working hours — with unusually high data transfer volumes (8–12 GB per session). The researcher's normal pattern is 8:00–18:00 with under 500 MB per day.
The RADIUS accounting records are the first indicator. They do not show what data was transferred — but the combination of unusual hours, high volume, and repetition triggers an investigation. Reviewing network logs from those sessions confirms large file transfers to an external IP. The RADIUS accounting log time-stamps allow investigators to correlate the wireless sessions with network flow records, identifying the specific transfers.
Without RADIUS accounting, this behavior would have been invisible. The shared-password model (WPA3-Personal) would show only that "some device" connected — with no association between the traffic and a specific user identity.
A university IT team is designing 802.1X wireless authentication for 25,000 students and 3,000 faculty. They evaluate three EAP options:
EAP-TLS: Requires issuing client certificates to all 28,000 users and managing certificate lifecycle (issuance, renewal, revocation). Faculty devices are university-managed — IT can push certs. Student devices are personal — 28,000 different device types from 28,000 individuals. Certificate deployment and ongoing management at this scale with unmanaged personal devices is impractical.
PEAP (Protected EAP with MSCHAPv2): Requires only a server-side certificate on the RADIUS server. Students authenticate with their existing university credentials (username/password) through a TLS tunnel established using the server cert. IT deploys one certificate (the RADIUS server cert). Students use existing credentials. The university's CA signs the RADIUS cert; students' devices trust it after initial configuration. Manageable at scale.
EAP-TTLS: Similar to PEAP but allows more flexible inner authentication. Considered for legacy devices with non-standard inner auth needs, but PEAP covers the university's requirements adequately.
The team deploys PEAP. Faculty research workstations (managed by IT) will eventually use EAP-TLS after the PKI infrastructure matures — the highest-security devices get the strongest auth method.