Policy Fail Mode Is an Architecture Decision, Not an Identity Integration Default

Policy fail mode is what an identity-conditioned rule does when the identity it depends on cannot be evaluated, and it is often inherited from an integration default instead of chosen. The default is set by a vendor, or by whoever wired the identity provider into the enforcement plane, and it stays invisible until the day the identity input is missing.

On October 20, 2026, Cloudflare reported an issue with traffic through Cloudflare One Gateway when an identity policy was part of the policy decision, while Gateway policies with no identity policy were unaffected. That outage is the occasion for this post, not its subject. The subject is the decision it made visible: what each rule does when its identity input is missing, who may change that mid-incident, and whether the path they would use depends on the thing that failed.

Three arguments follow. Composition determines how much of the estate an identity failure takes with it. Fail-closed protects the boundary but is not a recovery architecture. And the emergency path has to be independently operable and explicitly authorized, or the fallback inherits the failure it was built to survive.

One identity dependency, a partial outage. The rule set decides what fails.

What Is Documented, and What Is Not

Cloudflare's status page records the October 20 incident as Cloudflare Zero Trust connectivity, impact critical. It opened at 03:20 UTC with an investigation into an issue with traffic through Cloudflare One Gateway when an identity policy was present in the policy decision, and stated that all onramps were affected, that Gateway policies with no identity policy were unaffected, and that Dashboard impact was also being seen. The page marked the Zero Trust component a major outage. A fix was reported implemented at 04:44. At 05:46 Cloudflare reported edge functionality, including Access logins and Secure Web Gateway connectivity, restored, with Access API errors still elevated.

As of November 6, Cloudflare had published no root cause. It had not said whether affected traffic was blocked, timed out or bypassed, or whether any emergency path was affected. Nothing in this post depends on those answers.

Cloudflare's post-mortem for its June 12, 2025 outage documents a mechanism for that incident. Gateway retrieved user identity and device posture from Workers KV. DNS queries with identity-based rules failed when it could not, and the proxy path was designed to fail closed so traffic could not bypass customer-configured rules. The WARP emergency disconnect override became unavailable because it depended on the same storage service. That documents 2025. It does not explain 2026, and this post does not use it that way.

What follows is a cloud architecture strategy argument about policy fail mode.

Policy Fail Mode Is Decided Per Rule

An identity-conditioned rule carries a dependency its text does not show. Before the evaluator can match the rule, it has to obtain who is asking, and often which groups that person belongs to and what state their device is in. When it cannot, it has a short list of options: deny, skip the rule and fall through, allow, or apply a fallback someone defined in advance. Which one happens is the policy fail mode, and it belongs to each rule, not to the integration.

Where nobody decided, the behavior came from the vendor's defaults, and the rule was written for the case where identity evaluates. Cloud Governance Failure Domains describes the condition: policy engines sit in the execution path, so they carry a runtime, a failure mode and a blast radius. That post covers a wrong decision cascading downward; this one covers a correct decision whose input has gone missing. The Strategic Governance stage anchors the governance side.

Composition sets the blast radius. The October 20 statement describes a partial outage: rules with an identity condition were affected, rules without one were not. Whatever the cause, the failure follows the rule set. An estate that put an identity condition on every rule has made identity evaluation a single point of failure for all enforcement. An estate with a mix has a partial, predictable failure, but only if someone mapped which traffic classes sit on which side of the line.

Identity-free by selector isn't identity-independent by dependency. A rule with no identity selector can still depend on inputs retrieved the way identity is: group membership synchronized from the directory, device posture, session or registration state, or a shared store behind several of those. The 2025 post-mortem documents identity and device posture coming from one storage service in that incident. For October 2026 nothing is documented, and this post does not assume it. The architect's task is to map, per rule, every input the evaluator needs and where each is fetched from, by tracing dependencies instead of reading the rule. That inventory is the matrix below.

The Policy Failure-Mode Matrix

Written down per traffic class, a policy fail mode becomes a design decision: what happens when identity cannot be evaluated, what stays reachable, and who can authorize recovery. The matrix is the artifact to take into a design review.

Proposed design examples, not any vendor’s implementation.

Each row answers what a default never does: what the rule does, what remains reachable, and who may change that, in what role, under what trigger. A row with only the traffic class filled in is a default with a label on it.

Where Deny Is Correct

Privileged administration and sensitive applications are the rows where the boundary is the product. If identity cannot be evaluated, nothing establishes that the requester is entitled to the access, and refusing is the outcome the rule exists to produce. Deny is right here, but not complete: the people responding to the incident need privileged access too, which is why the first row names a break-glass path and the second a designated security authority, not whoever holds the pager.

Fallback Needs a Boundary and an Exit

The third row is where designs go soft, and where silent widening starts. "Restricted behavior" is not a fail mode until it says what is restricted. The fallback needs an explicit boundary, meaning which destinations and which traffic, and an exit condition: restoration of identity evaluation, a hard time limit or a named person closing it, whichever comes first. A bounded last-known-identity window is one option, but the cache is itself a dependency and an authorization decision, and needs the same boundary and exit. Some estates will choose deny here too, legitimately, if the outage cost is priced.

A restricted workforce fallback that never expires is just another permanent exception. It is the failure state the Emergency Reconciliation Gap names for configuration changes made during incidents, moved onto the policy plane: an authorized exception with no named owner and no closure deadline becomes the steady state without anyone deciding it should.

An Identity-Free Policy Is Not a Safe Policy

The usual advice for an identity outage is to keep an identity-free baseline: a rule set that keeps working when identity does not. The advice is sound, and it hides a trap. A policy that does not ask who is asking can only grant by traffic characteristics, so it is coarse by construction. Activating it during an incident does not restore the normal boundary. It substitutes a blunter one, and the substitution has to be designed as carefully as the original.

Four things make an identity-free policy safe to activate. A least-privilege boundary narrower than the identity-conditioned policy it replaces, because it has lost the ability to tell users apart. A definition of permitted traffic that names destinations, not categories of convenience. An expiration condition that ends the policy without anyone remembering to. And an audit trail that records who activated it, what it permitted and for how long, because the decisions made under it are the ones reviewed afterward.

⚠ Common mistake: Treating the identity-free baseline as the safe state. It is the available state. Without its own boundary, expiry and audit trail, activating it trades a loud outage for an unreviewed policy.

Fail-Closed Protects the Boundary. It Doesn't Restore Availability.

Fail-closed is a security outcome. For the deny rules it is the correct one, and Cloudflare's 2025 post-mortem states it as design intent for the Gateway proxy path. What it does not do is return anyone to work. The boundary holds, legitimate access stops, and availability returns only when the dependency recovers or someone changes what enforcement does.

Each of those is decided by default if it is not decided on purpose. Waiting for the vendor accepts the outage’s duration: on October 20 the status page reported edge functionality restored about two and a half hours after the incident opened, with Access API errors still elevated at that point. Whether your organization can absorb that for the traffic classes behind those rules is a question to answer before the outage, with a number attached. Changing what enforcement does needs a mechanism, an authority and a boundary, which is what the last two columns of the matrix are for.

Neither outcome is sufficient architecture by itself. Fail-closed with no designed recovery path is an outage the organization accepted without knowing it. A fail-open default is worse in a different way: it is silent widening, authorization broadening with nothing to announce it. The architecture is the pair: a deliberate policy fail mode per rule, and a recovery path that is tested and authorized.

The boundary held. Nobody was designated to open it.

This is the enforcement-plane version of the problem Your Identity System Is Your Biggest Single Point of Failure describes for operators, where an identity provider goes silent and locks the people out. Here the identity provider can be healthy while the plane that consumes its answers cannot get them. The dependency is the same and the place it breaks is different, so the break-glass accounts that post recommends do not by themselves recover user traffic.

Fail-closed is also the failure people report. The opposite failure produces no reports. Enterprise Browser Infrastructure describes enforcement that stops synchronizing while availability stays green, so nobody notices until an audit does. A policy fail mode that widens access quietly belongs to that family, which is why the first safeguard below is about outcomes, not labels.

Three Safeguards for Policy Fail Mode

Three safeguards apply to every row of the matrix.

The override needs a retrieval path the failed dependency cannot reach.

01 — NO SILENT WIDENING

Loss of identity evaluation must never produce broader authorization than the explicitly approved fallback permits. A condition that normally restricts access disappears, and the remaining policy permits more than anyone intended. The test is the outcome, not the label: fail-open is acceptable only as the approved fallback, with a boundary and an exit.

02 — NO SHARED EMERGENCY DEPENDENCY

The override cannot depend on the retrieval path that failed. Trace every input the emergency path needs to the same standard as the identity-independent row: where it is fetched from, and whether that source is the one in the incident.

03 — NO AMBIGUOUS AUTHORITY

Someone holds, by role, the authority to activate the alternative access path, someone can end it, and the activation has been rehearsed. Authority that is assigned, documented and exercised survives the incident. Authority that is assumed does not.

Safeguards 2 and 3 apply to the policy plane what Recovery Authority Fragmentation establishes for recovery in general: authority that shares a dependency with the thing it governs shares its blast radius. The 2025 post-mortem shows the first half: the override that let a user disconnect depended on the same storage service as the identity retrieval. Whether an equivalent path was affected on October 20 has not been stated, and the safeguard does not need the answer. It needs the trace.

What to Test

Policy fail mode needs an inventory and five answers per rule.

• Which rules carry an identity condition, and which traffic classes do they protect?
• When identity cannot be evaluated, what does each rule do, and who chose that?
• For each rule you call identity-independent, what inputs does it fetch, and from where?
• What does the fallback permit, and what ends it?
• Who can activate it, does the activation path touch the dependency that failed, and when was it last exercised?

Architect's Verdict

Policy fail mode is an architecture decision. What an identity-conditioned rule does when identity cannot be evaluated is chosen per traffic class, with a boundary, an exit and an owner, or it is inherited from a default and discovered during an incident.

The real problem is not that identity evaluation fails. It will. The problem is that composition decides how much fails with it, that fail-closed gets mistaken for a recovery plan, and that the emergency path is so often built on the dependency it exists to bypass. An identity-free baseline does not fix any of that on its own. It is a different boundary, and it needs its own limits.

No silent widening, no shared emergency dependency, no ambiguous authority. Those three constraints turn a default into a design. Everything else in the matrix is a choice an architect can defend in a review.

Failing closed protects the boundary. Failing well is deciding, in advance, who can safely open it again.

Additional Resources

• Cloud Architecture Strategy — the Cloud Strategy pillar hub: control plane governance, dependency ownership and the decision frameworks this argument sits inside.
• Strategic Governance — the Cloud Architecture learning path stage that anchors governance operating as infrastructure, the premise behind policy fail mode.
• Dependency Architecture — the stage on mapping and owning dependencies, the method for tracing what a rule actually needs to evaluate.
• Cloud Governance Failure Domains — policy engines in the execution path and the cascade from a wrong decision; this post covers a correct decision with a missing input.
• Your Identity System Is Your Biggest Single Point of Failure — the operator-side counterpart: break-glass access when the identity provider goes silent.
• Enterprise Browser Infrastructure — the quiet counterpart: enforcement that stops while availability stays green.
• Disaster Recovery Authority — Framework #144: recovery authority that shares a dependency with what it governs shares its blast radius.
• Configuration Standards Emergency Changes — the Emergency Reconciliation Gap: an authorized exception with no owner and no closure deadline becomes permanent.
• Cloudflare Zero Trust connectivity, October 20, 2026 — Cloudflare's status-page record of the incident: the primary source for every October 2026 statement here.
• Cloudflare service outage, June 12, 2025 — Cloudflare's post-mortem: the documented mechanism, fail-closed intent and shared override dependency for 2025.

Originally published at rack2cloud.com