What are the biggest implementation mistakes with just-in-time access?

Why This Matters for Security Teams

Just-in-time access is meant to shrink privilege windows, but implementation mistakes can turn it into a false sense of control. The biggest failures are usually operational: broad request templates, delayed revocation, and cleanup that works in the portal but not in downstream systems. That is especially risky for NHI because access is often consumed by service accounts, API keys, and automation paths that do not behave like human users.

In NHI Mgmt Group research, 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how often revocation lags the intent of the workflow. The broader pattern is visible in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10: access is usually compromised by lifecycle gaps, not by the approval button itself.

In practice, many security teams discover JIT failures only after a secret has already been reused, extended, or left active in a system the workflow never touched.

How It Works in Practice

Effective JIT access is a control chain, not a single approval event. A requester should receive only the minimum entitlement needed for a specific task, for a defined time, with automated expiration that is enforced in every target system. For NHI, that usually means short-lived credentials, scoped tokens, or ephemeral workload access rather than standing privileges that are merely “time limited” in a console.

The operational mistake is to treat the request portal as the control boundary. Real enforcement has to happen at issuance, at use, and at teardown. That is why mature programs validate three things: the entitlement template is narrow, the expiry is cryptographically or programmatically enforced, and revocation reaches the actual resource, not just the access broker.

• Template design should map to a single task or workflow, not an entire role bundle.
• Expiration should be automatic and short enough that stale access has little value.
• Revocation should be verified in downstream systems, including APIs, vaults, and service accounts.
• Audit evidence should show who approved access, what was issued, when it expired, and whether cleanup completed.

This is where guidance from the Ultimate Guide to NHIs aligns with the NIST SP 800-53 Rev 5 Security and Privacy Controls: access governance has to be continuously validated, not assumed. The control breaks down when teams manage the ticket lifecycle correctly but fail to enforce expiry on cached tokens, replicated secrets, or third-party-integrated accounts because the access decision and the actual credential lifecycle are decoupled.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, requiring organisations to balance speed of delivery against revocation assurance and audit depth. That tradeoff is real, especially in CI/CD, production support, and multi-system workflows where a single task may touch several services with different identity models.

Current guidance suggests that the hardest edge cases are not the initial grant but the cleanup path. A workflow can appear successful while one subsystem keeps a token alive, a downstream connector auto-renews it, or a service account inherits access beyond the approved window. That is why “approved” and “revoked” must be tested independently.

There is no universal standard for this yet, but best practice is evolving toward narrower task-based approvals, stronger integration testing for revocation, and periodic failure drills that prove the expiry path works under load. Teams should also watch for overloading JIT with exceptions. Too many emergency bypasses, standing break-glass accounts, or long-lived “temporary” extensions usually indicate the process is compensating for poor entitlement design.

For a deeper view of how access sprawl persists even after remediation begins, see the Guide to NHI Rotation Challenges. The practical lesson is simple: JIT fails when the organisation measures request approval time but does not measure whether privilege was truly removed everywhere it existed.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• What breaks when AWS least privilege is treated as a one-time IAM project?
• How do JIT access and PAM differ in practice?