1. Why Deauth Attacks Still Work (On Networks Without PMF)

802.11 management frames are unauthenticated. Any station within RF range can attempt a deauthentication or disassociation attack against a connected client. The target has no mechanism to distinguish a legitimate deauthentication frame from the AP from one with a spoofed source MAC, because the 802.11 frame header carries no cryptographic signature, no sequence integrity check, and no binding to the session keys established during authentication. The BSSID field is just a value in a header, and anyone can write whatever they want into it (IEEE, “IEEE Std 802.11-2020”).

This is what makes aireplay-ng --deauth so effective. A free Kali Linux distro, a cheap wireless adapter, and a single command is all it takes. No password. No credentials. No knowledge of the network beyond the BSSID. It does not matter whether the target is running WPA2-Personal or WPA2-Enterprise with full 802.1X authentication, the certificate and the PSK protect data frames. Management frames are on their own, and without PMF, they are completely exposed.

2. How 802.11w PMF Works

Protected Management Frames extends cryptographic protection to a specific class of management frames called Robust Management Frames. Rather than a new key hierarchy, PMF reuses the session keys already established during the EAPOL four-way handshake (IEEE, “IEEE Std 802.11w-2009”).

Unicast Protected Management Frames

Individually addressed Deauthentication, Disassociation, and Action frames are protected with the Pairwise Transient Key (PTK), the same key already driving CCMP or GCMP on data frames. The Protected Frame bit (bit 6 of Frame Control) is set to 1, and the frame carries a full CCMP or GCMP header. An attacker cannot forge a valid protected deauth without the PTK, which never crosses the wireless medium (IEEE, “IEEE Std 802.11w-2009”).

Broadcast and Multicast Protected Management Frames

The PTK is a per-client unicast key and cannot protect group-addressed frames. PMF introduces a dedicated key called the Integrity Group Temporal Key (IGTK), distributed to all clients during EAPOL Message 3/4 as a Key Data Encapsulation (KDE) element. Broadcast Robust Management Frames are integrity-checked with BIP-CMAC-128, which appends a Message Integrity Check Element (MMIE) to the frame. BIP provides integrity, not confidentiality, the content of broadcast management frames remains readable in a capture, but forgery becomes detectable (IEEE, “IEEE Std 802.11w-2009”).

The SA Query Procedure

When a PMF-capable client receives an unprotected Disassociation or Deauthentication frame, exactly what a deauth attack generates, it does not immediately disconnect. Instead it initiates the Security Association (SA) verification procedure: it sends an SA Query Request to the AP over the protected channel. If the AP responds with a valid SA Query Response (also protected), the session is confirmed intact and the forged frame is discarded. If no valid response arrives within the timeout window, the client proceeds with disassociation (IEEE, “IEEE Std 802.11-2020”).

3. What PMF Protects, and What It Doesn’t

The table below categorizes 802.11 management frame types by their PMF protection status, as defined in the IEEE specifications (IEEE, “IEEE Std 802.11w-2009”; IEEE, “IEEE Std 802.11-2020”).

4. RSN Information Element: Decoding the PMF Bits

PMF capability and requirement are communicated through the RSN Information Element (IE Tag 48), present in Beacon, Probe Response, Association Request, and Reassociation Request frames. Within the RSN IE, the 2-byte RSN Capabilities field carries the two bits that govern PMF (IEEE, “IEEE Std 802.11-2020”):

What It Looks Like in Wireshark

In any Beacon from PMF_Required, expand Tagged Parameters → RSN Information (Tag 48) → RSN Capabilities. The lab capture below shows exactly what to look for (IEEE, “IEEE Std 802.11-2020”):

5. PMF Mode Comparison

6. Lab Setup

My lab setup consists of a Kali Linux instance running an Alfa AWUS036ACH 802.11ac (Wi-Fi 5) adapter in monitor mode, statically set to Channel 36 (5180 MHz) on a 20 MHz channel width. Infrastructure is a Cisco Catalyst 9800-L WLC on 17.15.4d code behind a Cisco 3560X PoE+ switch, one Cisco Catalyst 9166 AP (Cisco Systems, Catalyst 9800 Series Wireless LAN Controller Security Configuration Guide). Test client is a Samsung Galaxy S25+.

Three SSIDs are configured on the same AP, same 5 GHz radio, same Channel 36. Keeping everything on one channel means the Alfa catches all three without channel-hopping:

7. Scenario 1: Deauth Attack Without PMF

First thing we do is prove the problem is real. PMF_Disabled is a plain WPA2-PSK SSID with no PMF. Management frames are wide open. This is what that looks like on the 9800:

Connect the Samsung to PMF_Disabled and run the flood:

# AP BSSID: 5c:64:f1:bf:4b:ed  (Cisco 9166, PMF_Disabled)
# Samsung Galaxy S25+:          f6:dc:54:62:03:35
aireplay-ng --deauth 0 -a 5c:64:f1:bf:4b:ed -c f6:dc:54:62:03:35 wlan0

The Samsung drops. In Wireshark, filter for deauthentication frames on PMF_Disabled:

wlan.bssid == 5c:64:f1:bf:4b:ed && wlan.fc.type_subtype == 0x0c

Frame 6372 through 6389, same ~60ms window, all identical:

  Type/Subtype: Deauthentication (0x000c)
  Frame Control Field: 0xc000          ← Protected Frame bit = 0
  Transmitter: Cisco_bf:4b:ed (5c:64:f1:bf:4b:ed)  ← aireplay spoofing the AP
  Receiver:    f6:dc:54:62:03:35               ← Samsung Galaxy S25+
  Sequence Number: 126 ... 126 ... 126 ... 126  ← same SN repeated = injected
  Reason Code: 0x0006  ← "Class 2 frame from nonauthenticated STA"

Frames 9423–9433: SN resets to 131, same pattern repeats.
No SA Query. No Action frames. No protection. Client dropped clean.

A few things worth pointing out in that capture. The source address on every frame is the AP’s own BSSID, 5c:64:f1:bf:4b:ed, because aireplay-ng spoofs the AP to make the Samsung think it is being kicked by the infrastructure itself. The Samsung has no way to verify that. The sequence number repeating at 126 across sixteen consecutive frames is the dead giveaway that these are injected, not real, a legitimate AP increments the sequence number on every frame. And the reason code 0x0006 is the default aireplay-ng value. None of this requires a password, a certificate, or any knowledge of the network. Just the BSSID and the target MAC (IEEE, “IEEE Std 802.11-2020”).

8. Scenario 2: Deauth Attack With PMF Required

Now connect the test client to PMF_Required. Do not run any attack yet. Just associate normally and capture the whole process. PMF is not something you turn on after the fact, it gets negotiated in three specific places during the association itself (IEEE, “IEEE Std 802.11w-2009”). Here is the configuration that makes it happen:

Step 1, The Beacon Announces It

The AP advertises PMF support in every Beacon frame before any client shows up. Filter for Beacons from PMF_Required:

wlan.bssid == 5c:64:f1:bf:4b:eb && wlan.fc.type_subtype == 0x08

Expand: Tagged Parameters → RSN Information (Tag 48) → RSN Capabilities

.... .... 1... ....  = Management Frame Protection Capable:  Capable   ← MFPC, bit 6
.... ...1 .... ....  = Management Frame Protection Required: Required  ← MFPR, bit 7

Scroll past PMKID List:
Group Management Cipher Suite: 00:0f:ac (IEEE 802.11) BIP (128)
← Confirms broadcast management frame protection is active (IEEE Std 802.11w-2009)

Step 2, The Client Agrees to It

When the Samsung sends its Association Request to PMF_Required, it does not just advertise PMF support, it sets both MFPC=1 and MFPR=1. On WPA3-SAE, a modern Android client goes further than “I can do PMF” and says “I require PMF too.” Also notice the Group Management Cipher Suite: BIP (128) is present in the client’s own RSN IE, explicitly advertising broadcast management frame protection capability. This is full WPA3 client behavior (IEEE, “IEEE Std 802.11-2020”; Wi-Fi Alliance, “WPA3 Specification”).

Note the new randomized MAC: the Samsung used f6:dc:54:62:03:35 on PMF_Disabled and switched to 82:c5:bc:bd:21:c5 on PMF_Required. Android assigns a unique stable randomized MAC per SSID by default.

wlan.bssid == 5c:64:f1:bf:4b:eb && wlan.fc.type_subtype == 0x00

# Frame 685, Samsung Galaxy S25+, MAC: 82:c5:bc:bd:21:c5
Open RSN Information (Tag 48) → RSN Capabilities: 0x00cc

  AKM Suite:  00:0f:ac (IEEE 802.11) SAE (SHA256)      ← WPA3-SAE
  Management Frame Protection Capable:  Capable         ← MFPC = 1
  Management Frame Protection Required: Required         ← MFPR = 1 (WPA3 client sets this)
  Group Management Cipher Suite: 00:0f:ac BIP (128)     ← client advertises BIP support
  PTKSA Replay Counter: 16 replay counters (0x3)         ← modern device

If MFPC = 0 here against a PMF-Required AP:
  Association Response → Status Code 30: ROBUST_MGMT_FRAME_POLICY_VIOLATION
  Association fails. Client cannot connect.

Step 3, The Key That Protects Broadcast Frames Gets Handed Off

In EAPOL Message 3 of 4, the AP hands the client the IGTK, the key used to protect broadcast management frames with BIP-CMAC-128. This is the moment broadcast management frame protection actually activates.

eapol && wlan.bssid == 5c:64:f1:bf:4b:eb

Open EAPOL Message 3 of 4 → WPA Key Data
  Key Data Type: IGTK KDE (OUI 00:0f:ac, Type 9)
  IGTK Key ID:   4          ← IGTK IDs start at 4; GTK IDs are 1–3
  IPN:           [6 bytes]   ← Integrity Packet Number, anti-replay counter
  IGTK:          [16 bytes]  ← The BIP-CMAC-128 key for broadcast frames (IEEE Std 802.11w-2009)

WPA2-PMF-Optional vs. WPA3-SAE: RSN Capabilities Side by Side

Capture a Beacon from each SSID type and look at the same RSN Capabilities field. The difference comes down to one bit and one AKM suite (IEEE, “IEEE Std 802.11-2020”; Wi-Fi Alliance, “WPA3 Specification”):

RSN Capabilities: 0x00a8

.... .... 1... ....
  = MFPC: Capable
.... ...0 .... ....
  = MFPR: Not Required

AKM: 00:0f:ac:2 (PSK)

Group Mgmt Cipher:
BIP (128) present
but not enforced.

Non-PMF clients can
associate freely.

RSN Capabilities: 0x00e8

.... .... 1... ....
  = MFPC: Capable
.... ...1 .... ....
  = MFPR: Required

AKM: 00:0f:ac:8 (SAE)

Group Mgmt Cipher:
  BIP-CMAC-128 (128)

Client MFPC=0 →
Status Code 30,
assoc rejected.

9. Scenario 3: Deauth Attack Against PMF-Capable Client Without Enforcement

Run the exact same attack as Scenario 1. Same command. Same Alfa adapter. Same channel. The only difference is the SSID.

# Same command, now targeting PMF_Required
aireplay-ng --deauth 0 -a 5c:64:f1:bf:4b:eb -c 82:c5:bc:bd:21:c5 wlan0

Now filter so you can watch the attack and the defense at the same time:

# Unprotected deauths (attacker) AND SA Query frames (PMF response) together
(wlan.bssid == 5c:64:f1:bf:4b:eb && wlan.fc.type_subtype == 0x0c && wlan.fc.protected == 0) ||
(wlan.bssid == 5c:64:f1:bf:4b:eb && wlan.fc.type_subtype == 0x0d && wlan.fc.protected == 1)

What you will see interleaved in the frame list:
802.11  Deauthentication  [Protected=0]  ← attacker's frame, ignored
802.11  Deauthentication  [Protected=0]  ← another one, ignored
802.11  Action            [Protected=1]  ← SA Query Request  (client → AP)
802.11  Action            [Protected=1]  ← SA Query Response (AP → client)
802.11  Deauthentication  [Protected=0]  ← flood keeps going, client still associated

# Drill into either SA Query Action frame and confirm:
#   Category: 8 (SA Query)
#   Action Code: 0x00 (Request) or 0x01 (Response)
#   Transaction Identifier: same 2-byte value in both frames (IEEE Std 802.11-2020)

The flood runs the whole time. The client does not move. The difference between Scenario 1 and Scenario 3 is three RSN IE bits, one IGTK, and a key exchange that happened 30 seconds earlier during the four-way handshake (IEEE, “IEEE Std 802.11w-2009”).

Wireshark Filter Reference

All discrete display filters used across Scenarios 1, 2, and 3:

10. WPA2 vs. WPA3 PMF Behavior

The IEEE 802.11-2020 consolidated standard and the Wi-Fi Alliance WPA3 Specification together define where PMF is optional versus where it is non-negotiable. The table below maps each security mode to its PMF mandate (IEEE, “IEEE Std 802.11-2020”; Wi-Fi Alliance, “WPA3 Specification”).

11. Deployment Guidance

Cisco Catalyst 9800 Configuration Reference

The following CLI applies to Cisco IOS XE 17.x on the Catalyst 9800 platform (Cisco Systems).

# Check current PMF setting on a WLAN
show wlan id <id> detail | include PMF

# WPA3-SAE with PMF Required (mandatory by spec)
wlan <profile-name> <id> <ssid>
  security wpa akm sae
  security wpa wpa3
  security pmf mandatory
  no shutdown

# WPA2-Enterprise with PMF Required (valid and recommended)
wlan <profile-name> <id> <ssid>
  security dot1x
  security wpa wpa2
  security pmf mandatory    # ← change "optional" to "mandatory"
  no shutdown

# Verify in a capture after applying:
# Beacon RSN IE should show MFPC=1, MFPR=1
# Association Request from client should echo MFPC=1
# EAPOL Message 3/4 Key Data should contain IGTK KDE

12. Works Cited