What should teams do when Zero Trust is harder to run than defense in depth?

Why Zero Trust Should Be Measured Against Blast Radius, Not Dogma

When zero trust is harder to run than defense in depth, the practical question is not whether to “be more Zero Trust” at any cost. It is where tighter trust decisions will reduce the most exposure first. That usually means concentrating on identities and paths that can reach the most sensitive systems, then shrinking inherited trust so each decision is based on current context rather than old assumptions.

A useful way to think about the trade-off is that defense in depth can still be safer than an overextended Zero Trust program if the latter creates brittle exceptions, hidden bypasses, or unmaintainable policy sprawl. The goal is not a perfect architecture diagram, it is a control model that actually changes who can reach what, under what conditions, and with what auditability.

For workload and service access, that often means treating the identity layer as the first boundary to harden. NHIMG’s Guide to SPIFFE and SPIRE is a good reference point for reducing ambient trust in service-to-service paths, while Ultimate Guide to NHIs — Standards shows how Zero Trust ideas connect to identity governance and controls for machine access.

Where Teams Usually Start Getting Real Security Value

The first rollout step should target the access paths that create the largest blast radius, not the easiest systems to modernise. Privileged users, service accounts, shared integration identities, and high-value applications are the places where a single trust decision can amplify into broad compromise, so they are the best candidates for earlier policy enforcement and stronger verification.

That also means reducing trust inheritance between layers. If a user, workload, or application is already authenticated once, do not let that fact automatically justify every later request. The stronger pattern is to re-evaluate access by request, resource, device, and session state, especially where the action is sensitive or the destination is production-grade.

Zero Trust Identity Guide is useful here because it frames the phased move from perimeter-style trust to identity-centric policy. For teams that need the IAM building blocks first, IAM and IGA Basics helps separate authentication, authorization, provisioning, and review so the rollout does not collapse into vague “least privilege” language.

What Good Looks Like When Zero Trust Is the Slower Path

Good practice is not “complete” Zero Trust on paper, it is narrower trust with fewer inherited privileges and fewer silent exceptions. A slower program is acceptable when it produces contextual decisions that are actually enforced, because a partially deployed control that is consistent is often safer than a broad policy that is routinely bypassed.

Teams should expect the strongest benefits where they can measure reduced standing access, shorter credential exposure windows, fewer cross-environment privileges, and better traceability on high-risk actions. In this model, the architecture is progressing if an attacker who compromises one account or one service cannot automatically reuse that trust across adjacent systems.

Zero Trust for AI Agents is a useful adjacent example of the same principle: verify the principal, remove standing privilege, and enforce policy per action. Even where the environment is not agentic, the control lesson is the same, trust should be temporary, contextual, and bounded.

Risk and Threat Considerations

The main risk in an overly ambitious Zero Trust rollout is that teams create complexity faster than they remove exposure. That often leaves inherited trust in place, but wrapped in more policy layers, more exceptions, and more brittle integrations, which can make the environment harder to operate while preserving the same attack paths.

Failure mechanism: Broad, inconsistent policy rollout encourages bypasses, emergency exceptions, and shadow trust paths, especially around privileged access and service-to-service flows. Attackers then benefit from the remaining high-value identities and from any place where old trust assumptions still grant broad reach.

Impact: The organisation ends up with a control surface that is expensive to maintain and still vulnerable to lateral movement, privilege abuse, and blast-radius expansion if one strong identity or application is compromised.

Practitioner Guidance

What to prioritise: Start with the identities and applications that can touch the most sensitive data or control planes. If a control change cannot be applied there without creating unacceptable operational risk, it probably belongs in a phased rollout, not a blanket mandate.

What to verify: Confirm that each policy change removes an actual trust shortcut, not just another approval step. If access can still be inherited from a previous check, the control is probably adding friction more than reducing risk.

Practitioner takeaway: The right trade-off is not Zero Trust versus defense in depth, it is whether your first Zero Trust moves reduce blast radius in ways you can sustain under real operational pressure.

Related resources from NHI Mgmt Group

• How should security teams choose between Zero Trust and Defense in Depth for identity governance?
• How should security teams run access reviews for non-human identities?
• How should defense teams implement zero trust in complex government environments without creating blind spots?
• What is the difference between Zero Trust and defense-in-depth in cloud security architecture?