What is the difference between ZTNA and zero standing privilege?

Why This Matters for Security Teams

ZTNA and zero standing privilege solve different problems, and teams that treat them as substitutes usually leave a gap between network access control and entitlement control. ZTNA is about who can reach a resource during a session, while ZSP is about whether any persistent privilege exists before that session starts. That distinction matters most for non-human identities, where service accounts, API keys, and automation often accumulate access over time.

NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is why session-level controls alone do not remove the standing authority that attackers target first. The Ultimate Guide to NHIs also highlights that many organisations still lack full visibility into service accounts, making hidden privilege a persistent risk. On the architecture side, NIST SP 800-207 Zero Trust Architecture frames access as continuously evaluated and explicitly granted, but it does not, by itself, remove dormant entitlement.

In practice, many security teams discover the difference only after a compromised account is able to authenticate cleanly through ZTNA while still retaining excessive backend rights that were never stripped away.

How It Works in Practice

ZTNA and ZSP should be designed as complementary controls. ZTNA establishes a policy decision at connection time and can limit what a user or workload can reach, often by verifying device state, identity signals, and context before brokering access. ZSP, by contrast, removes always-on privilege and makes elevated access ephemeral, so the identity has no standing authority unless it is explicitly approved for a task.

For human admins, that often means JIT elevation through PAM workflows. For NHIs, it usually means replacing static secrets and broad roles with short-lived credentials, scoped tokens, and workload identity patterns such as SPIFFE and SPIRE. The Guide to SPIFFE and SPIRE is useful here because it shows how cryptographic workload identity can support stronger assurance than a long-lived API key. The OWASP Non-Human Identity Top 10 also underscores how overprivileged machine identities, secret sprawl, and poor lifecycle control amplify blast radius.

• Use ZTNA to gate session access and enforce context-aware policy at the connection layer.
• Use ZSP to ensure no account, token, or service identity retains permanent elevated rights.
• Issue short-lived credentials for the minimum task window, then revoke them automatically.
• Bind workload identity to the workload itself, not to a reusable shared secret.

That model works best when policy is evaluated in real time and entitlement is continuously reduced, not merely hidden behind a proxy. These controls tend to break down in legacy environments where shared service accounts, hard-coded secrets, or long-running batch jobs require persistent access that cannot yet be safely decomposed.

Common Variations and Edge Cases

Tighter privilege controls often increase operational overhead, so organisations have to balance speed of automation against the cost of more frequent approval and credential renewal. Best practice is evolving, but there is no universal standard for mapping every ZTNA policy to a ZSP model, especially when agents, pipelines, and third-party integrations all depend on different trust boundaries.

One common edge case is a workload that needs uninterrupted connectivity but not uninterrupted privilege. In that situation, ZTNA may keep the network path open while ZSP still removes admin rights except during a narrow execution window. Another is service-to-service traffic where teams assume mTLS or network segmentation is enough. It is not, if the underlying identity still has standing access to production secrets or control-plane actions. The Ultimate Guide to NHIs and the What are Non-Human Identities section are useful reminders that entitlement, lifecycle, and visibility problems often matter more than the access path itself.

Current guidance suggests treating ZTNA as a perimeter replacement and ZSP as an entitlement minimisation strategy. They intersect, but they are not interchangeable, and teams that conflate them usually end up with stronger session control but the same standing privilege underneath.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between zero trust for users and zero trust for NHIs?
• What is the difference between JIT access and Zero Trust for NHIs?