OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Key rotation and reauthentication timers

Group key rotation, session timeouts, and 802.1X reauthentication run on timers, and a client that handles them badly drops on a schedule even when it never moves.

Ben RutterIndustrial network engineer
  • Updated
  • Reviewed
  • 2 min read
  • 4 sources
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Drops recur at a steady interval measured from when the device connected, whether it moves or not.
  • Stationary devices drop as well as mobile ones.
  • The access point logs a deauthentication with a reason such as previous authentication no longer valid, or a failed group key handshake.
  • Right after a group key update, some models lose broadcast and multicast traffic or disconnect while others carry on.
  • The interval between drops matches a configured timer.
Bands
2.4 GHz5 GHz5 GHz DFS6 GHz
Not sure?
Rank the likely causes from your symptoms

Why it happens

Every secure association carries clocks. In hostapd’s reference configuration the group key rotates once a day with CCMP by default, and 802.1X reauthentication defaults to 3600 seconds1, with a warning that reauthentications may enforce a disconnection. The authentication server can add its own clock. With Termination-Action set to RADIUS-Request, Session-Timeout means reauthentication. With Default, it means the session should terminate.

The handshakes fail on real clients. hostapd tells you to raise group key retries when stations are constantly deauthenticated during GTK rekeying, and warns that pairwise rekeying is buggy with many drivers/devices.

The AGV study saw the vehicle side of this. 4.21%2 of the disconnections began with the access point deauthenticating the vehicle with reason PREV_AUTH_NOT_VALID, which the authors read as authentication had expired. Those recovered quickly, typically within 5 seconds. On a short application timeout, quickly is still too long.

A repeating interval is the signature to look for. One AMR maker’s wireless guide lists it in its troubleshooting table: the robot loses its fleet manager on a schedule while still reporting itself connected, regains it after a set duration, 180 minutes in its example, and repeats at the same frequency3. The guide points to the access point’s security policy, or to interoperability between robot and infrastructure. It names no timer, so measure the interval and match it against every clock above.

Rekeying is a security control, and you should not switch it off to make a symptom go away. Keep the timers, know when each one fires, and prove every client model survives it.

How to confirm it

  1. List every timer on the SSID and the authentication server. Include the group key rekey interval, pairwise rekey, 802.1X reauthentication period, RADIUS Session-Timeout and Termination-Action, and idle timeout.
  2. Measure the interval between one device's drops and compare it with each timer.
  3. Pull the access point log for the deauthentication reason code at each drop.
  4. Capture a group key handshake and check whether every client answers it.
  5. Check whether the authentication server sends Session-Timeout, and with which Termination-Action.

The fix

  • Set Termination-Action so a session timeout triggers reauthentication instead of ending the session.
  • Lengthen timers that are shorter than your security policy requires, with your security team's agreement.
  • Increase group key handshake retries if clients are being deauthenticated during group rekeys.
  • Update or replace clients that fail group key or pairwise rekeys.

Prevent it at design time

  • Record every rekey and session timer in the timing budget and in change control.
  • Test each client model through several rekey and reauthentication cycles before rollout.
  • Agree timer values with the security team at design time, so nobody changes them later without testing.

Related causes

Terms on this page

About this page

Built from 4 sources: 1 standards body or lab, 1 research paper or thesis and 2 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Key rotation and reauthentication timers." OT Wireless, published October 5, 2026. https://otwireless.com/causes/key-rotation-and-reauthentication-timers/

APA 7

Rutter, B. (2026, October 5). Key rotation and reauthentication timers. OT Wireless. https://otwireless.com/causes/key-rotation-and-reauthentication-timers/

BibTeX

@misc{rutter2026keyrotationandreauthenticationtimers,
  author = {Rutter, Ben},
  title = {{Key rotation and reauthentication timers}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/key-rotation-and-reauthentication-timers/}},
  organization = {OT Wireless},
}