Why do JIT programs still leave organisations exposed to standing privilege?

Why This Matters for Security Teams

JIT access is meant to shrink privilege windows, but that only works when issuance and revocation are both enforced at the point of use. If access is approved quickly but removed slowly, the organisation has not reduced exposure, it has only shortened the paper trail. That gap matters because standing privilege is what attackers want: a durable path that survives the original business request.

NHI Management Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why “temporary” access often persists in practice. The pattern is consistent with guidance in the OWASP Non-Human Identity Top 10 and with the operational failures documented in the Ultimate Guide to NHIs — Key Challenges and Risks. The issue is not the request workflow itself, but the assumption that approval equals removal once the ticket closes. In practice, many security teams encounter standing privilege only after an incident review reveals that revoked access was never actually revoked.

How It Works in Practice

Effective JIT programmes treat privilege as an event, not a membership state. Access is issued for a specific task, bound to a specific workload or operator, and automatically expires when the task completes. That means the control plane must do more than log an approval. It must verify revocation, confirm token invalidation, and ensure downstream sessions, API keys, and delegated grants are actually unusable.

The operational model usually includes:

• Short-lived credentials with explicit TTLs rather than reusable static secrets.
• Workload identity for non-human actors, so the system knows what is requesting access, not just who clicked approve.
• Real-time policy evaluation at request time, not a pre-approved entitlement that lingers until the next review.
• Automated deprovisioning across every place the privilege propagated, including vaults, brokers, CI/CD jobs, and cloud control planes.

This is where current guidance suggests a tighter alignment between JIT and Zero Trust: access should be continuously re-evaluated, and removal should be programmatic rather than manual. The Ultimate Guide to NHIs highlights how broad NHI sprawl and weak lifecycle control create persistent exposure, while the OWASP Non-Human Identity Top 10 frames credential lifecycle failures as a first-order risk. JIT also benefits from policy-as-code patterns, where approval, scope, and expiry are enforced consistently at runtime rather than reviewed after the fact.

These controls tend to break down when legacy applications cache tokens, when cloud permissions are inherited through nested roles, or when revocation depends on a human closing a ticket instead of a machine invalidating the credential.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, requiring organisations to balance faster access delivery against stricter revocation discipline. Not every environment can use the same pattern, and best practice is evolving for agentic and automated workloads.

For human admins, a JIT grant might be time-boxed and manually approved, but for agents and service accounts, the stronger pattern is per-task ephemeral access with machine-enforced expiry. In autonomous systems, static role assignment is a weak fit because behaviour is dynamic and goal-driven. An agent may chain tools, call APIs in unexpected sequences, or trigger secondary privilege paths that the original request never described. That is why emerging guidance increasingly favours intent-based authorisation and workload identity primitives over broad RBAC assignments.

There is no universal standard for this yet, but the direction is clear across the Anthropic AI-orchestrated cyber espionage report, the 52 NHI Breaches Analysis, and the Ultimate Guide to NHIs — Why NHI Security Matters Now: if revocation is not verified continuously, “just in time” becomes “just in name.”

JIT also struggles in high-latency approval chains, disconnected OT environments, and systems that cannot invalidate sessions cleanly. In those cases, organisations need compensating controls such as narrower scope, shorter TTLs, stronger monitoring, and explicit post-task verification.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• Why do entitlement tools still leave organisations exposed to over-privilege?
• When do short-lived access tokens still leave organisations exposed?
• When does a phishing-resistant login method still leave organisations exposed?