Rolling out zero standing privileges

Zero standing privileges (ZSP) means no human or workload holds permanent elevated access: privileges are granted just in time, scoped to a task, and expire on their own. It is the strongest practical form of least privilege. If no account carries standing admin rights, a phished password, a stolen session, or a leaked token has far less to abuse, and privilege escalation and lateral movement get much harder. This guide is for IAM, PAM, and cloud platform teams planning a 6 to 12 month rollout.

Why standing privilege is the fuel

Standing rights turn one compromised identity into a full incident. The pattern repeats across the Identity Breach Database:

• Insider with permanent cloud admin. At Ubiquiti, a senior developer used his own administrative access to AWS and GitHub to steal data, then posed as an outside attacker. Standing access meant nothing had to be requested or approved.
• Workload identities with standing rights. In the JadePuffer attacks Microsoft reported, two compromised service principals were used to request storage account keys and delete most targeted storage accounts within seven minutes. Credentials for one had appeared in a public GitHub issue.
• A standing deployment token. In the Binance wallet theft, the attacker found a container deployment permission token on an engineer's computer and used it to deploy a container that reached the internal wallet signing service.
• Privilege that outlives its purpose. Mover entitlement accumulation and orphaned account abuse are both standing-privilege problems: rights granted for a past job or a departed person that nobody removed.

NIST's Zero Trust Architecture, SP 800-207 frames authentication and authorization as discrete functions performed before each session to a resource is established. ZSP applies the same idea to privilege: decide per task, not once at onboarding.

Decide the model per privilege tier

Not every role needs the same treatment. Use this table to assign a pattern before you buy or configure anything.

The rollout sequence

1. Discover privileged access. Inventory who and what holds elevated rights across cloud, SaaS, on-prem, and non-human identities. CIEM and PAM tools surface effective permissions, including rights inherited through groups.
2. Right-size first. Remove unused and excessive entitlements before automating. JIT on top of a bloated baseline just makes the bloat time-boxed.
3. Convert standing to eligible. In Microsoft Entra Privileged Identity Management, an eligible assignment gives exactly the same access as a permanent one once activated; the difference is that the user must activate it, by passing MFA, giving a justification, or getting approval (Microsoft Learn: What is PIM). PIM assignments can target users, groups, service principals, and managed identities.
4. Set activation policy per role. PIM role settings let you require MFA, a Conditional Access authentication context, a justification, ticket information, and approval, and set an activation maximum duration of one to 24 hours (Microsoft Learn: PIM role settings). Note that the ticket number is information only: PIM does not validate it against your ticketing system.
5. Extend to cloud accounts. For AWS, IAM Identity Center calls this temporary elevated access and relies on AWS Security Competency partner solutions validated against a common set of requirements. AWS lists Apono, CyberArk Secure Cloud Access, Okta Access Requests, and Tenable (AWS docs).
6. Automate grant and revoke. Requested, approved (or auto-approved by policy), granted for a fixed window, revoked automatically. Self-service with guardrails keeps it usable.
7. Add break-glass deliberately. Configure break-glass accounts before you make every admin eligible (see below).
8. Bring workloads in. Replace static secrets with short-lived credentials (see workload identity 101 and non-human identity security). A non-expiring admin or deploy token is standing privilege, whatever the PAM dashboard says.
9. Measure standing privilege down to near zero. Track, per scope, the count of permanent active privileged assignments, excluding documented break-glass. Drive it toward zero over successive quarters.

Break-glass without lockout

ZSP has one well-documented way to fail catastrophically: everyone is eligible, nobody is active, and activation needs an approver who does not exist. Microsoft warns that you will be locked out of the tenant if all Privileged Role Administrators and Global Administrators are eligible but none are active, approval is required, and no approvers are configured. Its emergency access guidance sets the baseline:

• At least two cloud-only emergency accounts on the .onmicrosoft.com domain, not federated or synced.
• Phishing-resistant authentication (FIDO2 passkey recommended, or certificate-based authentication), different from what normal admins use.
• Global Administrator assigned as permanent active, not eligible, for these accounts.
• Excluded from Conditional Access policies that block or restrict sign-in.
• An alert on every sign-in, and validation at least every 90 days.

Make it usable, or it fails

ZSP dies if elevation is slow; people route around it and demand standing exceptions. Fast approvals (chat-based, policy-driven auto-approval for low-risk requests), clear audit, and good defaults matter more than the product choice. One Entra detail worth knowing: MFA required at activation may not prompt again if the user already presented strong credentials earlier in the session, so for top-tier roles pair activation with an authentication context whose Conditional Access policy sets sign-in frequency to every time.

Also watch the second gap Microsoft documents: the activation requirement applies at activation only. A user can activate on a compliant device and then use the activated role from a non-compliant one. Close it with a second Conditional Access policy scoped to the directory roles themselves.

Readiness checklist

• Privileged inventory covers cloud, SaaS, directory, on-prem, and workloads
• Unused entitlements removed before JIT goes live
• Every top-tier role is eligible only, with approval and phishing-resistant MFA
• At least two approvers per approval-gated role
• Two break-glass accounts tested, alerted, and excluded from blocking policies
• Static admin and deploy tokens inventoried with a removal date
• Standing-privilege count reported to leadership each quarter

Common failure modes

Related

Guides: what is PAM, implementing privileged access management, how to choose a PAM solution, zero trust rollout. Vendors: PAM, CIEM. Glossary: zero standing privileges, JIT access, least privilege, break-glass.