The control fails when each request is valid in isolation but the resulting access bundle becomes too broad. Users can accumulate multiple approvals, cross environment boundaries, and exceed least-privilege intent without any single request looking suspicious. The failure is not the first approval, but the absence of accumulation control.
Why request-by-request JIT approval can still fail
Just-in-time access only stays least-privileged if the review model looks at the full entitlement bundle, not just the next request. When approvals are evaluated in isolation, the user can slowly assemble access that would never have been granted as one package. That is a governance failure, not an execution failure, because the system is approving fragments rather than effective privilege.
The practical problem is entitlement drift across time. A request may be narrow on paper, but once it is combined with prior grants, role inheritance, environment-specific permissions, or a lingering exception, the actual access picture can become much broader than intended. Controls built around single approvals miss that cumulative state.
This is why JIT needs an entitlement lens, not only a ticket lens. The question is not whether each request was defensible at the moment it was approved, but whether the resulting access set still matches the intended boundary after aggregation. For a broader access-governance baseline, see IAM and IGA Basics, which frames requests, reviews, and entitlements as one control system.
Where accumulation breaks least privilege
The most common breakpoints are overlapping approvals, role stacking, and cross-environment reach. A user may separately receive temporary admin rights, production read access, and a vendor support exception, none of which looks excessive alone. Together, they can create a path that exceeds least-privilege intent and undermines separation between environments or duties.
Another failure mode is hidden effective permissions. If the review process only sees the requested entitlement, it may not account for permissions inherited from groups, policies, policy bindings, or previous activations that have not yet expired. In that case the user appears compliant at request time while the effective access graph is already too broad.
That is why access review, entitlement review, and role design need to converge. If the organisation cannot show the full set of permissions that will exist after approval, it cannot reliably say the JIT control preserved least privilege. The same issue appears in Role Mining and Role Design Guide, which addresses role structure and role explosion as part of controlling cumulative access.
How to review JIT as an entitlement set, not a single request
Practitioners should treat each approval as a change to an accumulated access state. The review question is not simply “is this request justified?”, but “what does the total entitlement set become after this request is added, and does that remain acceptable?” That is the only way to detect privilege creep caused by many small approvals.
Useful operating checks include comparing requested access against current effective access, flagging cross-environment combinations, and requiring review when a new approval would push the user past a defined threshold of privilege or scope. Where roles or entitlements are already noisy, recertification should focus on the combined access picture rather than the latest ticket alone. A strong reference point is Access Reviews and Certification Guide, which emphasises review design that removes access instead of rubber-stamping it.
The control also benefits from periodic effective-permission analysis. If you cannot compute what a user can actually do across environments, the approval workflow is blind to accumulation risk. That is especially important when standing roles, temporary elevation, and emergency access all coexist in the same environment.
Risk and Threat Considerations
When cumulative review is missing, the organisation creates a slow privilege-escalation path that does not look malicious at any single step. An attacker, insider, or simply an over-provisioned user can exploit that gap by collecting individually justified approvals until the effective bundle crosses a security boundary.
Failure mechanism: Each approval is validated locally, but no control reconciles the total entitlement set, so privilege accumulates across time, scope, or environment.
Impact: Least privilege erodes quietly, auditability weakens, and a user can end up with broader production reach than any reviewer would have approved in one decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | JIT approvals must preserve least privilege across the full entitlement set. |
| IA-5 — Authenticator Management | JIT commonly depends on time-bound credential handling and revocation discipline. | |
| AC-2 — Account Management | Accumulated JIT grants are an account governance problem, not only a ticket problem. | |
| Recommendation — Apply AC-6 to evaluate effective access before granting any new JIT entitlement. Use IA-5 to ensure temporary access material expires or is revoked after use. Use AC-2 to govern lifecycle changes and review the resulting account state. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is whether access remains controlled after multiple approvals are combined. |
| A.5.18 — Access rights | JIT request reviews must consider the total access rights held at any moment. | |
| Recommendation — Enforce access control so aggregated entitlements stay within approved boundaries. Review access rights as a whole, not as isolated requests. | ||
| CIS Controls v8 | CIS-5 — Account Management | Accumulated approvals create account sprawl and privilege creep. |
| Recommendation — Track and review account entitlements to stop JIT-driven privilege accumulation. | ||
Practitioner Guidance
What to verify: Confirm that the approval workflow evaluates current effective access before granting anything new. If the system cannot surface inherited, active, and pending permissions together, it is not capable of preventing entitlement accumulation.
Decision rule: If the new request changes the user’s access set in a way that crosses an environment, expands admin scope, or combines with prior grants to create a new risk class, require higher-level review or recertification rather than auto-approval.
What good looks like: Reviewers can see the full entitlement bundle, the system can explain what the user already has, and every new JIT grant is tested against aggregate privilege, not just request-level justification.
Practitioner takeaway: JIT is only safe when the control reasons over effective access over time; request-level approval without accumulation control becomes a privilege-creep mechanism.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org