Zero Standing Privilege vs Least Privilege: Adding Time to the Privilege Question

A perfectly scoped permission that exists every hour of every day is still a permission an attacker can inherit at three in the morning. Least privilege answers the question "how much access does this identity need?" Zero standing privilege (ZSP) adds a second question: "does this identity need that access right now?" This guide compares the two on the time dimension only: where a least privilege programme still leaves standing risk, what ZSP actually removes, where ZSP is impractical and what residual standing access every organisation has to keep and defend. It is written for PAM owners, IAM architects and platform teams deciding how far to push time-bound access for people, workloads and AI agents. The patterns themselves are covered in the JIT Access Guide and the scoping methods in the Least Privilege Techniques Guide; this page is about choosing between them and combining them.

Key takeaways

• They measure different axes. Least privilege limits the scope of a permission; ZSP limits the time it exists. A role can be minimal and permanent, or broad and present for ten minutes, and both carry risk.
• Least privilege alone leaves an exposure window. A correctly scoped admin role assigned permanently is usable by anyone who steals the session or credential, at any hour, without any further check.
• ZSP still has standing parts. Eligibility, the activation path, the approver set, break-glass accounts and the workload identities that request tokens all exist permanently and become the new targets.
• Short-lived is not zero-risk. A temporary credential is fully usable until it expires, so session length, binding and in-session monitoring matter as much as the absence of a standing grant.
• Use both, deliberately. Scope every grant with least privilege, then remove standing access where an activation step is cheap and reliable, and document compensating controls where it is not.

The short answer: scope and time are separate controls

NIST SP 800-53 Rev. 5 defines least privilege as an architecture in which each entity is granted the minimum system resources and authorisations it needs to perform its function (control AC-6). Nothing in that definition says when. A least privilege review that removes unused actions from a role, and a JIT system that grants the same role for one hour, are attacking different parts of the same risk equation: the blast radius of a compromised identity is roughly scope multiplied by exposure time.

ZSP is the target state in which no human or machine identity holds privileged access permanently, outside a small, controlled emergency set. It is reached through just-in-time (JIT) techniques: time-bound role activation, ephemeral accounts, short-lived credentials and brokered sessions. The SP 800-53 enhancement that comes closest to ZSP is AC-2(6) Dynamic Privilege Management, alongside AC-2(2) for automated removal of temporary and emergency accounts.

Least privilege on its own: where standing risk remains

Threat model: least privilege assumes compromise will happen and limits what the compromised identity can reach. It does not change when the identity can act. An attacker who obtains a credential or a live session gets the full scoped privilege immediately, for as long as the credential works.

Architecture in words: permissions are attached permanently to a user, group, role or service account. Changes happen through joiner, mover and leaver processes and periodic reviews (AC-6(7) review of user privileges). The privilege is present during holidays, weekends and the months between uses.

Failure modes on the time axis

• Rarely used, always present: a role used for a quarterly maintenance task is reachable on the other 89 days. Usage-based right-sizing tools often keep it because it was used inside the lookback window.
• Attacker persistence through admin rights: standing rights to manage identities let an attacker create their own durable foothold, mapped in ATT&CK as T1098 Account Manipulation and T1098.003 Additional Cloud Roles. In the Stryker Cyberattack 2026, a source told BleepingComputer the attacker compromised an administrator account and created a new Global Administrator account before issuing Intune wipe commands.
• Machine credentials that never expire: OWASP lists NHI5:2025 Overprivileged NHI and NHI7:2025 Long-Lived Secrets as separate risks for a reason. A perfectly scoped API key that never expires remains usable for its whole life once leaked.
• Review cadence lag: a quarterly review can, at best, remove privilege that became unnecessary up to three months earlier. Time-bound grants remove it at the end of the task.

Controls that reduce time exposure without ZSP

• Separate admin accounts: privileged rights on dedicated accounts used only for admin work (AC-6(5)), so a phishing compromise of the everyday account does not carry them.
• Session limits: shorter sign-in frequency and step-up authentication for admin portals.
• Automatic disablement: disable accounts after a defined inactivity period (AC-2(3)).
• Credential rotation: rotate vaulted secrets after each checkout so a captured password ages out.

Zero standing privilege: what it removes and what it creates

Threat model: ZSP assumes that a privilege nobody holds cannot be stolen. A compromised account with only eligibility has to pass an activation step, ideally with fresh strong authentication, approval or both, before it can do damage, and that step creates a detection point.

Architecture in words: identities hold eligibility rather than assignment. A request, with justification, goes to a policy engine; the engine checks conditions and approvals, adds the role binding or issues a short-lived credential, and removes it at expiry. Microsoft Entra Privileged Identity Management, for example, separates eligible from active assignments, lets administrators set an activation maximum between one and 24 hours, and can require MFA, a Conditional Access authentication context, justification or approval on activation. Google Cloud Privileged Access Manager models the same idea as entitlements with a maximum grant duration and optional approvers, and revokes roles automatically when the grant ends. In AWS IAM Identity Center, temporary elevated access is delivered through validated partner solutions that supplement permission sets and MFA. Platforms are listed alphabetically; the order is not a ranking.

What stays standing under ZSP

Failure modes of ZSP

• Short-lived but long enough: a temporary credential is usable until it expires. In the Bybit Hack 2025, Safe reported that attackers hijacked a developer's AWS session tokens, which had already passed MFA, and used them to alter JavaScript in an S3 bucket. Temporary did not mean harmless.
• Durations creep to the maximum: if activation is slow or unreliable, people request the longest allowed window every time, which turns JIT into standing access with extra steps.
• Persistence created inside the window: an attacker who activates once can create keys, users or role assignments that outlive the grant. The grant expires; the backdoor does not.
• Out-of-band changes: Google Cloud's documentation warns not to manually modify role bindings managed by Privileged Access Manager. Infrastructure as code that re-applies permanent bindings silently undoes ZSP.
• Coverage gaps: JIT on the cloud control plane does not cover resource-based policies, Kubernetes RBAC or database grants. AWS notes that resource-based policies, Amazon EKS cluster config maps and AWS KMS key policies need separate handling.

Where ZSP is impractical

ZSP is a direction, not a switch. The test for each target is whether an activation step can be made fast, reliable and available when the systems it depends on are degraded. Where it cannot, keep the access standing, scope it with least privilege and add compensating controls.

The last row is the key distinction for machines: a workload can hold a standing role while holding no standing secret. That is a time control on the credential rather than the permission. The Credential Vaulting vs Just-in-Time Elevation page covers the vault side of this choice.

What the time dimension means for NHIs and AI agents

For non-human identities, ZSP is mostly achieved by shortening credential lifetime rather than by human-style activation, because nobody is there to click "activate".

• Federated workload tokens: GitHub Actions OIDC lets a workflow request a cloud access token that is only valid for a single job, so no long-lived cloud secret is stored in GitHub. See the Workload Identity Federation vs Static Cloud Keys comparison.
• Cloud temporary credentials: AWS describes temporary security credentials as lasting from a few minutes to several hours, not stored with the user, and unusable after expiry, so they do not need explicit revocation.
• Kubernetes bound tokens: the TokenRequest API issues tokens bound to the lifetime of the pod, and the kubelet rotates projected tokens before expiry. Kubernetes describes Secret-mounted tokens, which do not expire, as no longer recommended because of the risks of static, long-lived credentials.
• Dynamic secrets: a vault creates a database or cloud credential per lease and revokes it at lease end. See the Dynamic Secrets and Ephemeral Credentials Guide.
• Self-elevating machines: Google Cloud Privileged Access Manager allows service accounts and agent identities to request grants for automated tasks instead of holding permanent roles, which is ZSP applied to the permission itself.

AI agents add a twist: their tasks are dynamic, so least privilege is hard to define in advance, and the time axis becomes the more practical control. A grant scoped to one task, expiring when the task ends, limits what a hijacked or confused agent can do far better than a broad standing role reviewed quarterly. The agent's own identity, its tool connections and the delegation from the user are the standing parts to defend. See the Agent Identity and Access Guide.

Decision guidance: when to push for ZSP

1. Is the privilege able to change identity or security configuration? Directory admin, IAM admin, policy and key management: make these JIT first, because standing access here enables persistence.
2. How often is it used? Used weekly or less: strong ZSP candidate. Used many times a day: keep a narrow standing role and move only the dangerous actions to JIT.
3. Does the target support runtime grants? If yes, JIT. If not, vault and rotate, and record that the access is standing by design.
4. What happens if the JIT system is down? If the answer is "we cannot recover", design break-glass before removing standing access.
5. Is the identity a workload? Prefer standing scoped role plus short-lived credential over human-style activation.
6. What size is the team? Small organisations get most of the benefit from making a handful of tenant-wide admin roles eligible-only with MFA on activation. Large organisations need a policy engine, approver rotas and coverage reporting across many platforms.

Worked scenarios

Scenario 1: cloud platform team

A platform team of eight holds a permanent, carefully scoped "PlatformAdmin" role across production accounts. A least privilege review last quarter removed unused services, so by the scope measure the role is clean. Activity logs show each engineer uses write actions on about four days a month. Moving to ZSP: the role becomes eligible-only, activation requires phishing-resistant MFA and a ticket reference, maximum duration two hours, no approval for routine use, and approval for the IAM write subset split into a separate role. Read-only access stays standing. Residual standing items are recorded: the eligibility list, the two break-glass accounts and the deployment pipeline's federated role. Result: the exposure window for production write drops from every hour to the hours actually worked, while scope stays the same.

Scenario 2: CI/CD pipeline and an AI coding agent

A pipeline holds a static cloud access key with a least privilege policy for deploying to one service. The key is replaced with OIDC federation scoped to the main branch of one repository, so each job gets a token valid only for that job. The role stays standing, the secret does not. An AI coding agent that opens pull requests is given a short-lived repository token per task rather than a personal access token, and cannot trigger production deploys itself. The standing elements to watch are the federation trust conditions and the agent's own registration, both reviewed like privileged roles.

How to implement: phased approach

1. Baseline both axes: inventory privileged assignments and record for each its scope and whether it is permanent, time-bound or eligible. Count long-lived machine credentials separately.
2. Right-size first: apply least privilege before making roles JIT, so you are not automating the activation of an oversized role.
3. Pilot on Tier 0: make tenant-wide admin roles eligible-only for a pilot group, with MFA on activation and alerts on activation. Keep at least two break-glass accounts outside the scheme.
4. Measure friction: track activation latency and duration chosen. If most activations hit the maximum, shorten the work, not the control.
5. Extend to workloads: replace static keys with federation or dynamic secrets, starting with CI/CD and anything internet-facing.
6. Close side doors: make infrastructure as code non-authoritative for JIT-managed bindings, and bring resource-based policies and Kubernetes RBAC into scope.
7. Document residual standing access: every remaining permanent privileged assignment needs an owner, a reason and compensating controls.
8. Rollback: keep the previous permanent assignments exported so a failed JIT rollout can be reversed per role; never remove break-glass during rollout.

Detection and measurement

What to log: every activation and its justification, approver and duration; every grant expiry; any privileged assignment created outside the JIT system; any key, user or role created during an active grant; break-glass sign-ins; and use of temporary credentials from new networks or devices. Google Cloud notes that PAM grants are deleted 30 days after they end while logs persist in Cloud Audit Logs, so detection should rely on the audit log, not the grant list.

Common failure patterns

• Treating JIT as a replacement for scoping: a JIT-activated Global Administrator role is still Global Administrator for its duration.
• Eligibility for everyone: making the whole IT team eligible for every role moves standing risk from assignment to eligibility and changes little.
• Ignoring what is created in the window: grants expire but new keys, users and federated trusts persist, which is exactly how attackers turn a short window into permanent access.
• Short-lived but unbound credentials: tokens that can be replayed from any network until expiry, as the hijacked AWS sessions in the Bybit case show.
• No break-glass plan: removing standing access before emergency access is designed and tested, then reinstating permanent admin after the first outage.
• Infrastructure as code fighting the JIT system: authoritative policy resources re-adding permanent bindings every deploy.

Framework mapping

Practitioner checklist

• Record scope and time state (permanent, time-bound, eligible) for every privileged assignment.
• Right-size roles before making them JIT.
• Make identity and security administration roles eligible-only first, with strong MFA on activation.
• Set maximum durations by task, and review activations that always hit the maximum.
• Alert on keys, users, roles and federation trusts created during an active grant.
• Replace static machine secrets with federated or dynamic short-lived credentials.
• Keep two or more tested break-glass accounts outside the JIT scheme.
• Stop infrastructure as code from re-adding permanent bindings.
• Document every residual standing privilege with owner, reason and compensating control.
• Report privileged hours exposed, not just the number of roles.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Glossary, least privilege
• OWASP: Non-Human Identities Top 10 2025
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management
• Google Cloud: Privileged Access Manager overview
• AWS: Temporary security credentials in IAM
• Kubernetes: Service Accounts
• GitHub Docs: OpenID Connect

Related NHI Mgmt Group resources: JIT Access Guide · Least Privilege Techniques Guide · Privileged Access Management Guide · Service Account Security Guide · Cloud PAM and Just in Time Access