Control objective
Revocation latency is the elapsed time between an effective removal decision and the last action that old authority can still perform. Measure it separately for identity status, authenticator, session, token, group, device, policy, application permission, connection, and cached decision.
Trace the freshness chain
Identify the authoritative source, event propagation, polling or subscription interval, caches, token and session lifetime, enforcement check, active connection behavior, and application state. The maximum stale window can be the sum of several delays, not one documented timeout.
Test the bound
Start a valid session and access path. Disable the account or remove the permission. Send protected requests at measured intervals until denial. Repeat for an existing connection, unavailable context source, multiple enforcers, and application action. Record normal and adverse results.
Failure and residual risk
Short lifetimes increase dependency load and outage sensitivity. Immediate source change does not terminate every session or connection. A deny at the gateway does not remove a local application session. Emergency access and offline credentials can have different revocation behavior.
Pomerium boundary
Pomerium can reevaluate configured context for protected HTTP requests. Its documentation states that TCP and WebSocket policy applies when the connection starts, so an established connection can remain after a later policy change. Upstream applications must revoke their own sessions and permissions.
Evaluation checklist
- Is the revocation start event and protected action explicit?
- Are source, propagation, cache, session, token, connection, and application delays included?
- Has the bound been measured under normal operation and dependency failure?
- Do long-lived connections or application sessions need separate termination?
- Is the residual stale-access window accepted by the correct owner?
