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, for as long as it is needed, and zero standing privilege (ZSP) is the goal of having no permanent privileged access at all. This guide explains JIT and ZSP for people, workloads and AI agents, how to implement them and how to avoid the usual pitfalls.
Key takeaways
- JIT reduces the time window in which a compromised identity can be used for privileged actions; ZSP removes the window entirely outside approved use.
- Patterns include time-bound role activation, ephemeral accounts, short-lived credentials and approval workflows.
- JIT must be fast and reliable, or engineers will work around it. Design for low friction on routine tasks and stronger checks for high-risk ones.
- Apply JIT to non-human identities and AI agents too: short-lived, task-scoped credentials are JIT for machines.
- Keep break-glass access for emergencies, tightly controlled.
JIT patterns
| Pattern | How it works | Examples |
|---|---|---|
| Time-bound role activation | User is eligible for a role and activates it for a limited period, with MFA and optional approval | Privileged role activation in cloud directories; temporary group membership |
| Ephemeral accounts | A temporary account is created for the task and deleted afterwards | Temporary database users; ephemeral local admin accounts |
| Short-lived credentials | Credentials are issued on demand and expire quickly | Cloud STS credentials; SSH certificates; dynamic database secrets |
| Brokered sessions | User connects through a PAM gateway that injects credentials they never see | Session-managed server and database access |
| Approval-based elevation | Access granted after peer or manager approval, tied to a ticket | Production changes; access to sensitive data |
Designing JIT policy
- Define eligibility: who may request which privilege, based on role.
- Set durations: default short (for example, one to four hours), with maximums per privilege level.
- Require strong authentication at activation: phishing-resistant MFA. See the Passwordless and Passkeys Guide.
- Tier approvals by risk: self-approval with justification for routine tasks; peer or manager approval for high-risk ones.
- Link to change or incident tickets for audit context.
- Record and monitor privileged sessions. See the Privileged Session Management Guide.
Moving towards zero standing privilege
- Inventory standing privilege: permanent admin roles, privileged group memberships, owner rights and privileged service accounts.
- Convert people first: make administrators eligible rather than permanently assigned.
- Remove unused privilege: use activity data to remove access nobody uses.
- Address workloads: replace standing service account privilege with short-lived, scoped credentials.
- Keep break-glass: a small number of emergency accounts with standing privilege, heavily controlled. See the Break-Glass Account Guide.
- Measure: number of standing privileged assignments, activation volume and time to access.
JIT for non-human identities
- Replace long-lived cloud keys with role assumption and federation, which issue short-lived credentials. See the NHI Authentication Guide.
- Use dynamic secrets for databases. See the Secrets Management Guide.
- For automation that needs occasional elevated rights, use a separate privileged identity activated only for that job.
- Pipelines should obtain deployment credentials only in protected jobs. See the CI/CD Pipeline Identity 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. High-impact actions should require approval at the moment of use rather than standing permission. See the AI Agent Authorisation Guide.
Common pitfalls
- Too much friction: slow approvals lead engineers to request maximum durations or create backdoor accounts.
- Eligible but never reviewed: eligibility lists grow unchecked; review them like access.
- Long default durations that make JIT little different from standing access.
- Persistence after activation: users creating keys or accounts during an elevated session that outlive it. Monitor for this.
- Break-glass used routinely.
Practitioner checklist
- Inventory standing privileged access for people and NHIs.
- Convert administrators to eligible, time-bound activation with MFA.
- Set short default durations and risk-tiered approvals.
- Replace workload standing privilege with short-lived credentials.
- Apply task-scoped JIT access to AI agents.
- Monitor elevated sessions and look for persistence created during them.
- Review eligibility regularly and measure standing privilege over time.
Standards and references
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-53 Rev. 5 (AC-6 Least Privilege)
- ASD Essential Eight: Restrict administrative privileges
- OWASP Non-Human Identities Top 10 (2025): NHI5, NHI7
Related NHI Mgmt Group resources: Privileged Access Management Guide · Cloud PAM and CIEM Guide · PAM Buyer's Guide · Zero Trust for AI Agents
