Why Zero Trust fails without availability

Zero Trust has become the dominant framework for enterprise security — and for good reason. By requiring continuous verification of every user, device and application, it eliminates the implicit trust that makes perimeter-based models so easy to exploit.

But there is a gap in how most organizations think about Zero Trust. The framework addresses who can access resources. It does not address whether those resources remain reachable in the first place. In practice, this means zero trust is highly dependent on the availability of identity providers, access gateways and policy enforcement points —  all of which must remain continuously reachable for the model to function.

That gap is where availability lives. And it is where DDoS attacks do their most effective work.

The assumption Zero Trust cannot afford to make

The NIST Zero Trust Architecture framework is defined in SP 800‑207 through a set of seven core tenets, rather than fixed “pillars.” However, these concepts are often simplified into four practical principles — identity verification, least privilege access, microsegmentation and continuous monitoring. Each of these depends on enforcement systems that are online and responsive.

Consider what happens when an employee attempts to access a business-critical application. Their identity must be verified. Their device posture must be assessed. Access policy must be evaluated and enforced. That sequence requires identity providers, secure access gateways and cloud security services to respond in real-time.

Zero Trust has no graceful fallback when those systems become unreachable. It cannot. Introducing an offline fallback would mean granting access without verification — which defeats the entire model. While some implementations define tightly controlled “break-glass” or emergency access policies for exceptional scenarios, these are deliberate, highly governed exceptions — not a standard fallback. The architecture is designed to be uncompromising, and that is its strength. But it also means availability is not optional. It is a prerequisite.

What a DDoS attack actually disrupts

A DDoS attack does not need to steal credentials or bypass access controls to cause serious damage. It only needs to make the systems that enforce those controls unreachable.

In practice, that looks like this: an application-layer attack targets an organization’s identity provider, flooding it with requests that appear legitimate until it can no longer respond to real ones. Authentication slows. Then it fails. Users cannot log in. Access to applications stops — not because anyone’s credentials were compromised, but because the system that validates those credentials is no longer functioning.

The business consequence is the same as a breach. Productivity stops. Customer-facing services degrade. Operations that depend on real-time access cannot proceed.

Modern DDoS attacks increasingly target exactly these systems — identity providers, APIs and secure access gateways — because attackers understand that disrupting availability is often faster and more effective than attempting to compromise access directly.

These attacks increasingly operate at the application layer (Layer 7), mimicking legitimate traffic patterns to evade traditional network defenses while overwhelming the services that zero trust relies on.

Why strong access controls are not enough

Organizations that have invested heavily in Zero Trust architecture sometimes treat DDoS risk as a secondary concern. The reasoning is understandable. If access is controlled, the thinking goes, the damage from any attack is limited.

That logic holds when the threat is unauthorized access. It does not hold when the threat is availability disruption.

An organization can have robust identity verification, tightly scoped least privilege access and comprehensive microsegmentation in place and still face complete operational disruption if a DDoS attack takes its enforcement infrastructure offline. The access controls remain intact. They are simply unreachable.

This is the fundamental gap. Zero Trust secures the path. DDoS protection ensures the path remains open.

Availability is a security outcome, not a network concern

The temptation is to treat availability as an infrastructure problem — something the network team handles separately from security strategy. That separation made sense when security and networking were genuinely distinct disciplines. It does not make sense in environments where identity providers and access gateways are the security infrastructure.

When those systems go down, security goes down with them. Availability is not a precondition for security. It is part of what security means in a Zero Trust environment.

Organizations building or maturing a Zero Trust strategy need to account for this explicitly. That means evaluating DDoS protection not as a standalone network defense but as a component of the same architecture that governs access, enforcement and monitoring.

A Zero Trust model that does not account for availability is not complete. It is a framework that works well under normal conditions and fails precisely when conditions are not normal — which is when security matters most.

Addressing this requires integrating DDoS protection into the same edge-delivered architecture as Zero Trust enforcement, ensuring that identity systems and access gateways remain both protected and reachable under attack conditions.

For a broader view of how Zero Trust, SASE and availability protection work together as a unified security framework, see our SASE guide.