WPA3 vs WPA2: What Changed?
WPA3 was certified by the Wi-Fi Alliance in 2018. As of 2024, it's required for Wi-Fi CERTIFIED devices, and most new routers and client devices support it. The question that comes up constantly in security testing contexts: does WPA3 actually fix the deauth attack problem?
The short answer is: WPA3 makes deauth attacks harder and reduces their impact, but it doesn't eliminate them. Understanding why requires looking at exactly what WPA3 changed - and what it intentionally left alone.
What WPA2 Got Wrong
WPA2's core vulnerability in the personal (PSK) context is that all devices on the network share the same pre-shared key. From that single key, the session key (PTK) for each connection is derived. A passive observer who captures the 4-way handshake and knows the PSK can decrypt all traffic for that session, including traffic captured before they had the PSK.
This is the absence of forward secrecy. If you capture encrypted WPA2 traffic today and crack the password six months later, you can decrypt the historic capture retroactively.
The deauth vulnerability is a separate issue. WPA2 management frames - including deauthentication frames - are not authenticated. Any device can spoof a deauth frame with the source address of any AP, and clients that receive it will disconnect. There's no way for the client to verify that the deauth frame actually came from its AP.
Protected Management Frames (802.11w) was developed as a fix for this and was made optional in WPA2. Optional means many deployments didn't use it.
WPA3's Key Change: SAE Instead of PSK
WPA3-Personal replaces the Pre-Shared Key (PSK) authentication exchange with Simultaneous Authentication of Equals (SAE). SAE is based on the Dragonfly key exchange, which is a balanced password-authenticated key exchange (PAKE) protocol.
The critical difference from a security standpoint:
With WPA2-PSK, the 4-way handshake involves the client and AP proving they both know the password by deriving matching keys. But the derivation is done in a way that lets an offline attacker take a handshake capture and try passwords against it at billions of attempts per second with hashcat or similar tools.
With SAE, the key exchange is designed so that offline dictionary attacks against the handshake aren't feasible. The protocol requires an actual interactive exchange between client and AP - a passive capture of the SAE exchange doesn't give an attacker something they can crack offline. Each authentication attempt requires a real interaction with the AP, which rate-limits brute force.
SAE also provides forward secrecy. Each session derives a unique PMK (Pairwise Master Key) independent of the password. Cracking the password later doesn't decrypt previously captured sessions. This is the same principle that HTTPS's TLS 1.3 uses with ephemeral Diffie-Hellman key exchange.
sequenceDiagram
participant C as Client
participant AP as Access Point
Note over C,AP: WPA2-PSK: 4-Way Handshake
C->>AP: Association Request
AP->>C: ANonce (random)
Note over C: Derives PTK from:
PSK + ANonce + SNonce + MACs
C->>AP: SNonce + MIC
Note over AP: Derives same PTK
AP->>C: GTK + MIC (encrypted)
C->>AP: ACK
Note over C,AP: Vulnerability: PMK derived from
PSK + SSID (offline dictionary attack)
Note over C,AP: WPA3-SAE: Dragonfly Handshake
C->>AP: SAE Commit (EC point + scalar)
AP->>C: SAE Commit (EC point + scalar)
Note over C,AP: Both derive PMK via
elliptic curve math
(zero-knowledge proof)
C->>AP: SAE Confirm (hash proof)
AP->>C: SAE Confirm (hash proof)
Note over C,AP: PMK is session-unique
Offline attack impossible
Forward secrecy achieved
C->>AP: 4-Way Handshake (same as WPA2)
AP->>C: Session keys installed
WPA2 vs WPA3 handshake comparison - WPA2 derives the PMK directly from the password (enabling offline attacks), while WPA3-SAE uses Dragonfly key exchange for a unique session key that cannot be brute-forced offline.
WPA3 Makes PMF Mandatory
WPA2 made Protected Management Frames (802.11w) optional. WPA3 makes them mandatory.
This is the most direct answer to the deauth attack question. PMF works by cryptographically authenticating management frames - including deauthentication and disassociation frames - between an AP and an already-associated client. Fake deauth frames from an attacker don't have the correct MIC (Message Integrity Code) and get rejected.
But PMF has a specific scope: it protects the management frame exchange after a client has already associated with an AP. It uses the security context established during the 4-way handshake to sign subsequent management frames.
Before association, PMF doesn't apply. An attacker can still broadcast deauth frames targeting unassociated clients or targeting the pre-association phase. The client can be prevented from completing an association by sending deauth frames during the authentication/association process itself, before PMF protection kicks in.
And here's the persistent limitation: even with PMF enabled on both the AP and the client, a deauthentication frame sent to a client that hasn't yet associated gets through. The protection is session-based, not pre-association.
Does Deauth Still Work on WPA3?
Yes, with caveats.
On a WPA3-only network with PMF required (not just enabled): deauth frames targeting already-associated clients are rejected because they fail the MIC check. A client that receives a spoofed deauth frame from an attacker will detect that the frame is not properly authenticated and ignore it (or log it as a potential attack).
However:
- Clients reconnect faster. WPA3 with SAE doesn't help if the client is briefly disconnected and immediately reconnects. The deauth disassociates the client momentarily, but SAE's reconnection is fast. The disruption may be brief.
- Pre-association deauth still works. During the authentication frame exchange (before full association), PMF isn't active. An attacker sending deauth frames during this window can prevent a client from completing connection.
- Mixed WPA2/WPA3 networks. Many networks run in "Transition Mode" - supporting both WPA2 and WPA3 clients simultaneously. In transition mode, the network can't require PMF for all clients (WPA2-only devices don't support it). WPA2 clients on a transition mode network remain vulnerable to deauth. An attacker just needs to target the WPA2 clients.
- Beacon flooding. Flooding beacon frames isn't stopped by PMF at all - beacon frames in the noise don't require authentication, and flooding can cause UI confusion regardless of WPA3 adoption.
The Transition Mode Problem
WPA3 Transition Mode is the practical reality for most enterprise and home networks upgrading from WPA2. The AP broadcasts two network modes simultaneously (sometimes as separate SSIDs, sometimes as a single SSID with multi-mode association).
graph TD
subgraph "WPA3 Transition Mode Vulnerability"
AP_TRANS["AP in Transition Mode
Accepts WPA2 + WPA3"]
subgraph "Normal Client Behavior"
C_WPA3["WPA3 client
connects via SAE"]
C_WPA2["Legacy client
connects via PSK"]
end
subgraph "Downgrade Attack"
ATK["Attacker"]
CLONE["Clone AP with
WPA2-only"]
DEAUTH["Deauth client
from real AP"]
RECONNECT["Client falls back
to WPA2 on clone"]
CAPTURE["Capture WPA2
handshake"]
CRACK["Offline dictionary
attack succeeds"]
end
end
AP_TRANS --> C_WPA3
AP_TRANS --> C_WPA2
ATK --> CLONE
ATK --> DEAUTH
DEAUTH --> RECONNECT
RECONNECT --> CAPTURE
CAPTURE --> CRACK
subgraph "Mitigation"
MIT1["WPA3-only mode
(no transition)"]
MIT2["802.11w PMF required
(blocks deauth)"]
MIT3["Client pinning
(refuse downgrade)"]
end
CRACK -.->|"Prevented by"| MIT1
DEAUTH -.->|"Prevented by"| MIT2
RECONNECT -.->|"Prevented by"| MIT3
WPA3 transition mode weakness - networks supporting both WPA2 and WPA3 are vulnerable to downgrade attacks where an attacker forces clients to use the weaker WPA2 handshake.
PMF in transition mode is configured as "optional" rather than "required." This is necessary to support legacy WPA2 clients that don't support PMF at all. But optional means a WPA2 client without PMF support can connect, and deauth attacks against those clients work exactly as they did before WPA3 existed.
A WPA3-capable client connecting to the same network in WPA3 mode with PMF required is protected. But if you have a mix of devices, your network is only as protected as its least-capable client.
The security testing implication: when assessing a network for deauth vulnerability, check whether PMF is required or optional, and whether WPA2 clients exist on the network. A network with "WPA3 enabled" may still have significant deauth exposure if it's running transition mode with WPA2 clients.
Forward Secrecy in Practice
The forward secrecy improvement in WPA3 is significant for encrypted traffic capture scenarios. With WPA2, capturing traffic today and cracking the password later gives you all of it. With WPA3, cracking the password doesn't help with past captures because each session's PMK is derived from the SAE exchange, not directly from the password.
graph TD
subgraph "WPA2: No Forward Secrecy"
W2_CAP["Attacker captures
handshake + traffic"]
W2_CRACK["Cracks PSK later
(offline dictionary)"]
W2_PMK["Derives PMK
(same for all sessions)"]
W2_PTK["Derives all PTKs
(from captured nonces)"]
W2_DECRYPT["Decrypts ALL past
and future traffic"]
end
subgraph "WPA3: Forward Secrecy"
W3_CAP["Attacker captures
SAE exchange + traffic"]
W3_CRACK["Even if password
is compromised later"]
W3_PMK["Each session PMK
is unique (EC-derived)"]
W3_NO["Cannot derive past
session keys"]
W3_SAFE["Past traffic remains
encrypted and safe"]
end
W2_CAP --> W2_CRACK --> W2_PMK --> W2_PTK --> W2_DECRYPT
W3_CAP --> W3_CRACK --> W3_PMK --> W3_NO --> W3_SAFE
subgraph "Key Differences"
DIFF1["WPA2 PMK = PBKDF2(password, SSID)
Static - same every session"]
DIFF2["WPA3 PMK = SAE(password, random EC)
Dynamic - unique every session"]
DIFF3["WPA2: crack once, decrypt everything"]
DIFF4["WPA3: compromise password,
past sessions still protected"]
end
Forward secrecy comparison - WPA2 uses a static PMK derived from the password, so cracking it unlocks all traffic. WPA3 generates unique session keys, protecting past communications even if the password leaks.
For security researchers doing authorized penetration tests: WPA3 networks don't yield a crackable handshake capture in the same way WPA2 networks do. The PMKID attack (extracting the PMKID from an authentication frame and cracking it offline) also doesn't apply to WPA3's SAE exchange in the same way.
For attackers doing passive traffic interception: WPA3 significantly raises the bar. A passive capture of a WPA3 session isn't retroactively useful the way a WPA2 capture is.
WPA3-Enterprise
WPA3-Enterprise (used with RADIUS authentication rather than a shared password) adds 192-bit security mode - requiring 256-bit AES-GCMP encryption and ECDHE/ECDSA or RSA with 3072-bit keys. This is primarily relevant for government and high-security enterprise environments.
For most enterprise environments, the practical difference between WPA2-Enterprise and WPA3-Enterprise is smaller than the WPA2-Personal vs WPA3-Personal gap. WPA2-Enterprise with 802.1X was already substantially more secure than WPA2-Personal because there's no single shared password to crack.
Testing WPA3 Networks With the BLEShark Nano
The BLEShark Nano is a 2.4GHz device. WPA3 networks on 2.4GHz are visible and scannable. The deauth feature, where supported (disabled in EU firmware per RED regulations), behaves differently on WPA3-PMF networks:
If the target network has PMF required and the client is properly associated in WPA3 mode, deauth frames sent by the BLEShark won't disconnect the client - the client's WPA3 stack will verify the MIC, find it doesn't match, and discard the frame.
If the target network is in WPA3 Transition Mode with WPA2 clients, deauth against those WPA2 clients works normally.
This is actually useful information for a wireless security audit: if your deauth test succeeds against clients on a network you've advertised as WPA3, it reveals either that PMF isn't actually required, or that clients are connecting in WPA2 compatibility mode rather than WPA3 mode. Both findings are useful for a security report.
The BLEShark Nano's WiFi scan will show the security capabilities of APs it finds - WPA2, WPA3, PMF optional, PMF required - giving you the baseline information before any active testing.
What WPA3 Actually Improved
To summarize what changed and what didn't:
What WPA3 fixed:
- Offline dictionary attacks against handshake captures (SAE makes these infeasible)
- Lack of forward secrecy (each WPA3-SAE session has an independent PMK)
- PMF being optional (WPA3 requires it, eliminating the largest deployment gap)
- Weak password exposure from passive capture (capturing a WPA3 exchange doesn't give you something crackable)
What WPA3 didn't fully fix:
- Pre-association deauth - still possible before PMF context is established
- Transition mode exposure - WPA2 clients on mixed networks remain vulnerable
- Beacon flooding and AP Spam - unrelated to authentication, still works
- Physical-layer attacks - jamming doesn't care about authentication protocols
- Dragonblood vulnerabilities - SAE had implementation-level side-channel attacks disclosed in 2019 (since patched in most implementations, but a reminder that "new protocol" doesn't mean "no vulnerabilities")
WPA3 is a genuine improvement. It's worth enabling wherever your device ecosystem supports it. But running WPA3 doesn't mean your wireless network is immune to the categories of attack that security testers use. PMF required + WPA3-only (no transition mode) is the strongest configuration. Most real deployments won't be in that state for years due to legacy device support requirements.
Deauth testing features on the BLEShark Nano are disabled in EU firmware to comply with RED regulations. In all regions, use deauth testing only on networks you own or have explicit written permission to test.