8 August 2026

Designing Zero Trust for Failure

Zero Trust is not resilient just because it is cloud-hosted. Identity, posture, policy, tunnels, DNS and SaaS authentication all create failure domains that need deliberate recovery paths.

A Zero Trust platform can become one of the most important control planes in an enterprise.

That is exactly why its failure modes deserve as much design effort as its normal operation.

If private access, web filtering, identity, device posture and SaaS authentication all depend on the same access architecture, an outage does not necessarily have one cause.

It has failure domains.

Start with the control planes

A useful access path can be simplified to:

User
 ↓
Identity
 ↓
Endpoint / posture
 ↓
Access policy
 ↓
Network / tunnel
 ↓
Application

A failure at any stage can look to the user like:

Zero Trust is broken.

But the recovery action should be completely different depending on which layer actually failed.

Failure domain 1: identity

Symptoms might include:

• authentication failures
• MFA unavailable
• missing groups or claims
• users authenticating successfully but being denied later

The temptation during an identity outage is to weaken access policy.

That may be the wrong layer.

The better question is:

Is the access platform unhealthy, or is its identity dependency unhealthy?

If emergency identity is required, it needs to exist before the outage.

An untested break-glass mechanism invented during an incident is not a recovery strategy.

Failure domain 2: endpoint and posture

Posture is valuable because it allows policy to distinguish healthy managed devices from unknown ones.

It also creates another dependency.

A posture provider outage can deny perfectly healthy devices if policy fails closed.

The design therefore needs an explicit answer to:

What should happen when a posture signal is unavailable rather than negative?

A safe emergency approach is usually narrower than disabling posture globally.

For example:

• named managed devices
• named application
• named users
• explicit expiry
• retain all posture checks that still work

Failure domain 3: policy

A configuration error can look exactly like a platform outage.

This is especially common after:

• policy changes
• rule-order changes
• DNS changes
• route changes
• identity group updates

That means the first incident question should include:

What changed?

Good operational design keeps enough information to answer that quickly:

• policy IDs
• change records
• source-of-truth repository
• previous values
• rollback path
• audit logs

Failure domain 4: tunnel or connector

A specific site or private route failing is very different from a global service outage.

If only one application or private CIDR is unavailable, investigate the narrowest layer first:

• connector health
• outbound connectivity
• tunnel credentials
• route ownership
• overlapping routes
• origin reachability

Do not immediately create a broad bypass because one connector failed.

Failure domain 5: SaaS authentication

When Zero Trust is also part of SaaS SAML authentication, another decision tree appears.

If every SaaS integration fails, investigate common dependencies:

• identity provider
• access platform
• signing certificates
• global policy

If one application fails, investigate application-specific configuration:

• ACS URL
• entity ID
• signing certificate
• app policy
• vendor status

The scope of the failure is diagnostic evidence.

The golden rule: recover with the narrowest change

My preferred recovery hierarchy is:

No bypass
   ↓
Targeted policy fix
   ↓
Time-bound exception
   ↓
Alternative private path
   ↓
Application emergency login
   ↓
Broad bypass - last resort

This matters because emergency access can easily become worse than the original outage.

A broad bypass may restore availability while silently removing:

• identity enforcement
• posture checks
• logging
• network restrictions
• application controls

Availability has been restored, but the security architecture has disappeared.

Every exception needs an expiry

Emergency controls should be treated as temporary configuration with evidence.

At minimum record:

• incident ID
• approver
• affected users
• affected applications/routes
• exact policy change
• expiry time
• rollback owner
• validation evidence

A change with no expiry has a habit of becoming permanent.

Build recovery before you need it

A resilient Zero Trust architecture should already know:

Which applications are critical?

Not every service needs the same emergency-access design.

Which routes are critical?

Private access should have known ownership and connector redundancy where appropriate.

What happens if identity is unavailable?

If an alternative IdP or OTP path is part of the strategy, test it.

What happens if posture is unavailable?

Define fail-open/fail-closed behaviour deliberately.

How are SaaS administrators recovered?

Critical SaaS services may need app-native emergency administration that does not depend on the primary SSO chain.

Where is configuration evidence stored?

A dashboard outage should not prevent responders from knowing what was configured.

Test the failure paths

The normal path gets tested every day because users depend on it.

The emergency path can remain untouched for a year.

That is exactly why tabletop exercises matter.

Useful scenarios include:

• identity provider outage
• Zero Trust edge outage
• tunnel failure
• DNS policy error
• posture-provider failure
• SaaS SAML certificate rollover

A break-glass process that has never been exercised is a theory.

Zero Trust resilience is an architectural property

Zero Trust is often discussed as a set of controls:

• verify identity
• verify device
• apply least privilege
• continuously evaluate

Resilience belongs in that list.

The architecture should also be able to answer:

What is the smallest safe action that restores business access when one of those controls fails?

That question produces a much stronger design than simply adding a bypass rule for emergencies.

This article describes general resilience patterns. It intentionally excludes organisation-specific runbooks, application inventories, internal hostnames and production configuration details.