What is zero standing privilege, why do least privilege programs still leave standing risk, and what does a realistic path to ZSP look like? A practical guide.
Most organizations that claim to enforce least privilege still carry an enormous amount of standing risk. The access reviews pass. The role definitions are reasonable. Every admin who holds elevated access can point to a legitimate reason they were granted it.
And yet: the database admin's credentials work at 3 a.m. on a Sunday, when no change window is open. The former project lead still has write access to the production environment she hasn't touched since the project shipped. The finance system admin role has been active, continuously, for four years, though it gets used maybe six hours a month.
None of this violates least privilege as most organizations practice it. All of it is exploitable.
Zero standing privilege (ZSP) is the security model that closes this gap. Instead of asking "does this user need this access for their role," ZSP asks a harder question: "does this user need this access right now?" If the answer is no, the access shouldn't exist. Not dormant, not unused, not waiting. Gone, until the moment it's needed again.
This guide covers what zero standing privilege is, why standing privileges persist even in well-run least privilege programs, how ZSP relates to least privilege and just in time access, and what a realistic path to ZSP looks like.
What Is Zero Standing Privilege?
Zero standing privilege is a security model in which no user, application, or system holds permanent elevated access to any resource. Elevated permissions exist only during the specific windows when they're actively needed, and they're provisioned on demand and revoked automatically when the need ends.
The term was coined by Gartner analyst Ben Hertzberg in the context of privileged access management, and the definition is deliberately absolute. ZSP is not "less standing privilege" or "reviewed standing privilege." It's the elimination of the category. In a true ZSP environment, an attacker who compromises any account at a random moment finds exactly zero elevated permissions attached to it, because elevated permissions only materialize when a verified user requests them for a specific, approved, time-limited purpose. It's the assume-breach principle of zero trust carried to its logical conclusion for privileged access.
In practice, ZSP is a target state rather than a binary switch. Organizations move toward it incrementally, starting with the highest-risk systems. But the direction matters: every standing privilege eliminated is a permanent reduction in attack surface, not a temporary one.
Why Standing Privileges Persist
If standing privileges are this dangerous, why does every organization have them? Because access is granted at moments of need and forgotten at moments of completion, and the two are structurally asymmetric.
Granting access has a forcing function: the person needs it, the work is blocked, someone escalates. Revoking access has none. The project ends quietly. The role changes gradually. The contractor's engagement winds down without a ticket. Nothing breaks when unused access persists, so nothing prompts its removal.
The result is access debt: the accumulated gap between what users currently need and what they still hold. Access debt compounds over time and across systems, and it produces a privilege footprint that bears little resemblance to what any access policy would design from scratch.
Standing privileges also persist for defensible operational reasons. Admins keep permanent elevated access because requesting it repeatedly is friction. Shared privileged accounts survive because rotating them is work. Third-party access outlives its purpose because nobody owns the offboarding. Each individual decision is reasonable. The aggregate is a standing attack surface that grows monotonically.
The Risk Model: What Standing Privileges Actually Cost
Credential compromise inherits the full privilege footprint. When an attacker phishes or steals credentials, they acquire everything attached to that account, at that moment. A standing admin credential is a standing offer to any attacker who obtains it. This is why privileged accounts command premium prices in credential markets: the access is guaranteed to be there.
Lateral movement runs on standing access. Attackers rarely land on the system they want. They land somewhere, then move. Every account with standing elevated access is a potential pivot point, and the density of standing privileges across an organization determines how far a single compromise can spread. Reducing standing privileges doesn't prevent the initial compromise; it strands the attacker in a low-privilege account with nowhere to go.
Insider misuse hides inside normal. When elevated access is permanently active, privileged activity is indistinguishable from background noise. There's no anomaly to detect, because the access being used is access the user always has. When elevated access only exists inside approved windows, misuse becomes visible by definition: privileged activity outside a window is an alert, not an ambiguity.
Audits become reconstruction projects. SOC 2, ISO 27001, SOX ITGC, PCI DSS, and HIPAA all require demonstrating that access to sensitive systems is controlled and justified. In standing privilege environments, answering "who could access this system in Q3 and why" means reconstructing history from records never designed for the question. In a ZSP environment, the answer is a query: every access grant was an explicit, logged, time-bounded event.
ZSP vs Least Privilege: Different Questions
Zero standing privilege is often described as an extension of the principle of least privilege, which is roughly right but blurs the important distinction. The two principles constrain different dimensions of access.
Least privilege governs scope: how much access a user holds. It asks whether the permissions attached to a role match the role's actual requirements, and it fails when roles are over-provisioned or when access accumulates beyond the role.
Zero standing privilege governs duration: whether access persists between uses. It accepts that a user legitimately needs elevated access for certain tasks, and then asks why that access exists during the 95% of the time the user isn't performing those tasks.
The distinction matters because a perfect least privilege program still leaves standing risk. A database admin whose role genuinely requires database admin rights passes every least privilege review, and their standing credential remains a permanent target. Least privilege answers "is this the right amount of access." ZSP answers "should this access exist right now." Mature access programs need both: least privilege to scope what's grantable, ZSP to ensure it's only granted while in use.
ZSP vs JIT Access: Target State vs Mechanism
The relationship between zero standing privilege and just in time access is the relationship between a destination and the vehicle that gets you there.
ZSP is the target state: no permanent elevated access anywhere. JIT access is the operating mechanism that makes the target state livable: elevated permissions granted on demand, scoped to the task, and revoked automatically when the window closes. Without JIT mechanics, ZSP is unworkable, because every legitimate need for elevated access would become a manual provisioning event. With JIT mechanics, eliminating standing privileges stops being a productivity tax and becomes a background property of how access works.
The three JIT models map to different points on the ZSP spectrum: justification-based access with vaulted credentials, ephemeral accounts that are created for a session and deleted after it, and temporary elevation of existing accounts. Ephemeral accounts are the purest ZSP implementation, most common for infrastructure. Temporary elevation is the most practical model at the SaaS application layer. For the full breakdown of how each model works and how to implement them, see our guide to just in time access.
A Realistic Path to Zero Standing Privilege
1. Inventory what's standing. You can't eliminate what you can't see. Start with a complete map of elevated access across systems: who holds admin roles, elevated licenses, and privileged permissions, in which applications, and when that access was last actually used. The gap between held and used is your access debt, and it's usually the fastest risk reduction available: standing privileges that are never used can be revoked outright, no JIT machinery required.
2. Classify by risk, sequence by exposure. Full ZSP everywhere on day one is neither realistic nor necessary. Rank systems by the blast radius of a compromised admin credential: production infrastructure, financial systems, customer data stores, and identity providers first. Apply ZSP where standing credentials are most dangerous, and expand outward.
3. Replace standing grants with policy-based, time-bound access. For each system in scope, define who is eligible for which elevated permissions, under what conditions, and for how long. Pre-approved policies handle routine, low-risk elevation automatically; human approval gates the sensitive cases. The policy layer is what separates ZSP from an approval bottleneck.
4. Make revocation structural, not procedural. The defining failure of manual access management is that revocation depends on someone remembering. Every elevated grant must carry an expiry that the system enforces. If revocation requires a human action, standing privileges will re-accumulate; the asymmetry that created access debt in the first place hasn't gone anywhere.
5. Review continuously for drift. ZSP environments drift too: new systems get onboarded with default admin accounts, integrations request broad scopes, exceptions get granted and forgotten. Periodic access reviews shift from being the primary control to being the verification layer that confirms standing privileges aren't quietly returning.
Two Ways ZSP Implementations Fail
Friction that users route around. If requesting elevated access is slow, users will find ways to keep it: shared credentials, over-broad service accounts, "temporary" exceptions that never expire. A ZSP program that ignores workflow reality produces shadow standing privilege, which is worse than the visible kind because it's unmanaged. The fix is meeting users where they work: access requests through Slack or a self-serve catalog, auto-approval for policy-matched scenarios, and elevation that takes seconds rather than tickets.
Static credentials that outlive the session. Time-bound access built on long-lived passwords or API tokens is time-bound in name only. If the credential released for a two-hour window still works after the window closes, the standing privilege never actually left. Short-lived certificates, rotated secrets, and session-scoped tokens are what make expiry real. This applies doubly to non-human identities, where static API keys are the most common form of invisible standing privilege in modern environments.
Zero Standing Privilege at the SaaS Layer
ZSP originated in infrastructure PAM, where the standing credentials in question were root accounts and database passwords. But the same access debt dynamics now play out across the SaaS layer, at larger scale and with less visibility: admin roles in dozens of applications, elevated license tiers that were needed once, integration scopes granted broadly and never revisited.
Zluri drives this layer toward zero through four mechanisms working as a continuous loop.
It measures how much standing privilege exists. Zluri's Optimization categories function as a live standing-privilege inventory: Unassigned licenses (capacity nobody uses), Undeprovisioned licenses (access still attached to departed users, the clearest ZSP violation there is), and Unused and Underused licenses (grants that exist but aren't exercised enough to justify persisting).
It eliminates what's no longer justified. Orphaned Access and Dormant Account detection identify standing grants with zero remaining justification, and Optimization Playbooks execute the removal, including the consent-first Request to Forego flow that confirms with the employee before revoking rather than silently pulling access.
It converts new grants to time-boxed by default. The Access Duration field on Access Requests, paired with an automatically executing Deprovisioning Playbook, means a new grant expires on its own instead of becoming the next permanent standing entry. That is the ZSP principle applied at the point of grant rather than only during cleanup.
It contains what has to remain. Some standing access is operationally necessary, and Segregation of Duties ensures whatever remains doesn't combine on any single identity into a toxic combination, capping the damage of the standing privilege that can't be removed.
The same scoring, elimination, and conversion mechanics apply identically to service accounts and integration tokens via Service Account Exposure, which matters because non-human identities are where standing privilege concentrates most and gets reviewed least. For the full mechanism-by-mechanism breakdown, including the honest boundary where ephemeral credential issuance remains a PAM vault's job, see how Zluri helps with zero standing privilege.
Frequently Asked Questions
What is zero standing privilege?
Zero standing privilege is a security model in which no user, application, or system holds permanent elevated access. Elevated permissions are provisioned on demand for specific, approved, time-limited purposes and revoked automatically when the window closes. The goal is that a compromised account, at any random moment, carries no exploitable elevated access.
What is the difference between zero standing privilege and least privilege?
Least privilege governs the scope of access: users should hold only the permissions their role requires. Zero standing privilege governs the duration: even role-appropriate elevated access shouldn't persist between uses. A least privilege program can pass every review while leaving standing admin credentials exposed around the clock. The two are complementary: least privilege defines what's grantable, ZSP ensures it's only granted while in use.
Is zero standing privilege the same as just in time access?
No, but they're inseparable. ZSP is the target state (no permanent elevated access), and JIT access is the mechanism that makes it operational (on-demand, time-bound grants with automatic revocation). ZSP without JIT mechanics is an unworkable policy; JIT without a ZSP goal is just faster provisioning.
Is 100% zero standing privilege realistic?
For most organizations, ZSP is a direction rather than an absolute. Some standing access is deliberately retained, most notably break glass accounts for emergencies when normal access paths fail. The practical goal is eliminating standing privileges everywhere the risk justifies it, starting with the systems where a compromised admin credential does the most damage, while keeping the remaining exceptions explicit, minimal, and monitored.
Does zero standing privilege apply to non-human identities?
Yes, and it's often where the largest standing risk hides. Service accounts, API keys, and integration tokens are typically provisioned with broad scopes and no expiry, making them permanent standing privileges that no access review catches. Applying ZSP to non-human identities means short-lived credentials, scoped tokens, and the same grant-and-expire discipline applied to human access.
.svg)
