Accounts can be created automatically at first login but still remain active after a user changes role or leaves, because JIT does not manage deactivation. That leaves lifecycle closure to other controls, which is where access drift and orphaned accounts usually appear.
Why JIT Works Only as a Trigger, Not a Full Lifecycle Control
Just-in-time provisioning solves a narrow problem: it creates access when it is needed. It does not, by itself, decide when access should end. That is why JIT can reduce standing privilege while still leaving a separate lifecycle gap that must be closed by deprovisioning, role change handling, and access review.
A useful way to think about it is that JIT is an activation mechanism, not an ownership model. The control can be excellent at first-use provisioning and still be blind to later events such as transfers, termination, contract end, or an application account that should be revoked after the original purpose is gone.
That distinction is especially important when just-in-time access and zero standing privilege are being introduced as a replacement for manual approval chains. If the organisation does not pair JIT with a lifecycle control, the same automation that reduces standing access can also hide stale entitlements longer than expected.
What Breaks After the Role Changes or the User Leaves
The main failure is access drift. A user can receive access automatically at the moment of need, then accumulate a different business relationship later without the original access being revisited. When that happens, the account may still exist, still authenticate, and still retain permissions that no longer match the person’s current role or employment status.
That creates orphaned accounts, excessive access, and unowned credentials. In practice, the break is not that JIT failed to grant access, it is that no separate process was responsible for removing access when the trigger condition disappeared. The more applications and environments depend on the same account source, the more persistent that drift becomes.
The lifecycle view matters because offboarding is part of a broader identity lifecycle, not a side task. NHI lifecycle management is the right model here because it treats provisioning, rotation, offboarding, and visibility as distinct controls rather than one automated event.
Why the Gap Becomes a Security Problem
When JIT is treated as the whole control, deactivation becomes dependent on informal cleanup, ticket closure, or someone remembering to revoke access later. That is where security exposure appears. The account can remain active long after the business need has ended, and dormant access is exactly what attackers and insider misuse benefit from.
Orphaned access also weakens auditability. If no explicit offboarding step exists, teams cannot reliably show when access ended, who approved the removal, or whether every dependent system was updated. The result is a control that looks strong at issuance time but becomes weak over time.
Joiner-Mover-Leaver processes are the natural counterpart to JIT because they close the loop on movers and leavers, not just joiners. For organisations trying to reduce lingering access, this is the missing half of the design.
Risk and Threat Considerations
When JIT is deployed without a separate offboarding process, the control can leave behind active access that no longer has a business owner. That creates a durable exposure window for stale accounts, privilege creep, and unauthorized reuse of credentials after the original need has ended.
Failure mechanism: The system grants access on demand, but no lifecycle event removes it when the user changes role, exits, or the relationship ends. That allows residual permissions and dormant accounts to persist across systems, especially where the original access was created automatically and never revisited.
Impact: Attackers and insiders gain a longer-lived path to authentic systems, audits lose clarity on entitlement closure, and organisations inherit avoidable exposure from accounts that appear temporary but remain valid.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | JIT without offboarding leaves non-human access active after the need ends. |
| NHI-05 — Overprivileged NHI | Residual JIT accounts can retain more access than their current role requires. | |
| Recommendation — Pair JIT with explicit deprovisioning triggers and revoke lingering NHI access promptly. Review post-activation entitlements and reduce any access that exceeds current need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Lingering JIT access often persists through unmanaged credentials and tokens. |
| AC-2 — Account Management | The issue is account lifecycle closure after role change or departure. | |
| AC-6 — Least Privilege | Stale JIT access becomes excessive privilege when the business need changes. | |
| Recommendation — Revoke or expire authenticators when the account or role ends. Tie account lifecycle events to provisioning, review, suspension, and removal. Continuously trim access so active accounts retain only current required privilege. | ||
| CIS Controls v8 | CIS-5 — Account Management | Temporary access still requires removal controls to prevent orphaned accounts. |
| CIS-6 — Access Control Management | JIT needs companion controls to remove access at the end of need. | |
| Recommendation — Automate account disablement and removal when users or roles change. Enforce timely revocation and periodic review of temporary access paths. | ||
Practitioner Guidance
What to verify: Confirm that every JIT entitlement has a defined removal trigger, not just a creation trigger. If you cannot point to the event that ends access, the design is incomplete even if the initial provisioning flow is well controlled.
Implementation sequence: First map which accounts are JIT-created, then identify the authoritative offboarding source, and finally test whether leaver and mover events actually revoke access across all dependent systems. The control only works when issuance and deactivation are both observable.
Common mistake: Treating JIT as a substitute for access governance. JIT can reduce standing privilege, but it does not remove the need for lifecycle ownership, periodic review, and explicit revocation rules.
Practitioner takeaway: The right question is not whether access was granted just in time, it is whether access is also removed on time when the business relationship ends.
Related resources from NHI Mgmt Group
- What breaks when JIT provisioning is used without organisation controls?
- How should security teams use JIT provisioning without creating offboarding gaps?
- What breaks when JIT access is used without identity governance?
- What breaks when organisations rely on inline guardrails without a separate evaluation process?