Time is a security input
Security protocols use time to limit credentials, assertions, sessions, certificates, cached policy, device posture, approvals, and emergency access. Systems also need freshness: confidence that a message, decision, or state belongs to the current interaction and has not been replayed or rolled back.
Wall-clock time is one mechanism. Nonces, challenge-response, sequence numbers, versions, epochs, leases, replay stores, and channel binding can provide freshness without assuming that clocks perfectly agree.
Define every time rule
For each security object, define issuer time, not-before time, expiry, maximum age, idle limit, absolute lifetime, refresh rule, accepted skew, time source, and failure behavior. State whether the verifier uses wall time or monotonic elapsed time. Record which system created each timestamp and which clock the verifier trusts.
Keep authentication freshness separate from session age, policy freshness, device-signal age, and application transaction age. A recent session does not prove a recent authenticator use. A valid token can carry group state that changed after issuance.
Replay and ordering
Bind a challenge or proof to its issuer, audience, client, request, redirect, method, target, and transaction where the protocol requires it. Store one-time identifiers for the needed replay window. Protect the store from races and unbounded growth.
Do not use wall-clock timestamps alone to order distributed events. Network delay, clock adjustment, leap behavior, suspend and resume, virtual-machine restore, and malicious time changes can reorder them. Use explicit versions, causal identifiers, database ordering, or protocol state for decisions that require sequence.
Failure and residual risk
Large clock tolerance accepts older objects. Small tolerance rejects legitimate users during clock faults or network delay. Short lifetimes reduce replay duration and increase issuer, renewal, and availability pressure. Replay stores improve one-time enforcement and add shared state and denial-of-service risk.
An authenticated time source can still be unavailable or wrong at its source. Expiry stops future acceptance and does not undo an action that already completed. Rotating a key or restoring a clock does not remove copied sessions or application state.
Pomerium boundary
Pomerium validates time-bound protocol objects and uses configuration and session lifetimes according to documented behavior. Operators own reliable host time, identity-provider clocks, application transaction state, external context freshness, and monitoring. The upstream must enforce any object or action freshness that Pomerium cannot know.
Evaluation checklist
- Does every credential, session, assertion, context value, approval, and emergency grant have explicit time and freshness rules?
- Which clock or non-time mechanism establishes freshness and ordering for each decision?
- Do tests cover skew, delay, replay, race, suspend, restore, rollback, and time-source failure?
- Can a large tolerance, short lifetime, or replay store create a new availability or abuse problem?
- After expiry or revocation, what is the measured last action still accepted by every relevant system?
