Some devices work, some do not: WPA3 and frame protection

Likely causes

• Management frame protection set to required on a mixed SSID

  30%

  Modern phones and laptops are fine; older handhelds, printers, scanners and IoT gear cannot associate at all. The split follows device age, not location or signal. Controller logs show association rejected rather than an authentication failure.

• WPA3-Personal transition mode not handled by older clients

  25%

  Transition mode advertises both the new key exchange and legacy PSK. Some older supplicants parse the mixed advertisement badly and refuse or loop; others join once and then fail after a roam or a reboot because the saved profile no longer matches what is offered.

• 6 GHz mandates the newer security, so non-capable clients never see the band

  20%

  Device works on 2.4 and 5 GHz and never appears on 6 GHz anywhere in the building. Not a coverage fault: a client that cannot meet the security required on that band has no way onto it. Also confirm the SSID is on a preferred scanning channel so clients that only scan those can find it.

• Driver or supplicant bugs, and stale saved profiles

  15%

  One make and model fails while equally old devices succeed. Forgetting the network and rejoining fixes it, or a driver/firmware update does. A capture shows the new key exchange starting and never completing.

• Configuration inconsistent across AP groups, controllers or sites

  10%

  Works on one floor and not the next. Same SSID name, different security profile: a roam across the boundary drops the session because the key type the client established is not offered on the other side.

What to bring

• Controller SSID security profile view, per AP group
• controller association and client event logs
• laptop with a monitor-mode capture adapter
• a known-good modern client and one of the failing devices
• device datasheets for the failing gear

Steps

1. 1

   Step 1: Get the split straight before changing anything

   List which devices work and which do not, with make, model and OS version. If the boundary follows device age rather than location, this is a security-negotiation fault and no amount of RF work touches it.

   If that doesn’t do it

   Failures follow location rather than device type: go to Heat map was green, the room is dead or APs fighting each other for airtime.

2. 2

   Step 2: Read the SSID's actual security profile on every AP group in the path

   Which key management is offered (legacy PSK, the new exchange, transition mode), what frame protection is set to (disabled, capable, required), and on which bands. Then write down what the failing device supports. Those two lists side by side are the whole diagnosis.

   If that doesn’t do it

   Profile is consistent and the device claims support: capture the association, step 4.

3. 3

   Step 3: Give the legacy estate its own SSID rather than weakening the new one

   The clean fix is separation: one SSID with current security and frame protection required for capable clients, and a separate, tightly scoped legacy SSID on 2.4/5 GHz only for the gear that cannot do it, with its own VLAN and ACLs. Dropping frame protection back to optional on the main SSID fixes today's ticket and reopens the exposure that made someone turn it on.

   If that doesn’t do it

   Cannot add an SSID (airtime overhead or a platform limit): set the main SSID to transition mode with frame protection capable rather than required, record it on the ticket as an exception and put a date on revisiting it.

4. 4

   Step 4: Capture the failure instead of guessing at it

   Monitor-mode capture on the AP's channel while the device tries to join. An association rejected on a frame-protection status code points at the SSID setting; a key exchange that starts and stops points at the supplicant. Those need different fixes and look identical from the user's side.

   If that doesn’t do it

   Capture shows association completing and the failure comes later: that is authentication or addressing, go to Cannot connect: 802.1X, RADIUS, certificates.

5. 5

   Step 5: Clear the client side properly

   Forget the network on the device, update driver or firmware, then rejoin. Saved profiles hold the old key type and are a common reason a corrected SSID still fails on one device.

   If that doesn’t do it

   Fresh profile on current firmware still fails against an SSID other devices join: the device cannot do what this SSID requires. Put it on the legacy SSID and record it.

6. 6

   Step 6: Hand back a list, not a verdict

   Document every device that cannot meet the current security policy. That list is a procurement and replacement decision, not a Wi-Fi fault, and it is the only thing that stops this ticket returning every quarter.

   If that doesn’t do it

   Customer will not replace or segment the legacy gear: get the accepted exception in writing, with who accepted it and when.

More Wireless & DAS guides

• Full signal, no usable throughput
• Clients hang onto the far AP
• APs fighting each other for airtime
• Heat map was green, the room is dead
• Cannot connect: 802.1X, RADIUS, certificates
• AP will not join, or joins in the wrong country

All 54 guides