Privileged access
Just-in-time access
Privilege that exists only while it is being used: requested, approved, time-bound and removed automatically. How it works and where it usually goes wrong.
Standing privilege is access that exists all the time, whether or not anyone is using it. Just-in-time (JIT) access replaces it with privilege that is granted when needed, for a stated reason, for a limited time, and then removed automatically. Combined with just-enough access (granting the narrowest role that does the job), it shrinks both how long a stolen credential is useful and what it can do.
Standing, just-in-time and zero standing privilege
These are industry terms. SP 800-53 and SP 800-207 do not define "just-in-time access" or "zero standing privilege" for privileged access. In SP 800-53, "just-in-time" appears only in privacy controls, for consent and notices. The underlying ideas do map onto controls (see the next section), and the terms are used consistently enough to define:
- Standing privilege
- A privileged role or group membership held continuously. The account can use it at any moment, including when it has been compromised.
- Just-in-time (JIT) access
- Privilege activated on request, for a bounded time, then revoked automatically. The person keeps their identity. What changes is what that identity can do right now.
- Just-enough access (JEA)
- The elevated grant is scoped to the task: one subscription, one database, one action set. Not a global administrator role.
- Zero standing privilege (ZSP)
- A target state in which no human identity holds privileged access between elevations. In practice, emergency accounts and some service identities remain exceptions, and those exceptions need their own controls.
What the standards say
- AC-6, least privilege. Access "necessary to accomplish assigned organizational tasks". If the task takes two hours a month, privilege held for the other 718 hours is not necessary. See least privilege.
- AC-2(2), automated temporary and emergency account management. "Automatically [remove; disable] temporary and emergency accounts after [organization-defined time period]." The discussion says this should happen on a predefined schedule, "rather than at the convenience of the system administrator". JIT applies the same idea to temporary privilege on a permanent account.
- AC-2(6), dynamic privilege management. Runtime privilege changes instead of static assignments. NIST's example: immediately revoking privileges without requiring users to end and restart their sessions.
- AC-2(8), dynamic account management. Creating, activating and deactivating accounts at runtime. This is the basis for ephemeral admin accounts.
- SP 800-207, tenet 3. "Access to individual enterprise resources is granted on a per-session basis", with "the least privileges needed to complete the task". Authorization to one resource does not carry over to another.
- OMB M-22-09. For US federal agencies, PAM tools that hand out "ephemeral single-factor credentials" for human access should not be a general-purpose substitute for MFA, though the memo calls them "still an important tool" for high-privilege systems that are hard to modernize. The practical reading: put the elevation itself behind strong authentication.
The elevation request lifecycle
Step by step
- Request. The user asks for a specific role on a specific scope for a specific duration, with a reason. A ticket or change reference is better than free text because a reviewer can check it.
- Policy check. Is this user eligible for this role? Is the duration within the maximum? Is the request coming from an admin workstation? Eligibility is itself an entitlement and belongs in access reviews.
- Approval. High-impact roles go to a second person who is not the requester (separation of duties). Lower-impact roles can be self-activated with justification and after-the-fact review.
- Step-up authentication. Require fresh, strong authentication at activation time, ideally phishing-resistant. Otherwise a stolen session cookie is enough to elevate.
- Grant. Add the user to a group or role with a hard expiry, or issue temporary credentials. The system that grants should also be the system that removes.
- Use. Privileged functions are logged (AC-6(9)). Some teams also record sessions for the highest-risk systems.
- Expiry. Removal happens automatically on the timer, whether or not the user remembers (AC-2(2) applies the same principle to temporary accounts).
- Review. Sample completed elevations: did the work match the justification? Are some people elevating every day? That usually means a role is missing.
Mechanisms
| Mechanism | How it works | Watch out for |
|---|---|---|
| Time-bound group or role membership | The identity system adds the user to an admin group or role with an end time and removes them automatically. | Tokens and sessions issued during the window can outlive the membership (see below). |
| Role assumption with temporary credentials | The user, already authenticated, assumes a role and receives credentials that expire on their own, typically after minutes to hours. | Who is allowed to assume the role (the trust policy) is the real entitlement. Review it. |
| Ephemeral accounts | A privileged account is created for the session and deleted afterwards (AC-2(8)). | Audit trails must tie the ephemeral account back to the human. |
| Credential checkout | A PAM tool releases a vaulted password for a shared account and rotates it at check-in. | The account itself still has standing privilege. Checkout reduces who knows the secret, not what the account can do. |
Expiry is not the same as revocation
Removing a group membership usually stops new authorization decisions. It does not necessarily end sessions or tokens already issued. A web console session, a cached Kerberos ticket or an access token issued at minute 59 of a 60-minute grant may stay valid for its own lifetime. Two fixes help: keep token and session lifetimes for admin roles shorter than the grant, and where the platform supports it, revoke sessions when the grant ends. AC-2(6) describes exactly this: immediate revocation instead of waiting for users to restart their sessions.
Design decisions
- Maximum duration. Long enough to finish real work without repeated re-requests, short enough that forgotten grants expire the same day. Many teams use one to eight hours for human admin roles. That is a common practice; no standard sets a number.
- Who approves. Approvers need context: the reason, the target and the requester's recent history. An approval sent to a large group tends to get rubber-stamped by whoever answers first.
- What stays standing. Break-glass accounts, and the identities that run the JIT system itself. List them and monitor them more closely than anything else.
- Failure mode. If the JIT service is down, can anyone administer anything? Document the fallback before you need it.
Common mistakes
- Eligibility granted to everyone in IT, which turns JIT into standing privilege with an extra click.
- Activation protected by the same session that ordinary work uses, with no step-up authentication.
- Durations of days or weeks "so people are not blocked".
- Leaving the old standing assignments in place "for now" after JIT is introduced.
- No alerting on changes to JIT policy, approver lists or eligibility. Whoever can edit those effectively holds every role.
- Treating checkout of a shared admin password as least privilege. It improves accountability, but the account's power is unchanged.
Sources
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).
- NIST SP 800-207: Zero Trust Architecture, NIST. Public domain (U.S. government work).
- OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).