Wi-Fi Security Guide: WPA3, 802.1X and Rogue APs

Corporate Wi-Fi is a network access path that reaches past the building walls, yet many organisations still protect it with a shared passphrase or a password that attackers already spray against their VPN. Wireless attacks need radio proximity, but proximity is cheap: a wardriving laptop in the car park, a compromised device in the office next door or a drop box in a meeting room. This guide covers security modes (WPA2, WPA3, Enhanced Open), 802.1X and EAP method choice, protected management frames, guest networks and captive portals, rogue access points and evil twins, and wireless monitoring. It is written for network engineers, security architects and SOC analysts, and draws on Wi-Fi Alliance material, IETF RFCs, NIST SP 800-153 and MITRE ATT&CK.

Key takeaways

• Use certificate-based 802.1X for corporate SSIDs. EAP-TLS removes the password from Wi-Fi; Microsoft says Wi-Fi endpoints based on MS-CHAPv2 are "subject to similar attacks as for NTLMv1".
• Server certificate validation is what stops evil twins. RFC 9190 says clients should be configured with trusted roots and server names to match; without them, any server with a publicly trusted certificate can pass.
• Transition mode is a downgrade path, so time-box it. Mixed WPA2/WPA3 lets an attacker steer clients to WPA2, and the Dragonblood researchers expected most WPA3 networks to stay in transition mode "for many years to come".
• Protected management frames are no longer optional. The Wi-Fi Alliance says "PMF is required for all new certified devices", WPA3 requires it, and 6 GHz will not operate without it.
• Monitor the air continuously. NIST SP 800-153 asks for continuous attack monitoring plus at least annual assessments, and APT28's "Nearest Neighbor" intrusion reached an enterprise SSID through a neighbouring organisation's dual-homed laptop.

Wi-Fi security modes compared

Each SSID (extended service set identifier, the network name) combines three choices: how clients authenticate (pre-shared key, SAE, 802.1X or none), which cipher protects frames (AES-CCMP or the Galois/Counter Mode Protocol, GCMP) and whether management frames are protected. The robust security network information element (RSNIE) in beacons advertises these choices, which is why a rogue AP can copy them or advertise weaker ones.

The Wi-Fi Alliance states that "WPA3 is mandatory for Wi-Fi CERTIFIED devices". Cisco's WPA3 deployment guide adds that "WPA2 is not permitted in 6 GHz operation" and that Wi-Fi 7 Enterprise expects GCMP-256, so older clients may lose multi-link operation.

WPA3-Personal, SAE and transition mode

SAE is a password-authenticated key exchange based on the Dragonfly handshake. An eavesdropper who captures it cannot test guesses offline, and each session has forward secrecy, so a password learned later does not decrypt recorded traffic.

• Hash-to-element (H2E): the original "hunting and pecking" derivation leaked timing. Cisco's guide says "Wi-Fi 6E (6 GHz) and Wi-Fi 7 requires Hash-to-Element as mandatory, as HnP is prone to brute force dictionary attacks." Enable H2E wherever clients support it.
• Dragonblood: in April 2019 Mathy Vanhoef and Eyal Ronen published side-channel leaks (CVE-2019-9494, CVE-2019-13377), denial of service by forged commit frames and transition mode downgrades. Implementations were patched; the downgrade is a design property.
• Transition mode: one SSID offers SAE and PSK. An attacker runs a WPA2-only clone, captures a partial handshake from a WPA3 client and cracks it offline. Cisco: "For maximum security, the recommended mode is to use only WPA3".
• Transition Disable: tells a client to stop accepting the WPA2 variant once it has seen WPA3. It closes the downgrade path but can break roaming across providers sharing an SSID, so pilot it first.
• The password still matters: anyone holding it is inside. Rotate it when staff leave and use per-device or per-group keys where the platform offers them.

802.1X and choosing an EAP method

In enterprise mode the AP is the 802.1X authenticator, relaying EAP between the client (supplicant) and a RADIUS server on UDP 1812 (authentication) and 1813 (accounting). RADIUS checks the credential, returns the pairwise master key (PMK) to the AP and can return VLAN or role attributes. RADIUS itself relies on a shared secret, so use RadSec (RADIUS over TLS, TCP 2083) or a protected management network across untrusted links. Lightweight APs reach controllers over CAPWAP (RFC 5415, UDP 5246 control, 5247 data), with DTLS on the control channel.

Microsoft's Credential Guard documentation recommends moving from PEAP-MSCHAPv2 and EAP-MSCHAPv2 to PEAP-TLS or EAP-TLS, and blocks single sign-on to MS-CHAPv2 networks, which often forces the migration. Password Wi-Fi is also how the APT28 intrusion reported by Volexity worked: the target's internet services required MFA, but its Wi-Fi accepted a domain username and password obtained by password spraying.

Server certificate validation

RFC 9190 says peers should be configured with "one or more trusted root certificates" and server names to match against the SubjectAltName, and warns that a public root without name matching lets any server with a publicly trusted certificate pass. Issue the RADIUS certificate from a private CA, push that root and the exact server names in the Wi-Fi profile (Group Policy, Intune or another MDM) and remove the prompt that lets users accept unknown certificates. A profile that lets users click "Connect" on any certificate turns every evil twin into a credential collector.

Where identity fits

• Machine certificates are non-human identities: each laptop, scanner and AP with a Wi-Fi certificate needs issuance, renewal and revocation. RFC 9190 makes revocation checking mandatory and requires servers to support OCSP stapling. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Headless devices: printers and sensors that cannot do 802.1X land on PSK SSIDs. Give them their own SSID and VLAN, per-device keys where possible and tight egress rules. See the Device and IoT Identity Guide.
• Infrastructure secrets: RADIUS shared secrets, controller API keys and wireless admin accounts belong in a vault with rotation, not in configuration backups.

Management frames, deauthentication and legacy attacks

Before 802.11w, deauthentication and disassociation frames were unauthenticated, so anyone could forge them to knock clients off, capture a WPA2 handshake on reconnect or push clients towards an evil twin. Protected management frames (PMF, also called management frame protection) protect unicast management frames "from eavesdropping and forging", in the Wi-Fi Alliance's words, and multicast frames from forging. PMF does not stop radio jamming, which only spectrum monitoring detects.

Changing the Wi-Fi password does not fix an implementation flaw such as KRACK; patching does. Keep controllers, APs and client drivers in the normal patch cycle. See the Patch Management Guide.

Guest Wi-Fi, captive portals and Enhanced Open

NIST SP 800-153 states: "Devices on one WLAN should not be able to connect to devices on a logically separated WLAN." Put guests in their own VLAN or tunnel them to a DMZ anchor controller, enable client isolation, and allow only DNS, HTTP and HTTPS outbound through protective DNS.

• Enhanced Open (OWE, RFC 8110): a Diffie-Hellman exchange at association gives each client its own key without a passphrase, defeating passive sniffing. RFC 8110 warns "Opportunistic encryption does not provide authentication" and that OWE is open to an adversary impersonating the AP. Use it to replace open guest SSIDs, never 802.1X.
• OWE transition mode: pairs a hidden OWE SSID with an open one. Cisco notes it is unsupported in 6 GHz and deprecated in Wi-Fi 7, so build OWE-only guest networks.
• Captive portals: RFC 8952 says solutions "MUST NOT require the forging of responses from DNS or HTTP servers". Modern portals advertise an API through DHCP option 114 or router advertisements (RFC 8910) served over TLS (RFC 8908), avoiding DNS hijacks that break DNSSEC and HTTPS.
• No corporate credentials on portals: evil twins clone portals because users type passwords into them; ATT&CK T1557.004 describes victims being sent to fake captive portal pages.
• Logging and tracking: keep address assignment records for incident response. Phones randomise MAC addresses per network to limit tracking, and devices probing for remembered SSIDs leak names an evil twin can copy, so remove stale profiles from managed devices.

Rogue access points and evil twins

A rogue AP is any access point operating without authorisation. The dangerous ones bridge to the wired network or impersonate a corporate SSID (evil twin, ATT&CK T1557.004; MITRE notes APT28 has used a Wi-Fi Pineapple).

• WIDS and WIPS sensors: NIST lists dedicated sensors, sensors in APs and host agents. Dedicated radios scanning all channels, including DFS and 6 GHz, see far more than APs scanning off-channel.
• Locate, do not probe: NIST recommends finding rogues by triangulating signal strength so staff can respond physically.
• Containment has legal limits: automatic containment sends deauthentication frames to the rogue's clients, and regulators including the US FCC have penalised operators for deauthenticating people's own hotspots. Restrict it to rogues confirmed on your wired network or spoofing your SSIDs, and take legal advice.
• Dual-homed devices: in the case Volexity reported in November 2024, APT28 compromised an organisation across the street, found a system with "both a wired and wireless network connection" and used it to join the target's SSID (ATT&CK T1669, campaign C0051). NIST SP 800-153 already advised blocking dual connections, noting "Non-technical controls are usually not effective enough."

Choosing an approach

• EAP-TLS or PEAP: choose EAP-TLS whenever certificates can be enrolled through MDM or auto-enrolment. Keep PEAP-MSCHAPv2 only for a dated migration, with root and server name pinned.
• WPA3-only or transition: WPA3-only on new and 6 GHz SSIDs. Move WPA2-only devices to an isolated legacy SSID rather than holding the main SSID back.
• 192-bit mode: only where policy demands CNSA-grade cryptography and every client and AP model supports it.
• Small organisations: cloud-managed APs, WPA3-Personal with a strong rotated passphrase, an OWE guest SSID, PMF required and WPS off. Add 802.1X through a cloud RADIUS service once devices are managed.
• Large organisations: EAP-TLS with machine certificates, RADIUS-assigned VLANs or roles, dedicated WIPS sensors at sensitive sites, logs in the SIEM, and wired 802.1X so rogue APs cannot simply be plugged in.
• Treat Wi-Fi like remote access: Volexity advises handling corporate Wi-Fi "with the same care and attention" as VPN. If VPN needs MFA or a certificate, so should Wi-Fi. See the Remote Access Identity Guide.

Rolling out stronger Wi-Fi security

1. Inventory: SSIDs, security modes, EAP methods, firmware, and client capability by model (WPA3, PMF, H2E, 6 GHz). Export association data to see who still uses WPA2 or TKIP.
2. Remove the worst first: disable WEP, TKIP and WPS; set PMF to optional on every WPA2 SSID; patch controllers and APs.
3. Build the PKI path: RADIUS server certificate from a private CA, certificate auto-enrolment for managed devices, OCSP or CRL checking on RADIUS.
4. Pilot on a new SSID: WPA3-Enterprise, EAP-TLS, PMF required, pushed with pinned root and server names to an IT ring, then a wider ring. The old SSID stays untouched, so rollback means removing the new profile.
5. Test each ring: roaming, fast transition, sleep and resume, certificate renewal, revocation of a test device, RADIUS failover and behaviour when the CA is unreachable.
6. Migrate and retire: move users ring by ring while watching RADIUS reject rates; move the remaining exceptions to an isolated legacy SSID, then switch the old SSID off.
7. Tighten: PMF required, transition mode off, Transition Disable where tested, automatic containment only for confirmed on-wire rogues. Keep exported prior configurations and a temporary IT break-glass SSID for each cutover.

Detection and measurement

NIST SP 800-153 asks for attack and vulnerability monitoring, vulnerability checks "at least as often for WLAN components as they are for the organization's equivalent wired systems" and assessments at least annually. Send these to the SIEM:

• RADIUS and NPS: Windows NPS events 6272 (granted), 6273 (denied), 6274 (discarded) and 6279 (locked after repeated failures). Alert on bursts of 6273 for one account across many APs, sign-ins from sites a user never visits, and certificates used after a device was reported lost.
• Controller and WIPS: rogue and evil twin detections, deauthentication floods, ad hoc networks, and managed clients joining unknown BSSIDs.
• Endpoints: Volexity recommends watching anomalous netsh use, which can add Wi-Fi profiles and start hotspots; flag hosts with forbidden simultaneous wired and wireless links.
• Configuration drift: scheduled checks that every SSID matches the standard (cipher, PMF, EAP method, WPS off).

Framework mapping

Common failure patterns

• Password Wi-Fi beside MFA everywhere else: the Nearest Neighbor intrusion used sprayed passwords on an SSID that asked for nothing more. Bring corporate SSIDs into the same MFA or certificate standard as VPN and remote access.
• Users allowed to trust any certificate: profiles without pinned root and server name hand PEAP credentials to the first evil twin.
• Transition mode with no end date: one old scanner keeps WPA2 alive for years, and the downgrade path stays open for every modern client.
• Guest network that is not isolated: guest VLAN routed internally or client isolation off, so an infected visitor laptop can scan corporate devices.
• Branch and home equipment outside the standard: consumer routers with WPS on and firmware never patched after KRACK-class advisories.
• WIPS alerts nobody owns: thousands of neighbour APs marked rogue, so the one on-wire rogue is never physically located.

Practitioner checklist

• Move corporate SSIDs to WPA3-Enterprise with EAP-TLS and device or user certificates.
• Pin the RADIUS root and server names in every Wi-Fi profile and remove the user trust prompt.
• Require PMF and remove WEP, TKIP and WPS on every SSID, including branches.
• Run WPA3-only on new and 6 GHz SSIDs; give any transition mode an end date.
• Replace open guest Wi-Fi with isolated Enhanced Open.
• Cover all sites and bands with WIPS and classify rogues by wired correlation.
• Block unauthorised dual-homed connections and bridging on managed endpoints.
• Send NPS 6272, 6273, 6274 and 6279, controller and WIPS events to the SIEM.
• Manage Wi-Fi certificates, RADIUS secrets and controller credentials as non-human identities.
• Assess WLAN security at least annually and after major changes.

Standards and references

• NIST: SP 800-153 Guidelines for Securing Wireless Local Area Networks (WLANs)
• Wi-Fi Alliance: Wi-Fi CERTIFIED WPA3, Enhanced Open and Protected Management Frames
• IETF: RFC 9190 EAP-TLS 1.3
• IETF: RFC 8110 Opportunistic Wireless Encryption
• IETF: RFC 8952 Captive Portal Architecture
• MITRE ATT&CK: T1557.004 Adversary-in-the-Middle: Evil Twin
• Microsoft Learn: Credential Guard considerations and known issues
• Volexity: The Nearest Neighbor Attack

Related NHI Mgmt Group resources: Network Ports and Protocols Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Device and IoT Identity Guide · Zero Trust Identity Guide · DNS Security Guide