Just-in-Time Access: Least Privilege Done Right

In victim environments of the SolarWinds campaign, SUNBURST operators reached high-privilege credentials quickly — often not by escalating privileges, but by finding service accounts that carried standing administrative membership nobody had used or reviewed in months. Standing privileges are pre-positioned attack infrastructure that you pay for. Every account with persistent administrative access is an open invitation that requires zero exploitation skill to abuse once credentials are obtained.

Why This Matters Now

The Okta breach chain of 2023 demonstrated credential theft at industrial scale. Attackers compromised a support engineer's account and immediately had access to customer tenants — not through a clever exploit, but through standing access that existed because "the engineer might need it someday." When NIST 800-207 codified zero-trust principles, it specified per-session access decisions as a foundational requirement, not an aspirational goal. CISA's Zero Trust Maturity Model now requires "advanced" maturity organizations to implement time-limited access as a baseline control, not a differentiator.

The regulatory pressure is real: NIST 800-53 Rev 5 explicitly calls out time-bounded privilege in AC-6, CMMC Level 2 maps least privilege to every assessment objective in the Access Control domain, and FedRAMP now evaluates JIT capability during authorization assessments. Organizations still running standing privileges are accumulating both risk debt and compliance debt simultaneously.

The Standing Privilege Problem

The numbers tell a consistent story across industry research. The average enterprise has 3-5x more privileged accounts than employees who need them. Service accounts with Domain Admin persist for years without rotation. Shared administrative credentials get passed through Slack messages and sticky notes. A typical mid-market organization has between 40 and 80 accounts with standing Domain Admin access; fewer than 10 of those accounts use elevated privileges in any given week.

This isn't theoretical risk. Standing privileges reduce the cost of an attack to zero marginal effort. An attacker who compromises any one of those 40-80 accounts doesn't need to escalate — they land with full administrative capability. The SolarWinds compromise proved this at nation-state scale, but the same dynamic plays out in commodity ransomware operations daily. Groups like Conti and LockBit explicitly target accounts with standing Domain Admin because the payoff is immediate and guaranteed.

The operational cost is equally problematic. When every administrator has persistent elevated access, you cannot distinguish legitimate administrative activity from compromise-driven activity in your logs. The signal is buried in noise. Your SOC sees Domain Admin authentications constantly, so an additional one at 2 AM on a Saturday doesn't trigger investigation. JIT changes the baseline: any elevated access outside an approved window is immediately anomalous and actionable.

How JIT Access Works

The JIT lifecycle is a five-phase process with audit as a continuous thread, not a final step:

Request. A user identifies a specific task requiring elevated access and submits a request with justification, target systems, and requested duration. The request itself becomes an audit artifact — the "why" is captured before access is granted, not reconstructed after an incident.

Approve. Policy evaluation occurs against predefined rules. Low-risk requests during business hours may auto-approve within seconds. High-risk requests route to human approvers with full context: who is requesting, what they need, why they need it, and historical access patterns for that user. Approval can factor in real-time risk signals — is the user's device compliant, are they authenticating from an expected location, does threat intelligence indicate active targeting of this system?

Grant. Privileges activate with a hard time boundary. The user receives elevated access through whichever mechanism matches the environment: temporary group membership, credential checkout, role activation, or network ACL modification. The grant includes an explicit expiration — not "until revoked" but "until 14:30 UTC today."

Use. The user performs their administrative task. All activity during the elevated session is logged with elevated scrutiny. Session recording, command logging, and behavioral analytics apply during the access window because the system knows elevated access is active.

Revoke. When the time expires — or when the user explicitly releases access early — privileges are removed automatically. No human action required. Credentials rotate, group memberships drop, network ACLs revert. The attack window closes regardless of whether the user remembered to "log out."

This lifecycle reduces the attack surface from 8,760 hours per year (standing) to the actual hours of legitimate administrative use — typically 20-100 hours per year for most administrators.

JIT for Different Access Types

Privileged Account Management

The most mature JIT pattern: administrators check out privileged credentials from a vault for a defined period. The credentials are unique per checkout, rotate automatically after use, and are never stored on the administrator's workstation persistently. If the admin's laptop is compromised at 3 PM and their last checkout expired at noon, the attacker gets nothing.

This integrates with existing PAM solutions — CyberArk, BeyondTrust, Delinea, or HashiCorp Vault all support time-bounded credential checkout. The key architectural decision is whether the vault provides actual credential rotation (stronger) or merely access-gate enforcement (weaker, since the underlying credential remains static).

Role Elevation

The user keeps their standard identity but requests temporary elevation to a privileged role. In Entra ID environments, Privileged Identity Management (PIM) implements this natively — a user activates their eligible Global Admin assignment for two hours, performs the task, and the activation expires. In on-premises Active Directory, temporary group membership with TTL (introduced in Windows Server 2016 functional level) provides the equivalent capability.

Role elevation is architecturally preferable to credential checkout when you need unified audit trails. The user's identity is consistent across their standard and elevated sessions, making correlation trivial. The tradeoff: if the user's primary credential is compromised, the attacker can potentially request elevation (mitigated by step-up MFA requirements on activation).

Just-in-Time Network Access

Combine JIT with Comply-to-Connect and zero-trust network architecture: devices get network-level access to sensitive segments only when a JIT request is approved. A database administrator's workstation cannot reach the production database network until an approved session activates the necessary firewall rules or micro-segmentation policy. When the session expires, the network path ceases to exist.

This approach is particularly relevant for environments implementing CAC/PIV authentication where the network boundary and the identity boundary must agree. The access decision isn't just "is this user authorized?" but "is this user authorized, right now, from this device, for this specific network path?"

Application-Level JIT

Privileges within applications are elevated temporarily. A developer receives production database read access for a two-hour debugging session. A security analyst gets write access to detection rules for a one-hour deployment window. A compliance officer gets export permissions for evidence artifacts during a four-hour audit preparation session.

Application-level JIT is the least mature category in most environments but arguably the most impactful for reducing insider risk. Standing application permissions represent the majority of actual data access in modern organizations — most employees interact with data through applications, not through operating system privileges.

Break-Glass Procedures

Here is the contrarian take that needs stating: JIT access with a 24-hour window is just standing access with extra steps. If your "just-in-time" grants last an entire shift, you haven't reduced the attack window meaningfully — you've just added a request form in front of it. This same logic applies to break-glass design. A break-glass procedure that provides unconstrained access with no time limit and "we'll review it later" is standing access that you've given a different name.

Effective break-glass procedures have these properties:

Immediate but bounded. Emergency access grants immediately without prior approval but with a hard time limit — typically one to two hours. If the emergency isn't resolved in that window, a new break-glass request is required, which creates a forcing function for escalation and handoff.

Loud by design. Break-glass usage fires immediate alerts to the security team, the user's manager, and the system owner. Not a log entry that someone reviews next Tuesday — an active notification within minutes. The social pressure of visibility deters abuse more effectively than approval workflows.

Tested regularly. Break-glass procedures that haven't been tested in six months are break-glass procedures that don't work. Include break-glass activation in quarterly tabletop exercises and validate the technical path monthly through automated testing.

Post-hoc review is mandatory, not optional. Every break-glass usage triggers a formal review within 24 hours. The review examines whether the usage was justified, whether the scope was appropriate, and whether the triggering event indicates a gap in normal JIT workflows that should be addressed.

Compliance Alignment

JIT access directly satisfies least privilege requirements across every major compliance framework, and provides superior audit evidence compared to periodic access reviews:

Framework	Requirement	How JIT Satisfies
NIST 800-53 Rev 5	AC-6: Least Privilege	Privileges granted only when needed, automatically revoked
NIST 800-171	3.1.5-3.1.6	Time-limited, justified access with continuous logging
SOC 2 Type II	CC6.1-CC6.3	Access restricted to authorized periods with evidence
ISO 27001	A.8.2 (2022)	Privileged access rights managed with temporal controls
PCI DSS v4	Req 7.2	Access restricted by business need with defined periods
CMMC Level 2	AC.L2-3.1.5	Least privilege enforced through temporal access controls
FedRAMP	AC-6(1)(2)	Automated enforcement of least privilege with full audit

The compliance advantage of JIT over standing-privilege-with-periodic-review is the quality of evidence. During an audit, demonstrating that "this account had Domain Admin for 47 minutes on March 3rd to perform a specific configuration change" is categorically stronger evidence of least privilege than "we reviewed this account's access in January and it seemed appropriate." Continuous monitoring of JIT lifecycle events produces audit evidence that is granular, timestamped, and justified — exactly what assessors want to see.

Implementation Considerations

Start with High-Risk, Low-Volume

Don't attempt to JIT-enable every access type simultaneously. Start with Domain Admin and equivalent tier-zero accounts. These accounts represent your highest risk (full domain compromise on theft) and lowest volume (legitimate use is infrequent). The operational disruption is minimal because legitimate Domain Admin usage should already be rare.

Once tier-zero is under JIT control, expand to tier-one (server administrators, database administrators, security tooling administrators) and then to application-level privileges.

Approval Workflow Design

Match approval rigor to risk, not to organizational hierarchy:

Auto-approve for low-risk, high-frequency requests with established patterns (read-only access to non-production, access during business hours by users with clean history)
Single approver for standard administrative tasks during business hours
Dual approval for production-impacting changes, security configuration modifications, or access to systems containing CUI/PHI/PCI data
Time-delayed approval for non-urgent requests (request today, access grants tomorrow) which prevents social-engineering pressure

Time Limit Discipline

Default durations should be aggressive. You can always extend; you cannot un-compromise:

Debugging and investigation: 1-2 hours
Standard administrative tasks: 2-4 hours
Planned maintenance windows: 4-8 hours
Maximum single grant: 8 hours

Anything beyond 8 hours should require a new request. A "JIT" grant lasting 24 hours provides approximately zero security benefit over standing access for most threat models — the attacker's operational timeline for credential abuse, lateral movement, and objective completion is measured in minutes to hours, not days.

Integration with Identity Governance

JIT access doesn't replace identity governance — it complements it. Governance determines what access a user is eligible to request. JIT determines when that eligible access is active. The combination means users can only request access they're authorized for, and that authorized access only exists during approved windows.

Integrate JIT telemetry with SSO for unified session visibility and with your continuous monitoring program for anomaly detection on elevated sessions.

Key Takeaways

Standing privileges are pre-positioned attack infrastructure. Every account with persistent admin access is a free lateral movement path for any attacker who obtains credentials.

JIT reduces the attack window from 8,760 hours/year to actual usage hours (typically 20-100), making compromise detection trivially easier because any elevated access outside an approved window is immediately anomalous.

Break-glass procedures must be bounded, loud, tested, and reviewed — not "standing access by another name."

Start with tier-zero accounts (Domain Admin equivalents) where risk is highest and legitimate usage is least frequent.

Time limits under 8 hours are the only grants that meaningfully reduce attacker operational timelines. A 24-hour JIT window is compliance theater.

JIT evidence quality (per-session justification with timestamps) is categorically superior to periodic access reviews for audit purposes.

Frequently Asked Questions

How does JIT access work when administrators are in different time zones?

JIT is session-based, not clock-based. The access window starts when the request is approved and expires after the defined duration, regardless of local time. Approval routing can be time-zone-aware — routing to approvers who are currently working — but the access grant itself is duration-bounded from activation. Global teams typically implement follow-the-sun approval pools rather than time-restricted request windows.

Does JIT access create operational friction that slows down incident response?

This is the most common objection, and it's valid if your break-glass procedures are poorly designed. A well-implemented JIT system provides emergency access within seconds through break-glass — faster than most administrators can type credentials from a password manager. The friction exists for routine access, which is the point: routine administrative access should require a moment of intentionality. For incidents, break-glass bypasses all approval workflows and grants immediately, with post-hoc review as the accountability mechanism.

What's the difference between JIT access and Privileged Access Management (PAM)?

PAM is the broader discipline; JIT is a specific enforcement pattern within it. PAM encompasses credential vaulting, session recording, access governance, and analytics. JIT specifically addresses the temporal dimension — when privileges are active. You can have PAM without JIT (vaulted credentials that are always available) or JIT without full PAM (time-bounded role activation without session recording). The strongest posture combines both: vaulted credentials that are only accessible during approved JIT windows, with full session recording during the access period.

How do you handle JIT for service accounts and non-human identities?

Service accounts are the hardest JIT problem because they often need access continuously for application functionality. The honest answer: most service accounts cannot be fully JIT-enabled without application redesign. The practical approach is threefold. First, reduce service account privilege to the actual minimum (most have Domain Admin because someone copied a config). Second, implement credential rotation on short intervals (hours, not months). Third, for service accounts that truly need persistent access, implement behavioral monitoring that alerts on deviation from established patterns — the service account equivalent of session anomaly detection.

Is JIT access required for CMMC Level 2 certification?

JIT is not explicitly named as a requirement, but the assessment objectives for AC.L2-3.1.5 (least privilege) and AC.L2-3.1.6 (least privilege for security functions) are extremely difficult to satisfy with standing privileges alone. Assessors evaluate whether your organization "employs the principle of least privilege" — and an assessor who sees 60 accounts with persistent Domain Admin will reasonably question whether least privilege is employed in practice. JIT provides the strongest possible evidence that elevated access is granted only when needed and revoked when complete, which maps directly to the assessment objective's intent.

How Advisedly Helps

Advisedly maps JIT access controls across your environment as part of zero-trust architecture and identity governance compliance programs, providing continuous evidence that least privilege enforcement meets assessment objectives across 500+ compliance frameworks simultaneously. The platform tracks JIT lifecycle events as audit artifacts, correlates access grants with framework requirements, and generates assessor-ready evidence packages that demonstrate temporal access control for NIST 800-171, CMMC, FedRAMP, and SOC 2 without requiring your team to manually document each access decision: begin@advisedly.ai