What is zero standing privileges (ZSP)?
By Identra · Updated
Zero standing privileges (ZSP) is a security model in which no identity holds permanent access rights. Every privilege is granted just in time for a specific task, scoped to that task, and revoked when it completes. Between tasks, accounts, workloads, and AI agents hold nothing an attacker can steal or abuse.
Key numbers
- 82:1 ratio of machine identities to human identities in organizations (CyberArk Identity Security Landscape, 2025)
- 1% of granted cloud permissions are actually used by identities (Microsoft State of Cloud Permissions Risks Report, 2023)
- 22% of breaches used stolen credentials as the initial access vector (Verizon Data Breach Investigations Report, 2025)
- 88% of basic web application attacks involved stolen credentials (Verizon Data Breach Investigations Report, 2025)
How is ZSP different from just-in-time access?
Just-in-time (JIT) access and zero standing privileges are related but not identical. JIT is a mechanism: a way to grant elevated access on demand for a limited window. ZSP is the end-state that mechanism can produce. An organization can run JIT workflows for a handful of admin accounts while thousands of other identities still carry permanent entitlements. That organization has JIT, but it does not have ZSP.
ZSP is achieved only when the default privilege level for every identity, human and non-human, is zero. There is no standing admin group, no service account with a permanent database role, no API key that works around the clock. Access exists only during the interval between a grant and its revocation. The distinction matters because attackers do not care how you grant access. They care what they can use when they land. Under partial JIT, the answer is still plenty. Under ZSP, the answer is nothing until something is actively requested and approved.
How does zero standing privileges work?
A ZSP system replaces permanent entitlements with a repeating lifecycle. The steps look the same whether the requester is an engineer, a CI pipeline, or an AI agent.
- Request: an identity asks for a specific permission on a specific resource, tied to a task or ticket.
- Evaluate: policy checks the requester, the target, the justification, and runtime context such as device posture or workload attestation.
- Grant: the system issues short-lived credentials or an ephemeral role binding, scoped as narrowly as the task allows.
- Monitor: activity during the grant window is logged and attributable to the requesting identity and task.
- Revoke: at task completion or timeout, whichever comes first, the grant is torn down and the credential is invalidated.
Why do standing privileges matter so much?
Standing privileges are the raw material of nearly every serious intrusion. The Verizon 2025 Data Breach Investigations Report found that stolen credentials were the initial access vector in 22% of breaches, and that 88% of attacks against basic web applications involved stolen credentials. A stolen credential is only as dangerous as the access it carries at the moment of theft. If that access is zero, the theft yields nothing.
The scale of unused access makes the case sharper. Microsoft's 2023 State of Cloud Permissions Risks report found that identities use just 1% of the permissions they are granted. The other 99% is dormant attack surface: entitlements nobody exercises, nobody reviews, and nobody misses until an attacker finds them. ZSP eliminates that dormant surface by construction rather than by periodic cleanup.
Standing privileges vs. zero standing privileges
| Dimension | Standing privileges | Zero standing privileges |
|---|---|---|
| Default access level | Whatever was granted historically | Zero |
| Credential lifetime | Months or years, often unrotated | Minutes to hours, single task |
| Value of a stolen credential | Full entitlement set, immediately | Nothing outside an active grant window |
| Access reviews | Periodic recertification campaigns | Largely unnecessary; grants expire on their own |
| Blast radius of compromise | Everything the identity can ever touch | Only the active task scope |
| Audit story | Who has access | Who used access, for what, and when |
What are the practical limits of ZSP?
Pure ZSP is an asymptote, not a switch. Break-glass accounts must exist for incidents when the grant pipeline itself is down, and those accounts are standing privilege by definition; the compensation is vaulting, alerting on any use, and rotation after use. Legacy systems that only understand static passwords or long-lived API keys cannot participate directly, so teams front them with brokers that hold the static secret and expose ephemeral access. Grant latency is a real cost: if provisioning takes minutes, on-call engineers will demand pre-approved fast paths, and each fast path is a small step back toward standing access.
There is also a discovery problem. You cannot remove standing privileges you do not know about, and most organizations discover OAuth grants, service accounts, and forgotten API keys long after they were created. ZSP programs succeed when they start with an inventory of what exists, then ratchet default access down domain by domain, rather than declaring zero on day one.
What does ZSP mean for AI agents and non-human identities?
Non-human identities are where ZSP shifts from good practice to structural necessity. CyberArk's 2025 Identity Security Landscape study found machine identities outnumber human identities 82 to 1, and 42% of machine identities have privileged or sensitive access. No recertification campaign reviews access at that ratio. The only model that scales is one where access does not persist in the first place.
AI agents strengthen the argument further. An agent's task list is not fixed at deployment time; it emerges from prompts, tool outputs, and delegation chains. Granting an agent standing access means provisioning for every task it might ever attempt, which is over-permissioning by design. Under ZSP, each agent action triggers its own scoped grant, evaluated against what the agent is doing right now. That also produces the audit trail agent incidents demand: not "this agent had database access," but "this agent was granted read access to this table for this task at this time, and the grant ended four minutes later."
How Identra thinks about it
Identra treats zero standing privileges as a runtime problem, not a provisioning problem. The hard part is not issuing short-lived credentials; it is knowing, at the moment of each request, which human, workload, or AI agent is asking, what task it is actually performing, and whether that task justifies the access. Identra builds the runtime identity context that makes per-task grant and revoke decisions trustworthy at machine speed, so ZSP can extend past human admins to the non-human majority of the identity population.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between zero standing privileges and zero trust?
Zero trust is a broad architecture principle: never trust by default, verify every request regardless of network location. Zero standing privileges is a specific access model that removes permanent entitlements, so identities hold nothing between approved tasks. ZSP is one of the strongest concrete implementations of zero trust for the authorization layer, but zero trust also spans networks, devices, and data.
Is zero standing privileges the same as just-in-time access?
They are related but not identical. JIT is the mechanism: granting access on demand for a limited window. ZSP is the end state where every identity's default privilege is zero. An organization can run JIT for a few admin accounts while thousands of identities keep permanent entitlements; that is JIT without ZSP. ZSP requires JIT applied universally.
Can you achieve 100% zero standing privileges?
In practice, no. Break-glass accounts must exist for emergencies when the grant pipeline itself fails, and they are standing privilege by definition; the compensation is vaulting, alerting on any use, and rotating afterward. Legacy systems that only understand static credentials need brokers. Mature programs treat ZSP as a ratchet, driving standing access toward zero domain by domain.
How do you implement zero standing privileges?
Start with an inventory of existing standing access, including service accounts, OAuth grants, and forgotten keys, because you cannot remove what you have not found. Convert the highest-risk tier first: cloud owner roles, domain admins, production databases. Replace static machine credentials with short-lived issuance, set expiry as the default on every grant, and monitor sessions during grant windows.