WPA3, PMF, and a Rogue SSID on Campus
A university with 45,000 devices runs WPA2-Enterprise PEAP-MSCHAPv2 against ISE for staff and students, a WPA2-PSK SSID for 2,000 building-automation IoT devices, and a guest web portal. A security audit now requires WPA3 and protected management frames on the campus SSIDs, and the new research building is Wi-Fi 6E with 6 GHz radios. The IoT vendor states its controllers support only WPA2-PSK and 'may use TKIP'. Separately, a dorm resident plugged in a consumer router broadcasting the campus staff SSID, and telemetry shows 30 clients associated to it for about 40 minutes before facilities unplugged it.
1. Lay out the WPA3 and PMF migration across the SSIDs, and state what 6 GHz changes.
Read the worked answer
Enterprise SSID: move to WPA3-Enterprise. If your release offers a WPA3-Enterprise transition mode that admits WPA2-Enterprise clients, use it as a staging step and plan to remove it; otherwise stand up a parallel WPA3 SSID and migrate cohorts. Note that WPA3-Enterprise 192-bit mode requires Suite-B certificates and will exclude most current clients, so treat it as a separate, optional SSID.
Personal SSID: WPA3-SAE transition mode lets WPA2-PSK clients still associate while SAE clients get WPA3. In transition mode PMF is optional for the WPA2 clients but required for SAE ones.
PMF: set WPA2 SSIDs to optional first, watch for clients that fail to associate (older supplicants and some medical/IoT gear break when PMF is required), then flip to required. Enable infrastructure MFP so your own APs' management frames are protected.
6 GHz: WPA3 is mandatory, PMF is mandatory, WPA2 and TKIP do not exist there, and clients must be 802.11ax-capable. So the 6 GHz SSID must be WPA3-SAE or WPA3-Enterprise from day one, and any device that cannot do WPA3 simply cannot use 6 GHz.
2. The IoT vendor says WPA2-PSK with possible TKIP. What do you do with those 2,000 devices?
Read the worked answer
First, verify the claim before designing around it. Many devices advertising 'WPA2-PSK' actually negotiate AES-CCMP fine; the TKIP statement is often legacy documentation. Test a sample on a WPA2-PSK/AES-only SSID and confirm association and stability.
If they truly require TKIP, understand the constraint: TKIP is deprecated, WPA3 does not permit it, and current Wi-Fi 6 and 6E APs generally do not support it at all. That means these devices constrain you to older radios or to a separate legacy network.
Options, in order of preference:
- Firmware update or device replacement with AES-capable units; 2,000 devices is a capital conversation, not a technical one.
- Isolate them on a dedicated SSID, 2.4 GHz only, WPA2-PSK/AES, mapped to a quarantined VLAN with strict ACLs, rate limiting, and no path to the enterprise SSIDs. Restrict which APs broadcast it so the legacy requirement does not degrade the whole estate.
- Never allow them on the staff/student SSID or on the same WLAN as WPA3 clients; a downgrade path undermines the audit finding. Document the exception and compensating controls explicitly.
3. Given the rogue SSID-spoofing incident, decide what you would have done and what policy you set for containment.
Read the worked answer
This one is malicious by definition: it spoofed a campus SSID, so it was an evil-twin/credential-harvesting attempt, not a neighbor's hotspot. Actions, in order:
- Locate it: use the location capability and switch-port tracing to find the wall port, and shut the port. That terminates the threat far faster and more reliably than wireless containment.
- Protect clients: with PMF required, 11w-capable clients ignore forged deauthentications from the rogue. Server-certificate validation on ISE stops supplicants from handing credentials to a spoofed SSID; for staff, prefer EAP-TLS so a rogue has no password to capture.
- Containment policy: contain manually and narrowly, targeted at the specific BSSID, and only when the rogue is on your premises and cannot be located on the wire. Never enable automatic containment of all rogues.
Why the caution: containment works by flooding deauths, only works against APs you can hear on their channel, is unreliable against modern 802.11ax/WPA3 APs, and auto-containment routinely deauths neighboring campus APs, hotel hotspots, and personal devices, generating outages and complaints. Treat containment as a last resort with a paper trail.