Credential Vaulting vs Just-in-Time Elevation in PAM

Privileged access programmes usually start by vaulting shared admin passwords, then discover that a vaulted credential which never expires is still standing privilege, and that just-in-time elevation solves a different part of the same problem. This guide compares the two PAM architectures directly: credential vaulting, where the privileged account exists permanently and the secret is checked out under control, and just-in-time (JIT) elevation, where the privilege itself is granted for a task and removed afterwards. It covers what each protects against, where each fails, when to choose which, and how mature programmes combine them. It is for PAM owners, identity architects and security leaders choosing or reshaping a PAM design. Background on each pattern lives in the Privileged Access Management Guide and the JIT Access Guide.

Key takeaways

Vaulting controls the secret; JIT controls the privilege. A vault decides who may use a standing privileged account and records it. JIT decides whether the privilege exists at all at a given moment.
Each closes a different gap. Vaulting fixes shared, unknown and unrotated passwords. JIT fixes permanent role assignments and dormant admin rights that attackers inherit when they compromise an account.
Eligible is not the same as safe. Microsoft's PIM documentation notes that an eligible role grants the same access as an active one once activated, so activation controls (MFA, approval, justification) carry the weight.
Some privilege cannot be made just in time. Local administrator, network device, database and break-glass accounts often have to exist permanently, so they still need vaulting and rotation.
Mature programmes use both. JIT for directory and cloud roles, vaulting with rotation and session brokering for accounts that must persist, and a shared approval and audit trail across them.

What each architecture is

Credential vaulting

The privileged account exists all the time, with its full rights. Its password, key or certificate is stored in a vault that controls checkout, requires approval for sensitive accounts, rotates the credential on a schedule or after use, and often brokers the session so the user never sees the secret. The control point is the credential. Discovery and onboarding of accounts into the vault is the first major workstream; see the Privileged Account Discovery and Onboarding Guide. A narrow example of the vaulting model built into an operating system is Windows LAPS, which Microsoft describes as rotating each device's local administrator password and backing it up to Microsoft Entra ID or Active Directory so that devices do not share one password attackers can reuse to move laterally.

Just-in-time elevation

The user (or workload) has a normal identity with no standing privilege, and is eligible to receive a privileged role or group membership for a limited time after meeting conditions: MFA, justification, approval, ticket reference. When the time ends the privilege is removed. The control point is the entitlement. NIST SP 800-53 Rev 5 supports this pattern through AC-2(2) Automated Temporary and Emergency Account Management and AC-6 Least Privilege. Variants include temporary role assignment, temporary group membership, ephemeral accounts created for a session and deleted afterwards, and endpoint elevation of a single process.

Cloud and directory platforms document native JIT features. Platforms are listed alphabetically:

AWS: the IAM Identity Center documentation describes temporary elevated access as a way to request, approve and track use of a permission for a specific task during a specified time, supplementing permission sets and MFA, and delivered through validated partner solutions.
Google Cloud: Privileged Access Manager defines entitlements (eligible principals, roles, maximum grant duration, justification, optional approvers) and grants, revokes roles automatically when the grant ends, and logs events to Cloud Audit Logs.
Microsoft Entra: Privileged Identity Management provides eligible and active assignments, time-bound access, approval, MFA on activation, justification, notifications, access reviews and audit history.

Availability: Microsoft documents that PIM requires Microsoft Entra ID Governance or equivalent licences. Google documents some Privileged Access Manager features, such as multi-level approvals and grant scheduling, as Preview, with some requiring Security Command Center Enterprise or Premium. AWS directs customers to review partner solutions against their own needs and budget.

Side-by-side comparison

Property	Credential vaulting	Just-in-time elevation
Control point	The credential of a standing privileged account	The privilege assignment itself
Standing privilege	Yes: the account always holds its rights	No, or minimal: rights exist only during the grant
Who is accountable	Shared account; attribution comes from checkout and session records	Named identity holds the role; attribution is native
Main threat addressed	Unknown, shared, reused and unrotated passwords; credential theft from scripts and files	Dormant admin rights inherited by an attacker who takes over a user or workload
Residual risk	The account can be used outside the vault if the secret leaks before rotation; the vault becomes a high-value target	Activation can be abused by whoever controls an eligible identity; role definitions may be too broad
Works for	Local admin, root, network devices, databases, legacy apps, break-glass, service accounts	Directory roles, cloud IAM roles, SaaS admin roles, groups, endpoint elevation
Session control	Commonly brokered and recorded through the PAM proxy	Depends on the platform; often audit events rather than recorded sessions
Rotation need	Central: rotate on schedule and after checkout	Low for the privilege; the user's own credential still needs strong authentication
Failure mode at outage	Vault outage blocks admin work unless break-glass exists	Approval or activation service outage blocks elevation unless break-glass exists

Choosing: decision guidance

Target	Preferred pattern	Why
Entra ID, Active Directory admin groups, cloud IAM admin roles	JIT elevation of named accounts	Platform supports eligibility; removes permanent admin membership
Windows local administrator on endpoints and servers	Vaulting with per-device rotation (for example LAPS) plus endpoint elevation for users	The account must exist; unique rotated passwords stop lateral movement
Linux root and sudo	JIT sudo rules or certificate-based access where possible; vaulting for root	Root persists; sudo rights can be granted for a window
Network devices, appliances, OT systems	Vaulting with session brokering	Few support external role assignment
Databases	Vaulting, or dynamic short-lived database users issued per session	Built-in admin accounts persist; dynamic users approximate JIT
SaaS administrator roles	JIT where the SaaS supports it, otherwise vaulting of a dedicated admin account	Support varies by application
Break-glass accounts	Vaulting with dual control, monitoring and post-use rotation	Must work when JIT and federation are down; see the Break-Glass Account Guide
Service accounts and workloads	Workload identity and short-lived tokens first; vaulting with rotation where a static secret remains	Machines cannot approve their own elevation interactively

Small organisations often get the largest risk reduction from turning on the JIT feature of their identity or cloud platform for the handful of global administrator roles, plus LAPS or equivalent for local admin, before buying a full vault. Large organisations usually already vault thousands of accounts; the next step is to remove standing directory and cloud roles through JIT, and to put both under one request, approval and audit process. Regulated environments that require session recording for specific systems will keep a brokered vault path for those systems regardless.

Security trade-offs in detail

Vault concentration: a vault holds keys to everything, so its own admins, recovery keys, backups and integration credentials need the strictest controls. Embedded credentials that let scripts call the vault are a known weak point. See the PAM vault health check.
Rotation gap: a vaulted password that is checked out and not rotated after use is a standing credential in the user's hands until the next scheduled change.
Activation is the new perimeter: with JIT, the security of privileged access is the security of the eligible account plus the activation step. Require phishing-resistant MFA at activation and approval for the highest roles; Microsoft's privileged access strategy notes that implementing a PIM/PAM solution alone is not sufficient.
Role design: JIT grants the whole role. A broad role activated for eight hours is still broad; define task-sized roles and short maximum durations.
Self-approval and approval fatigue: approvers who rubber-stamp requests turn JIT into standing access with extra steps. Track approval times and denials.
Platform bindings: Google documents that Privileged Access Manager works by adding and removing role bindings with time conditions, and that manually changing those bindings can break its behaviour. Treat platform JIT bindings as managed objects.

How they work together

A combined architecture uses one request and approval workflow, with two fulfilment paths. For roles the platform can grant temporarily, the workflow activates an eligible assignment for a named identity. For accounts that must persist, the workflow releases a vaulted credential or opens a brokered session, then rotates the credential after use. Some PAM platforms also create ephemeral local accounts or grant temporary group membership, which brings JIT behaviour to targets that previously needed vaulting. Session records, activation logs and checkout logs go to the same SIEM so reviewers see one trail. The Cloud PAM and CIEM Guide covers the cloud side of this design.

Where non-human identities fit

Both patterns were designed around people, and both need adapting for machines. A service account, automation runbook or AI agent cannot answer an MFA prompt or wait for a human approver on every run, so interactive JIT rarely fits directly. The machine equivalents are:

Short-lived, federated credentials issued per run, such as cloud workload identity or OIDC federation from CI, which give JIT behaviour without a stored secret. See the Workload Identity Federation Guide.
Dynamic secrets issued by a secrets manager with a lease, which approximate JIT for databases and other targets that need a username and password.
Vaulting with automatic rotation for service accounts whose password must persist, with the consuming application reading the current value from the vault rather than holding a copy.
Human approval at the right level: approve the pipeline change or the agent task, not each credential use, and scope the machine role so that the approved task is all it can do.

Count machine accounts with standing privilege in the same metrics as human ones; they usually outnumber them.

How to implement: phased approach

Discover: inventory standing privileged role assignments in directories, cloud and SaaS, and privileged local, device, database and service accounts.
Classify each as JIT-capable (the platform supports eligible or time-bound assignment) or persistent (must be vaulted).
Quick wins: convert top-tier directory and cloud admin roles to eligible assignments with MFA and justification; enable per-device local admin rotation.
Vault the persistent accounts by tier, starting with domain-level and production database accounts, with rotation after checkout.
Pilot: run JIT for one admin team first, with a fallback eligible path and documented break-glass, and measure activation friction for two to four weeks.
Remove standing assignments once the pilot holds; keep a short list of approved exceptions with owners and review dates.
Roll back by temporarily restoring a time-bound active assignment for a named user, never by re-adding permanent group membership, and record it as an incident.
Unify audit and run periodic reviews of eligibility as well as active assignments.

Detection and measurement

Monitor: role activations outside business hours or without a linked ticket; activations of the highest roles; repeated activation of the same role by the same person (a sign the role should be redesigned or the person needs a different path); privileged role assignments created outside the JIT tool; vault checkouts of accounts not followed by rotation; logons by vaulted accounts that did not come through the vault or broker, which indicate the secret is in use elsewhere. See the Privileged Session Management Guide.

Metrics:

Standing privileged role assignments for humans (target close to zero outside break-glass).
Percentage of persistent privileged accounts under vault control with automatic rotation.
Median activation duration versus maximum allowed.
Privileged logons not originating from the vault, broker or JIT workflow.
Approval turnaround time and denial rate for high-tier roles.
Time from checkout to rotation for vaulted accounts.

Common failure patterns

Vaulted but never rotated: accounts are onboarded but rotation is off because an application would break, so the vault is an expensive password list.
Credentials outside the vault: admin credentials remain in scripts and shares. In the Uber Breach 2022 the attacker claimed to have found a script with hard-coded admin credentials on an internal share.
JIT over permanent roles: eligible assignments are added but the old permanent assignments are never removed.
Weak activation: activation requires only the same session that signed in, without fresh MFA or approval, so an attacker with the session activates the role.
Oversized roles: the only eligible role is a global administrator role, used for small tasks.
No break-glass path: a vault or identity provider outage blocks all privileged access, prompting emergency permanent assignments that are never removed.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-2(2) Automated Temporary and Emergency Account Management; AC-2(7) Privileged User Accounts	Temporary privileged assignment and role-based privileged accounts
NIST SP 800-53 Rev 5	AC-6(5) Privileged Accounts; AC-6(9) Log Use of Privileged Functions	Restricting and logging privilege
NIST SP 800-53 Rev 5	IA-5(1) Password-based Authentication; IA-5 Authenticator Management	Vaulted credential lifecycle and rotation
NIST CSF 2.0	PR.AA-05; PR.AA-01	Least privilege; managed credentials
MITRE ATT&CK	T1078.002 Domain Accounts; T1078.004 Cloud Accounts; T1555 Credentials from Password Stores	Abuse of standing privileged accounts and of credential stores
MITRE ATT&CK mitigation	M1026 Privileged Account Management; M1032 Multi-factor Authentication	Core mitigations for both patterns
ISO/IEC 27001:2022 Annex A	A.8.2 Privileged access rights; A.5.17 Authentication information	Allocation of privilege and secret management

Practitioner checklist

Inventory standing privileged assignments and privileged accounts separately.
Mark each target JIT-capable or persistent.
Make top-tier directory and cloud admin roles eligible, not active.
Require phishing-resistant MFA and justification at activation; approval for the highest tier.
Vault every persistent privileged account and rotate after checkout.
Rotate local administrator passwords per device.
Define task-sized roles and short maximum activation durations.
Keep two monitored break-glass accounts outside the JIT dependency.
Alert on privileged logons that bypass the vault, broker or JIT workflow.
Review eligibility, not only active assignments, at each access review.

Credential Vaulting vs Just-in-Time Elevation: Choosing a PAM Architecture