Zero Standing Privileges: Goal, Myth or Next Year's Project?
Zero standing privileges means no account holds privilege until it's needed. What's realistic, where it breaks, and how to measure progress toward it.
In this post
Zero standing privileges (ZSP) means no human or machine identity holds privileged access by default. Privilege is granted when a specific task needs it and removed when the task is done. Is it a goal, a myth or next year’s project? It’s a direction you can make real progress toward, not a state most organizations will fully reach, and that’s fine.
It’s December, which means it’s the season for roadmaps with ZSP somewhere on slide four. Before it goes on yours, it’s worth being clear about what it means and what it will cost.
What are zero standing privileges?
Standing privilege is any privileged access that exists whether or not anyone is using it right now: the domain admin group with 40 members, the cloud engineer who’s permanently an owner on the production subscription, the vendor account with admin rights that nobody has logged into since spring.
Zero standing privileges is the end state where none of that exists. Privileged accounts, roles and group memberships are empty at rest. When someone needs elevated access, it’s granted for the task and then removed, so a stolen identity between tasks gets an attacker very little.
How ZSP relates to just-in-time access and least privilege
These three get used interchangeably, and they’re not the same thing.
| Concept | What it limits | The question it answers |
|---|---|---|
| Least privilege | How much access an identity has | Does this identity have only what its job requires? |
| Just-in-time access | When access exists | Is this access present only while it’s being used? |
| Zero standing privileges | Whether any privilege persists at rest | Is there any privileged access left standing at all? |
Least privilege is the principle. Just-in-time access is the main mechanism. ZSP is what you get when you apply JIT to every privileged path. You can practice least privilege with standing access (a narrowly scoped permanent role), and you can do JIT on some systems while plenty of standing privilege remains elsewhere. ZSP is the claim that there’s nothing left over.
Is zero standing privileges realistic?
Partly. Here’s how I’d split it.
Realistic now: human admin access to cloud consoles, SaaS admin roles, identity provider admin roles and most Windows and Linux server administration. The tooling for time-bound role assignment, ephemeral accounts and JIT group membership is mature for these, and in most environments human admins are the easiest standing privilege to remove.
Realistic with work: directory-level admin rights, database admin access and network infrastructure. These usually involve legacy authentication, shared accounts and operational habits that take longer to unwind.
Aspirational for most organizations: service accounts, non-human identities and operational technology. That’s not because nobody’s tried. It’s because the constraints in those areas are real.
In practice: Human cloud admin access is where ZSP most often lands first. A reasonable target is that nobody holds a permanent admin role in the production cloud tenant: engineers activate time-bound roles when they need them, and break-glass accounts sit separately. Getting there is mostly about the on-call workflow. Once activation takes under a minute, the arguments for standing access tend to fade, and progress usually slows only when you reach servers and databases.
Where zero standing privileges breaks
Break-glass accounts. You need a way in when the identity provider, the PAM platform or the network is down. Those emergency accounts are standing privilege by definition. The answer is not to pretend otherwise: keep them few, vaulted, monitored, alerting on any use and tested on a schedule. Count them separately and don’t let them grow.
Operational technology. In OT, a delayed login can be a safety or production problem, not just an annoyance. Many control system components don’t support modern authentication, and some can’t change credentials without downtime. JIT can work for engineer and vendor remote access, brokered at the boundary, but pushing ZSP down to devices at the lower levels of an industrial network is often not practical. (More on that in what OT security means for identity and the Purdue model through an identity lens.)
Legacy service accounts. The service account that runs a 15-year-old application, has domain admin “because it needed it once” and breaks if you touch its password is one of the most common blockers. You can vault it, rotate it carefully and restrict where it can log on, but making it non-standing usually means re-engineering the application.
Non-human identities in general. API keys, workload identities, CI/CD pipelines, bots and now AI agents often outnumber people by a wide margin. Some can move to short-lived tokens and federated workload identity, which is ZSP in spirit. Many can’t yet, and few organizations have a complete inventory of them in the first place.
A common version of this: A least-privilege or ZSP project reaches the service accounts, someone proposes rotating the password on the account behind an old line-of-business application, and nobody can say what else depends on it. The vendor no longer supports the product, so the account gets an exception and the project moves on. My advice is to record that exception with an owner, a compensating control and a review date, rather than letting it quietly become permanent.
How to measure progress toward ZSP
ZSP is easy to claim and hard to verify, so measure it. The simplest useful metric is a count, tracked monthly:
- Standing privileged accounts and entitlements, by category: human admin, service account, vendor, break-glass, non-human.
- Percentage of privileged access delivered just in time versus held permanently.
- Average duration of granted elevation, to catch “temporary” access set to 30 days.
- Break-glass account count and usage, which should be small and flat.
- Standing privilege found by discovery that wasn’t in the inventory, which tells you how much you don’t know.
The trend matters more than the absolute number. A chart that goes from, say, 600 standing privileged entitlements to 90 over a year is a far better story for leadership, and a better security outcome, than a slide that says “ZSP: in progress.” It also forces the question of which identities you’re counting, which is half the value.
My advice: For leadership, I’d keep it to one trend line of standing privileged entitlements by category, plus one sentence on what changed and what’s blocking the next drop. For auditors, the same number needs a definition behind it: which identities are counted, where the data comes from and how exceptions are approved. A metric that can’t survive the question “where did this come from?” does more harm than not reporting one.
A staged path to zero standing privileges
- Discover. Find every privileged account, group, role and credential across on-premises, cloud and SaaS. You can’t remove what you can’t see, and the first discovery run is usually humbling.
- Vault what has to stay. Put remaining standing credentials, including break-glass and service accounts, under management: rotated, brokered and recorded. This is classic privileged access management, and it’s still the foundation.
- Remove standing human admin access. Start with cloud and SaaS admin roles, then server admin. Make people eligible instead of assigned, with fast request flows and policy-based approval for routine work.
- Govern eligibility. Decide who is allowed to request what through your identity governance program, and review eligibility like any other entitlement. JIT doesn’t help much if 500 people are eligible for domain admin.
- Bring vendors under JIT. Third-party access should be requested, time-boxed and recorded every time. Privileged remote access tools are built for exactly this.
- Tackle non-human identities. Inventory them, assign owners, move what you can to short-lived credentials and federated workload identity, and vault the rest.
- Measure and report. Track the count every month and treat new standing privilege as an exception that needs an owner and an expiration date.
The short answer
Zero standing privileges is a real goal, not a myth, but it’s a direction rather than a finish line. For human admin access in the cloud and on servers, it’s achievable now, and that’s where most of the risk reduction is. For break-glass, OT and legacy service accounts, the honest target is “minimal, managed and measured,” not zero. So put ZSP on next year’s roadmap, but write it as a number going down rather than a box to tick. Most access problems don’t start with a breach. They start with nobody being able to answer who, and what, can reach your most critical systems right now. Counting your standing privilege answers that question.
More PAM field notes live in the PAM topic hub.