802.11w Protected Management Frames: Does It Stop Deauth Attacks?

The deauthentication attack works because 802.11 management frames are unauthenticated. Any device can forge a deauth frame with any source address and send it to any client. Until 802.11w, there was no way for a client to verify that a deauth frame actually came from its AP.

Protected Management Frames (PMF), standardized in IEEE 802.11w-2009 and later incorporated into the main 802.11 standard, is the protocol-level fix for this. Understanding exactly what it protects - and where it doesn't apply - is essential for anyone testing or securing wireless networks.

Standard 802.11 frame structure. Without PMF, management frames like deauth and disassociation are sent with the frame body unencrypted and unauthenticated. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

What PMF Does

PMF adds cryptographic protection to specific management frame types using mechanisms derived from the same security context established during the 4-way handshake. The protected frame types include:

• Deauthentication frames
• Disassociation frames
• Action frames (including spectrum management, QoS, and some vendor actions)
• Certain SA Query frames (used for PMF negotiation itself)

The protection works differently depending on whether the frame is unicast or broadcast/multicast.

Unicast management frames (directed at a specific client) use CCMP encryption - the same AES-based cipher used for data frames. The management frame is encrypted and includes a Message Integrity Code (MIC). A client that receives a deauth frame for itself can verify the MIC. If it doesn't match - meaning the frame came from somewhere other than its associated AP - the frame is silently discarded.

Broadcast management frames use a different mechanism called BIP (Broadcast/Multicast Integrity Protocol), also known as AES-128-CMAC. The AP includes an MMIE (Management MIC Information Element) in broadcast frames, allowing clients to verify integrity without full encryption.

PMF keys come from the 4-way handshake. The IGTK (Integrity Group Temporal Key) for broadcast management frame protection is delivered in Message 3 alongside the GTK. (Diagram: mikm / Wikimedia Commons, public domain)

Where PMF Gets Its Keys

PMF requires an established security association to work. The keys used to protect management frames are derived during the WPA2 or WPA3 4-way handshake, specifically:

graph TD
    subgraph "PMF Key Hierarchy"
        PSK["Pre-Shared Key
(or EAP-derived MSK)"]
        PMK["Pairwise Master Key
(PMK)"]
        PTK["Pairwise Transient Key
(PTK)"]

        subgraph "PTK Components"
            KCK["KCK
Key Confirmation Key
Protects EAPOL frames"]
            KEK["KEK
Key Encryption Key
Encrypts key data"]
            TK["TK
Temporal Key
Encrypts unicast data"]
        end

        GTK["Group Temporal Key
(GTK)
Encrypts broadcast/multicast"]
        IGTK["Integrity GTK
(IGTK) - PMF only
Signs broadcast mgmt frames"]

        subgraph "What IGTK Protects"
            DEAUTH_B["Broadcast deauth"]
            DISASSOC_B["Broadcast disassociation"]
            ACTION["Action frames"]
        end

        subgraph "What PTK Protects (PMF)"
            DEAUTH_U["Unicast deauth"]
            DISASSOC_U["Unicast disassociation"]
            SA_QUERY["SA Query frames"]
        end
    end

    PSK --> PMK
    PMK -->|"4-way handshake"| PTK
    PTK --> KCK
    PTK --> KEK
    PTK --> TK
    PMK -->|"Group handshake"| GTK
    PMK -->|"PMF enabled"| IGTK
    IGTK --> DEAUTH_B
    IGTK --> DISASSOC_B
    IGTK --> ACTION
    TK --> DEAUTH_U
    TK --> DISASSOC_U
    TK --> SA_QUERY

PMF key hierarchy - the IGTK (Integrity Group Temporal Key) is the key addition from 802.11w, providing message authentication for broadcast management frames that were previously unprotected.

• IGTK (Integrity Group Temporal Key) - used for broadcast management frame integrity
• The PTK (Pairwise Transient Key) is used for unicast management frame protection

This means PMF only applies to clients that have already completed authentication and key establishment. There's no PMF protection for frames transmitted before the 4-way handshake completes. This is a fundamental architectural constraint - PMF can't protect frames that are exchanged before the keys that protect those frames have been generated.

sequenceDiagram
    participant ATK as Attacker
    participant STA as Client Station
    participant AP as Access Point

    Note over ATK,AP: Scenario 1: Without PMF (802.11w)
    ATK->>STA: Spoofed Deauth (reason=3)
Source=AP MAC (forged)
    STA->>STA: Accept frame
(no integrity check)
    STA->>STA: Disconnect immediately
    STA->>AP: Reassociation attempt
    Note over STA: Vulnerable to repeated deauth

    Note over ATK,AP: Scenario 2: With PMF Required
    ATK->>STA: Spoofed Deauth (reason=3)
Source=AP MAC (forged)
    STA->>STA: Check CCMP/BIP MIC
    STA->>STA: MIC invalid - frame rejected
    STA->>STA: Stays connected

    Note over STA,AP: SA Query Verification
    STA->>AP: SA Query Request
    AP->>STA: SA Query Response
(proves AP is alive)
    STA->>STA: Confirm association valid

    Note over ATK,AP: Scenario 3: PMF with Legitimate Deauth
    AP->>STA: Deauth with valid MIC
(IGTK-signed)
    STA->>STA: Verify MIC - valid
    STA->>STA: Accept deauthentication

PMF in action - without 802.11w, forged deauth frames are blindly accepted. With PMF, the client verifies message integrity and uses SA Query to confirm the AP is still associated.

What PMF Does Not Protect

The gaps in PMF protection are important to understand:

Pre-association frames: Authentication request/response and association request/response frames happen before the security context exists. An attacker can send deauth frames during this phase. If a client is trying to connect and receives a deauth frame during the authentication exchange, it may give up and retry, making connection difficult. PMF doesn't apply here because there are no keys yet.

Beacon frames: Beacons are broadcast by the AP and are explicitly excluded from PMF protection in most implementations. The reason is practical: clients can't verify beacon integrity before they've associated. Beacon protection (802.11bi) is a separate, newer addition that addresses this, but deployment is rare.

Probe requests/responses: These happen before association and are not PMF-protected.

Physical layer attacks: PMF is a protocol-level defense. Physical-layer jamming - overwhelming the channel with RF noise - isn't stopped by any authentication mechanism. You can jam a 2.4GHz channel into uselessness without sending a single valid 802.11 frame.

Optional PMF deployment: For WPA2, PMF is configurable as disabled, optional, or required. If it's disabled or optional, clients can connect without PMF negotiation, and those clients don't get the protection.

PMF Optional vs. PMF Required

The capability field in the RSN Information Element (the 802.11 security advertisement in beacon frames) indicates PMF support with two bits:

• MFPC (Management Frame Protection Capable): the AP supports PMF
• MFPR (Management Frame Protection Required): the AP requires PMF for all associations

When MFPC is set but MFPR is not, PMF is optional. Clients that support it will negotiate PMF during association. Clients that don't support it can still connect without PMF protection.

When MFPR is set, only clients that support PMF can associate. Legacy clients that don't support 802.11w get rejected. This is the strongest configuration, but it breaks compatibility with older devices.

In WPA3, PMF is required by specification. A WPA3-only network with MFPR set provides the strongest deauth protection available.

For security testing: you can read the RSN IE from the beacon frame to see whether a network has PMF required, optional, or disabled. The BLEShark Nano's WiFi scan results include security type information. A more detailed view requires examining the raw beacon frames in a packet capture.

The SA Query Mechanism

PMF introduces the SA Query (Security Association Query) mechanism to handle a specific edge case: what happens when a legitimate client actually does get disconnected and reconnects?

stateDiagram-v2
    [*] --> Connected: PMF association established

    Connected --> SuspiciousDeauth: Receive unprotected
deauth/disassoc
    SuspiciousDeauth --> SAQuerySent: Send SA Query Request
(protected frame)

    SAQuerySent --> SAResponseOK: AP responds with
SA Query Response
    SAResponseOK --> Connected: Association confirmed
Ignore the deauth

    SAQuerySent --> SATimeout: No response
after timeout
    SATimeout --> SARetry: Retry SA Query
(up to max retries)
    SARetry --> SAQuerySent: Send another query
    SARetry --> Disconnected: Max retries exceeded
AP truly unreachable

    Connected --> LegitDeauth: Receive protected deauth
(valid MIC)
    LegitDeauth --> Disconnected: Accept disconnection

    Connected --> ProtectedDisassoc: Receive protected
disassociation
    ProtectedDisassoc --> Disconnected: Accept disconnection

    Disconnected --> [*]: Reassociation needed

SA Query state machine - when a PMF-enabled client receives a suspicious deauth, it queries the AP before disconnecting. Only if the AP fails to respond (or sends a properly signed deauth) does the client actually disconnect.

When a WPA3/WPA2-PMF AP receives an association request from a client it already has an active session with, it doesn't know if the client genuinely disconnected (lost power, left range, rebooted) or if this is a spoofed reassociation attempt from an attacker. The SA Query protocol resolves this:

1. The AP sends an SA Query Request to the client's current session (if any active session exists)
2. If the client responds correctly (using its PTK to MIC the response), it's the legitimate client
3. If there's no response within a timeout, the AP assumes the client genuinely disconnected and allows the new association

This prevents an attacker from forcing a client off a PMF-protected session and then associating in its place. Without SA Query, an attacker could disconnect a client and quickly claim its identity.

What Happens When You Send Deauth to a PMF Client

When the BLEShark sends a deauth frame to a client on a PMF-required WPA3 network, the outcome depends on how the client handles PMF-protected frames.

A properly implemented PMF client receives the deauth frame, checks for a valid MIC in the MMIE, finds none (because the frame came from the BLEShark, not the real AP), and discards the frame. The client stays connected. The deauth attempt fails silently.

Some older PMF implementations may not be perfectly compliant. There are reports of devices that have PMF listed as enabled but don't correctly validate management frames from all contexts. These are implementation bugs, not design flaws in 802.11w itself.

This is why testing matters: "PMF enabled" in an AP configuration UI doesn't guarantee all clients on the network are actually protected. The real test is sending deauth frames and observing whether associated clients disconnect.

PMF Deployment in the Real World

Despite 802.11w being published in 2009 and incorporated into the main 802.11 standard in 2012, PMF deployment remained slow for years. Several factors contributed:

Legacy clients: Many enterprise environments have devices (printers, IoT sensors, old laptops) that don't support PMF. Setting MFPR breaks those devices.

Interoperability bugs: Some older AP and client combinations had bugs in their PMF implementations that caused connectivity problems. This made admins reluctant to enable it.

Lack of awareness: Many network administrators didn't know deauth attacks were a practical concern. The motivation to enable PMF wasn't there.

WPA3's mandatory PMF requirement is forcing the issue. As devices upgrade to WPA3, PMF comes with them. But transition mode (supporting both WPA2 and WPA3 clients simultaneously) requires PMF to remain optional for WPA2 clients, which means the mixed environments that make up most production networks are partially exposed for as long as they run WPA2 clients.

Checking PMF Status on Your Network

To verify PMF is actually working on your network:

1. Check your AP configuration. Look for "Protected Management Frames," "802.11w," or "PMF" settings. Confirm whether it's disabled, optional, or required.

2. Check the beacon frames. Use a WiFi analyzer app or Wireshark to look at the RSN IE in your network's beacons. The MFPC and MFPR bits tell you what the AP is advertising.

3. Check client behavior. After connecting a device to a PMF-required network, attempt to send a spoofed deauth frame. If the client stays connected, PMF is working. If it disconnects, either PMF isn't actually required, or the client isn't respecting it.

The BLEShark Nano can be used for step 3 in an authorized test environment. This is one of the most common uses of its deauth feature in a professional context: not to disrupt the network, but to verify that PMF is actually providing the protection the configuration claims it should.

Note: Deauth transmission is disabled in EU firmware builds of the BLEShark Nano to comply with RED (Radio Equipment Directive) regulations. EU users can still verify PMF status by checking beacon frame RSN IE data via passive scan.

PMF in the BLEShark Security Testing Workflow

For wireless security audits, PMF testing is a standard checklist item:

• Scan and identify whether each AP has PMF optional or required
• Test deauth against a client on each network to verify whether PMF is actually enforced
• Note which clients are connecting in WPA2 mode vs WPA3 mode on transition-mode networks
• Document any clients that disconnect despite PMF being enabled (potential implementation bugs)

The BLEShark's WiFi scan gives you the AP-level PMF configuration. The deauth test (in authorized environments) gives you the empirical answer to whether it's working as configured. Together, they give you the information you need to write a meaningful finding in a wireless security audit report.

For networks where PMF is not yet required, the audit finding and recommendation is straightforward: enable MFPR where the client device inventory supports it, and create a migration plan for legacy devices that block full PMF deployment.

Get BLEShark Nano - $36.99+

Always test deauth and PMF only on networks you own or have written authorization to test. Unauthorized interference with wireless networks is illegal in most jurisdictions.