Identity-provider outages  / field guide
Practitioner field guide · 2026-10-15

When the identity provider goes down

Every request your estate serves begins with the question "who is asking, and may they?", and one central remote service answers it. Between 2020 and 2025 that service failed, in public, at Google, Microsoft, AWS, Auth0 and Cloudflare. This guide reconstructs what kept working during those outages and why, so you can decide what in your own design keeps answering when sign-in cannot.

45 ledger rows, 30 distinct sources 10+ production systems 7 incidents and advisories Evidence through October 2026 Read: ~22 min
01

The territory

Authentication is the one dependency shared by everything else, which is why its outages are the only ones that take down products that share nothing else.

>90%
of Microsoft Entra authentications are reauthentications of existing sessions, not new sign-ins
47 min
of failed account authentication across Google, when a quota tool cut the User ID Service, Dec 2020
100%
of Cloudflare Access identity logins failed when Workers KV lost its third-party storage, Jun 2025
24 h
minimum outage budget SPIRE will accept when you set its availability_target for workload identity

State the problem without naming a product: a distributed estate must answer "who is asking, and may they?" on every request, the answer comes from one logically central service, and that service is made of the same databases, caches, queues and deploy pipelines as everything else. So it fails at the same base rate as everything else, while being the one dependency nothing can route around. Google's December 2020 report says its User ID Service lost its quota to an automated tool and authentication failed for about 47 minutes; Gmail and YouTube fell over not because they broke but because they could no longer tell who anyone was.

The surprise in this research is not that identity providers fail. It is where the survivability actually comes from. Microsoft publishes the number that explains it: over 90 percent of Entra authentications are reauthentications of existing sessions, not new sign-ins. The systems that ride out an identity outage are not the ones with a more available identity provider. They are the ones that exploit that skew: they split identity into an issuance side that mints new sessions and a validation side that re-checks existing ones, and they arrange for validation to keep answering from material it already holds, keys, tickets, tokens, replicated decision data, while issuance is down. That split is not new. The 1988 Kerberos paper already had it: a service verifies a ticket with its own secret key, no call to the authentication server, and the ticket lifetime bounds how stale that trust can get.

Scope, stated up front. This guide covers surviving the unavailability of the identity plane: user sign-in, service-to-service credentials, and request-time authorization checks. It does not cover responding to identity-provider compromise (a different problem with opposite instincts: there you want everything to stop trusting cached material), does not cover choosing a federation protocol, and does not cover certificate expiry during normal operation, which is its own failure domain. Fail-open versus fail-closed is covered in depth, because the evidence says that choice, made per enforcement point and usually by default rather than by decision, is where the real risk sits.

Figure 1 · One question, two planes

The identity plane

keys, sessions,
decision data

New sign-ins,
new tokens

Issuance
(control plane)

Requests carrying
existing tokens

Validation
(data plane)

Hidden dependencies:
quota tools, streams, KV stores

Keeps answering
from held material

Fails with its
dependencies

The identity plane

keys, sessions,
decision data

New sign-ins,
new tokens

Issuance
(control plane)

Requests carrying
existing tokens

Validation
(data plane)

Hidden dependencies:
quota tools, streams, KV stores

Keeps answering
from held material

Fails with its
dependencies

Issuance mints new trust; validation re-checks existing trust. Every incident in this guide entered through issuance or its hidden dependencies, and everything that kept serving did so because validation held local material. Reconstructed from Google's, AWS's and Cloudflare's incident reports.
Diagram source
02

How the survivors are built

The same shape recurs across Google, Microsoft, Netflix, AWS, SPIFFE and the authorization systems: issuance is treated as a control plane that may be absent, and validation is pushed to the caller with everything it needs held locally.

Netflix is the cleanest published example of the shape. Its edge, described in the 2021 Edge Authentication post, cracks open whatever credential arrives (cookie, JWT, MSL token) and mints a short-lived internal identity object, the Passport, integrity-protected with an HMAC, which every downstream service verifies locally. The ratio that matters comes from the engineer who built it: in the QCon SF 2019 talk, Satyajit Thadeshwar reports that only about 5 percent of requests need a remote call from the edge proxy, and that "this split of 95% and 5%... helped a lot with the resiliency of Zuul". Validation at the caller, issuance behind it, and the remote dependency confined to the minority path: that is the reference architecture in one sentence.

AWS applies the same split to its own identity system and names it. The IAM security blog divides IAM into a control plane (create and modify principals and policies) and a data plane, "the authorization system that is used at scale to grant access", with STS in the data plane. The Builders' Library names the property the data plane must have: static stability, meaning everything the system was already doing continues to work when a dependency is impaired, even if nothing new can be configured. SPIFFE/SPIRE, the open workload-identity stack, implements the same idea and, uniquely in this corpus, exposes it as a number: the agent's availability_target, "the minimum amount of time desired to gracefully handle SPIRE Server or Agent downtime", must be at least 24 hours, and the agent rotates certificates early so that a workload always holds at least that much remaining lifetime.

Authorization data follows the same pattern as authentication keys: replicate it to where the question is asked. Google's Zanzibar paper is blunt about why the central check cannot be allowed to be slow or absent: "authorization checks are often in the critical path of user interactions", and the system holds 99.999 percent availability over three years at more than 10 million checks per second by serving from caches and replicated state rather than a single store. Airbnb's Himeji, per InfoQ's 2021 write-up, fronts its store with a sharded, replicated in-memory cache; the current job posting puts it above 8 million checks per second. Neither system survives its database being down forever; both survive it being down for the length of a cache lifetime, which is the same trade the token systems make.

The one divergence point worth calling out: a separate backup issuance path. Microsoft, after the 2020 and 2021 outages, built one. The Entra backup authentication system is a second service that syncs session metadata while the primary is healthy and reissues tokens during an outage, runs active-active handling a share of traffic continuously so it cannot rot cold, and deliberately serves only reauthentications: same app, same device, used within the last three days. No other organisation in this corpus has published such a system. The honest reading is that a backup issuer is an identity-provider-operator's move; everyone else gets most of the same protection from token lifetime and caches, which cost nothing to operate.

Figure 2 · Reference architecture for outage-tolerant identity

Validation: data plane, keeps serving

Issuance: control plane, may be absent

every request

new session only

publish keys,
ahead of need

Identity provider
(sign-in, MFA, token mint)

Key rotation +
deploy automation

Backup issuer
(reauth only)

Enforcement point
(gateway, sidecar, app)

Cached trust material
(JWKS, service keys)

Replicated decision data
(authz cache, policy)

Client holding a token

Validation: data plane, keeps serving

Issuance: control plane, may be absent

every request

new session only

publish keys,
ahead of need

Identity provider
(sign-in, MFA, token mint)

Key rotation +
deploy automation

Backup issuer
(reauth only)

Enforcement point
(gateway, sidecar, app)

Cached trust material
(JWKS, service keys)

Replicated decision data
(authz cache, policy)

Client holding a token

The enforcement point answers from locally held material (keys, token, replicated decisions); only new sessions cross into the control plane. Dashed components are the divergence points: Microsoft operates a backup issuer, most organisations do not. Reconstructed from Netflix, Microsoft, SPIRE and AWS sources.
Diagram source

Verifiable identity object

A short-lived, integrity-protected credential minted once at the boundary and verified locally by every hop. The 1988 Kerberos ticket, Netflix's Passport and SPIFFE's SVID are the same design three decades apart.

Runs this way at: Netflix, SPIFFE/SPIRE adopters

Trust material pushed ahead of need

Signing keys and policy distributed to validators while everything is healthy, so validation has no runtime read against the issuer. The failure mode moves to rotation, which is exactly where Azure AD broke in March 2021.

Runs this way at: Microsoft, AWS (as static stability)

Decision data replicated to the asker

Authorization answers served from caches and replicas co-located with the check, so the central store's outage budget equals the cache lifetime, not zero.

Runs this way at: Google (Zanzibar), Airbnb (Himeji)

03

The decisions that matter

Four forks recur in every system studied. Two of them are really the same number viewed from different sides: how long you let held trust stay valid.

Decision: do validators verify locally, or ask the issuer on every request?

Chosen
  • Local verification of self-contained credentials: Kerberos tickets (1988), Netflix Passport, SPIFFE SVIDs, JWT validation against cached JWKS.
  • Netflix: 95% of edge requests resolve identity with no remote call, which its engineer credits for the edge proxy's resilience (QCon SF 2019).
Rejected
  • Per-request introspection against the identity provider.
  • Rejected because it makes every request inherit the issuer's availability; Zanzibar's authors note authorization checks sit "in the critical path of user interactions" (ATC '19), and the same holds for token checks.
Flips when
  • You must revoke in seconds (regulated sessions, admin credentials). Then the central check is the point, and you pay for it with the issuer's availability, or you keep local validation and shrink the token lifetime until the revocation lag is acceptable.

Decision: when an enforcement point cannot reach its checker, does it fail open or closed?

Chosen
  • Fail closed at the authentication boundary. Envoy ships failure_mode_allow: false by default (ext_authz proto); Kubernetes reversed its webhook default from Ignore to Fail at GA (KEP-492 vs v1 docs); Duo moved its Windows logon default from fail-open to fail-closed in 4.3.0 (release notes) after the fail-open default was exploited.
Rejected
  • Fail open as the general default. The record shows it being triggered deliberately: CISA documents actors redirecting MFA calls to localhost so the fail-open default waved them in (AA22-074A), and Envoy's fail-open path became a bypass twice (CVE-2023-27488, CVE-2024-23324).
Flips when
  • The check is supplementary rather than the boundary, an independent detective control exists, and lockout would block recovery. Gatekeeper defaults its admission webhook to Ignore precisely because "Audit is expected to pick up any slack in enforcement" and fail-closed can deadlock cluster recovery (failing-closed doc).

Figure 3 · Choosing a failure policy per enforcement point

yes

no

no

yes

yes

no

Is this check the
authentication boundary itself?

Fail closed.
Buy survivability with token
lifetime and cached keys instead

Does an independent detective
control see what this check misses?

Fail closed, or build the
audit path before relaxing it

Could a lockout block its own
recovery (circular dependency)?

Fail open, alert on every use,
and treat each use as an incident

Default closed; exempt only
named recovery namespaces

yes

no

no

yes

yes

no

Is this check the
authentication boundary itself?

Fail closed.
Buy survivability with token
lifetime and cached keys instead

Does an independent detective
control see what this check misses?

Fail closed, or build the
audit path before relaxing it

Could a lockout block its own
recovery (circular dependency)?

Fail open, alert on every use,
and treat each use as an incident

Default closed; exempt only
named recovery namespaces

The tree the sources collectively imply. Note that "fail open" is only ever the answer when something else is watching: Gatekeeper pairs Ignore with audit (OPA docs), while Auth0's fail-open bot challenge writes no log event at all (Auth0 support article), which removes the pairing.
Diagram source
DecisionChosenRejectedBecauseFlips whenEvidence
Where validation happensAt the caller, against held materialPer-request call to the issuerIssuer availability would gate every requestRevocation must land in secondsNetflix talk, 2019
Credential lifetimeExplicit outage budget (SPIRE: at least 24h when set)Reflexively short TTLs everywhereLifetime minus rotation point is exactly how long you survive issuer downtimeTheft of a long-lived credential costs more than an outageSPIRE docs, 2026
Failure mode at the boundaryFail closed (Envoy default, K8s v1 default, Duo 4.3.0 default)Fail openFail-open paths get triggered deliberately, not just by outagesCheck is supplementary AND audited AND lockout blocks recoveryCISA, 2022
Backup issuance pathMicrosoft: separate active-active reauth-only serviceCold standby issuerA cold second issuer rots; Entra's handles live traffic continuouslyYou are not an IdP operator: lifetime and caches buy most of the same cover for freeEntra blog, 2024
Authorization data placementReplicated/cached next to the checkSingle consistent store queried per checkCheck volume (10M+ QPS at Google) and critical-path latencyChecks are rare and strongly consistent denial is a legal requirementZanzibar, 2019
Policy evaluated mid-outagePre-declared degraded policy (Entra resilience defaults)Deciding during the incidentThe backup path only honours choices recorded before the outageNever; Microsoft states defaults "must be reenabled before an outage occurs"Entra CA docs, 2024

One absence is worth recording: I could not find a single closed-unmerged pull request in Envoy, Gatekeeper or Kubernetes that tried to flip a fail-open/fail-closed default and was rejected. The argument happens in issues and documentation instead, and in Gatekeeper's case the fail-closed request (issue #248) has stayed open since 2019 while the default remains Ignore. Read that as a signal: projects treat the failure-mode default as too consequential to change casually, so whatever default you inherit is the one your estate will run.

04

What broke in production

Seven published incidents and advisories, in four classes. None of them is an exotic identity failure; every one is ordinary infrastructure failing underneath the one service that gates everything else.

Class 1 · The identity plane's own hidden dependency

Postmortem

Google, Dec 2020: the quota tool turned off sign-in

AssumptionThe User ID Service's resource quota would always reflect its real usage.
What happenedDuring a quota-system migration, parts of the old system reported the service's usage as zero; when a grace period lapsed, automation cut its quota and authentication began failing globally.
Blast radiusAbout 47 minutes (03:46 to 04:33 Pacific); most authenticated traffic across Gmail, YouTube and Cloud errored.
FixGoogle disabled the quota automation for the service class and added checks for the reported-zero case its safeguards had missed.
Design ruleCapacity automation must treat the identity plane as a protected class: a tool that can reduce its resources can end every product at once.
Postmortem

AWS, Nov 2020: Cognito fell because Kinesis did

AssumptionAn analytics dependency could never take down sign-in.
What happenedKinesis in us-east-1 failed (an OS thread limit reached during a small capacity add); Cognito, which streamed usage data to Kinesis, buffered on error until its web servers' buffers filled and sign-in APIs began failing.
Blast radiusElevated Cognito User and Identity Pool failures roughly 05:15 to 14:28 PST; one downstream customer logged a six-plus-hour login outage of its own.
FixAWS "modified the Cognito webservers so that they can sustain Kinesis API errors" without exhausting buffers: static tolerance, not dependency removal.
Design ruleAny write your auth path makes to another system must be sheddable; an unbounded buffer converts someone else's outage into yours.

Figure 4 · June 2025: the dependency chain under Cloudflare Access

Third-party storageWorkers KVAccess login flowUserThird-party storageWorkers KVAccess login flowUserExisting sessions and tunnels continue. New logins and device registrations stop.sign in to protected appread identity/session configuncached read to origin storeprovider outage, 2h28m90.22% of KV requests fail100% of identity logins fail
Third-party storageWorkers KVAccess login flowUserThird-party storageWorkers KVAccess login flowUserExisting sessions and tunnels continue. New logins and device registrations stop.sign in to protected appread identity/session configuncached read to origin storeprovider outage, 2h28m90.22% of KV requests fail100% of identity logins fail
The identity product sat three dependencies above the failure, and the one that broke was outside Cloudflare entirely. Existing WARP tunnels stayed up; everything that needed a new login or registration stopped. From Cloudflare's postmortem.
Diagram source
Postmortem

Cloudflare, Jun 2025: Access inherited a KV store's cloud provider

AssumptionWorkers KV was redundant enough to sit under the company's own zero-trust login path.
What happenedKV's central store was partly "backed by a third-party cloud provider", which failed; KV failed 90.22% of requests, and Access, built on KV, "failed 100% of identity based logins for all application types". WARP could not register or authenticate new devices.
Blast radius2 hours 28 minutes; all new identity-based logins across Access, plus dependent products.
FixKV's storage was re-architected onto Cloudflare's own infrastructure, with third-party clouds demoted to redundancy (Aug 2025 post).
Design ruleDraw the transitive dependency graph below your identity products; the availability of sign-in is the minimum across that whole chain, including vendors you cannot see.
Incident account

Auth0, Apr 2021: the IdP vendor's database got congested

AssumptionOutsourcing login to a specialist removes the need to plan for login being down.
What happenedPer the Downtime Project's reading of Auth0's RCA, several large queries plus a run of database cache misses congested the primary store and logins failed for 4 hours 20 minutes.
Blast radiusEvery customer relying on Auth0-hosted login for the duration; thousands of products' sign-in pages.
FixQuery and cache work on Auth0's side; on the customer side, nothing changed unless they built it.
Design ruleBuying the IdP outsources operations, not the failure mode. Your session lifetime and your tolerance for stale sessions are still your decisions, and they are the only mitigation you control.

Class 2 · Trust material lifecycle: the service was up, the keys were wrong

Postmortem

Azure AD, Mar 2021: rotation deleted a key marked keep

AssumptionKey-rotation automation would honour a key flagged to be retained.
What happenedA signing key was marked "retain" for a cross-cloud migration; the cleanup automation ignored the flag and removed it, so tokens signed with it stopped validating across Microsoft and third-party apps.
Blast radiusFrom about 19:00 UTC Mar 15; key metadata rolled back at 21:05 UTC, residual failures until 09:25 UTC the next day. The tail came from downstream services and caches re-converging, not the fix itself.
FixSafe Deployment Process protections extended to the key-rotation backend, the work Microsoft had promised after the Sept 2020 outage (a latent defect in that same SDP system, roughly three hours of auth errors).
Design ruleRotation is a deploy. Stage it, canary it, and keep the old key verifiable until every validator has converged; the recovery time is set by your slowest cache, not your rollback.
Advisory

CISA, Mar 2022: fail-open triggered on purpose

AssumptionFail-open only activates during genuine connectivity loss, which is rare and benign.
What happenedState-sponsored actors enrolled a device against a dormant account (un-enrolled in the MFA system, still live in the directory), then redirected the MFA agent's calls to localhost; the Windows integration's then-default fail-open treated the unreachable service as an outage and let them in.
Blast radiusFull network access at the victim NGO, cloud and email accounts, document exfiltration.
FixDuo's Windows logon installers default to fail-closed from 4.3.0, and exe upgrades force the new default. Duo's own incident blog separately documents a customer breach through a fail-open RADIUS proxy.
Design ruleA fail-open path is an authentication bypass that an attacker can switch on by inducing the failure. If you keep one, alert on every use and treat each use as an incident, because the "outage" may be theirs.

Class 3 · The failure-mode switch itself misbehaving

CVE pair

Envoy, 2023 and 2024: fail-open became a request-shaped bypass

Assumptionfailure_mode_allow only fires when the authorization service is actually down.
What happenedTwice, a client-controlled malformed input (a non-UTF-8 header in CVE-2023-27488, an invalid gRPC request in CVE-2024-23324) made the ext_authz call "fail", and fail-open admitted the request. The attacker did not need an outage; they could manufacture the failure per request.
Blast radiusAny deployment running the vulnerable versions with fail-open on; fixed in 1.26.0-line and 1.29.1-line releases respectively.
FixInput sanitisation upstream of the failure-mode branch, and the advisories' standing workaround: set failure_mode_allow: false.
Design ruleThe predicate "the checker failed" must be computable only from the checker's health, never from properties of the request; otherwise fail-open is attacker-callable.
Issue thread

Gatekeeper: fail-closed locked the cluster out of its own recovery

AssumptionFailing closed on policy checks is strictly safer.
What happenedWith failurePolicy Fail on a self-hosted webhook, users reported namespace creation blocked (issue #733) and a stopped cluster unable to start again (issue #3183): the webhook's own pods needed the API server operations the webhook was blocking. The docs name the deadlock: delete every node and "this circular dependency will need to be broken before the cluster's control plane can recover".
Blast radiusCluster-wide write unavailability until a human deletes the webhook configuration out-of-band.
FixGatekeeper keeps Ignore as its default and pairs it with the audit controller as the detective control; Kubernetes itself exempts webhook-configuration edits from admission so the escape hatch always works.
Design ruleBefore failing closed, trace the recovery path; if recovery passes through the thing that failed, you have built a lock whose key is inside the box.
Audit is expected to pick up any slack in enforcement. Gatekeeper documentation, on why its admission webhook defaults to fail-open; the honest version of a trade most teams make silently.

Figure 5 · Five years of identity-plane incidents

2020Sept. Azure ADdeploy defect, about3h of auth errorsNov. AWS Cognitocollateral of Kinesis,about 9h of elevatedfailuresDec. Google User IDService quota cut,47 min global2021Mar. Azure ADsigning key deleted,14h tailApr. Auth0 databasecongestion, 4h20mof failed logins2022Mar. CISA reportsfail-open MFAexploited by stateactors2023Apr. EnvoyCVE-2023-27488,fail-open becomesbypass2024Feb. EnvoyCVE-2024-23324,same class again2025Jun. CloudflareAccess 100% loginfailure, 2h28mIdentity-plane incidents and advisories, 2020-2025
2020Sept. Azure ADdeploy defect, about3h of auth errorsNov. AWS Cognitocollateral of Kinesis,about 9h of elevatedfailuresDec. Google User IDService quota cut,47 min global2021Mar. Azure ADsigning key deleted,14h tailApr. Auth0 databasecongestion, 4h20mof failed logins2022Mar. CISA reportsfail-open MFAexploited by stateactors2023Apr. EnvoyCVE-2023-27488,fail-open becomesbypass2024Feb. EnvoyCVE-2024-23324,same class again2025Jun. CloudflareAccess 100% loginfailure, 2h28mIdentity-plane incidents and advisories, 2020-2025
Every root cause is ordinary infrastructure: a quota tool, a stream buffer, a deploy pipeline, a key janitor, a KV store, a database. Sources linked in the failure cards above and the references.
Diagram source
05

Numbers you can plan against

The planning quantity this corpus keeps producing is slack: credential lifetime minus rotation point, which is how long validation keeps answering after issuance stops.

MetricValueAtContextAs ofSource
Share of authentications that are reauthentications>90%Microsoft EntraVendor-stated; the basis of the backup system's reauth-only design2024Entra docs
Backup-auth eligibility window3 daysMicrosoft EntraSame app, same device; no new sessions, no guests2024Entra docs
Edge requests needing no remote identity call95%NetflixMeasured; stated as the basis of edge-proxy resilience2019QCon talk
Global sign-in outage duration47 minGoogleMeasured, 03:46 to 04:33 Pacific2020-12incident #20013
Auth-error window, key-rotation incident~14 hMicrosoft Azure ADMeasured; mitigated at 2h, long tail from caches2021-03PIR LN01-P8Z
Cognito elevated sign-in failures~9 hAWS us-east-1Measured downstream, 05:15 to 14:28 PST2020-11customer status
Identity logins failed during KV outage100% for 2h28mCloudflare AccessMeasured; KV itself failed 90.22% of requests2025-06postmortem
IdP vendor login outage4 h 20 minAuth0Reported via RCA coverage; database congestion2021-04Downtime Project
Central authz availability99.999%Google ZanzibarMeasured over 3 years, p95 under 10 ms2019ATC '19 paper
Central authz check volume>10M QPSGoogle ZanzibarMeasured; over two trillion ACLs stored2019ATC '19 paper
Authorization checks per second~850k then 8M+Airbnb Himeji850k/s reported 2021 (InfoQ); 8M+/s in a live 2026 job posting2021 / 2026InfoQ, Airbnb careers
Default workload-credential lifetime1 hSPIREdefault_x509_svid_ttl; default rotation at half-life gives ~30 min of slack2026SPIRE server docs
Minimum declared outage budget24 hSPIRE availability_targetFloor the project accepts when the knob is set at all2026SPIRE agent docs
IdP uptime commitment99.99%OktaVendor claim/SLA, cell-based active-active architecture2022Okta whitepaper
Read these carefully

Measured and vendor-claimed figures are mixed above and labelled in the Context column. The Entra 90 percent figure and Okta's 99.99 percent are vendor statements with no independent measurement published anywhere I could find. The arithmetic worth doing on your own estate: 99.99 percent still concedes about 52 minutes a year, almost exactly one Google-December-2020 per year, so size your token lifetime to survive at least that. And note the asymmetry the SPIRE defaults encode: a 1 hour credential rotated at half-life leaves roughly 30 minutes of slack, which would not have covered a single incident in the table above.

06

The evidence wall

Every source behind this page, graded. Filter by kind. The full claim-by-claim ledger ships alongside this file as sources.md.

Postmortem Google2020-12

Google Cloud incident #20013

The authoritative account of the December 14 sign-in outage: a quota-system migration under-reported the User ID Service's usage as zero, automation cut its quota, and authentication failed globally for about 47 minutes.

Carry forwardSafeguards keyed on "large change" miss the reported-zero case; protect the identity plane from your own automation.
status.cloud.google.com/incident/zall/20013
Postmortem Microsoft2021-03

Azure AD PIR, tracking LN01-P8Z

Key-rotation automation ignored a key's "retain" flag and deleted it; token validation broke across Microsoft and third-party apps. Rollback took two hours; the tail ran past fourteen as caches re-converged.

Carry forwardTrust-material changes are deploys; the recovery time is your slowest validator cache, not your rollback.
documentcloud.org (PIR PDF)
Postmortem AWS2020-11

Summary of the Kinesis event in US-EAST-1

The canonical hidden-dependency incident: Cognito buffered analytics writes to a failed Kinesis until its own web servers choked. The fix made sign-in tolerate the dependency's absence rather than removing it.

Carry forwardEvery write from the auth path must be sheddable under error, with bounded buffers.
aws.amazon.com/message/11201
Postmortem Cloudflare2025-06

Cloudflare service outage June 12, 2025

Workers KV's storage sat partly on a third-party cloud; when it failed, Access failed 100 percent of identity logins and WARP could not register devices. Unusually precise per-product impact percentages.

Carry forwardYour login's availability is the minimum of a transitive chain that may leave your company; map it.
blog.cloudflare.com/cloudflare-service-outage-june-12-2025
Postmortem Cloudflare2025-06

Status incident: broad service outages

The live statement during the event, naming "an outage of a 3rd party service that is a key dependency" and listing Access and WARP among affected products.

Carry forwardStatus pages name dependencies under pressure that blog posts later soften; archive them during incidents.
cloudflarestatus.com/incidents/25r9t0vz99rp
Postmortem Sparkcentral2020-11

Customer status page during the Cognito outage

The downstream view: a SaaS vendor's own users locked out for the roughly nine-hour window of elevated Cognito failures, with the vendor able to do nothing but wait.

Carry forwardOutsourced sign-in means your incident timeline is somebody else's; your only lever is how long existing sessions survive.
status.sparkcentral.com/incidents/ntf10pw9rnnx
Postmortem CISA / FBI2022-03

AA22-074A: default MFA protocols exploited

State actors re-enrolled a dormant account, then redirected MFA calls to localhost so the fail-open default admitted them. The advisory explicitly warns that fail-open "can happen to any MFA implementation".

Carry forwardAn attacker who can induce the failure owns your failure mode; fail-open is attacker-callable.
cisa.gov (AA22-074A PDF)
Source Envoy2026-10

ext_authz filter API: failure_mode_allow

The failure-mode decision reduced to one boolean, shipped fail-closed: "When set to true, the filter will accept the client request even if communication with the authorization service has failed... Defaults to false."

Carry forwardInventory this flag (and its equivalents) across your gateways; each one is a standing decision someone made, or nobody did.
github.com/envoyproxy/envoy (ext_authz.proto)
Source Envoy2023-04

GHSA-9g5w-hqr3-w2ph (CVE-2023-27488)

A non-UTF-8 header produced an invalid message to the auth service; with fail-open set, those requests were allowed through. The workaround was the default: fail closed.

Carry forwardThe "checker failed" predicate must not be derivable from request content.
github.com/envoyproxy/envoy advisory
Source Envoy2024-02

GHSA-gq3v-vvhj-96j6 (CVE-2024-23324)

The same bypass class one year later, via invalid gRPC requests. Two independent CVEs against one flag is a pattern, not an accident.

Carry forwardFail-open surfaces re-open as the parser evolves; they need standing adversarial review, not one-time sign-off.
github.com/envoyproxy/envoy advisory
Source Open Policy Agent2019

Gatekeeper issue #248: Fail Closed

Open since 2019: the request that Gatekeeper fail closed, including the observation that a freshly started webhook pod that has not yet loaded constraints is itself a fail-open window.

Carry forwardStartup is a failure mode: a validator that answers before it has state is failing open silently.
github.com/open-policy-agent/gatekeeper/issues/248
Source Open Policy Agent2023

Gatekeeper issue #3183: cluster could not start

Field report of the fail-closed lockout: a stopped cluster with failurePolicy Fail could not come back because starting the webhook required API operations the absent webhook was blocking.

Carry forwardTrace the recovery path before failing closed; the key must not live inside the box.
github.com/open-policy-agent/gatekeeper/issues/3183
Source SPIFFE / SPIRE2026-10

spire-agent configuration: availability_target

The only system in this corpus that names the outage budget as a config key: minimum 24 hours, enforced by rotating credentials early so workloads always hold that much remaining lifetime. Default credential TTL elsewhere in the docs is one hour.

Carry forwardMake slack a declared number, then alert when the fleet's minimum remaining lifetime dips below it.
github.com/spiffe/spire/doc/spire_agent.md
Decision record Open Policy Agent2026-10

Gatekeeper docs: Failing Closed

A rare written argument for a fail-open default: single-instance webhook availability, the audit controller as compensating control, and the node-deletion circular dependency that fail-closed creates, with the emergency escape documented.

Carry forwardIf you fail open, write down the compensating control in the same document; if you cannot name one, you may not fail open.
open-policy-agent.github.io (failing-closed)
Decision record Kubernetes2019-01

KEP-492: Graduate Admission Webhooks to GA

Documents that v1beta1 defaulted failurePolicy to Ignore; the v1 API shipped with the default reversed to Fail. A recorded default-flip on exactly the question this guide is about, in the opposite direction from Duo's.

Carry forwardDefaults encode a threat model; when the ecosystem's threat model changes, re-read every inherited default.
github.com/kubernetes/enhancements (KEP-492)
Paper Google2019-07

Zanzibar: Google's Consistent, Global Authorization System

States the availability bar and hits it: checks "often in the critical path of user interactions", 99.999 percent availability over three years, more than 10 million checks per second over two trillion ACLs, served from replicated and cached state.

Carry forwardA central decision point is tolerable only with replication and caching designed in from the start; the store is never on the hot path.
usenix.org/conference/atc19/presentation/pang
Paper MIT (Steiner, Neuman, Schiller)1988

Kerberos: An Authentication Service for Open Network Systems

The original issuance/validation split: a ticket sealed under the service's own key carries identity, lifetime and a session key, so the service verifies with no call to the authentication server, and lifetime bounds the staleness. Summary copy linked; the original is in the USENIX Winter 1988 proceedings.

Carry forwardOffline validation with bounded lifetime is a 38-year-old design; your JWT setup is re-deriving it, so copy its discipline about lifetimes too.
pages.cs.wisc.edu (Kerberos paper summary)
Talk Netflix2019-11

User and Device Identity for Microservices at Netflix Scale (QCon SF)

The transcript carries the load-bearing ratio: only 5 percent of edge requests need a remote call, "helped a lot with the resiliency of Zuul". Slides detail the HMAC-protected Passport minted at the edge.

Carry forwardMeasure your own 95/5 split; the remote-call fraction of your auth path is the fraction that shares the issuer's fate.
infoq.com/presentations/netflix-user-identity
Talk The Downtime Project2021

Auth0's Seriously Congested Database

A careful outside reading of Auth0's April 2021 RCA: large queries plus cache misses congested the database behind login for 4 hours 20 minutes. The IdP failed as a database application, because that is what an IdP is.

Carry forwardRate your IdP vendor as you would any database service you depend on, not as a security product.
downtimeproject.com (Auth0 episode)
Eng blog Netflix2021-02

Edge Authentication and Token-Agnostic Identity Propagation

How token handling was pulled out of every microservice and centralised at the edge, with a cryptographically verifiable Passport propagated instead of raw credentials.

Carry forwardOne team owning token cracking at the boundary beats every service linking an auth library and calling home.
netflixtechblog.com (edge authentication)
Eng blog Cisco Duo2022

Failing open: a lesson in attention to configurations

A vendor narrating a customer breach through its own product's fail-open setting: a RADIUS proxy configured "safe" (fail open) admitted an attacker during a connectivity loss to Duo's service.

Carry forward"Safe" in a config enum can mean available, not secure; audit the words your failure modes hide behind.
duo.com/blog/failing-open-a-lesson-in-attention-to-configurations
Eng blog Cloudflare2025-08

Redesigning Workers KV for increased availability

The structural fix after June 12: KV's data moved onto Cloudflare's own infrastructure with third-party clouds demoted to redundancy, removing the single point the login path had been standing on.

Carry forwardAfter the incident, the dependency was not made more reliable; it was made less load-bearing. Prefer that direction.
blog.cloudflare.com/rearchitecting-workers-kv-for-redundancy
Eng blog RCP Magazine2021-03

What happened with the Azure AD outages

Coverage connecting the September 2020 outage (latent defect in the Safe Deployment Process backend, roughly 21:25 to 00:23 UTC) to the March 2021 key deletion, including Microsoft's own admission that the promised SDP hardening was still mid-rollout.

Carry forwardRemediations have lead times measured in quarters; the second incident often lands inside the first one's fix window.
rcpmag.com (Azure AD outage)
Case study Airbnb2021-05

Himeji: centralised authorization at Airbnb (InfoQ coverage)

A Zanzibar-shaped check service fronted by a sharded, replicated in-memory cache; roughly 850 thousand checks per second in 2021, with the current job posting claiming over 8 million. Availability comes from the cache tier, not the store.

Carry forwardThe cache in front of the decision store is not an optimisation; it is the availability design.
infoq.com/news/2021/05/airbnb-himeji
Vendor Microsoft2024

Microsoft Entra backup authentication system

The only published backup issuer: syncs session metadata while healthy, reissues tokens for existing sessions during outages (same app, same device, three-day window), runs active-active, and explicitly does not serve new sessions or guests.

Carry forwardMicrosoft sized its backup to the 90 percent reauth skew; size your own degraded mode to your traffic's actual shape.
learn.microsoft.com (backup authentication system)
Vendor Microsoft2024

Conditional Access: resilience defaults

The degraded-mode policy contract: conditions that cannot be evaluated in real time are either blocked or evaluated from session-start data, the choice is recorded per policy in advance, and enabling it mid-outage does nothing. Sign-in frequency controls reduce what the backup can serve.

Carry forwardDecide your outage policy in peacetime and encode it; the backup path only honours pre-declared choices.
docs.azure.cn (resilience defaults)
Vendor Cisco Duo2024

Duo for Windows Logon release notes

The default reversal in the shipped product: fail-open through 4.2.2, fail-closed from 4.3.0, with exe upgrades forcing the new default. Paired with PSA-2019-001, where fail-closed systems could silently behave fail-open through a defect.

Carry forwardVerify the failure mode empirically after every upgrade; the default under your config may have moved.
duo.com/docs/rdp-notes
Vendor Okta2022-09

Okta High Availability Architecture whitepaper

What an IdP operator commits to: self-contained cells, active-active-active across availability zones, 99.99 percent uptime. A vendor claim, and still about 52 minutes a year of conceded downtime for the thing in front of all your logins.

Carry forwardTranslate every IdP SLA into minutes per year and check your session lifetime covers it.
okta.com (HA whitepaper PDF)
07

Build a miniature, then productionise it

Seven rungs from a toy IdP to a measured, drilled estate. The line from toy to real is crossed at rung four, where you start measuring instead of believing.

Stand up the split

Run a local OIDC provider (Keycloak or Dex), one web app that validates JWTs against a cached JWKS, and sign in once. Then stop the provider and keep clicking.

Done when: you can state precisely which requests still succeed with the IdP dead, and why.  Teaches: issuance and validation are separate systems wearing one name.

Add the anti-pattern on purpose

Add a second service that calls the provider's token-introspection endpoint per request instead of validating locally. Kill the provider again and compare the two services' behaviour.

Done when: the introspection service fails while the local-validation one serves.  Teaches: a remote check inherits the issuer's availability, request by request.

Make lifetime the dial

Issue 5-minute and 8-hour tokens to different test users, take the provider down for an hour, and chart surviving traffic against outage time for each cohort.

Done when: you can draw the survival curve and point at where each cohort dies.  Teaches: token lifetime is simultaneously your outage budget and your revocation lag; one number, two prices.

Wire the failure-mode switch, with a witness

Put a gateway (Envoy ext_authz or equivalent) in front, configure fail-closed on the login route and fail-open on a low-risk route, and emit a metric on every fail-open pass-through, copying Envoy's failure_mode_allowed stat.

Done when: inducing a checker outage trips an alert within a minute, naming the route.  Teaches: fail-open without a detective control is silent; the metric is the control.

Run the outage drill against staging

Block egress to your real identity provider from a staging environment for one hour, during business hours, and inventory everything that breaks: cron jobs, service accounts, CI, webhooks, the admin console you planned to fix things with.

Done when: a written list of fail-closed surprises exists and each has an owner.  Teaches: the hidden callers of the identity plane, which no architecture diagram shows.

Build the recovery path that skips the IdP

Pre-provision a break-glass credential in a vault with its own trust root, write the runbook, and prove an operator can reach the control plane with SSO fully down. Test it quarterly; an untested break-glass is a prop.

Done when: a timed drill gets an operator from cold start to privileged access without touching the IdP.  Teaches: recovery must not authenticate through the thing being recovered.

Declare and monitor your slack

For every credential class in production (user sessions, service tokens, workload certificates), compute lifetime minus rotation point, publish it as an explicit availability target the way SPIRE does, and alert when the fleet minimum drops below it.

Done when: a dashboard shows the minimum surviving-hours number per credential class, and it has an agreed floor.  Teaches: outage tolerance is a measurable property you set, not a hope.

08

Keep hunting

The queries that actually found this material, grouped by what they surface. The incident set will have grown by the time you read this.

Postmortems and incident reports

  • <idp name> outage postmortem "root cause" authentication
  • status.<vendor>.com incident history authentication
  • "authentication errors" "post-incident report" key rotation
  • site:cisa.gov "fail open" MFA advisory

The fail-open/fail-closed argument

  • failure_mode_allow CVE envoy ext_authz
  • failurePolicy "fail closed" gatekeeper issue
  • "fail open" OR "fail closed" authentication outage "we"
  • duo "fail open" default windows logon

How the survivors are built

  • "backup authentication service" site:learn.microsoft.com
  • "statically stable" authentication data plane control plane
  • "availability_target" spire SVID rotation
  • netflix "edge authentication" passport identity propagation

Scale and decision-system numbers

  • zanzibar authorization "critical path" availability paper
  • "authorization checks per second" engineering blog cache
  • <company> careers authorization "checks per second"
09

References

Research for this guide ran in a sandbox whose network policy allowed direct fetches only to GitHub; GitHub-hosted sources were fetched directly, and all others were retrieved and quoted through search-engine retrieval of the live pages on the check date. Quotes come from that retrieved text, never from memory.

  1. Google, "Google Cloud Infrastructure Components Incident #20013" Google Cloud status dashboard, December 2020. Checked 2026-10-15.
  2. BleepingComputer, "Google explains the cause of the recent YouTube, Gmail outage" December 2020. Checked 2026-10-15.
  3. Microsoft, "Authentication errors across multiple Microsoft services", PIR tracking LN01-P8Z Azure status history PDF, March 2021. Checked 2026-10-15.
  4. RCP Magazine, "What happened with the Azure AD outage" March 2021, covering the September 2020 and March 2021 incidents. Checked 2026-10-15.
  5. AWS, "Summary of the Amazon Kinesis event in the Northern Virginia (US-EAST-1) Region" November 2020. Checked 2026-10-15.
  6. Sparkcentral, "Login issues on PROD region" Status page incident, November 2020. Checked 2026-10-15.
  7. Cloudflare, "Cloudflare service outage June 12, 2025" June 2025. Checked 2026-10-15.
  8. Cloudflare, status incident "Broad Cloudflare service outages" June 2025. Checked 2026-10-15.
  9. Cloudflare, "Redesigning Workers KV for increased availability and faster performance" August 2025. Checked 2026-10-15.
  10. Microsoft, "Microsoft Entra backup authentication system" Microsoft Learn, updated 2024. Checked 2026-10-15.
  11. Microsoft, "Conditional Access: resilience defaults" Microsoft docs (Azure China mirror of the same page), updated 2024. Checked 2026-10-15.
  12. Microsoft, "Microsoft Entra resilience update" (Entra blog) 2024. Checked 2026-10-15.
  13. Netflix, "Edge Authentication and Token-Agnostic Identity Propagation" Netflix Technology Blog, February 2021. Checked 2026-10-15.
  14. Satyajit Thadeshwar (Netflix), "User & Device Identity for Microservices @ Netflix Scale" QCon San Francisco 2019 via InfoQ, with transcript. Checked 2026-10-15.
  15. Slides for the same talk QCon SF 2019 archive PDF. Checked 2026-10-15.
  16. Pang et al. (Google), "Zanzibar: Google's Consistent, Global Authorization System" USENIX ATC 2019; paper text verified via the authzed/zanzibar-annotated mirror. Checked 2026-10-15.
  17. Steiner, Neuman, Schiller, "Kerberos: An Authentication Service for Open Network Systems" (summary copy) USENIX Winter 1988; linked summary hosted at UW-Madison. Checked 2026-10-15.
  18. Envoy, ext_authz v3 filter API (failure_mode_allow) envoyproxy/envoy source, fetched 2026-10-15.
  19. Envoy security advisory GHSA-9g5w-hqr3-w2ph (CVE-2023-27488) April 2023; description cross-checked against NVD. Checked 2026-10-15.
  20. Envoy security advisory GHSA-gq3v-vvhj-96j6 (CVE-2024-23324) February 2024. Checked 2026-10-15.
  21. Open Policy Agent, Gatekeeper documentation: "Failing Closed" Fetched from the gatekeeper repository, 2026-10-15.
  22. Gatekeeper issue #248, "Fail Closed" Opened 2019, still open. Checked 2026-10-15.
  23. Gatekeeper issue #733, failurePolicy Fail blocking namespace creation 2020. Checked 2026-10-15.
  24. Gatekeeper issue #3183, cluster startup failure with failurePolicy Fail 2023. Checked 2026-10-15.
  25. Kubernetes KEP-492, "Graduate Admission Webhooks to GA" kubernetes/enhancements, created 2019-01-27; fetched 2026-10-15.
  26. Kubernetes documentation, "Dynamic Admission Control" Docs source fetched from kubernetes/website, 2026-10-15.
  27. SPIRE, spire-agent configuration reference (availability_target) spiffe/spire source, fetched 2026-10-15.
  28. SPIRE, spire-server configuration reference (default_x509_svid_ttl) spiffe/spire source, fetched 2026-10-15.
  29. CISA/FBI, joint advisory AA22-074A March 15, 2022. Checked 2026-10-15.
  30. Cisco Duo, "Failing open: a lesson in attention to configurations" Duo blog, 2022. Checked 2026-10-15.
  31. Cisco Duo, product security advisory DUO-PSA-2019-001 2019. Checked 2026-10-15.
  32. Cisco Duo, Duo for Windows Logon release notes Updated through 2024. Checked 2026-10-15.
  33. Auth0, "Understanding the Auth0 Challenge Settings Fail Open feature" Auth0 support knowledge base. Checked 2026-10-15.
  34. The Downtime Project, "Auth0's Seriously Congested Database" Podcast episode, 2021. Checked 2026-10-15.
  35. Okta, "Okta High Availability Architecture" whitepaper September 2022. Checked 2026-10-15.
  36. AWS, "Static stability using Availability Zones" (Amazon Builders' Library) 2019. Checked 2026-10-15.
  37. AWS, "How to monitor and query IAM resources at scale, part 1" AWS Security Blog, 2020. Checked 2026-10-15.
  38. InfoQ, "How Airbnb standardised authorization with Himeji" May 2021, covering Airbnb's engineering post. Checked 2026-10-15.
  39. Airbnb careers, "Staff Software Engineer, Authorization" Live posting naming Himeji's current check volume. Checked 2026-10-15.