What Should Zero trust Do When the Policy Service Is Down?

An unavailable policy service should trigger a predefined access mode for the affected resource and action. Stop operations that require fresh authorization you cannot obtain. Continue only the specifically approved operations whose remaining evidence and enforcement still satisfy a bounded continuity policy. Treat service errors, explicit denials and stale evidence as different conditions, and reconcile policy state before restoring normal access. “Fail open” or “fail closed” is too incomplete to serve as the entire architecture.

I want an outage design to answer a concrete question: what can this requester still do to this resource, using which evidence, for how long? That is more useful than asking whether the organization has redundant identity servers. Redundancy matters, but the surviving path must still make the intended decision.

The research question here is how to preserve justified access when part of the decision system becomes unavailable. It is distinct from proving that an expired privilege has ended, recovering a lost authenticator or monitoring a control after change. Those tasks intersect with continuity, but an outage forces a separate choice about which decisions the organization is prepared to make with incomplete information.

Identify the failed dependency before choosing the response

NIST's zero-trust architecture distinguishes the policy engine, policy administrator and policy enforcement point. These are logical functions for deciding access, establishing or ending the path, and enforcing the result. The same publication explicitly treats disruption of these components as an operational threat and notes that replication mitigates rather than eliminates that risk (Rose et al., 2020, §§3, 5.2).

A request can fail because its evaluator is unavailable, because the evaluator cannot retrieve an attribute, because its answer cannot reach the enforcement point or because the protected application is down. Those are different incidents. Replacing all of them with “authentication failed” can send responders toward the wrong remedy and encourage unnecessary credential resets.

I would map the decision path alongside the application path. Include identity verification, policy distribution, attribute retrieval, key discovery, time, decision transport, enforcement and observation. Mark which dependencies are contacted for each request, which are contacted only periodically and which are needed on startup. A design that survives loss of an update service while warm may fail completely when its nodes restart.

For each dependency, specify the scope of failure. One region may be isolated while another has current policy. One action may need an unavailable attribute while another does not. A global emergency switch can erase these useful distinctions and expand an otherwise bounded interruption.

Local decisions and remote decisions fail differently

NIST's service-mesh guidance describes external authorization and locally evaluated token claims, including the central-failure and revocation considerations involved in those choices (Chandramouli et al., 2021, §4.5.2). Local evaluation can remove a remote call from the immediate request path. It does not remove the need to obtain and maintain trustworthy policy, keys and relevant attributes.

I would separate two architectural statements: “The evaluator is local” and “The evaluator has everything needed to make this decision.” A local process can still depend synchronously on a remote directory. Conversely, a remotely managed policy can continue to be evaluated locally after the management connection fails. These arrangements have different continuity properties despite similar diagrams.

Locality also changes the failure unit. A central service outage may affect many consumers at once; a bad distributed policy can reach many local evaluators at once. Replicating the evaluator does not protect against every common dependency or erroneous update. Ask which faults the placement actually isolates and which it merely distributes.

The resulting choice should be resource-specific. A high-consequence approval may require current authoritative state. A narrowly defined read may tolerate an older, explicitly bounded snapshot. That is a policy decision informed by consequences and architecture, not an automatic advantage of either centralized or decentralized products.

Preserve the difference between deny and cannot decide

An explicit denial means the evaluator reached a negative decision under a stated policy and available inputs. A timeout means the expected response did not arrive within the allowed interval. An evaluation error means the decision could not be completed as intended. The enforcement action may be refusal in all three cases, but the evidence and recovery actions differ.

Envoy's version 1.30.2 external-authorization documentation illustrates how configuration can determine the result. Its failure_mode_allow setting permits requests on specified communication failures or authorization-service server errors when enabled; the alternative rejects them. Its error-status setting controls the response returned for those failures (Envoy Project, n.d.). This is a version-specific example, not a claim about every proxy or deployment.

I would review the exact error classes covered by an exception. Does it apply to a connection timeout, malformed result, unavailable key, explicit denial or disabled filter? Treating these as interchangeable can create permission through a condition the policy owner never considered. Test the actual configured behavior rather than infer it from a friendly label in a console.

Preserve a machine-readable reason internally even when the user receives a simple message. Responders need to distinguish a justified denial from a dependency failure. Avoid exposing sensitive policy details to the requester, but do not make incident diagnosis depend on guessing whether an access refusal was a security success or an availability failure.

A signature cannot answer a freshness question

A signed policy bundle can establish provenance and integrity relative to a trusted verification process. It does not, by itself, establish that the bundle remains the latest applicable policy. The same distinction applies to a signed assertion about a device or role: an authentic statement may describe an earlier state.

NIST's ABAC guidance discusses attribute metadata such as authority, creation time, confidence and freshness as potentially relevant to decisions (Hu et al., 2014, p. 3). I would make freshness a property of each decision-relevant input rather than assign a single comforting timestamp to the whole access system.

A recent policy may depend on yesterday's device observation. A new token may carry a role copied from an older directory snapshot. An evaluator may have restarted a minute ago while loading a week-old policy. Record the origin and meaning of the timestamps; receipt, activation and observation time are not interchangeable.

Define what happens when an input is absent, too old or contradictory. A missing risk signal should not silently become a low-risk signal. If the continuity policy permits a decision without that input, name the limited operation and the remaining evidence required. Otherwise, the system has changed its authorization rule merely because information disappeared.

Bound cached authority at the place it is used

RFC 7662 permits caching of introspection responses but identifies the security/performance tradeoff, including a window in which revoked tokens can remain usable through cached information. Where the response contains an expiration value, it must not be cached beyond that time (Richer, 2015, §4). A cache can reduce an immediate dependency while preserving an earlier authorization state.

I would distinguish cached policy, cached attributes, cached token status and cached final decisions. They answer different questions and may have different validity rules. A valid policy snapshot does not make an expired token acceptable. A current token does not make an old device assertion fresh. Copying a previous “allow” result without its conditions loses the reasoning the continuity decision needs.

RFC 7519 defines processing requirements for expiration and audience claims when present, while leaving their use optional in the generic JWT format (Jones et al., 2015, §§4.1.3–4.1.4). The application profile must therefore define which claims are required and how they are validated. Merely choosing JWT does not supply a complete authorization or outage policy.

For the bounded continuity rule proposed here, every mandatory condition must remain satisfied. Its effective deadline is the earliest applicable deadline among those conditions, not the longest cache lifetime on the dashboard. This is a design rule to implement and test, not an automatic property of caches, tokens or zero-trust products.

Explain the consistency limit honestly

Suppose a branch evaluator cannot communicate with the authoritative policy service. In one possible history, no relevant permission changed. In another, access was revoked after communication stopped. If the branch has received identical information in both histories, it cannot distinguish them from its local evidence alone. Continuing the operation accepts that uncertainty; refusing it sacrifices some availability.

Gilbert and Lynch's formal work demonstrates an incompatibility between atomic consistency and availability in their asynchronous model when partitions are permitted (Gilbert & Lynch, 2002, §§2–3). That result has precise definitions. It does not prove that every authorization system must fail open, that every outage is a partition, or that returning an error satisfies the desired business service.

The practical inference is narrower: do not promise both current knowledge of an unreachable authority and uninterrupted successful decisions that depend on that knowledge. Identify which information can remain boundedly stale, which operation must wait and which independent evidence could change the decision. The answer can differ across operations on the same application.

This also explains why a larger fleet is not a complete answer. Additional replicas can improve fault tolerance, but the decision still needs a consistency and freshness contract. If a replica is permitted to answer from older state, say so. If it must wait for sufficiently current state, include that dependency in the availability analysis.

Define continuity by operation, not by application name

NIST's cyber-resiliency engineering guidance considers sustaining mission-essential functions under adverse conditions, including degraded operation (Ross et al., 2021, Chapter 1). That supports examining a reduced useful service instead of treating full functionality and total shutdown as the only possibilities. It does not designate which local security checks may be relaxed.

I would define continuity around the smallest useful action with a defensible consequence. Reading an already authorized operational instruction differs from exporting an entire repository, changing a role or approving a sensitive transfer. “Read-only” is not automatically low consequence: a bulk read can expose information irreversibly.

The following table is a proposed decision structure. Its dispositions require local evidence and approval before an incident; they are not universal defaults.

Decision condition	Possible disposition	Boundary that must be established
Required current evidence is available and valid	Evaluate ordinary policy	Confirm the actual enforcement path uses that evidence
Only an approved older snapshot is available	Permit the specifically bounded continuity operation	Enforce freshness, scope, credential and time conditions locally
A mandatory condition is unknown or expired	Refuse or defer the affected operation	Preserve the reason and a usable escalation path
An explicit current denial is known	Enforce denial	An outage must not erase a denial already received
Essential work needs separately authorized emergency access	Use the predefined emergency route	Independent authority, limited scope, evidence and termination must exist

Do not allow a broad application availability objective to override these distinctions invisibly. If leadership chooses to continue a consequential action with weaker evidence, record the exact change in assurance and its expiry. Calling the decision “resilience” does not remove its security consequences.

A continuity rule should also distinguish loss of availability from loss of confidence in integrity. I would test suspected policy tampering, an invalid signature and an unexplained rollback as separate conditions from a simple unreachable update endpoint. They need not enter the same operating mode. Retaining a previously verified artifact may be appropriate for a specified failure, but treating an unverified replacement as an emergency substitute would change the trust basis itself. Consider deliberate disruption in the threat model: an actor should not gain broad authority merely by causing the preferred decision path to stop answering. Any permitted continuation must remain bounded even when the cause of the outage is unknown.

Make the continuity window expire without the failed service

A time bound is useful only if the surviving components can enforce it. I would identify the clock or elapsed-time mechanism used, its uncertainty, behavior after restart and dependency on synchronization. The failed policy service cannot be the sole component responsible for ending the exception it is unavailable to supervise.

Consider an explicitly fictional example. An evaluator last confirmed policy at 10:00 and device state at 09:58. For a particular continuity read, the approved maximum ages are twelve and eight minutes respectively. The presented token expires at 10:09. Assume trustworthy comparable time, no additional mandatory conditions, and local enforcement of all three limits. The earliest deadline is 10:06, set by the device evidence. The example's minutes are illustrative, not recommended production settings.

If the node restarts at 10:04, it must not relabel the old observations as new and extend the window. Persisted state needs its original evidence times and applicable policy version. If the node cannot establish them reliably, it has lost a condition for this particular continuity permission. Its startup time does not create new authority.

The model also needs to state what the deadline ends: a new request, a continuing stream or an operation already committed. A request admitted before 10:06 may otherwise continue producing sensitive effects afterward. Define the relevant authorization checkpoint and cancellation or completion rule rather than assume a token deadline terminates every downstream action.

Test cold starts as well as running systems

OPA's bundle documentation describes optional persistence of activated bundles and best-effort loading from disk on startup when the bundle server cannot be reached. It also describes retaining an existing bundle when a replacement fails signature verification (Open Policy Agent, n.d.). Those mechanisms provide specific continuity behavior; they do not independently establish that an older bundle remains acceptable for every operation.

A warm evaluator may have policy, keys and attributes in memory. A cold evaluator may need one or more of those from the failed dependency. Test both cases, including a missing persisted file, an invalid replacement and a restored file with an obsolete revision. These are proposed test conditions, not allegations about a product's behavior.

I would distinguish artifact authenticity, successful activation and current authorization suitability. An authenticated bundle can be activated successfully while containing a rule the organization has since withdrawn elsewhere. Recovery must address that state difference rather than declare success because a checksum or signature passed.

Keep the evidence needed to diagnose startup without retaining reusable credentials or unnecessary request contents. Version identifiers, validation outcomes and dependency status can be sufficient for many checks. The exact retention design must match the service's privacy requirements and incident needs; indiscriminately logging every token is not a continuity strategy.

Readiness must mean more than a responsive process

Kubernetes distinguishes liveness, readiness and startup probes. A failed readiness probe removes a Pod from matching Service EndpointSlices, while liveness serves a different purpose associated with restarting an unhealthy container (Kubernetes Authors, 2026). This is platform behavior, not proof that a particular health endpoint measures authorization correctness.

A policy process can answer a health request while lacking an acceptable policy or required key. Conversely, a process may remain capable of a permitted degraded operation while an optional update endpoint is unreachable. Design the readiness signal around the operations the instance is allowed to serve, and document what the probe actually exercises.

Do not make the process restart merely because a remote policy dependency is briefly unavailable unless that behavior is justified. Restarting can discard useful local state and transform a warm continuity case into a failed cold start. That is a testable architectural possibility, not a claim that a particular orchestrator always behaves that way.

Separate process health, policy readiness and the service's permitted operating mode in monitoring. A green infrastructure tile should not imply that ordinary authorization has resumed. Equally, an intentionally restricted mode should not be hidden as an unexplained outage when the service is performing exactly the approved continuity function.

Keep retries from becoming a second incident

An unavailable authorization service can attract repeated requests from clients, gateways, applications and policy adapters. Google's original SRE discussion explains how retries at multiple layers can amplify load and describes bounded retries, backoff, jitter and retry budgets as mitigations (Ulrich, n.d.). These mechanisms need to be coordinated across the request path rather than configured independently and assumed harmless.

I would distinguish retrying a decision lookup from retrying the business operation that followed it. A transport failure after a write does not establish that the write never happened. RFC 9110 cautions against automatically retrying non-idempotent requests without a basis for knowing they are safe to repeat or were not applied (Fielding et al., 2022, §9.2.2).

For sensitive operations, preserve an operation identifier and a way to determine the actual outcome before repeating the effect. That is an application design requirement, not something an authorization retry automatically supplies. A fresh “allow” response cannot tell the caller whether an earlier transfer, export or configuration change already committed.

On restoration, limit the surge of queued requests and refresh attempts. A service that has just recovered may be least able to absorb simultaneous retries from every dependent component. The recovery plan should specify admission and backlog handling as well as the policy decision, with explicit treatment of work whose original authorization conditions have changed.

Emergency access needs a different dependency path

A predefined emergency route can be justified for essential work, but its authority must be available under the failure it is intended to address. An emergency approval that requires the same unavailable identity service is not independent merely because it uses a different screen. Map its issuance, storage, approval, enforcement, logging and termination dependencies separately.

I would keep emergency authority narrower than a global bypass wherever the operational task permits. Limit the resource, action, operator and interval; distinguish a route for repairing the policy infrastructure from ordinary access to business data. Do not let an emergency repair credential become an unreviewed alternative for routine work.

Existing refusals require attention. If a subject was explicitly denied before the outage, entering degraded mode should not wipe that fact and treat the subject as merely unknown. Define how locally known prohibitions interact with continuity permissions. If a separate authorized emergency process can override a restriction, that override must be explicit and attributable.

Termination also needs an independently workable mechanism. The detailed problem of proving that temporary authority ends is addressed in Does Privileged Access Really End When the Timer Expires?. An emergency procedure should use that proof discipline without making the continuity paper another general guide to privileged-access management.

Restoration is a policy transition, not just a network event

A successful connection to the policy service shows restored connectivity. It does not show that all evaluators have the intended policy, that intervening revocations were incorporated or that emergency exceptions ended. I would make return to normal operation an explicit state transition with evidence requirements.

Compare the applicable policy revision and the input state needed by the affected operations. Reconcile locally retained denials, queued requests and exceptional grants. Determine whether any work was admitted under weaker evidence and whether its effects require review. Do not automatically replay every deferred action: the requester, object or permitted purpose may have changed during the outage.

Some operations may return to normal before others. A service can possess current policy while a device-state provider remains stale. Preserve the remaining restriction rather than infer complete recovery from one repaired dependency. The system should report partial recovery in terms of the affected capability, not only component uptime.

For continuing assurance after the transition, How Do You Know a Security Control Still Works After a Change? develops evidence validity and reassessment. Here the essential acceptance question is whether the recovered authorization path has incorporated the state needed for its current decisions and whether the exceptional path has actually closed.

Validate the contract with faults that distinguish outcomes

I would test a representative access journey in an authorized environment with harmless resources. Establish successful ordinary access and a meaningful denied action first. Then introduce selected dependency failures while keeping the protected application available, so a refusal can be attributed to authorization behavior rather than a broken test environment.

Include evaluator timeout, stale input, failed policy update, cold startup, partial network isolation and recovery with a newer denial. Select cases from the actual architecture; this list is not a universal certification suite. Observe permitted continuity actions and prohibited actions together. A system that blocks everything has not demonstrated the promised continuity behavior.

Record the policy and configuration versions, evidence ages, mode transition, decision reason, enforcement result and relevant operation outcome. Compare observations with the preapproved contract. If the test cannot distinguish an explicit denial from an evaluation error, improve the observation before reporting the boundary as proved.

The most informative failures challenge a premise: the cache is older than assumed, the emergency route shares the failed dependency, a restart renews an evidence timestamp, or restored connectivity leaves an old rule active. These findings should change the architecture or narrow its continuity claim. Repeating the happy path more often cannot resolve them.

The tradeoff cannot be outsourced to a default setting

A strong objection is that refusal is the only defensible response to missing authorization evidence. For some actions, that is the appropriate policy. But an organization still needs to examine the consequences of interruption and establish a feasible route for essential work. “Always refuse” is incomplete if operators are then expected to improvise an undocumented bypass.

The opposite objection is that a business-critical service must always remain available. Criticality increases the need for a deliberate continuity design; it does not establish that every operation should continue with any credential. Reducing functionality, pre-positioning suitable evidence and separating repair authority can produce better options than abandoning the decision boundary entirely.

This paper offers an engineering synthesis, not a validated resilience score or measured deployment result. Its twelve sources combine architecture guidance, protocol specifications, project documentation, reliability practice and a formal distributed-systems result. Their assumptions differ. Product behavior is version-specific; the fictional timeline is not an empirical outage; no production system was tested. Applicability requires the actual architecture, consequences and authorized acceptance criteria.

The useful deliverable is a resource-specific contract for ordinary, degraded, emergency and recovering access, with evidence that the implementation follows it. If that contract is missing, I can help review one critical access journey, identify its hidden policy dependencies and define a bounded continuity exercise. Bring the decision path and the work that must remain possible; those give the discussion a concrete starting point.