---
name: harden-wpa3
description: "WPA3-SAE transition-mode and downgrade hardening for Wi-Fi. Transition mode lets an adversary stand up a WPA2-only rogue AP with the same SSID, force clients down to WPA2 with spoofed deauth frames, and capture a crackable 4-way handshake; related abuse includes SAE commit flooding and Dragonblood side channels (CVE-2019-9494, CVE-2019-9495, CVE-2019-13377, CVE-2019-13456). Maps to MITRE ATT&CK T1557, T1040, T1499.001. Signal lives at the 802.11 layer: WIDS/WIPS rogue-AP alerts, WLC syslog, hostapd logs, beacon RSN/RSNXE elements (SAE vs PSK AKM, PMF bits, Transition Disable), deauth bursts, and Windows WLAN-AutoConfig events. Gives the SAE and PMF settings to mandate, downgrade signals, a hunt, and framework-mapped hardening. Use when deploying WPA3-SAE, choosing transition mode vs separate SSIDs, hardening 6 GHz / Wi-Fi 6E, triaging evil-twin alerts, hunting clients that fell back to WPA2, or responding to SAE auth flooding."
---

# WPA3-SAE Transition-Mode and Downgrade - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule and reference sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

SAE itself is sound; the exposure is almost always the configuration around it. The single highest-value fix is to stop living in **transition mode**. Transition mode advertises one SSID as both WPA2-PSK and WPA3-SAE so old clients can still join, and that is exactly the seam an adversary pries open: a WPA2-only rogue AP with your SSID, a burst of deauth frames, and clients roam down to WPA2 where the 4-way handshake is captured and cracked offline. Close it in this order: enable the WPA3 **Transition Disable** indication so clients that have seen your SSID in SAE refuse to use WPA2 for it afterward; mandate **Protected Management Frames (802.11w, MFPR=1 required)** so deauth/disassoc forcing no longer works; split legacy and WPA3 clients onto **separate SSIDs** and retire the WPA2 SSID on a schedule; make every **6 GHz / Wi-Fi 6E** SSID WPA3-only with PMF, which the spec already forbids transition mode on; and **patch AP and supplicant firmware** to close the Dragonblood side channels and prefer **Hash-to-Element (H2E)** over hunting-and-pecking. The telemetry that shows whether this holds is 802.11 management-frame and WIDS data, not host syslog. This skill is defensive and ships no rogue-AP, downgrade, deauth, SAE-flood, or handshake-capture tooling.

## What it looks like, defender view

A downgrade presents as a second access point claiming your identity. In WIDS/WIPS you see an **evil-twin / honeypot / spoofed-BSSID / rogue-AP** alert: the same SSID (and often a cloned BSSID) advertised by a radio that is not in your managed inventory, frequently with a **weaker RSN security** than your real AP (WPA2-PSK where yours is SAE, or PMF absent). Around it you see a **deauthentication / disassociation burst** aimed at your clients to knock them off the legitimate AP, then client associations that complete over **WPA2 (AKM suite 2)** on an SSID your policy says is **SAE (AKM suite 8)**. On the client side the same event is a WLAN-AutoConfig connection record showing a WPA2/PSK cipher where you expect WPA3/SAE.

SAE auth flooding presents differently: a flood of **SAE Commit** authentication frames from many (often spoofed) MAC addresses driving the AP's CPU up as it computes the Dragonfly scalar for each, which starves legitimate associations. In hostapd-based APs this shows as sustained SAE commit processing and anti-clogging-token challenges in the log. The Dragonblood side channels (CVE-2019-9494/9495/13377/13456) are implementation timing and cache leaks in the SAE and EAP-pwd password derivation (CVE-2019-13456 is the FreeRADIUS EAP-pwd case, fixed on the RADIUS server rather than in AP or supplicant firmware); you do not realistically detect the attacker measuring them, so defensively they collapse to "patch the firmware and use H2E", and the observable you hunt is the rogue AP and the downgrade, not the cache-timing measurement itself.

## Log sources and signals

The evidence is 802.11 management/association telemetry plus client association records. Use one or more of:

- **WIDS / WIPS and wireless controller.** HPE Aruba Wireless Intrusion Prevention, Cisco Catalyst / 9800 WLC with CleanAir and Rogue Management, Meraki **Air Marshal**, Ekahau/other scanners. Watch rogue-AP, evil-twin/honeypot, spoofed-BSSID, "SSID advertised with different security", and **containment** events; ship controller syslog to the SIEM.
- **Beacon / Probe-Response RSN and RSNXE information elements.** The signal is in the frame, not a log: **AKM suite selector** (00-0F-AC:8 = SAE, 00-0F-AC:2 = PSK, 00-0F-AC:24 = SAE-EXT-KEY (SAE with group-dependent hash, which requires H2E), 00-0F-AC:9 = FT-SAE, 00-0F-AC:25 = FT-SAE-EXT-KEY; H2E support itself is signaled by the SAE Hash-to-Element bit in the RSNXE, not by an AKM), the **RSN Capabilities** bits **MFPC** (PMF capable) and **MFPR** (PMF required), and, separately, the **Transition Disable** indication, which is not advertised in the beacon at all but is delivered to an associating client in the Transition Disable KDE inside EAPOL-Key message 3 of the 4-way handshake (verify it from AP configuration or a capture of an association's M3). Capture with Wireshark/tshark (`wlan_rsna`, `wlan.rsn.akms.type`, `wlan.rsn.capabilities.mfpr`). A corporate SSID appearing as WPA2-only, or a duplicate BSSID, is the finding.
- **Deauthentication / disassociation frames.** 802.11 management subtypes 0x0C (deauth) and 0x0A (disassoc). On a PMF-required network these are protected and spoofed ones are rejected; a burst of **unprotected** deauth/disassoc for your BSSIDs means PMF is not being enforced and a forced-roam downgrade is possible or underway.
- **Access-point / hostapd logs.** SAE commit/confirm processing, anti-clogging token issuance, `SAE: Not enough entropy`, and association-reason codes. High-rate SAE commit from many MACs is the flood signal.
- **Client-side Windows WLAN-AutoConfig.** `Microsoft-Windows-WLAN-AutoConfig/Operational`: **8001** (association succeeded, carries SSID, authentication and cipher), **8002** (association failed with reason), **11000/11001/11010** (connection/association phase), **12011/12012/12013** (802.1X authentication started, succeeded, failed - WPA3-Enterprise only; for Personal PSK/SAE the security phase is 11010 started, 11005 succeeded, 11006 failed). These let you find a fleet client that negotiated WPA2-PSK on an SSID that should be SAE.
- **RADIUS / NPS (WPA3-Enterprise).** Authentication records for the Enterprise case, to correlate which station authenticated where.

**Baseline.** On a hardened network every managed BSSID advertises SAE (AKM 8, or 24/25 with H2E), MFPR=1, and the Transition Disable bit set; the steady-state count of unmanaged BSSIDs claiming your SSIDs is zero, spoofed/unprotected deauth is rejected, and SAE commit volume tracks your real client population.

## Detection approach

Alert on configuration drift and rogue presence, not on individual frames. The high-signal conditions are: (1) a **WIDS evil-twin / rogue-AP / spoofed-BSSID** event for one of your SSIDs, especially one advertising **weaker RSN security** (WPA2-PSK or PMF absent) than your managed AP; (2) a **client association over WPA2/PSK on an SSID your policy defines as SAE**, correlated across WIDS beacon inventory and Windows WLAN-AutoConfig 8001 records (Authentication field); (3) a **burst of unprotected deauthentication/disassociation** for your BSSIDs, which both signals a forced-roam attempt and proves PMF is not enforced; and (4) **high-rate SAE Commit** authentication frames from many source MACs at one AP, i.e. auth-flood CPU exhaustion.

Because the primary signal is 802.11 management-frame and WIDS data rather than a standard SIEM log schema, **a tuned UMBRASEC rule is not yet shipped for this threat**, and conditions (1) to (4) are expressed against your wireless platform and capture tooling. For the host-shaped portion (the Windows WLAN-AutoConfig operational events), track and reuse community SIEM content in the [SigmaHQ repository](https://github.com/SigmaHQ/sigma) (`rules/windows/` builtin channels). For rogue and evil-twin detection rely on the vendor analytics named above (for example [Cisco Rogue Management and aWIPS](https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/rogue-management/b-rogue-management-c9800.html) and [Meraki Air Marshal](https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal)). For the protocol and spec basis use the [Wi-Fi Alliance WPA3 Specification](https://www.wi-fi.org/discover-wi-fi/security) (Transition Disable, H2E, 6 GHz requirements), the [Wireshark 802.11 RSN reference](https://www.wireshark.org/docs/dfref/w/wlan.html), and the Dragonblood advisory at [wpa3.mathyvanhoef.com](https://wpa3.mathyvanhoef.com/).

## Threat hunt

Hypothesis: a managed SSID is reachable over WPA2, PMF is not enforced, or a rogue AP is impersonating it.

1. **Inventory your airspace by security.** From WIDS/controller or a tshark capture, enumerate every SSID/BSSID in range and record per BSSID the AKM suites and MFPC/MFPR from the beacon, and confirm Transition Disable separately from the AP/controller configuration or from the Transition Disable KDE in a captured EAPOL-Key M3. Flag any SSID in your inventory advertising both SAE (8) and PSK (2), any that is WPA2-only, and any **unmanaged** BSSID advertising one of your SSIDs.
2. **Confirm PMF is required, not merely capable.** MFPC=1 with MFPR=0 means PMF is offered but spoofed deauth still works; MFPR must be 1 on every managed BSSID.
3. **Confirm Transition Disable is set.** Without it, a client that has already connected with SAE will still accept WPA2-PSK for the SSID, so a rogue WPA2-only AP plus forced roaming can downgrade it.
4. **Hunt client fallback across the fleet.** Query `Microsoft-Windows-WLAN-AutoConfig/Operational` for event 8001 records on the target SSIDs where the Authentication field is WPA2-Personal rather than WPA3-Personal (SAE). Each is a client that downgraded.
5. **Review WIDS history.** Pull evil-twin, honeypot, spoofed-BSSID, rogue-AP, and containment events over a long window and correlate their appearance with any deauth bursts.
6. **6 GHz check.** Confirm every 6 GHz SSID is WPA3-only with PMF and carries no WPA2 AKM; transition mode is not permitted there by spec, so its presence is a misconfiguration.

## Hardening

Shrink the surface by removing the downgrade path; detection is then a backstop. The mappings below follow the control codes used in the UMBRASEC [identity and access guide](https://umbrasec.dev/guide/identity-and-access.html); a cell is left blank where no single control maps cleanly. The Essential Eight column is blank throughout because the Essential Eight is a Windows-estate maturity model and does not address Wi-Fi radio or RSN configuration; patch-management of AP firmware is the one place it brushes this surface, and that is called out in prose rather than forced into a cell.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Enable WPA3 Transition Disable indication | Tells clients that have seen the SSID in SAE to stop using WPA2 for it, closing the forced-fallback window without breaking first-time legacy joins | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| Mandate PMF (802.11w, MFPR=1) | Authenticates management frames so spoofed deauth/disassoc are rejected and the forced-roam step of a downgrade fails; mandatory on 6 GHz | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| Separate SSIDs for legacy vs WPA3; retire WPA2 | Removes transition mode as a standing seam; legacy devices sit on a scoped, scheduled-for-retirement SSID, WPA3 clients never carry a WPA2 fallback | - | A.5.15 Access control; A.8.5 Secure authentication | PR.PS Platform security |
| 6 GHz / Wi-Fi 6E WPA3-only with PMF | Enforces the spec: no transition mode, PMF required, SAE only | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| Patch AP and supplicant firmware; prefer H2E | Closes the Dragonblood side channels (CVE-2019-9494/9495/13377/13456) and moves SAE to Hash-to-Element, which removes the hunting-and-pecking timing/cache leak | - (AP firmware patching aligns to the Essential Eight patch controls) | A.8.8 Technical vulnerabilities | PR.PS Platform security |
| WIDS/WIPS rogue-AP and evil-twin monitoring | Continuous detection and (optionally) containment of impersonating APs and downgrade attempts | - | A.8.16 Monitoring activities; A.8.15 Logging | DE.CM Continuous monitoring |

SAE anti-clogging is a protocol property rather than a governance control, so it is noted here in prose: keep the AP's SAE anti-clogging token / rate-limit defenses enabled and sized to your client population so a commit flood is shed rather than allowed to exhaust CPU, and rate-limit or source-filter SAE auth at the controller where supported.

## Honest limitations

Transition disable and PMF defeat the **forced** downgrade, but a client that has never seen your SSID in SAE, or a legacy-only device you must keep on a WPA2 SSID, can still be lured to a rogue WPA2 AP; the residual risk is the legacy SSID you have not yet retired, which is why retirement is a dated plan, not a checkbox. WIDS rogue-AP detection depends on sensor coverage: an evil twin operated just outside your monitored airspace, or on a channel you do not scan, will not alert, and containment can raise legal and co-tenancy issues you must clear first. The Dragonblood side channels are not practically detectable in flight; you detect the rogue AP and the downgrade, and you close the side channel by patching, so an unpatched AP remains exposed to a local timing/cache attacker regardless of your monitoring. Passive sniffing of a correctly negotiated SAE + PMF session yields nothing, which is the goal, but that same protection blinds a passive defender to a legitimately associated but malicious station. Finally, SAE flood mitigation sheds load but a sufficiently resourced flood from spoofed MACs can still degrade service; treat anti-clogging as harm-reduction, not immunity.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) (Credential Access, Collection) for the transition-mode downgrade / evil-twin rogue AP; [T1040 Network Sniffing](https://attack.mitre.org/techniques/T1040/) (Credential Access, Discovery) for capturing the downgraded WPA2 4-way handshake; [T1499.001 Endpoint Denial of Service: OS Exhaustion Flood](https://attack.mitre.org/techniques/T1499/001/) (Impact) for SAE commit flooding of the AP CPU.
- MITRE D3FEND: [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) for the WIDS rogue-AP and downgrade detection; [D3-MAN Message Authentication](https://d3fend.mitre.org/technique/d3f:MessageAuthentication/), which is precisely what PMF (802.11w) applies to management frames so spoofed deauth is rejected; [D3-MENCR Message Encryption](https://d3fend.mitre.org/technique/d3f:MessageEncryption/) for the SAE-negotiated link itself.
- Public rule and reference sources: [Wi-Fi Alliance WPA3 Specification](https://www.wi-fi.org/discover-wi-fi/security) (Transition Disable, H2E, 6 GHz mandatory PMF); [Dragonblood advisory](https://wpa3.mathyvanhoef.com/) (CVE-2019-9494/9495/13377/13456); [Cisco Rogue Management / aWIPS](https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/rogue-management/b-rogue-management-c9800.html); [Meraki Air Marshal](https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal); [Wireshark 802.11 / RSN fields](https://www.wireshark.org/docs/dfref/w/wlan.html); [SigmaHQ repository](https://github.com/SigmaHQ/sigma) for Windows WLAN-AutoConfig host-side rules.

**Scope note.** This is a defensive skill. It explains WPA3-SAE transition mode and downgrade only to the depth needed to harden a network and detect abuse, and deliberately ships no rogue-AP, downgrade, deauthentication, SAE-flooding, or handshake-capture tooling. UMBRASEC publishes defense, not offense.