PMF Mandatory + SAE Instead of PSK: Closing Deauth and Offline Dictionary Gaps

The two Wi-Fi problems every ops team has war stories for

Story one: deauth headaches. You’re mid-migration. New APs, old controllers still in the mix, guest network bridged in a way nobody admits in documentation. Suddenly a floor reports mass disconnects. Help desk hears “the Wi-Fi is under attack.” Sometimes it is. Sometimes it’s a rogue transition, a bad roam, or a client that handles management frames like a suggestion. Either way, unauthenticated deauthentication and disassociation frames were a gift to both attackers and troubleshooting ambiguity.

Story two: PSK archaeology. Somewhere in every enterprise is a “shared device” SSID with a password that has been emailed, printed, and reused across vendors. With WPA2-PSK, a captured handshake often meant offline cracking at leisure. Rotate the password after an incident and you still don’t know how many copies exist in password managers, onboarding PDFs, and the facilities closet.

WPA3’s practical punch for day-to-day defenders is not a marketing slogan. It’s PMF required and SAE instead of raw PSK semantics.

PMF: from optional checkbox to table stakes

Protected Management Frames (PMF), from 802.11w, integrity-protect (and for unicast, encrypt) robust management frames so random spoofed deauth/disassoc noise is much harder to pull off against a fully protected association.

Under WPA2, PMF was frequently optional. Optional meant:

• Some clients supported it
• Some APs advertised capability
• Mixed SSIDs negotiated down
• Security reviews said “enable when ready”
• Ready never quite arrived

WPA3 changes the default expectation: PMF is mandatory for WPA3 connections. Meraki’s WPA3 configuration guide is explicit that WPA3-Enterprise extends WPA2-Enterprise partly by requiring PMF on those connections, and that PMF is mandatory for 6 GHz and Wi-Fi 7 operation.

WWT’s WPA3 need-to-know puts PMF in the short list of what all WPA3 networks require, alongside ditching outdated legacy protocols.

For 6 GHz, there is no “we’ll turn PMF on later.” The band assumes modern security. For Wi-Fi 7, Redway’s security write-up also highlights related integrity controls such as AP beacon protection (MIC on beacons) as mandatory for proper Wi-Fi 7 connections—another step against forged infrastructure signalling.

Wi-Fi Alliance materials on WPA3 and related security tech remain the public umbrella reference when you need something non-vendor to link in a standard.

What PMF does—and what it doesn’t

PMF helps with:

• Spoofed deauthentication / disassociation against protected sessions
• Certain management-frame based denial and disruption patterns
• Making “someone is deauthing the floor” a higher-effort claim

PMF does not:

• Fix bad channel plans or DFS storms
• Replace 802.1X identity
• Stop every evil twin (clients can still be tricked onto other SSIDs)
• Save you from captive portal confusion and broken roaming

In ops terms: PMF reduces a whole class of cheap wireless griefing. It doesn’t replace RF design, monitoring, or user education.

SAE: same password UX, different attack economics

WPA3-Personal replaces the WPA2-PSK handshake model with Simultaneous Authentication of Equals (SAE), a password-authenticated key exchange.

From the user’s chair: pick SSID, enter password, get on. From the attacker’s chair: the old “capture handshake, leave, crack offline with a dictionary” workflow is what SAE was designed to wreck. Guessing becomes an online interaction problem against a live AP, with rate limiting and far worse economics.

Additional properties people care about in design reviews:

• Forward secrecy: compromising the password later shouldn’t decrypt past sessions the way classic PSK failures could imply
• Per-session keying rooted in the SAE exchange rather than a static PSK stretched the old way

Meraki notes two Password Element methods historically associated with SAE: Hunting and Pecking (HnP) and Hash-to-Element (H2E). H2E is mandatory for Wi-Fi 6E (6 GHz) and Wi-Fi 7 because HnP had brute-force dictionary concerns. If your “WPA3-Personal” still smells like transitional SAE settings from early firmware, re-check H2E.

Wi-Fi 7 personal mode goes further with extended AKMs (e.g. SAE-EXT-KEY / AKM 24-class behaviour) and GCMP-256 expectations—Redway covers the AKM/cipher matrix well if you’re deep in controller knobs.

Transition mode: the compromise that keeps the old holes warm

Both Meraki and WWT describe transition modes for enterprise and personal SSIDs so WPA2 clients can coexist while WPA3 clients step up.

Useful? Yes, during migration. Safe forever? No.

WWT is direct: while transition mode runs, legacy WPA2 vulnerabilities remain exploitable. Use it with a kill plan.

On personal SSIDs, transition often means modern clients do SAE while older ones still do PSK. Guess which devices attackers prefer to target. On enterprise SSIDs, optional PMF for the WPA2 side is often recommended for compatibility—Meraki notes enabling 802.11w in a way that still allows non-PMF WPA2 clients. That’s operationally honest and security-imperfect. Document it as temporary risk.

Field notes from migrations (the unglamorous bit)

Guest networks PSK guest with a quarterly password rotation feels productive and changes little if the password is always “CompanyGuest2024!”. SAE improves the crypto path; it does not fix password distribution theatre. Prefer portal + segmentation, or OWE for open-style convenience with encryption (topic 20).

IoT and scanners These are why PMF stays optional longer than it should. I’ve watched warehouse scanners fail a “PMF required” pilot and force a dual-SSID design overnight. Don’t discover that on cutover night. Lab the ugly devices first.

Deauth tickets after PMF required Some disconnect storms were never attacks—they were sticky clients, coverage holes, or controller bugs. When PMF is required, your troubleshooting narrative changes. Keep wireless IPS/IDS and packet capture skills sharp so you don’t blame “hackers” for a mis-set minimum data rate.

Fast transition / 802.11r SAE and 802.1X both interact with FT AKMs. Wrong combo = roam pain that users describe as “Wi-Fi keeps dropping on the walk to the boardroom.” Test walks beat synthetic iperf pride.

CISSP-relevant control thinking

• Threat modelling: cheap management-frame disruption and offline PSK cracking were realistic threats, not CTF trivia
• Crypto protocol choice: SAE is a PAKE-class improvement over PSK handshake capture economics
• Configuration management: “PMF optional” is a control state, not a neutral default
• Risk acceptance: every transition-mode SSID is an accepted residual exposure with an owner and a date

If you write policies, ban eternal transition mode the same way you banned WEP—politely at first, then in change control.

Practical enablement sequence

1. Inventory SSIDs: enterprise vs personal vs open
2. Lab PMF required on a pilot WPA3-Enterprise SSID with corporate images
3. Move PSK SSIDs you still need toward WPA3-Personal (SAE + H2E), not “stronger WPA2 password”
4. Keep transition modes time-boxed; track client counts still using WPA2 AKMs
5. Validate with captures: MFPC/MFPR bits, AKMs, and whether deauth spoof tests behave as expected in a controlled lab (not on the CEO floor)
6. Update service desk scripts so “set it back to WPA2” isn’t the only fix path

Actionable takeaway

Mandatory PMF closes a long-abused gap around spoofed management frames. SAE replaces PSK’s offline dictionary-friendly design while keeping the password UX users already understand. Together they’re why WPA3 is more than a rename—and why 6 GHz / Wi-Fi 7 deployments that cling to optional PMF and classic PSK are choosing nostalgia over the security model the new bands assume.

Next: Multi-Link Operation—when one device uses several bands at once, keying and AKM consistency stop being academic.