Just-in-Time Access as a Control Derived From Privilege Escalation Incidents

Just-in-time access exists because standing privilege is the mechanism that turns a stolen password into a stolen kingdom. This piece treats JIT not as a best practice someone wrote down in a framework, but as a direct engineering response to a pattern visible across incident after incident: credentials that stayed powerful long after anyone needed them to be. The argument is structural. Removing the standing privilege leaves the escalation step an attacker depends on with nothing left to exploit.

Standing privileges as the structural precondition for privilege escalation

A credential that grants administrative access produces administrative compromise the moment it's stolen, whether or not the legitimate owner happens to be logged in. That's the mechanical core of the problem: the cost of a stolen credential scales with whatever scope that credential already carried, not with how sophisticated the thief turned out to be. A narrow credential buys narrow access. A standing admin credential buys the whole environment, handed over without a fight.

This isn't a misconfiguration somebody forgot to fix. Traditional privileged access management was built on the assumption that elevated rights could sit around, waiting to be reviewed and eventually pulled, on a schedule set by an audit calendar rather than by actual need. An attacker doesn't have to beat that schedule. They just have to show up inside it. Ping Identity's framing of vault-centric PAM gets at this directly: attackers don't break vaults, they log in, and then move sideways through an environment using the static entitlements and standing privileges that keep working long after the original login is forgotten.

The problem compounds because overprivileging is standard operating procedure, not an exception. The Cloud Security Alliance's 2025 publication notes that cloud roles pick up more rights than they need over time, a slow accumulation often called privilege creep, and that non-human identities, meaning APIs, bots, and AI agents, often hold powerful permissions with far less oversight than human accounts get. The 2025 Ponemon-Sullivan Privacy Report found that a large share of incidents trace back to overprivileged internal users and third parties. The attackers behind those incidents weren't unusually clever. The permissions were already sitting there, waiting to be used by whoever logged in next.

How escalation unfolds in the incident record

If you look at the major privilege escalation incidents of the last several years, they don't show new attack techniques; they show the same structural condition exploited at different scales, with different consequences attached.

Take SolarWinds in 2020. Attackers got in through a compromised software update, so that's what made the headlines as the technical feat. But the real damage, months of undetected access across email systems, cloud environments, and sensitive government communications, came from what standing privileges allowed the attackers to do once they were inside. CISA documented that the persistence and escalation mechanism was forged authentication tokens and credentials tied to highly privileged Active Directory domain accounts. The access was already provisioned. The attacker simply inherited it.

Kaseya VSA in 2021 tells a similar story at a different scale. The attack hit a vast number of downstream businesses, and the size of that blast radius had little to do with how clever the initial exploit was. It had everything to do with the privilege escalation that followed: a zero-day authentication bypass in Kaseya VSA servers gave attackers control over managed service provider infrastructure, and from there they pushed ransomware out to every downstream managed endpoint. Without that escalation step, the damage stays contained to one server instead of spreading across an entire client base.

AWS credential exposure data shows the same thing, but in a different register, one you measure in minutes rather than months. When AWS credentials leak publicly, attackers attempt to use them within an average of 17 minutes. Standing privilege doesn't just sit on a risk register as a theoretical exposure window. It's a stopwatch, and it's already running by the time anyone notices the leak.

And this isn't a one-off pattern tied to a couple of famous breaches. BeyondTrust's 2024 analysis found that Elevation of Privilege was the leading vulnerability category in Microsoft environments for the fifth consecutive year, accounting for a substantial share of a record total of Microsoft vulnerabilities that year. Five years running points to a structural pattern built into how access gets provisioned, not a spike tied to one bad quarter.

What JIT access is designed to do

JIT access works by removing the target before an attacker can reach it, rather than by watching more carefully once the attacker arrives. The Cloud Security Alliance's 2025 publication defines it precisely: privileged rights get granted only when necessary, typically for a limited period, through an approval or ticket-based workflow, with automatic revocation once the task is done. JIT isn't a smarter monitoring tool bolted onto the old system, and it isn't a faster way to detect misuse after the fact. It changes what exists in the first place, rather than changing how closely that existence gets watched.

The inversion runs against decades of PAM design. Traditional systems assumed you could let privilege sit around long enough to review and remove it on some audit schedule. JIT flips that by tying privilege to an immediate task and a short operating window instead of a calendar. The NHI Management Group's 2026 editorial frames this well: the shift moves organizations from managing entitlements to governing access at the moment it's actually used.

JIT doesn't work alone. It pairs with Just-Enough Access, which scopes permissions to the exact task rather than handing out a broad role, and with Zero Standing Privileges, the goal state where no identity holds always-on elevated rights. Together, these three ideas define the surface JIT is trying to eliminate: not the people, not the systems, but the gap in time where access exists without a task attached to it. The mechanism applies the same way to developers, finance staff, third-party vendors, service accounts, and AI agents, because the underlying problem, entitlements that outlive the task that justified them, doesn't care what kind of identity is holding the keys.

CSA's 2025 publication describes a working JIT implementation as resting on a handful of operative pieces. Time windows get tied directly to the task rather than set on a generic schedule. Entitlements get scoped narrowly to task-based roles instead of broad "admin" labels that cover far more than any one job requires. Every grant links to an approval workflow, whether that's a change ticket, an ITSM record, or a manager's sign-off. The system keeps a full audit trail, so you can see who requested access, what got approved, and what happened during the window. And at the more advanced end, access decisions adjust in real time based on contextual signals like device posture and location, rather than treating every request the same way regardless of circumstance.

Where JIT disrupts the ransomware and lateral-movement attack chain

JIT's security value concentrates almost entirely in the discovery-and-escalation phase of an attack, which happens to be exactly where standing privileges do the most damage. Once an attacker lands inside an environment, the question that decides how bad things get is whether the credentials available to them still carry power they shouldn't have.

Lateral movement needs credentials that stay valid well past the task that first justified them. SolarWinds is the clearest illustration available: the forged tokens and domain admin credentials that powered months of movement through government and corporate networks weren't custom attack tools built for the occasion. They were just ordinary standing entitlements, and the attackers found them lying around and used them.

Third-party and vendor access, in particular, makes up an exposed slice of this surface. A 2025 Ponemon Institute report sponsored by Imprivata found that a substantial share of incidents involve third parties holding excessive privileged access: vendors and contractors whose credentials stick around between engagements become a durable entry point for lateral movement long after the original contract ends. CrowdStrike's 2025 Global Threat Report backs this up from the attacker's side: nearly most attacks that gain initial access do so without malware at all, relying instead on valid credentials and trusted identities. What JIT is built to close is the plain, boring persistence of access that nobody got around to removing.

The cost of leaving that surface open is not small. IBM's 2025 Cost of a Data Breach Report found that malicious insider attacks cost the most of any initial attack vector, so they rank among the most expensive breach types organizations have to remediate. That figure tracks with the mechanism described above: insiders and compromised insider credentials carry whatever standing privilege was already assigned to them, and cleanup costs scale with how much that privilege allowed.

Real implementations: how Microsoft Entra PIM with AWS IAM Identity Center and CrowdStrike Falcon Privileged Access put JIT into practice

Two documented implementations show what this looks like once it moves past the whiteboard and into production.

A reference architecture published on the AWS Security Blog integrates Microsoft Entra PIM with AWS IAM Identity Center to provide temporary, limited access to AWS resources based on explicit user requests and approvals. A user submits a request for a specific AWS permission set, the system grants access for a set duration, and then it automatically pulls that access back once the window closes. So the configuration includes time-bound access with explicit start and end dates, MFA enforcement, justification tracking tied to each request, and dynamic group management. The reference scenario built around a group called AWS – Amazon EC2 Admin, scoped to a DevOps on-call SRE lead role, shows the task-based logic in action: the grant maps to a specific job that needs doing, not to a job title that sounds important. Dynamic groups and groups synchronized from self-managed Active Directory can't be used with Entra PIM, so the implementation requires direct assignment within Entra ID instead.

CrowdStrike Falcon Privileged Access, from 2025, follows the same logic, but through a different mechanism. It grants elevated permissions only when needed and only when conditions look secure at that moment, pulling in real-time signals from endpoints, threat intelligence feeds, and AI models trained on trillions of security events, so it can judge user behavior and privilege status before it decides on access. That's the contextual risk adaptation CSA identifies as the advanced tier of JIT, put into working software: the decision isn't a simple approved-or-denied switch, it's conditioned on live signals at the exact moment someone asks for access.

Both implementations produce the audit trail that compliance frameworks require anyway: a record of who asked, what got approved, how long it lasted, and what happened during that window. That record also happens to be the evidence trail an incident response team needs after a breach, so the compliance requirement and the security requirement point in the same direction here. JumpCloud's operational guidance, summarized by the NHI Management Group, adds a layer of practitioner discipline on top of both systems: inventory standing privilege before building anything, tie every grant to explicit task evidence like a change ticket or incident record, and treat revocation as a control objective in its own right, meaning someone actually checks that access got removed when the task ended rather than assuming the timer handled it.

The operational friction JIT introduces and the failure modes that recreate standing privilege

The most common way JIT fails is an approval workflow so slow or so clumsy that users find ways around it, and in doing so, rebuild the exact standing-privilege problem JIT was supposed to erase, just through behavior instead of configuration.

The workarounds tend to look mundane rather than dramatic. People request elevation for longer windows than the task needs, so they don't have to re-request access later in the day. Approved sessions get shared between colleagues who don't want to wait for their own grant. Break-glass emergency paths exist for rare crises, but people start using them as routine shortcuts because they're faster than the normal request flow.

A practitioner who led a PAM transformation across tens of thousands of servers documented underestimating how much user education the rollout would need. JIT was unfamiliar to most admins going in, early resistance ran high, and the team ended up adding a dedicated change management stream, FAQs, short videos, and weekly office hours, before adoption actually improved. The control itself worked fine. The rollout plan hadn't accounted for the fact that people don't change habits just because a new system asks them to.

A related failure appears in approval quality, not adoption speed. The NHI Management Group's editorial points out that teams often focus entirely on how temporary the grant is and pay far less attention to the quality of the approval logic behind it. An approval that doesn't describe the exact task scope defeats the whole point of scoping access narrowly in the first place, because the grant ends up broad even if it's short.

There's also a legitimate structural problem at the edges of JIT, not just a sloppy one. If the JIT infrastructure itself goes down, or if approvers are unreachable when something urgent needs fixing, organizations typically keep recovery-service accounts around, with static admin privileges, so they can still reach business-critical systems. That's standing privilege by another name, kept around on purpose because the alternative, no access at all during an outage, is worse. Tenable's implementation guidance flags a related limit directly: access that people need constantly for their daily job is a poor candidate for JIT in the first place, because forcing a login-and-approval ritual every single day turns a security control into an obstacle course.

The practical consensus among practitioners is JIT where it matters most, with Zero Standing Privileges reserved for the identity segments carrying the highest risk: domain admins, people operating financial systems, production-engineering access, and the accounts used during incident response itself.