Join our Newsletter — 33% off our NHI Course

Who is accountable when just-in-time access is not revoked after use?

Accountability should sit with the identity governance and access control owners, because they are responsible for defining the policy, enforcing time limits, and verifying revocation. If just-in-time access remains active after the task ends, the organisation has lost the main security benefit. Clear ownership, automated expiry, and audit review are essential.

Why This Matters for Security Teams

When just-in-time access stays active after the task ends, the control has failed in the one way that matters most: it no longer limits blast radius. That creates an accountability problem, but also a governance failure. Identity governance, access control, and service owners all need a shared operating model because revocation is only effective if policy, enforcement, and verification work together.

NHIMG’s research shows how common the underlying weakness is. In the Ultimate Guide to NHIs, NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys. That gap matters because JIT access is meant to remove standing privilege, not merely delay it. The same lifecycle discipline discussed in the NHI Lifecycle Management Guide is what turns temporary access into a defensible control.

For control design, NIST’s SP 800-53 Rev 5 Security and Privacy Controls reinforces that access enforcement, review, and revocation are not optional add-ons. In practice, many security teams encounter over-extended JIT access only after a privileged session has already outlived the work it was meant to support, rather than through intentional monitoring.

How It Works in Practice

Accountability for expired JIT access should be assigned before the first request is approved. In practice, that means the identity governance owner defines the policy, the platform or access control owner enforces the expiry mechanism, and the application or workload owner confirms the task is complete. The operational question is not who noticed the problem, but who owned the automated revocation path and the audit evidence that proves it happened.

For human-admin workflows, JIT often sits inside PAM. For NHIs and agents, the stronger pattern is time-bound, task-scoped credentials with automated expiry and revocation, as described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Current guidance suggests the most reliable model is layered:

  • issue access only for a named task or ticket, not a standing role
  • bind the approval to a specific owner and expiry time
  • revoke through automation, not manual cleanup
  • log issuance, use, expiry, and failed revocation checks
  • review exceptions as governance defects, not routine noise

That approach aligns with the broader controls in the OWASP Non-Human Identity Top 10, especially where short-lived access can still become long-lived through weak lifecycle management. It also helps when secrets are exchanged across CI/CD, orchestration, and automation layers, where ownership tends to blur. These controls tend to break down when revocation depends on a human approval chain in fast-moving pipeline environments because the task often finishes before the access review does.

Common Variations and Edge Cases

Tighter JIT enforcement often increases operational overhead, requiring organisations to balance security gain against response speed and support burden. That tradeoff becomes more visible in shared automation platforms, incident response, and emergency admin scenarios, where a temporary delay in revocation can be tolerated only if the exception is explicit and time boxed.

There is no universal standard for who must trigger revocation in every environment, but best practice is evolving toward shared accountability with clear primary ownership. In a mature model, the identity governance team owns the policy and evidence, while the system owner owns the workflow that actually ends access. If the access is issued through a broker, vault, or orchestration layer, that platform team must also own expiry enforcement and failure alerts.

The most important edge case is when access remains active because the task was never formally marked complete. That is a process failure, not just a technical one. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it shows why dynamic access only works when the full lifecycle is closed. Where teams lack reliable offboarding, even a short TTL can become a de facto standing credential.

Practitioners should treat any missed revocation as a control exception requiring root-cause analysis, because the accountability gap usually reflects missing automation, unclear ownership, or both.

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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Expired JIT access is a lifecycle and revocation failure for non-human identities.
OWASP Agentic AI Top 10 A-04 Autonomous agents need time-bound authority so access does not persist past task completion.
CSA MAESTRO IAM MAESTRO emphasizes identity governance and runtime control for machine access.
NIST AI RMF AI RMF governance requires accountability for automated decision and access workflows.
NIST CSF 2.0 PR.AC-4 Access permissions must be managed and revoked as part of least-privilege enforcement.

Assign clear owners for issuance, monitoring, and revocation across machine identity workflows.