Zero trust vs defence in depth for identity governance

At a glance

What this is: This is a comparison of Zero Trust and Defense in Depth that argues continuous verification reduces identity attack surface more effectively than layered perimeter-style protection.

Why it matters: It matters because IAM, NHI, and human identity programmes all fail when trust decisions are made once and left to age, instead of being continuously re-evaluated.

👉 Read Axiad's comparison of Zero Trust and Defense in Depth for identity security

Context

Zero Trust and Defense in Depth are both attempts to reduce breach impact, but they start from different assumptions about trust. Zero Trust treats every identity and device as needing continuous verification, which makes it a stronger fit for environments where access is dynamic and identity is the real control plane, including human access, service accounts, and automated workloads.

Defense in Depth still has value as a layered protection strategy, but it can create gaps when teams mistake stacked controls for continuous identity assurance. For IAM programmes, the practical question is not whether layers exist, but whether identity, privilege, and session state are rechecked often enough to reflect how access actually changes.

The result is a governance problem as much as a security architecture problem. If access decisions are made once at the perimeter, the programme is implicitly assuming that identity context stays stable, which is increasingly untrue across cloud, SaaS, and non-human identity estates.

Key questions

Q: How should security teams choose between Zero Trust and Defense in Depth for identity governance?

A: Use Zero Trust when the main risk is stale trust, lateral movement, or identity-driven access across cloud and SaaS systems. Defense in Depth still helps with containment, but it should not be the primary governance model if identities change frequently. The deciding factor is whether your controls continuously verify identity state or only stack barriers around it.

Q: Why do service accounts and API keys weaken Defense in Depth models?

A: Service accounts and API keys weaken Defense in Depth when they retain access long after the original approval point. Layered controls may still exist, but persistent machine credentials can move through those layers without fresh verification. That makes the real problem standing privilege, not the number of defenses around it.

Q: What do security teams get wrong about Zero Trust in practice?

A: Teams often treat Zero Trust as a network design project instead of an identity governance model. If continuous verification is not applied to users, workloads, and secrets, then the environment still relies on one-time trust decisions. The result is Zero Trust branding without Zero Trust behavior.

Q: Who is accountable when layered security fails but identity trust was never rechecked?

A: Accountability sits with the teams that own identity policy, access governance, and runtime verification, not only with perimeter defenders. When trust is granted once and never reassessed, the failure is architectural as well as operational. Frameworks such as NIST CSF and Zero Trust governance make that shared responsibility explicit.

Technical breakdown

Continuous verification in Zero Trust

Zero Trust is built on the idea that trust is never permanent. Every request is evaluated using identity, device posture, context, and policy before access is granted or renewed. In practice, this shifts security from network location to identity state, which matters because a valid login, service token, or device does not remain trustworthy forever. For human users, that means re-authentication and policy checks. For NHIs, it means access scope, secret validity, and runtime context must stay bounded, not merely approved once.

Practical implication: design access controls that re-evaluate identity context at each decision point, not only at sign-in.

Defense in Depth and layered control failure

Defense in Depth adds multiple barriers, but those barriers are often independent and unevenly maintained. That means an attacker who gets past one layer may still find stale credentials, broad entitlements, or weak internal segmentation behind it. The model can reduce blast radius, but it can also mask the fact that identity governance is not being actively enforced across every layer. For IAM teams, the issue is less the number of controls and more whether those controls share a common identity signal.

Practical implication: map identity controls across layers and verify that they enforce the same privilege and verification logic.

Identity attack surface versus perimeter confidence

The key architectural difference is that Zero Trust reduces reliance on perimeter confidence, while Defense in Depth can still allow trust to accumulate inside the environment. That matters in cloud and SaaS estates where internal traffic is no longer inherently safer than external traffic. If service accounts, APIs, and users can move laterally after a single successful check, then the organisation has layered defenses but not identity containment. The security model is only as strong as the weakest identity path.

Practical implication: measure whether lateral movement is still possible after first access, then tighten identity-based containment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust works because it rejects the core assumption that identity can be trusted after a single approval. Defense in Depth often assumes that enough layers will compensate for a one-time trust decision, but that assumption breaks when identity context changes continuously across cloud, SaaS, and machine access. The implication is that identity governance must be treated as a runtime discipline, not a perimeter event.

Defense in Depth can create control density without identity certainty. Multiple layers may look resilient, yet they can still leave stale entitlements, overbroad roles, and unmanaged secrets untouched behind the outer shell. That makes the programme appear mature while leaving the identity attack surface largely intact. Practitioners should judge the architecture by whether it constrains identity, not by how many products sit in front of it.

Zero Trust is now the more coherent model for non-human identity governance. Service accounts, API keys, and tokens do not benefit from human-centric trust assumptions or network location heuristics. The governance problem is not just access, but how quickly identity state can be re-evaluated when the actor is a machine rather than a person. IAM teams should align policy, session control, and secret lifecycle around that reality.

Identity blast radius is the better metric than security layer count. A stack of controls can still permit broad internal movement if privilege remains standing after first access. A Zero Trust model narrows that blast radius by forcing continuous checks, while Defense in Depth often relies on deterrence and containment after the fact. Practitioners should reframe success around how far one compromised identity can travel.

Access decisions designed for stable sessions become unreliable in dynamic identity environments. This is where human IAM, NHI governance, and broader Zero Trust strategy converge: the same trust model cannot be assumed to work equally well across all actor types. The implication is that teams must govern access as a changing state, not a fixed entitlement.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves most machine identities outside effective governance.
• For a deeper control baseline, review Guide to SPIFFE and SPIRE for workload identity patterns that fit continuous verification models.

What this signals

Identity programmes that still rely on perimeter confidence will keep missing the real blast radius. Zero Trust is not simply a tighter version of layered defense. It is a different operating assumption, and that assumption becomes more valuable as human, machine, and service identities share the same environment.

Identity blast radius is the concept teams should operationalise next. If one identity can still move widely after first access, the architecture is still carrying Defense in Depth habits even if the documentation says Zero Trust. That gap shows up fastest in NHIs, where standing credentials and broad entitlements are still common.

The programme signal to watch is whether policies re-evaluate access at runtime across users, workloads, and secrets. That is where the model stops being a security slogan and starts changing how identity governance is actually enforced.

For practitioners

• Inventory where trust is granted once Map every place where access is approved at entry and then left unchanged, including SSO sessions, service account permissions, API tokens, and internal network trust zones. Prioritise the paths that allow lateral movement after first access.
• Unify identity signals across control layers Tie authentication, authorisation, device posture, and secret lifecycle into one policy model so that layered defenses do not drift apart. The goal is a consistent decision path for users, workloads, and automated identities.
• Reduce standing privilege before expanding layers Cut persistent access that survives beyond the task or session, then verify that segmentation and monitoring are enforcing the reduced privilege model. Without that step, more layers only create more places for stale access to hide.
• Measure containment by identity blast radius Test how far one compromised identity can move before it hits a hard stop, not how many security products the environment contains. Use that result to decide whether the current model is truly zero trust or only layered defense.

Key takeaways

• Zero Trust and Defense in Depth are not interchangeable because only one model assumes trust must be continuously revalidated.
• The practical risk is not the number of security layers, but whether identity governance still allows broad movement after first access.
• IAM teams should measure identity blast radius and standing privilege before claiming a Zero Trust posture.

Key terms

• Zero Trust: A security model that assumes no identity or device should be trusted by default. Access is granted only after continuous verification of identity, context, and policy, which makes it especially relevant where users, workloads, and machine identities share the same control plane.
• Defense in Depth: A security strategy that uses multiple layers of controls to make compromise harder and reduce blast radius. It can improve resilience, but it does not guarantee identity certainty if access is approved once and then allowed to persist without re-evaluation.
• Identity Blast Radius: The amount of access, movement, and downstream impact a single identity can create if compromised. In mature governance, it is constrained by continuous verification, least privilege, and lifecycle controls rather than by the sheer number of security tools deployed.
• Standing Privilege: Persistent access that remains available beyond the immediate task or session. In identity programmes, it is one of the clearest signs that the environment still depends on trust granted at setup time instead of trust rechecked at runtime.

Deepen your knowledge

Zero Trust identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still depends on layered trust rather than continuous verification, it is worth exploring.

This post draws on content published by Axiad: Zero Trust vs. Defense in Depth: What's the Difference? Read the original.