Just-in-time privilege elevation, not standing admin

What the control is

Just-in-time privilege elevation is the architectural pattern in which administrative access is granted to a user on a per-task basis, for a bounded time window, with auditable approval, rather than being a permanent property of the user’s account. A user who needs to perform a privileged action requests elevation for a defined scope — a specific resource, a specific role — and the elevation is granted for a fixed duration, typically four hours or less. When the duration expires, the privilege evaporates automatically. The user’s day-to-day account holds no standing privileged rights.

The control inverts the default. In the standing-admin model, the account is the privilege; in JIT, the privilege is a request. The shift maps onto the principle of least privilege articulated in NIST SP 800-53 control AC-6 and the broader Zero Trust direction articulated in NCSC and NIST guidance.

JIT does not require a single product or vendor pattern. Microsoft’s Privileged Identity Management is one implementation; equivalent native capabilities exist in AWS IAM Identity Center, GCP IAM Conditions, and the major cloud-native and on-prem PAM ecosystems. The key architectural decision — making elevation a request-and-grant flow rather than a permanent assignment — is implementation-independent.

Why it matters

Standing admin rights make every privileged-account-credential-theft incident immediately catastrophic. The attacker who steals the credential operates with the same window and scope as the legitimate admin: at LastPass, the compromised DevOps engineer’s credentials gave persistent access to the vault backup; at Wynn Resorts, the compromised employee credential into Oracle PeopleSoft sat next to standing HR-administrator rights, allowing 800,000 employee records to be exfiltrated over five months; at Operation Aurora, the persistent admin access in Google’s source-code management infrastructure was the prize that made the campaign worthwhile; at the OPM breach, contractor credentials with standing federal-IT access were the entry vector; at SolarWinds Sunburst, build-pipeline credentials with standing capability to sign updates were the door. Uber’s 2022 Lapsus$ event, MGM’s 2023 vishing-led ransomware, and Sony Pictures’ 2014 Guardians of Peace event followed the same pattern: credential theft into a standing-privilege role becomes immediate operator capability.

JIT changes the geometry of every one of those incidents. A stolen credential without elevation rights is far less useful: the attacker has to either steal the credential and time the elevation request to land within the legitimate admin’s working window, or compromise the elevation-approval channel as well as the credential. Both raise the cost of the attack and create new detectable signals — an unexpected elevation request, an off-hours approval flow, a peer-review approval that an attacker cannot easily fake.

The control does not stop initial access. It stops a single compromised privileged account from being the keys to the entire kingdom for as long as the attacker chooses to retain access.

Where the regulators sit

NCSC’s privileged-user-management guidance is direct: standing privileged access should be the exception, not the default, and access should be time-bound and reviewed. NIST SP 800-53 control AC-6 (“Least Privilege”) is the foundational US-government standard and is mandatory across federal civilian and defence systems via NIST SP 800-171 and FedRAMP. CIS Controls v8 splits the work across Control 5 (Account Management) and Control 6 (Access Control Management), with explicit sub-controls for privileged-access workflows. Microsoft’s Privileged Access Strategy publishes the architectural pattern that underpins Privileged Identity Management. NCSC’s Zero Trust Architecture design principles point at JIT as part of the implementation.

The framework view is unanimous. The implementation choice is the open question, not whether to do it.

Where it usually breaks

Two failure modes account for most stalled JIT programmes. The first is the inventory problem. Most enterprises do not have a current map of every privileged role across every platform — the AD admin tier, the cloud-tenant root, the database admin populations, the application-tier admins, the CI/CD service-account population, the SaaS-tenant admin roles. JIT requires that map. The fix is to start with the highest-blast-radius roles — domain admin, cloud root, code-signing — and migrate them first, leaving the long tail for subsequent quarters.

The second is the approval-flow politics. JIT elevation needs an approver, and the approver population needs to be available, accountable, and trained. The temptation is to default to “self-approval after MFA,” which collapses the control to a single-factor improvement. The better pattern is peer-or-supervisor approval for the highest-tier roles, with an explicit break-glass procedure for the legitimate emergency case. The break-glass procedure is auditable, reviewed monthly, and used rarely.

What good looks like

Every privileged role across the estate inventoried with a documented owner. Standing privileged access reduced to break-glass-only on the highest-tier roles. JIT elevation flows defined per role with appropriate approval requirements and time windows. All elevation requests, approvals and grants logged and retained for audit. A monthly review of break-glass usage. No service or application accounts holding the same standing privilege as user accounts.

The cost is the inventory work and the platform investment. The benefit is that the catastrophic-credential-theft scenario becomes a much harder problem for the attacker.