Zero Standing Privilege

Expanded Definition

Zero Standing Privilege describes an access model where a Non-Human Identity has no persistent permissions by default and receives access only for the exact task it is performing. In NHI security, this is closely related to OWASP Non-Human Identity Top 10 guidance on reducing unnecessary access, although usage in the industry is still evolving and definitions vary across vendors.

For service accounts, API keys, workload identities, and AI agents, ZSP is the practical opposite of broad standing entitlements. It works best when paired with short-lived credentials, strong identity governance, and just-enough access decisions that expire automatically. The control goal is not just to restrict what an identity can do, but to ensure access exists only during an authorized execution window. That matters because persistent privileges tend to outlive the task, the operator, and sometimes the system that created them.

For experienced operators, the distinction is simple: least privilege limits scope, while ZSP eliminates permanence. The most common misapplication is treating long-lived credentials with narrow IAM policies as ZSP, which occurs when permissions are reduced but still remain continuously available.

Examples and Use Cases

Implementing Zero Standing Privilege rigorously often introduces orchestration overhead, requiring organisations to weigh faster automation against stronger containment when credentials are issued only on demand.

• A CI/CD pipeline requests a short-lived deployment token only after a release approval, then loses that token immediately after the deployment completes.
• An AI Agent is granted tool access for a single retrieval and action sequence, rather than holding persistent rights to production data stores.
• A database migration job receives temporary elevation through PAM, then returns to a baseline identity with no active admin rights.
• A third-party integration is forced through time-bound access and monitored approval instead of maintaining a reusable API key in a config file.
• A workload identity in a microservices environment uses federated, ephemeral credentials rather than a standing certificate embedded in a host image.

These patterns align with the operational direction described in the Ultimate Guide to NHIs — Key Challenges and Risks, where standing permissions and credential reuse are recurring sources of exposure. They also map cleanly to implementation priorities discussed in the OWASP Non-Human Identity Top 10, especially around secret handling, privilege scope, and token lifecycle.

Why It Matters in NHI Security

Zero Standing Privilege matters because NHIs are often created for speed, not governance, and that leaves them with access that outlasts the business need. When secrets remain valid after notification, as highlighted in the Ultimate Guide to NHIs — Key Challenges and Risks, the security gap is not theoretical but operational. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which broadens the attack surface and makes any compromised identity far more valuable than it should be.

ZSP is especially important for zero trust programs because identity-based access must be continuously justified, not permanently assumed. That logic is consistent with OWASP Non-Human Identity Top 10 recommendations and with OWASP Non-Human Identity Top 10 implementation themes around ephemeral credentials, secret hygiene, and access review. Organisations typically encounter the urgency of ZSP only after a service account, API key, or agent credential is abused in an incident, at which point standing privilege becomes operationally unavoidable to remove.

Related resources from NHI Mgmt Group

• What is Zero Standing Privilege (ZSP) and how does it apply to NHIs?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• When is zero standing privilege more useful than broader access models?
• Why do NHIs complicate zero trust and least privilege efforts?