Just-in-Time Access and Zero Standing Privilege

Standing privilege is access that exists all the time, whether it is being used or not. An administrator who is permanently a Domain Admin, a developer with permanent production access, a service account with permanent owner rights: each is a target every hour of every day, even though the privilege may be needed for minutes a week. Just-in-time (JIT) access grants privilege only when it is needed and for as long as it is needed; zero standing privilege (ZSP) is the goal of having no permanent privileged access at all outside a small, controlled emergency set. This guide explains JIT and ZSP for people, workloads and AI agents, how to design the policy, how to detect abuse and how to measure progress. It is written for PAM and IAM owners, cloud platform teams and the security architects who set privileged access standards.

Key takeaways

JIT shrinks the window; ZSP removes it. A stolen credential with no standing privilege has to pass an activation step, with fresh authentication, before it can do damage.
Several patterns, one principle. Time-bound role activation, ephemeral accounts, short-lived credentials, brokered sessions and approval workflows all grant privilege per task, in line with NIST SP 800-207's per-session access tenet.
Speed decides adoption. If activation is slow or unreliable, engineers request the maximum duration or build backdoor accounts; tier the friction by risk.
Machines and agents need JIT most. OWASP lists overprivileged NHIs and long-lived secrets in its NHI Top 10; short-lived, task-scoped credentials are JIT for workloads and AI agents.
Activation is not the end of the control. Monitor what happens while privilege is active, especially new accounts, keys and role assignments that would outlive the session.

Why standing privilege is the problem

Most serious identity incidents follow the same arc: an attacker gets one credential, then finds privilege that was already there waiting. NIST SP 800-207 states the opposite principle as a tenet of zero trust: access to each resource "is granted on a per-session basis" and "with the least privileges needed to complete the task". Standing privilege breaks that tenet by design.

Standing admin with weak authentication: in the Storm-0501 Hybrid Cloud Attacks 2024, Microsoft described a compromised Domain Admin whose matching Entra ID account had MFA disabled and held the Global Administrator role.
Standing admin on management planes: in the Stryker Cyberattack 2026, a source told BleepingComputer that the attacker compromised an administrator account, created a new Global Administrator account and used Intune to wipe nearly 80,000 devices.
Standing privilege on machine identities: in the Microsoft Midnight Blizzard Breach 2024, Microsoft said the actor compromised "a legacy test OAuth application that had elevated access to the Microsoft corporate environment".
Secrets reachable from inside: in the Uber Breach 2022, the attacker claimed to have found a PowerShell script with hard-coded admin credentials; Uber did not confirm this but rotated keys to many internal services.

JIT would not have stopped every one of these intrusions, but each would have been harder: an eligible-only Global Administrator role needs activation with fresh strong authentication, and a JIT-only management plane has no standing admin to steal.

JIT patterns

Pattern	How it works	Examples	Watch out for
Time-bound role activation	User is eligible for a role and activates it for a limited period, with MFA, justification and optional approval	Microsoft Entra Privileged Identity Management (PIM); Google Cloud Privileged Access Manager entitlements; temporary group membership	Eligibility lists that grow unchecked
Ephemeral accounts	A temporary account is created for the task and deleted afterwards	Temporary database users; ephemeral local admin accounts	Clean-up failures leaving accounts behind
Short-lived credentials	Credentials are issued on demand and expire quickly	AWS STS temporary credentials; SSH certificates; dynamic database secrets	Maximum lifetimes set too long
Brokered sessions	User connects through a PAM gateway that injects credentials they never see	Session-managed server and database access	Direct paths that bypass the broker
Approval-based elevation	Access granted after peer or manager approval, tied to a ticket	Production changes; access to sensitive data	Rubber-stamp approvals and self-approval

The cloud providers now document these patterns directly. AWS describes temporary elevated access in IAM Identity Center as "also known as just-in-time access" and as a way to "request, approve, and track the use of a permission to perform a specific task during a specified time". Google Cloud's Privileged Access Manager revokes the granted roles at the end of the grant duration. AWS notes that temporary credentials "can be configured to last for anywhere from a few minutes to several hours" and are not recognised once they expire.

Designing JIT policy

Define eligibility: who may request which privilege, based on role, and an end date for each eligibility. Microsoft PIM can require all eligible assignments to have start and end dates rather than being permanent.
Set durations: default short, with a maximum per privilege level. In Entra PIM the activation maximum duration can be set from one to 24 hours; most teams should sit well below the ceiling.
Require strong authentication at activation: phishing-resistant MFA, not just a session that already exists. PIM can require a Conditional Access authentication context, and Microsoft notes that setting sign-in frequency to "Every time" forces reauthentication on each activation. See the Passwordless and Passkeys Guide.
Tier approvals by risk: self-activation with justification for routine tasks; peer or manager approval for high-risk ones. Microsoft recommends selecting at least two approvers, and Google's Privileged Access Manager supports multi-party approval.
Link to tickets, and check them: PIM's ticket field is information-only and "Correlation with information in any ticketing system isn't enforced", so validate tickets through automation if you rely on them.
Record and monitor privileged sessions. See the Privileged Session Management Guide.

Risk tier	Examples	Approval	Suggested maximum	Authentication
Routine	Read-only production diagnostics, non-sensitive admin consoles	Self, with justification	1 to 4 hours	Phishing-resistant MFA
Elevated	Production changes, database administration, cloud project owner	Peer or on-call lead, ticket validated	1 to 2 hours	Phishing-resistant MFA, compliant device
Tier 0	Directory global admin, identity provider, PAM, endpoint management, CA	Two approvers, no self-approval	Under 1 hour	Phishing-resistant MFA from a privileged access workstation, reauthentication every time
Emergency	Break-glass when normal paths fail	None at the time; reviewed afterwards	Incident duration	Separate, physically held credentials

The durations are NHI Mgmt Group suggestions, not vendor defaults. See the Privileged Identity Management (PIM) Guide and the Conditional Access Guide.

Moving towards zero standing privilege

Inventory standing privilege: permanent admin roles, privileged group memberships, owner rights, local admin rights and privileged service accounts and app registrations, including test and legacy tenants.
Convert people first: make administrators eligible rather than permanently assigned, starting with Tier 0 roles.
Remove unused privilege: use activity data to remove access nobody uses. Google suggests remediating excessive permissions by moving a permanent role to an on-demand entitlement rather than revoking it outright, so the access stays available when it is genuinely needed.
Address workloads: replace standing service account privilege with short-lived, scoped credentials and, where needed, separate privileged identities activated per job.
Keep break-glass: a small number of emergency accounts with standing privilege, heavily controlled. Microsoft warns that requiring approval while every Global Administrator is eligible but none is active, with no approvers set, can lock you out of the tenant. See the Break-Glass Account Guide.
Measure: standing privileged assignments, activation volume and time to access, reported monthly.

For local administrator rights on endpoints, see the Endpoint Privilege Management Guide.

JIT for non-human identities

OWASP's NHI Top 10 lists NHI5 Overprivileged NHI and NHI7 Long-Lived Secrets, and its NHI5 guidance recommends tools that "enable temporary, on-demand elevation of privileges". For machines, JIT mostly means credentials that expire on their own.

Standing credential	JIT replacement	What it removes
Long-lived cloud access keys	Role assumption and workload identity federation issuing temporary credentials	Keys that work from anywhere until someone rotates them
Shared database password	Dynamic secrets, unique per service instance, with a lease	One credential shared by many services; untraceable queries
Static SSH keys on servers	Short-lived SSH certificates issued per session	Authorised keys files that are never cleaned up
Pipeline deploy secret in variables	OIDC federation in protected jobs only	Deploy rights available to every branch and job
Service account with permanent owner	Self-elevation to a scoped role only for the job that needs it	Owner rights available to anyone who compromises the workload

HashiCorp describes Vault's database secrets engine as generating credentials dynamically, so that every service "is accessing the database with unique credentials"; the default dynamic role TTL is one hour and maximum 24 hours. Google's Privileged Access Manager supports service accounts and agent identities that "self-elevate and assume roles only when needed for automated tasks". See the NHI Authentication Guide, the Workload Identity Federation Guide, the Secrets Management Guide, the SSH Key Management Guide and the CI/CD Pipeline Identity Security Guide.

JIT for AI agents

AI agents are ideal candidates for JIT: they should receive access for a specific task, for the task's duration, and lose it afterwards. An agent with standing access to production, mail or finance systems is an always-on target for prompt injection and tool misuse.

Task-scoped grants: issue a short-lived token scoped to the resources the current task needs, ideally through token exchange that records the human the agent acts for.
Approval at the moment of use: high-impact actions (payments, deletions, permission changes, data exports) should require a human approval at the time, not standing permission granted at deployment.
No inherited admin: do not let an agent run under an administrator's activated session; give it its own identity and its own eligibility.
Automated approvers with care: Google allows service accounts or agent identities to act as approvers that validate tickets; keep a human approver for Tier 0 and keep approver and requester identities separate.

See the AI Agent Authorisation Guide and the Zero Trust for AI Agents Guide.

Detection and monitoring

JIT produces clean, structured events: requests, approvals, activations and expiries. Use them.

Privileged role assigned outside the JIT system: any permanent active assignment, or a new Global Administrator, as in the Stryker case.
Persistence during an active window: new accounts, access keys, app credentials, federated domains or role assignments created while privilege is active.
Use from an unexpected context: Microsoft notes that after activation "users aren't prevented from using another browsing session, device, or location to use permissions", so correlate activation and use by device and location, or add a second policy scoped to the role.
Unusual activation patterns: activations outside working hours, repeated maximum-length activations, self-approval patterns or approvals within seconds.
Break-glass use: every sign-in to an emergency account alerts immediately.
Machine credential anomalies: temporary credentials requested by an unexpected workload, or long-lived keys reappearing after migration.

See the ITDR Guide.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 control list, the CIS Controls v8.1 control list and the OWASP NHI Top 10 (2025); ISO/IEC 27001:2022 Annex A numbers and names come from a published Annex A index.

Requirement	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI Top 10
Least privilege for privileged accounts	PR.AA-05	AC-6, AC-6(5)	A.8.2 Privileged access rights	6 Access Control Management	NHI5
Time-bound and temporary privilege	PR.AA-05	AC-2(2), AC-2(6)	A.8.2, A.5.18 Access rights	5 Account Management, 6	NHI5
Strong authentication at activation	PR.AA-03	IA-2(1), IA-11	A.8.5 Secure authentication	6	NHI4
Short-lived machine credentials	PR.AA-01	IA-5, IA-4	A.5.17 Authentication information	5, 6	NHI7
Logging and monitoring of privileged use	DE.CM-03	AC-6(9), AC-2(12), AU-6	A.8.15 Logging, A.8.16 Monitoring activities	8 Audit Log Management	NHI5
Review of eligibility and privileges	PR.AA-05	AC-6(7), AC-2	A.5.18	5, 6	NHI5

Common pitfalls and failure patterns

Too much friction: slow approvals lead engineers to request maximum durations, share activated sessions or create backdoor accounts.
Eligible but never reviewed: eligibility lists grow unchecked and become standing privilege with an extra click; review them like access. See the Access Reviews Guide.
Long default durations that make JIT little different from standing access, such as eight-hour activations for a ten-minute task.
Persistence after activation: keys, accounts or role assignments created during an elevated session that outlive it. The Stryker attacker created a new Global Administrator account.
JIT for people, standing privilege for machines: administrators activate roles while service accounts and legacy app registrations keep permanent owner rights, as Midnight Blizzard's use of a legacy test OAuth app showed.
Weak activation authentication: activation that accepts an existing session or a push approval adds little when the session itself is stolen.
Approvers who can approve themselves: requester and approver groups overlap, or automated approvers are given Tier 0 scope.
Break-glass used routinely, or locked away so carefully that it fails when needed.

Metrics that show progress

Metric	What it shows	Target direction
Permanent privileged assignments (people)	Remaining standing privilege	Down, towards break-glass only
Privileged NHIs with permanent high-privilege roles	Standing privilege on machines	Down
Long-lived cloud keys and static database passwords	Credentials not yet moved to short-lived issuance	Down
Median time from request to access	Whether JIT is fast enough to be used	Down, within an agreed service level
Median activation duration versus maximum	Whether durations fit real tasks	Down
Privileged assignments made outside the JIT system	Bypass and drift	Down, to zero
Eligible assignments without an end date	Eligibility that has become permanent	Down
Break-glass uses with completed post-use review	Emergency access discipline	Up, to 100%

Implementation roadmap

Phase	Actions	Exit criteria
First 30 days	Inventory standing privilege for people and NHIs; set up two break-glass accounts; convert Tier 0 directory and IdP roles to eligible with phishing-resistant activation; alert on assignments outside JIT	No permanent Tier 0 assignments except break-glass
Days 31 to 90	Extend eligibility to cloud, PAM, endpoint management and database admin roles; set risk-tiered durations and approvals; validate tickets automatically; start session monitoring for Tier 0	Elevated-tier roles JIT; time-to-access within service level
Days 91 to 180	Replace long-lived cloud keys with federation; introduce dynamic database secrets; move pipelines to OIDC in protected jobs; give AI agents task-scoped tokens	Long-lived machine credentials falling month on month
After 180 days	Quarterly eligibility reviews; remove remaining permanent assignments; test break-glass; report metrics to the risk committee	Standing privilege limited to documented exceptions

To assess where you are, see the PAM Maturity Model.

Practitioner checklist

Inventory standing privileged access for people, service accounts, app registrations and AI agents.
Convert administrators to eligible, time-bound activation, Tier 0 first.
Require phishing-resistant authentication on every activation, not just at sign-in.
Set short default durations and risk-tiered approvals with no self-approval for Tier 0.
Put end dates on eligibility and review it at least quarterly.
Replace workload standing privilege with short-lived, scoped credentials.
Apply task-scoped JIT access and point-of-use approval to AI agents.
Alert on privileged assignments made outside the JIT system.
Monitor elevated sessions for persistence created during them.
Keep two tested break-glass accounts and alert on every use.
Track standing privilege and time-to-access monthly.

Standards and references

Related NHI Mgmt Group resources: Privileged Access Management Guide · Cloud PAM and CIEM Guide · PAM Buyer's Guide · Zero Trust for AI Agents Guide

Just-in-Time Access and Zero Standing Privilege Guide