PMKSA Caching After Network Policy Changes: Avoid Misreading a Cached Authentication

A reconnect that succeeds after an authentication-policy change does not prove that the new policy was evaluated. The client and network may reuse a cached pairwise master-key security association, or run an EAP exchange that resumes earlier method state. Establish which path occurred before concluding that a changed credential, trust rule or authorization policy works.

This guide uses wpa_supplicant 2.11 and hostapd 2.11 implementation behavior, with RFC 5247’s EAP key-management framework. It targets an authorized Enterprise Wi-Fi test environment with access to client, AP/controller and authentication-server evidence. FT key delivery, certificate-renewal deployment and generic reconnect timing are outside scope. Vendor firmware can own additional cache state; record that ownership rather than assuming userspace controls everything.

Separate three kinds of reuse

PMKSA reuse can allow secure association without a fresh EAP authentication. EAP method resumption is a different optimization: an EAP exchange may occur while reusing previously established method state. Neither should be inferred solely from how quickly the connection finishes. RFC 5247 also distinguishes freshness of derived traffic keys from freshness of the parent keying material. A new four-way handshake does not by itself establish that the authentication server rechecked the changed policy. RFC 5247, sections 4.3 and 5.7

State owner	Question to answer	Evidence to preserve
Client PMKSA and driver cache	Was an existing association selected?	Cache selection/removal events and matching association attempt
AP/controller key cache	Was the offered association accepted from retained state?	AP decision, scope and lifetime of the retained entry
EAP method and server	Was this full authentication or resumption?	Method-specific server trace and policy evaluation record
Authorization enforcement	What access was actually granted?	Applied role or policy plus permitted and denied operations

The last row matters even when authentication is fresh. The experiment should establish the effective authorization decision, not merely an EAP success message. RFC 5247 discusses maintaining correct authorization when AAA is bypassed; caching is not permission to ignore changes indefinitely. The required update mechanism and timing must come from the deployed network’s policy contract. RFC 5247, sections 4.3.2–4.3.3

Know what the reference controls actually change

In wpa_supplicant 2.11, the PMKSA_FLUSH control handler flushes its PTKSA cache and calls the PMKSA flush path for all network contexts. Removing the currently selected PMKSA entry, rather than replacing it, can clear the active PMK and request deauthentication. This is a disruptive control operation, not a read-only diagnostic. Schedule it only within an approved test window with a recovery path. wpa_supplicant 2.11, ctrl_iface.c, pmksa_cache.c and wpa.c

That operation is not proof that the AP, controller, firmware and authentication server have all discarded their relevant state. Likewise, setting proactive_key_caching=0 disables opportunistic caching for that profile; it is not a universal switch disabling ordinary PMKSA reuse. The global fast_reauth option addresses EAP method fast reauthentication, another distinct layer. Preserve the actual method-specific resumption evidence instead of treating a setting name as a complete test result.

On hostapd 2.11, disable_pmksa_caching=1 disables caching of associations created through EAP authentication. Its configuration documentation explicitly warns that enabled RSN preauthentication can still create cached associations. A test plan that changes only this switch can therefore retain an unintended alternate path. hostapd 2.11, hostapd.conf PMKSA caching section

Run a paired policy experiment

1. Define a reversible test change. Use a dedicated test identity and an isolated access rule, such as removing permission to reach a test endpoint. Record the policy revision and expected denial. Do not invalidate production credentials to create a convenient failure.
2. Establish the original full-authentication baseline. Correlate the client attempt with AP and server records. Verify the original allowed operation and a separate forbidden operation. Save sanitized event identifiers, not passwords, PMKs or exported TLS secrets.
3. Change policy and preserve warm state. Reconnect without deliberate invalidation. Classify the observed path. If it is a cache hit, record that as the warm-policy outcome rather than claiming a fresh authentication test.
4. Create a controlled fresh-state case. Coordinate supported client, driver, AP/controller and method/server invalidation or resumption controls. Identify which changes interrupt service. Do not assume a process restart clears persistent or remote caches.
5. Prove full authentication occurred. Require the relevant server-side credential and policy evaluation evidence. An EAP exchange without this distinction can still be a resumed exchange. If the stack cannot expose the distinction, mark the result inconclusive.
6. Compare authorization, then restore policy. Verify the changed denial and unaffected allowed behavior. Restore the original test policy and repeat the positive case so a broken test endpoint cannot masquerade as successful enforcement.

Use one connection-attempt identifier across the evidence bundle, or correlate timestamps with documented clock uncertainty. A nearby server log from another reconnect is not enough. For caches whose lifetime or scope cannot be observed, record that uncertainty explicitly and avoid making a global claim about policy propagation.

Interpret a disagreement without guessing

Suppose a hypothetical maintenance gateway remains able to reach a restricted test service after a policy revision. Its warm reconnect shows PMKSA reuse, while the coordinated full-authentication case applies the new denial. That comparison points toward the network’s cached-authorization update contract. It does not demonstrate defective cryptography or prove that disabling all caching is the right production solution.

If both paths still grant access, investigate whether the intended policy revision reached the relevant server and enforcement point. If authentication is denied but application traffic still passes, examine existing sessions and enforcement state separately. If both paths deny everything, restore the baseline before attributing the result to the changed rule.

Release evidence and test limits

The source paths and configuration boundaries above were inspected in the official 2.11 releases. No cache-flush command, authentication-server policy change or RF experiment was executed for this article. The procedure is a proposed target qualification campaign, not measured product behavior.

Close the investigation with a cache-ownership ledger, classified warm and full-authentication traces, effective access results, and the approved maximum policy-update delay. Keep routine caching when it satisfies that contract. Escalate an unobservable or excessive delay as a policy-enforcement limitation rather than labeling every successful reconnect “freshly authenticated.”