Treat the approval as a control failure and apply manual revocation immediately through the identity provider, PAM workflow, or session termination path. Investigate why the JIT grant did not expire, then fix the policy, webhook, scheduler, or downstream system that should enforce time-bound access. Any standing entitlement created by the failure should be removed and the access record reviewed.
When JIT approval fails to revoke access automatically
The priority is to treat the grant as no longer trustworthy and remove access through the fastest reliable path available. In practice, that means revoking the entitlement at the identity provider, cancelling it in PAM if that is the enforcement point, and terminating any active session that may still be using the approval.
That response is not just cleanup, it is the control outcome the JIT process was supposed to deliver. If revocation depends on a webhook, scheduler, workflow engine, or downstream integration, the failure has effectively converted time-bound access into standing access until someone intervenes.
Where the revocation path spans multiple systems, the order matters: first stop the access, then correct the automation. If teams fix the policy logic before removing the grant, they can leave an already-usable privilege in place longer than intended.
What to check after the expired grant is removed
Once the access is gone, teams should determine whether the failure was isolated or systemic. A missed expiry can point to a broken approval workflow, an unhealthy job that enforces TTLs, a sync issue between the IAM layer and the target system, or a downstream system that accepted the grant but never honoured the revocation event.
Review the access record, the approval window, the actual expiry timestamp, and any session or token state created during the approved period. If the access path included elevated rights, check whether the user or process left behind any changes that outlived the JIT window.
It is also worth verifying whether similar grants are vulnerable to the same fault. If one time-bound access control failed to auto-revoke, the real issue may be in the policy pattern rather than a single request.
How teams prevent a repeat failure
The control should be designed so that revocation does not rely on one fragile component. The expiry rule, the enforcement mechanism, and the monitoring that confirms revocation all need to agree, otherwise teams end up with a policy that looks correct but does not actually remove access.
Operationally, the most useful fix is to make revocation observable and testable. That means alerting on expired grants that still exist, checking that session termination really occurs, and proving that the target system no longer honours the entitlement after expiry.
Where the access model is approval based, teams should also test the exception path. A JIT process is only trustworthy if the failure mode is explicit and the fallback path is documented, because manual intervention is part of the operating model when automation misses.
Risk and Threat Considerations
When automatic revocation fails, the main risk is that a temporary elevation silently becomes longer lived than intended. That widens the window for misuse, especially if the access was privileged, cross-system, or tied to a session that can continue after the approval timer expires.
Failure mechanism: The control plane records a time limit, but the revocation event is not enforced in the identity provider, PAM workflow, or downstream target, so the entitlement remains usable after expiry.
Impact: The organisation loses the practical boundary that separates approved access from standing access, which can increase exposure, complicate audits, and leave an attacker or insider with a longer abuse window if the grant is compromised.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | JIT approval and revocation are account lifecycle controls that must end access on time. |
| IA-5 — Authenticator Management | Expired JIT access may still be usable through tokens, sessions, or other authenticators. | |
| AC-6 — Least Privilege | JIT exists to keep elevation temporary and remove standing privilege after approval ends. | |
| Recommendation — Enforce timely account disabling and revocation for expired JIT grants. Rotate or invalidate authenticators and sessions that remain usable after JIT expiry. Limit elevation duration and remove any standing privilege left by a failed revocation. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS account management directly covers provisioning, revocation, and removal of unnecessary access. |
| Recommendation — Revoke expired access promptly and verify no residual account access remains. | ||
| NIST CSF 2.0 | PR.AA-04 — Access Permissions and Authorizations are Managed | Expired JIT approvals are an authorisation lifecycle issue that must be enforced consistently. |
| Recommendation — Ensure time-bound approvals are removed when their authorization window ends. | ||
Practitioner Guidance
What to prioritise: Remove the access first, then investigate the root cause. The immediate question is not whether the approval was valid, but whether any active path still lets the identity continue using it.
What to verify: Confirm the revocation succeeded in every enforcement point, not just in the approval portal. If the entitlement exists in one place but not another, treat the remaining path as the source of truth until it is cleared.
Decision rule: If the grant can still authenticate, authorise, or maintain a live session after expiry, handle it as a control failure with potential exposure, not as a reporting issue. That is the point at which manual revocation and follow-up review become mandatory.
Practitioner takeaway: JIT only works if expiry actually removes usable access; when it does not, teams should act as though the control failed and then repair the enforcement mechanism, not the other way around.
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 November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org