Zero standing privilege is becoming the baseline for PAM programs

At a glance

What this is: This is an independent analysis of why Zero Standing Privileges is emerging as the practical answer to standing privilege, overprovisioned access, and weak privileged-access governance.

Why it matters: It matters because IAM, PAM, and identity architects have to reduce persistent privilege across people and machines, not just add another control layer on top of legacy access patterns.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read SSH Communications Security's analysis of Zero Standing Privileges for PAM

Context

Zero standing privilege is the condition where no person or machine keeps persistent privileged access between tasks. In practice, many PAM programmes still treat privilege as a standing entitlement and then try to manage the risk after the fact, which leaves overprovisioned accounts and broad access paths in place. For IAM teams, the core issue is not simply credential storage but the persistence of privilege across human and machine identities.

SSH Communications Security’s article frames ZSP as a shift from static privilege to task-bound access, not as a feature add-on. That framing matches what many enterprises are already seeing: PAM tools can exist while the underlying operating model still tolerates lingering access, slow revocation, and broad trust in privileged accounts.

Key questions

Q: How should security teams reduce standing privilege in privileged access programmes?

A: Start by mapping every account, workflow, and exception that can still hold access after a task is finished. Then replace persistent entitlement with time-bound access, explicit expiry, and recertification for the small set of cases that truly need elevation. If access remains available by default, the programme is still tolerating standing privilege.

Q: Why do standing privileges increase breach impact in cloud and enterprise environments?

A: Standing privileges enlarge the attacker’s options because one exposed administrative path can be reused for lateral movement, persistence, or broad operational control. In cloud environments, that risk is worse when human admins and machine identities both retain long-lived elevation. The practical result is higher blast radius from a single compromise.

Q: How do teams know whether ZSP is actually reducing risk?

A: Look for a measurable drop in persistent privileged entitlements, shorter elevation duration, and fewer workflows that bypass task-specific approval. If elevated access still survives between jobs, ZSP is not yet operating as a real governance model. The signal is whether privilege is becoming temporary by default.

Q: What should organisations do if PAM is deployed but standing access remains?

A: Treat that as an operating-model problem, not a tooling problem. Rework discovery, lifecycle controls, and approval paths so privileged access is granted only for defined work and removed as soon as the task ends. If persistent access remains normal, the deployment has not changed the security posture enough.

Technical breakdown

Why standing privilege remains the default failure mode

Standing privilege persists when organisations grant access once and then rely on periodic review, manual rotation, or vaulting to manage risk. That model scales poorly because privileged access is used across many systems, many account types, and many operational paths. The result is a control environment where access remains available longer than necessary, and attackers only need one exposed path to reuse it. In NHI terms, the problem is not just credential location, but the durability of the privilege behind the credential.

Practical implication: inventory every privileged account and access path before you decide where ZSP can replace standing access.

How just-in-time privilege changes the control model

Just-in-time access moves privilege from a permanent state to a time-bound authorization tied to a specific task. That means the identity is authenticated, the context is validated, and the privilege is granted only for the duration of the approved workflow. This is materially different from traditional privileged access because the default state is no access, not delayed access or dormant access. For machine identities, this also reduces the value of long-lived credentials that attackers commonly target for reuse.

Practical implication: define the exact workflows that justify temporary privilege, then remove standing entitlement for everything else.

Why ZSP depends on lifecycle governance, not only tooling

ZSP fails if organisations keep treating PAM as a one-time deployment project. The article points to the need for discovery, strategy, roadmap planning, and vendor evaluation, which all depend on knowing where privileged identities exist and how they are used over time. Without lifecycle governance, temporary privilege becomes another unmanaged exception rather than a durable operating model. That is why privileged access management has to cover provisioning, change, and offboarding across both humans and machines.

Practical implication: tie ZSP to access discovery, recertification, and offboarding so temporary privilege does not become a new class of standing access.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is the control assumption ZSP breaks. Traditional PAM assumes privileged access can exist continuously and still be made safe through monitoring, rotation, and review. That assumption fails when attackers target reuse, lateral movement, and overtrusted administrative paths faster than the review cycle can react. The implication is that privilege must be designed to expire by default, not simply be better monitored.

Zero Standing Privileges is a governance model, not a procurement outcome. The article correctly treats ZSP as a shift in how access is granted and governed, not a property of a tool. Organisations that stop at product selection keep the same privileged-account habits under a new label. The practitioner conclusion is that PAM maturity now depends on operating model change, not feature count.

Standing privilege creates identity blast radius across both human and machine accounts. The most dangerous environments are the ones where overprovisioned admins and long-lived workload credentials coexist. In that state, one compromise can move laterally across both human and non-human identities because the organisation has not separated task scope from identity scope. The conclusion is that least privilege has to be enforced as an operating boundary, not as a policy aspiration.

Ephemeral privilege debt: static access that remains administratively convenient but operationally obsolete becomes accumulated risk. The article shows that many organisations know ZSP is desirable but still plan for it as a later-stage improvement. That delay creates a governance backlog where privileged access stays available because the environment was never redesigned for temporary entitlement. Practitioners should treat that backlog as a measurable security liability.

IAM leaders should stop treating PAM as a tool selection problem and start treating it as a trust-model problem. Gartner's guidance, as cited in the article, points to planning, discovery, roadmap building, and operating model changes because privileged access touches every layer of identity governance. The field should read this as a signal that ZSP will increasingly define whether PAM programmes are actually reducing risk. The practitioner conclusion is to judge maturity by how much standing privilege remains, not by whether a platform is deployed.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why privileged access programmes so often miss the identities that matter most.
• For the deeper lifecycle lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how discovery, rotation, and offboarding support ZSP.

What this signals

Ephemeral access only helps if the organisation can prove where standing privilege still exists. In many programmes, the first constraint is not policy design but incomplete discovery across humans and non-human identities. That is why the operational signal to watch is whether admin workflows are shrinking in duration, scope, and exception count across the estate.

Zero Standing Privileges should be read as a lifecycle discipline, not a narrow privileged-session control. Once privilege becomes time-bound, the surrounding processes have to support discovery, approval, revocation, and offboarding at the same pace. The reader takeaway is to align PAM with lifecycle governance rather than treating it as a separate security island.

The identity blast radius in mixed human and machine environments grows whenever long-lived privilege survives a workflow change. Teams should expect ZSP to expose hidden operational dependencies first, then reduce them gradually. That makes change management, not just technical enforcement, part of the security programme.

For practitioners

• Discover every privileged account and access path Run account discovery across humans, service accounts, and administrative workflows before deciding where ZSP can replace standing access. Include indirect access paths such as VPN-style broad entitlements, break-glass roles, and machine credentials that quietly persist after deployment.
• Convert repeatable admin work into time-bound workflows Identify the privileged tasks that are genuinely episodic, then wrap them in just-in-time access with validated context and explicit expiry. The goal is to make no access the default state and temporary privilege the exception.
• Tie PAM to lifecycle governance Connect provisioning, review, rotation, and offboarding so temporary privilege does not drift back into standing entitlement. Build recertification and deprovisioning checkpoints into the process rather than assuming the platform will enforce them for you.
• Measure standing privilege reduction as a programme outcome Track how many administrative entitlements remain persistent, how long elevated access lasts, and how many privileged workflows still rely on manual approval. Those metrics tell you whether ZSP is changing the operating model or only adding another control layer.

Key takeaways

• Standing privilege remains one of the clearest reasons PAM programmes still underperform against real-world attack paths.
• Zero Standing Privileges changes the operating model by making privilege temporary, task-specific, and auditable instead of ambient.
• The programme test is simple: if persistent access still exists by default, the identity governance model has not yet shifted far enough.

Key terms

• Zero Standing Privileges: Zero Standing Privileges is an operating model where no identity keeps persistent privileged access between tasks. Privilege is granted only when needed, for a specific workflow, and removed immediately after use. In practice, it turns privileged access from a default condition into a temporary exception.
• Standing Privilege: Standing privilege is any permanent or long-lived elevated access that remains available outside the moment it is needed. It is risky because it widens the attack surface, makes misuse easier, and leaves security teams relying on review and rotation after the fact rather than preventing exposure up front.
• Just-in-Time Access: Just-in-time access is a control pattern that provisions elevated permissions only for the duration of an approved task. It is often used to support least privilege in operational environments, but it only works when scope, duration, and revocation are tightly governed across the identity lifecycle.
• Privileged Access Management: Privileged Access Management is the discipline of governing high-risk access for administrative users, service accounts, and other powerful identities. It covers discovery, approval, monitoring, rotation, and removal of elevation, and it fails when organisations treat it as a tool deployment instead of an identity governance programme.

Deepen your knowledge

Zero Standing Privileges, privileged access governance, and time-bound administrative workflows are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from standing privilege to task-scoped access, it is worth exploring.

This post draws on content published by SSH Communications Security: Zero standing privileges and the future of privileged access management. Read the original.