Stress-test a session timeout change by proving that each idle and absolute timer can terminate access inside the planned window, survive shared-device use, and avoid trapping operators inside a green policy slide that hides long-lived tokens.
Timeout changes often list a minute count while leaving refresh tokens, remember-me paths, and abort authority implicit. Those edges decide whether a late revoke stops inside the window or leaves a session live under customer load. The exercise should follow actual apps, token stores, and on-call paths rather than a clean policy deck.
Inventory the session path
List every app or token type with its idle timeout, absolute timeout, refresh behavior, owners, and notification channels. Mark sessions that cannot reverse without a central revoke. Attach the last three timeout incidents with raw timelines and any waivers. Include the source of truth for active session counts during the observation window.
Define the phases for schedule, cutover, observe, abort, and communicate. Each phase needs an owner and an exit condition. Write the point after which a stuck session would require a different procedure, then review whether that action is still permitted. Capture maximum acceptable reauthentication friction in measurable units, including which cohorts are excluded from the new timer and why.
Include the calendar of known events for the next two quarters: identity freezes, partner cutovers, and support peaks that shrink the usable change window. A timeout budget that ignores those dates will look calm until the week they land.
Failure drills
- A minority high-privilege app keeps refresh tokens while the aggregate policy dashboard stays green.
- A timeout has already left a shared kiosk session open on a money path.
- The primary session dashboard lags beyond the planned observation window.
- An operator extends idle time because a partner demo is close.
- Mobile and web timers collide under the new absolute window.
- Revoke authority is unclear at 2 a.m. and the page lands on the wrong rotation.
For each drill, identify detection time, customer impact, containment, and the authority to force logout. Require commands and dashboard links in the runbook. A statement that monitoring will catch it does not establish which alert fires or who receives it.
Prove timeouts are timed and owned
Run the package in Pingpong with identity ops, security, support, and product seats. Ask product which user decision becomes unsafe first if sessions remain after the claimed idle window. Ask security whether revoke can absorb a forced extension. Ask identity ops to show the exact logout or token-kill path used as the exit condition.
Related reviews include the identity ops lead seat, a SCIM provisioning rollout, and a privileged access review. Browse the war-game decisions hub for adjacent controls.
Authorize the published timers only after a timed drill restores usable session hygiene inside the documented budget without an undocumented manual step.