Which security did this client actually negotiate? Read the AKM, not the SSID

Someone hands you a capture and asks: is this client on WPA2 or WPA3? Most people look in the wrong place. The SSID is a string the admin typed. It is a label, not a protocol fact. The dashboard says "WPA2/WPA3 Mixed Mode" and stops there, which is true and useless. Mixed mode means the AP offers both. It says nothing about which one this client ended up on. · ​

The answer is not in any single field. It is written across five frames, in order, and each one carries a different, bounded piece of the story.

Capability → Selection → Acceptance → Establishment → Operation.

One note before the frames, because almost every write-up gets it loose: 802.11 security is not negotiated the way TLS is. There is no round of haggling. The AP offers a set, the client picks from it, the AP says yes or no. It is offer-and-select, not negotiate-and-agree. "Negotiated" is the word everyone uses, headline included, but what you are reading in the frames is a selection from a menu. Each stage below proves exactly one thing, and part of reading captures well is not claiming a later stage from an earlier frame.

1. OFFER — the beacon

The beacon is where the AP advertises the security it is willing to run on this BSS. Pull the RSN IE:

Two AKM types: 2 and 8. AKM 2 is PSK (WPA2-Personal). AKM 8 is SAE (WPA3-Personal). Pairwise cipher 4 is CCMP-128, same for both. So the AP is advertising WPA2 or WPA3, same cipher either way. That is transition mode in one line.

And that is the limit of what a beacon proves: capability, not client selection. It is the menu. It does not tell you what anyone ordered.

2. SELECTION — the Association Request

Now the client's request. Same filter, different subtype:

One AKM. Not 2,8. Just 8. In this transition-mode association, the AssocReq identifies SAE as the AKM selected by the STA from the AP's advertised choices. This is the frame everyone should read first and almost nobody does. If the beacon offered 2,8 and the AssocReq shows only 8, this client requested WPA3.

Read it for exactly what it is: the STA's selected association parameters. Not proof that WPA3 fully established, not proof the session came up. A request. The AP still has to accept it, and the keys still have to establish. This is your fast field read for "WPA2 or WPA3," and it is usually right, but it is not the finish line.

3. ACCEPT / REJECT — the Association Response

Status 0x0000 is success: the AP accepted the association carrying those selected parameters. A non-zero status indicates rejection; interpret the specific status code in its 802.11 context. What this proves is bounded too: the AP accepted the association request. That is association acceptance, not key establishment. The two are separate stages, and plenty of associations accept and then fail to key. Do not read 0x0000 as "WPA3 established." Read it as "the AP said yes to the request."

4. ESTABLISHMENT — SAE / the 4-Way Handshake

This is where the selected method actually runs its authentication and key exchange. WPA2-Personal uses the four-way EAPOL handshake. WPA3-Personal runs SAE (the Commit/Confirm authentication exchange) and then the four-way handshake to install keys.

For SAE you will see the Authentication frames with algorithm 3 (Commit, then Confirm), followed by the four logical EAPOL-Key messages (M1–M4). Note that retransmissions can leave more than four EAPOL frames in the capture; what you are confirming is the four logical messages, not a raw frame count. A completed exchange here is what actually establishes the security context. The AssocReq said the client wanted SAE; a completed SAE plus four-way handshake is what says SAE ran.

A note on the RSN IE inside EAPOL Message 2. It is there, and it is useful as a consistency check against the association context. But do not teach it as an independent second negotiation that "re-proves" the AKM. If the RSN information in the handshake looks inconsistent with what the association carried, that is an anomaly to flag and investigate, not automatically a driver bug and not proof the client "keyed under a different AKM." Note the inconsistency, then find out why. The establishment evidence is that the required exchange completed, not that any single field re-declared the AKM.

5. OPERATIONAL — protected data

Protected data frames flowing after a completed establishment support one conclusion: the resulting session became operational and carried traffic. The boundaries, stated plainly:

The Protected bit tells you frame-body protection is applied. By itself it does not identify the cipher. The cipher comes from the preceding RSN exchange, not from this bit.

Protected does not mean readable. Protected traffic is not automatically decryptable from a passive capture. Decryption requires the necessary key material and sufficient captured handshake/security context. The capture proves the session is protected and live. It does not prove what the traffic contained.

That is a limit of the sniffer's vantage, not a gap in your analysis. State it in the report and you look more rigorous, not less.

Reading the AKM in Wireshark

Same field, in the GUI, at any stage that carries an RSN IE. Select a beacon, AssocReq, or EAPOL M2, expand IEEE 802.11 → Tagged parameters → RSN Information (for M2, inside the Key Data). The Auth Key Management (AKM) Suite List is the field. The number after 00-0F-AC: is the AKM type:

A word on AKM 24 / 25, because they are easy to state wrong. 00-0F-AC:24 is SAE-EXT-KEY, introduced in 802.11be for Wi-Fi 7; 25 is the same with Fast Transition. They use a group-dependent hash (the hash length follows the SAE Diffie-Hellman group rather than being fixed at SHA-256), and Hash-to-Element is enforced with them. Note the distinction: H2E is a property enforced with AKM 24, not the identity of AKM 24. The identity is SAE-EXT-KEY. For standards-compliant Wi-Fi 7 WPA3-Personal operation, SAE-EXT-KEY or FT-SAE-EXT-KEY is the relevant AKM, with the applicable cipher requirements determined by the Wi-Fi 7 / WPA3 certification profile. Real-world implementations can differ, so report what the capture actually advertises and selects rather than inferring the security context from the PHY generation alone.

Watch the OUI. That 00-0F-AC prefix is IEEE. If you see 00-50-F2 instead, that is a WPA1 vendor element, not RSN. Older, different, separate problem.

Where the lifecycle breaks — the 6 GHz trap

Run the five stages on a 6 GHz capture and stage 1 is where it can fall apart. Transition mode is a 2.4/5 GHz thing. A 6 GHz WPA3-Personal BSS must not rely on legacy PSK — SAE-based security applies, with the exact AKM and cipher requirements depending on the Wi-Fi generation and feature set (base SAE for Wi-Fi 6E, SAE-EXT-KEY with GCMP-256 for Wi-Fi 7). A correct AP enforces that on its 6 GHz radio. Some do not: transition mode is set globally, the firmware does not apply the 6 GHz rule, and the 6 GHz beacon (stage 1, the OFFER) goes out still carrying AKM 2 next to AKM 8. That advertisement is incompatible with the band.

Here is how to reason about what you then see, without overclaiming. Say the capture shows this:

What the capture does prove: an AP-side advertisement that is incompatible with 6 GHz requirements, visible in the beacon. That alone is worth a finding — one filter, wlan.rsn.akms.type on the 6 GHz beacon reading 2 where the band forbids it, points straight at the AP configuration.

What the capture does not prove, and what you should not write in the report: that it is definitely a firmware bug versus a config choice, or that the client "fell from Wi-Fi 7 to Wi-Fi 6," unless the capture actually shows that transition. State the observed behavior and the correlation. Leave the client's internal reason as not proven. That is the honest finding, and it is stronger than a guessed root cause.

If you ever see an AP advertising WPA2 AKMs in the base RSN IE but additional SAE AKMs carried in a separate override element, that is RSN Overriding. WPA3 v3.4 defines RSN Overriding for WPA3-Personal Compatibility Mode: the base RSNE can remain interpretable by legacy STAs, while RSNE/RSNXE Override elements advertise additional security parameters to STAs that support RSN Overriding. Worth its own writeup.

The minute version

The beacon tells you what was possible. The AssocReq tells you what the client requested. The AssocResp tells you whether the AP accepted. The security exchange tells you whether keying completed. Protected data tells you whether the session came up. Read each frame for what it proves and nothing more, and "WPA2 or WPA3" stops being a guess. On 6 GHz, stage 1 is where the AP-side bugs show, and the capture points at them even when it cannot tell you why the client walked away.