Just-in-time access gives a person or workload elevated rights only when needed and only for a limited time, then removes them automatically. It reduces standing privilege, so a stolen account holds fewer powers most of the time. Start with your most powerful roles and keep an approval and audit trail.
What problem does JIT solve?
Permanent admin rights are convenient and dangerous. An engineer who is an administrator all year is an administrator for any attacker who steals their session at 3 a.m. on a Sunday. Most of those hours the rights were not used.
NIST SP 800-53 states the principle of least privilege as allowing only the accesses that are necessary to accomplish assigned tasks. JIT adds the time dimension: necessary now, not necessary tomorrow.
What does the standards material say?
NIST SP 800-53 has a control enhancement called Dynamic Privilege Management, AC-2(6). The organization defines what dynamic privilege management it implements, which is the formal home for the idea that privileges change as conditions change.
NIST SP 800-207 on zero trust is closer in spirit. One of its tenets is that access to individual enterprise resources is granted on a per-session basis. The same document says trust is evaluated before access is granted, and access should use the least privileges needed to complete the task. JIT is one practical way to meet that.
How does JIT work in practice?
The pattern has four steps. A person requests a role for a purpose and a duration. A rule or a human approves, depending on risk. The system grants the role and sets an expiry. The grant and every action under it are logged, and the role is removed when time is up or the work is closed.
Variations exist. Some systems issue short-lived credentials instead of changing a role. Others open a network path for a set window. For workloads, the equivalent is credentials that live minutes, not months.
Workloads need the same treatment. A deployment job that holds a permanent cloud key is standing privilege in the same way a human admin is. Prefer credentials issued per run that expire in minutes, so a leaked log line or a copied token is worthless soon after.
What can go wrong?
Approval fatigue is the main one. If every request needs a manager's click, people approve without reading, or they find ways around the process. Reserve human approval for high-risk roles and automate low-risk grants against rules such as being on call.
Break-glass access is another. If the JIT system itself is down during an incident, someone must still get in. Keep a break-glass account with strong controls, alerts on use, and a review after every use.
Long windows also defeat the idea. An eight-hour grant that is always extended is standing access with extra steps. Track extension rates.
A constructed example
A platform team of twelve has five people with permanent production admin. They list what the admin role was used for over the last 90 days and find that most uses were three tasks: restarting a service, reading logs and rotating a certificate. They create narrow roles for those three, available on request for two hours with automatic approval for the on-call engineer. Full admin becomes a four-hour grant with a second approver and a ticket number. Permanent admin drops from five people to a break-glass account. Weeks later a phished engineer account is found, and the attacker has only read access to staging.
How to check or apply this
- Inventory privileged roles and who holds them permanently.
- Pull usage data and find what each role is really used for.
- Create narrower roles for the common tasks.
- Choose a grant duration per role, and cap extensions.
- Require a reason or ticket on each request and log it.
- Alert on break-glass use and review it within a day.
- Measure the share of privileged access that is standing versus time-bound, and report it monthly.
Quick check
Is JIT the same as least privilege?
It supports it. Least privilege limits what rights exist. JIT limits when they exist.
Does JIT replace MFA?
No. Strong authentication is still required before any grant is issued.
Sources
- NIST SP 800-53 Rev. 5 controls catalog (OSCAL), AC-6 and AC-2(6)
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
