Security decisions use distributed state
An access decision can depend on identity lifecycle, group membership, device posture, policy, route configuration, issuer metadata, keys, revocation, session state, quotas, risk, and application object state. These facts are produced, copied, cached, and evaluated by different systems. They do not change atomically.
Distributed security state is the design of those versions, propagation paths, consistency rules, freshness bounds, conflicts, and failure results. The security question is not whether every replica is always current. It is which stale or conflicting result is acceptable for each protected action and for how long.
Version and freshness model
Give security state a source of authority, monotonic version or epoch, activation rule, issuance time where reliable, expiry, and observation evidence. Identify every cache and offline validator. Measure propagation from source change to the last accepted request under the old state.
Separate grants from revocations. A new low-risk grant can tolerate delayed availability. A credential revocation or removal of administrative authority can require bounded rejection across every enforcement point. Avoid comparing unsynchronized wall clocks when a version, lease, monotonic time source, or explicit acknowledgment can answer the question.
Partitions, rollback, and recovery
Define behavior when replicas disagree, updates arrive out of order, the source is unavailable, a cache expires, a node restores old state, or a partition isolates an enforcement point. Options include fail closed, serve bounded known state, preserve existing connections, restrict sensitive actions, or enter a separately controlled degraded mode.
Reject unapproved rollback. A signed old policy is authentic and can still be unsafe. After restore, reconcile epochs, revoked authority, keys, sessions, deletion state, and audit continuity before service reopens.
Failure and residual risk
Strong consistency reduces some stale decisions and adds latency and availability dependencies. Local caches improve continuity and extend old authority. Short lifetimes reduce exposure and increase renewal load and issuer dependence. A central source can simplify ownership and create a shared compromise and outage domain.
Evidence can report the version used at one evaluator while another path uses different state. An application can change object ownership after a gateway decision. No distribution protocol removes the need for end-to-end authorization at the state transition.
Pomerium boundary
Pomerium distributes and evaluates configuration and policy according to its deployment. It can record decision context for processed requests. Operators own identity-provider propagation, external data freshness, key and certificate rollout, application state, direct paths, version monitoring, and recovery. Pomerium cannot make separately managed sources update atomically.
Evaluation checklist
- Which security facts are distributed, who owns each source, and which components cache or validate them offline?
- What version, freshness, expiry, activation, and rollback rule applies to each fact?
- What is the measured last-accept time after revocation or policy restriction?
- What happens during delay, reordering, partition, cache expiry, replica disagreement, restore, and source outage?
- Does the final application state transition repeat the object and action authorization that only it can know?
