The zero standing privilege playbook

Zero standing privilege (ZSP) is a simple concept: nobody has admin rights by default. Every privileged action requires a just-in-time elevation, bound to a specific ticket, approved by a named authority, time-bounded to the operational task, and recorded for audit. When the elevation expires, the access goes away.

The concept is simple. Achieving it operationally is hard. We have run enough ZSP programs to know the failure modes are not technical — they are organizational. This piece covers the playbook we use, with the failure modes called out as we go.

What ZSP actually requires

A real ZSP program has four properties that are non-negotiable:

1. No persistent admin group memberships. Domain admins, root, sudoers, database administrators — no one is a member of the privileged group at rest. Membership is granted via the PAM platform on demand and revoked automatically.

2. Every elevation is ticket-bound. The PAM platform requires a ticket reference (ServiceNow, Jira, etc.) before it will elevate. The ticket has to be valid, in-scope, and approved.

3. Every elevation is time-bounded. Default elevation duration is short (we typically default to 60 minutes, extendable in 30-minute increments with re-approval). Elevations cannot exceed the duration of the ticket window.

4. Every elevation is recorded. Session recording is on by default for every privileged path, with no opt-out for "trusted" administrators.

If any of these is partially in place, you do not have ZSP — you have an aspirational ZSP program with a back door.

The four failure modes

We have seen the same four failure modes across every PAM program we have inherited:

Failure mode 1 — The "break-glass" account that nobody manages. Every organization has a break-glass account — domain admin credentials in a sealed envelope in a safe somewhere, or worse, a service account with persistent credentials in a vault somewhere. The break-glass account is rarely tested, rarely audited, and almost never rotated. ZSP programs that do not have a written break-glass discipline (rotation cadence, recording requirement, post-event review) have a hole through which the entire control collapses.

The fix: treat break-glass like any other privileged path. Vault the credential, require ticket binding even for emergency use, record the session, and conduct a written post-event review within 24 hours. Rotate after every use.

Failure mode 2 — The standing service account that nobody can replace. The line-of-business application that runs as domain admin "because that's how it's always been." The legacy connector that has root on a database. The CI runner that has a long-lived credential to the production cluster. Every organization has these; ZSP programs that do not address them have ZSP for humans and standing privilege for machines, which is not ZSP.

The fix: dynamic-secret patterns — Vault dynamic database credentials, AWS IAM Roles Anywhere, workload identity federation. Replace long-lived service-account credentials with short-lived, scoped credentials per workload. This is not optional for ZSP; it is the substrate.

Failure mode 3 — The "trusted operator" exception that becomes permanent. The senior platform engineer who needs to "just have access" because they are on call. The DBA who is "always going to need" production database access. The SRE who pages mean response time will go up if elevation is required. These exceptions are real organizational pressure; they are also the most common path to ZSP collapse.

The fix: engineer the elevation path to be operationally indistinguishable from standing privilege when used at full speed. Pre-approved elevations with named on-call rotations. Elevations that complete in under 30 seconds at the platform level. Recording that does not impede the workflow. The goal is to make the just-in-time path the path of least resistance — not the path of greatest friction.

Failure mode 4 — The audit-evidence pipeline that breaks during the audit. ZSP produces extensive audit evidence by design: every elevation, every approval, every session, every command. If the SIEM ingestion lags, if the retention policy is wrong, if the search interface cannot answer the auditor's question in real time, the audit becomes a reconstruction exercise. The auditor's confidence in the program drops; the next audit is harder.

The fix: stress-test the audit-evidence pipeline before the first audit, not during it. Run a tabletop exercise with the internal audit team — give them a question, see how long it takes to answer. The first answer should be under five minutes for any reasonable question.

The 90-day stand-up plan

For organizations starting ZSP from scratch, we sequence the work over 90 days:

• Days 1-30: Identity inventory (every privileged account and group, mapped to humans or workloads), break-glass discipline written and signed off, first audit-scope (one platform, ~ 50 users) defined.
• Days 31-60: Privileged credential vault stood up against the first audit-scope, elevation flow designed with named approvers, ticket binding implemented, recording on for every session.
• Days 61-90: First audit cycle run against the in-scope platform. Failures triaged, runbook revised, expansion plan drafted.

By day 90, the in-scope platform is at full ZSP. The next 90 days expand to adjacent platforms; the 90 after that close the long tail.

The bottom line

ZSP is not a vendor feature. It is an operating decision your platform team has to defend every quarter against the request to make exceptions permanent. Vendors give you the substrate. The discipline is yours.