Zero trust security explained for identity governance and access

At a glance

What this is: This is a zero trust explainer that argues continuous verification matters most when access is treated as an identity governance problem, not just a network design pattern.

Why it matters: It matters because IAM teams have to apply zero trust consistently across human users, service accounts, and emerging autonomous actors, or risk leaving the highest-risk access paths outside governance.

👉 Read Netwrix's zero trust security explainer and access model overview

Context

Zero trust is the idea that no request should be trusted by default, even if it originates inside the environment. For identity teams, that shifts the model from perimeter defence to continuous access evaluation across users, service accounts, and machine identities.

The practical problem is that many organisations still describe zero trust as a network architecture while leaving identity lifecycle, privileged access, and secrets governance under separate programmes. That split creates gaps in enforcement, especially where NHI credentials and delegated access behave differently from human logins.

For a deeper standards lens on the access side of this model, see the Ultimate Guide to NHIs - Standards and the NIST SP 800-207 Zero Trust Architecture framework.

Key questions

Q: How should security teams implement zero trust across human and non-human identities?

A: Start by aligning access policy, entitlement review, and session verification across both human users and non-human identities. Then separate transport controls from identity controls so certificate, token, and privileged access governance are reviewed as part of the same operating model. The goal is consistent trust evaluation, not a single tool.

Q: Why do service accounts complicate zero trust programmes?

A: Service accounts complicate zero trust because their access often persists long after the original task or deployment need has changed. That makes standing privilege, credential sprawl, and weak offboarding the real risk drivers. Zero trust only improves security when those identities are treated as governed subjects, not background infrastructure.

Q: What do security teams get wrong about zero trust and network access?

A: Teams often assume that if network access is mediated, the identity problem is solved. In reality, ZTNA only controls reachability. It does not handle credential rotation, entitlement lifecycle, or whether an identity should still exist with the same permissions after deployment, staffing, or vendor changes.

Q: How do you know if zero trust is actually working?

A: Look for evidence that access is continually re-evaluated and that standing privilege is shrinking across users, service accounts, and privileged roles. If entitlements remain broad, long-lived, or hard to map to ownership, the programme is behaving like perimeter control with modern branding rather than true zero trust.

Technical breakdown

Zero trust architecture and identity verification

Zero trust architecture assumes the environment is already exposed and therefore requires each access request to be evaluated on context, identity, and policy. In practice, that means authentication alone is not enough. The system must also check device state, session risk, entitlement scope, and whether the request matches the subject's expected behaviour. For NHI, the challenge is sharper because credentials often authenticate a workload without proving whether that workload should still retain the same access path. Zero trust becomes fragile when identity evidence is static but access decisions need to be dynamic.

Practical implication: bind access policy to runtime context, not just successful authentication.

Least privilege and just-in-time access in practice

Least privilege in zero trust is not a slogan. It is the requirement that access be narrow, time-bound, and specific to the task being performed. Just-in-time access supports that by issuing privileges only when needed and revoking them when the session ends. This works best when the identity subject is stable and the task is known in advance. It is harder for service accounts and automation because standing permissions often persist long after the original use case. Zero trust fails when privilege review happens less often than privilege use.

Practical implication: map high-risk entitlements to JIT workflows and remove standing privilege wherever possible.

Zero trust network access versus broader governance

Zero trust network access, or ZTNA, controls who can reach an application, but it does not by itself govern the full identity lifecycle behind that access. A tunnel that only opens after policy checks still leaves questions about credential rotation, offboarding, certificate expiry, and access recertification. That distinction matters because many teams confuse network-level denial with governance maturity. For NHIs, the real control plane is broader than transport. It includes secrets, tokens, workload identity, and how those identities are created, reviewed, and retired.

Practical implication: treat ZTNA as one control layer and align it with lifecycle and secrets governance.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 only works as an identity model when access is continuously re-evaluated at the point of use. The architecture is often described as a network stance, but the real control boundary is identity, privilege, and context. If the request is not rechecked at the moment it matters, then the programme is still relying on trust by default. Practitioners should treat zero trust as an enforcement model for identities, not a label for segmentation.

Standing privilege is the assumption zero trust is meant to break. Persistent access was designed for stable users and predictable tasks. That assumption fails when service accounts, tokens, and workload identities retain access beyond the exact business need that created them. The implication is that lifecycle governance and privilege governance cannot be separate streams in a zero trust programme.

Zero trust creates the sharpest value when it forces IAM, PAM, and NHI governance into one operating model. Human authentication, workload credentials, and privileged entitlements all need the same trust challenge, even if the controls differ. When teams run these programmes separately, they create policy islands that attackers can route around. Practitioners should collapse the governance silos around access rather than add another layer of policy language.

Identity blast radius: the amount of damage a compromised account can do before trust is re-evaluated is the right zero trust metric for modern environments. The concept is useful because it captures both duration and scope of exposure, which are more actionable than broad maturity labels. Teams that cannot measure blast radius are usually measuring architecture, not governance. Practitioners should use this as a design lens for both human and non-human access.

Zero trust also exposes whether an organisation is ready for autonomous behaviour. If an identity can decide, select tools, and act without human approval, then the traditional assumption that access is externally initiated no longer holds. That does not just create a new control gap. It collapses the premise that least privilege can be fully defined at provisioning time. Practitioners should use zero trust to expose where their model depends on human-paced decision loops.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader identity lifecycle lens, the Ultimate Guide to NHIs , What are Non-Human Identities helps teams map service accounts, API keys, tokens, certificates, and workload identities into a single governance view.

What this signals

Zero trust adoption is likely to move from network design into identity operating models as teams realise that access reviews, privilege boundaries, and credential lifecycle control are the real enforcement points. The organisations that will progress fastest are those that treat NHI governance as part of the same trust framework as human access.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the next zero trust gap is not connectivity but delegated trust. That makes lifecycle ownership and entitlement traceability central to future programme maturity.

For practitioners

• Recast zero trust as an identity governance programme Anchor the operating model in authentication, entitlement review, secrets rotation, and privileged session control rather than network segmentation alone.
• Inventory standing privilege across human and non-human identities Identify service accounts, tokens, certificates, and delegated admin roles that persist outside task windows, then classify them by blast radius and offboarding risk.
• Apply just-in-time access to high-risk access paths Use task-scoped elevation for privileged human access and replace persistent machine entitlements with narrow, time-bound approvals where workflow supports it.
• Tie recertification to runtime evidence Review access based on actual use, service ownership, and credential age so recertification reflects lived entitlement patterns instead of stale role mappings.

Key takeaways

• Zero trust is an identity governance discipline, not just a network control pattern.
• Standing privilege and weak lifecycle control are the main reasons zero trust programmes fail to reduce real access risk.
• Teams need one operating model for human, non-human, and privileged access if they want zero trust to work as intended.

Key terms

• Zero Trust Architecture: A security model that assumes no requester should be trusted by location alone. Access is granted only after policy, identity, and context are evaluated at the moment of the request, which makes it a governance model as much as a network design pattern.
• Standing Privilege: Access that remains active beyond the immediate task or business need that created it. In practice, standing privilege increases blast radius because the identity can be reused, abused, or forgotten long after the original approval was valid.
• Just-in-Time Access: A privilege model that issues access only when a specific task requires it and removes it when the task ends. For non-human identities, the value depends on whether the entitlement can be tied to a clear owner, purpose, and expiry condition.
• Identity Blast Radius: The amount of damage a compromised identity can cause before the organisation re-evaluates trust. It combines scope, duration, and privilege depth, making it a practical way to compare human accounts, service accounts, and delegated access paths.

Deepen your knowledge

Zero trust security, NHI governance, and access lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are turning zero trust from a network idea into an identity operating model, it is worth exploring.

This post draws on content published by Netwrix: Zero trust security explained: why "never trust, always verify" matters. Read the original.