Fast Roaming Compared: 802.1X, PMKSA, OKC and FT

The same roam done four ways. See what each method skips, how long the client is cut off, and which one a client actually uses on your network.

Why roaming can be slow

When a client moves to another AP, it has to prove itself again and agree new encryption keys before any data can flow. On an Enterprise network a full 802.1X login goes all the way to the RADIUS server and back several times; on WPA3-Personal a full SAE exchange means heavy elliptic-curve maths on both sides. Voice calls start to break up when the gap passes about 150 ms.

Fast roaming methods avoid repeating that work. PMKSA caching reuses a key from an earlier visit to the same AP, OKC shares one key across a controller's APs, and FT (802.11r) prepares keys for every AP in advance and even skips the 4-way handshake.

1 · Set up the network and the client

Security

The roam

Network (APs and controller)

FT (802.11r) OKC 802.11k neighbour reports

RADIUS round trip, AP to server and back:

Client

The client supports

FT OKC PMKSA caching

2 · The same roam, four ways

Each lane runs from the client's last frame on the old AP to its first data frame on the new one. Faded lanes show what a method would take but can't be used here, with the reason next to them. The outlined lane is the one this client uses.

3 · Frame by frame: what this client does

FT mode

Who holds PMK-R0 (the R0KH)

How the new AP gets its PMK-R1

Over the DS, the client sends its FT request through the AP it is still connected to. With no controller, the first AP the client joined keeps PMK-R0 and hands out the PMK-R1s.

4 · Who holds which key

Where the keys that make a fast roam possible are kept, just before the roam. A key has to be at the new AP before the client arrives, or the client falls back to a full login.

5 · Side by side

	Full login	PMKSA caching	OKC	FT (802.11r)
Defined by	IEEE 802.11 (802.1X, SAE or PSK)	IEEE 802.11, since 802.11i (2004)	Not in the IEEE standard: a vendor and controller feature	IEEE 802.11r (2008), now clause 13 of 802.11-2024
What it reuses	Nothing	The PMK from an earlier login to the same AP	One PMK, shared by the controller with all its APs	A key hierarchy: PMK-R0 at the key holder, a PMK-R1 made for each AP
Works when roaming to	Any AP	APs the client has used before, while both still have the cached key	Any AP of the same controller or cluster	Any AP in the same mobility domain (MDID)
What it skips	Nothing	The 802.1X login or SAE exchange	The 802.1X login	The login and the 4-way handshake
Frames on the air	SAE: 10 (its 4 frames replace Open System authentication); 802.1X: 8 plus 20 or more for the login	8	8	4
Security types	All	802.1X and SAE (PSK has no login to skip)	802.1X	PSK, SAE and 802.1X, with FT AKMs (3, 4, 9, 13, 25…)
Client support	All	Nearly all	Windows and most Android devices; not Apple devices	Most current phones, tablets and laptops; some older or embedded clients fail to join when FT is advertised
Watch out for	The RADIUS server's distance and load	Short cache lifetimes on the AP or client; AP reboots clear the cache	Only within one controller; not interoperable between vendors	Older clients: use adaptive or mixed FT modes, or a separate SSID

6 · Definitions

PMK and PMKSA ↗: The Pairwise Master Key (PMK) is the key a login (802.1X or SAE) or a passphrase produces. The PMKSA (PMK Security Association) is the PMK plus its details: its name (the PMKID), the AP and client it belongs to, the AKM it was made with, and how long it stays valid.
PMKID ↗: A 128-bit name for a PMK: HMAC(PMK, "PMK Name" ‖ AP MAC ‖ client MAC), cut to 128 bits. The client lists it in its (Re)Association Request to ask for a cached key. Because the AP's MAC address is part of it, each AP has its own PMKID for the same PMK.
PMKSA caching ↗: Keeping a PMKSA after the client leaves, so that when it comes back to the same AP both sides can skip the login and go straight to the 4-way handshake.
Roam back ↗: Not a term in the standard. It usually means returning to an AP used before, which is PMKSA caching at work. Some vendors also use it for keeping the old AP's keys for a short time so a client that bounces straight back reconnects quickly.
OKC (Opportunistic Key Caching) ↗: A controller copies a client's PMK to all its APs. The client works out the PMKID for the new AP itself, using the new AP's MAC address, so any AP of that controller can accept it without a new login.
FT (Fast BSS Transition, 802.11r) ↗: Roaming with keys prepared in advance. The client's first connection to the mobility domain creates a PMK-R0; each AP gets its own PMK-R1. A roam takes an FT authentication exchange and a reassociation: four frames, with no 4-way handshake.
R0KH and R1KH ↗: R0 and R1 key holders. The R0KH (usually the controller, or the first AP) holds the client's PMK-R0 and makes PMK-R1s; each AP is an R1KH for the PMK-R1 made for it.
Mobility domain (MDID) ↗: The group of APs that share FT keys, advertised in the Mobility Domain element. FT only works between APs with the same MDID.
FT over the air and over the DS ↗: Over the air, the client sends its FT request straight to the new AP. Over the DS, it sends it to its current AP, which forwards it to the new one over the wired network.
802.11k and 802.11v ↗: Help the client decide where to roam, without touching keys: 802.11k neighbour reports list nearby APs and channels, and 802.11v BSS Transition Management lets the AP suggest a better AP.
RADIUS round trip ↗: The time for one message from the AP (or controller) to the RADIUS server and its answer back. An 802.1X login needs several; a server at another site or in the cloud makes each one slower.
4-way handshake ↗: Four EAPOL-Key frames in which the client and AP prove they hold the same PMK and make fresh session keys. It runs after every full login, PMKSA or OKC roam, but not after FT.

↗ opens a term's full entry in the Wi-Fi Glossary, which explains over 400 Wi-Fi terms with their IEEE 802.11 references.

Notes

Timings are typical figures, not measurements. Each authentication or reassociation exchange is taken as about 1–3 ms, the 4-way handshake 8 ms, an FT exchange 3 ms each way, SAE about 10 ms of computation per side plus its frames, and each 802.1X step one RADIUS round trip plus 1.5 ms for the air and the processing; PEAP-MSCHAPv2 is taken as 9 round trips and EAP-TLS as 7 (the server's certificate takes several fragments), plus 15 ms of TLS computation. Real values depend on the devices, the load and the RADIUS server. What doesn't change is the order: FT is fastest, then PMKSA caching and OKC, and a full 802.1X login is far slower than all of them.
The gap excludes scanning. Most clients scan for the next AP in the background while still connected, a channel at a time, so scanning costs airtime and battery more than it adds to the gap. A full dual-band scan covers about 38 channels: roughly 20–40 ms on each normal channel (sending a Probe Request and collecting the Probe Responses and Beacons that arrive; less if the channel is empty), but 100 ms or more on DFS channels, where clients listen passively for a beacon, so about 2 seconds in all. 802.11k neighbour reports shrink that to the few channels the neighbours use. The standard leaves the per-channel times to the device (MinChannelTime and MaxChannelTime in MLME-SCAN.request, 6.5.3.2). The order of the channels and how the scan is split up are also up to each device: a full scan is usually a sweep through the driver's channel list, done in short slices with the client returning to its AP between them, and when roaming most clients first scan only the channels from a neighbour report or where they have seen the network before.
Which method a client picks: FT when both the network and the client support it and the new AP is in the same mobility domain; otherwise a cached PMKSA for that AP if there is one (PMKSA caching or OKC); otherwise a full login. A client uses FT only if it connected with an FT AKM in the first place.
PSK: with WPA2-Personal the PMK comes from the passphrase, so every AP already has it and there is no login to skip. PMKSA caching and OKC make no difference; FT-PSK still saves the 4-way handshake.
WPA3-Personal: without FT, every roam to a new AP means a full SAE exchange. PMKSA caching helps only when returning to an AP used before. FT-SAE (AKM 9, or 25 for SAE-EXT-KEY on Wi-Fi 7) avoids it everywhere in the mobility domain.
OKC isn't in the standard. IEEE 802.11 defines PMKSA caching for one AP (4.10.7, 12.6.8.3); sharing the PMK across APs is left to vendors. The standard's own way to cache across APs is FILS, whose APs can advertise a shared cache identifier (802.11ai).
When the cached key is gone: if the new AP doesn't have the PMKSA the client names, IEEE 802.11-2024 (12.6.8.3) says what happens next. For an SAE PMKSA the AP rejects the reassociation with status STATUS_INVALID_PMKID and the client falls back to a full SAE exchange; for an 802.1X PMKSA the AP starts a full 802.1X login after the association. Either way the roam takes as long as a full login, plus the failed attempt.
Cache lifetime: the standard's default PMK lifetime is 43,200 s (12 hours, dot11RSNAConfigPMKLifetime), but APs and clients often keep cached keys for much less, and a reboot clears them.
Where this comes from: IEEE 802.11-2024: PMKSA caching 4.10.7 and 12.6.8.3; PMKID 12.7.1.3; the FT and PMKSA-caching authentication algorithms per AKM, Table 9-190; FT initial mobility domain association 13.4, the FT protocol over the air and over the DS 13.5, the key holders 13.9 and the remote request broker between APs 13.10; Neighbor Report element 9.4.2.35; BSS Transition Management 11.21.7.
This model follows one client and one roam, with FT over the air, no competing traffic and no retries. Wi-Fi 7 multi-link devices move between their own links without any roam; roaming between different MLDs still uses these methods.