Who is accountable when a JIT-created account is never removed?

Why This Matters for Security Teams

A JIT-created account that is never removed turns a temporary access decision into a standing identity problem. Accountability does not disappear just because the account was meant to be short-lived. In practice, the service owner remains answerable for the business process, while identity and platform teams are responsible for the control design that should remove access reliably. That is why lifecycle failure is usually treated as a governance issue, not a one-off admin mistake.

The risk is larger than a single orphaned account. An unremoved JIT identity can retain privileges, bypass review cycles, and remain valid long after the original task ends. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle controls fail in practice. For baseline governance, NIST Cybersecurity Framework 2.0 is clear that identity and access controls must be managed as an ongoing operational function, not a one-time event.

In practice, many security teams only discover the issue after an audit, incident, or vendor change reveals that the “temporary” account was still active months later.

How It Works in Practice

For JIT identities, accountability should be split between ownership of the workload and ownership of the control. The service owner defines when access is needed, what it should allow, and when it must end. The identity team, PAM team, or platform engineering team implements the mechanism that enforces expiry, revocation, and logging. If deprovisioning depends on a future human action, the process is fragile by design.

A better pattern is to make revocation independent of user behaviour. That usually means short-lived credentials, explicit time-to-live settings, and automatic cleanup tied to workflow completion, not login activity. In NHI governance terms, this aligns with the lifecycle and offboarding emphasis in Ultimate Guide to NHIs. It also fits the control intent of NIST Cybersecurity Framework 2.0, especially around access control, monitoring, and continuous governance.

• Define a clear owner for the workload that requested JIT access.
• Set a hard expiry for the credential or account at creation time.
• Use automated revocation on task completion, timeout, or incident trigger.
• Log issuance, use, and removal so the control is auditable.
• Alert when cleanup fails, rather than waiting for the next access event.

For agents and automated systems, this should be paired with workload identity and policy enforcement at request time, because static approvals do not reflect changing runtime conditions. These controls tend to break down when the account is reused across pipelines or shared by multiple services because the cleanup trigger becomes ambiguous.

Common Variations and Edge Cases

Tighter JIT control often increases operational overhead, requiring organisations to balance fast access against reliable revocation. That tradeoff becomes more visible in CI/CD, third-party integrations, and emergency access paths, where teams are tempted to keep accounts alive “just in case.” Current guidance suggests that those exceptions should be explicitly time-boxed and reviewed, but there is no universal standard for every environment yet.

Some teams assign primary accountability to the service owner, while others treat identity engineering as the control owner and operations as the approver. The practical answer is that both matter, but the failure usually sits with the control owner if the mechanism cannot revoke without a human trigger. If the account belongs to an agentic workflow, the standard is even stricter: intent-based authorisation, ephemeral secrets, and runtime policy checks are needed because the workload may act autonomously after creation. That is consistent with the direction of OWASP and NIST guidance on workload and AI governance, and with the broader security principles described in Ultimate Guide to NHIs.

In shared-service environments, the main edge case is account coupling: one identity supports multiple jobs, so deprovisioning one use case can unintentionally break another. These controls tend to break down in legacy systems that cannot issue per-task credentials or enforce automatic expiry.

Related resources from NHI Mgmt Group

• What happens when a human uses an NHI account?
• How are most NHIs created in modern environments?
• What is Just-in-Time (JIT) access and why is it important for NHI security?
• What happened in the demo account left active in production scenario and what does it reveal?