How should organisations implement just-in-time access for human and non-human identities in cloud environments?

Why This Matters for Security Teams

JIT access is not just a convenience control in cloud environments. It is one of the few practical ways to replace standing privilege with task-scoped access across humans, service accounts, and agentic workloads. Without it, identities accumulate permissions that outlive the work they were meant to support, which expands blast radius and makes lateral movement easier after a single compromise. The problem is especially visible in non-human identity programs, where the 2024 Non-Human Identity Security Report found that 59.8% of organisations want dynamic ephemeral credentials, yet 88.5% say their NHI practices lag human IAM.

For security teams, the stakes are operational as well as architectural. Cloud platforms make it easy to grant access quickly, but much harder to prove that access was necessary, time-bound, and revoked on schedule. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege and access review, but organisations still struggle to operationalise those principles for fast-moving cloud tasks. In practice, many teams discover excessive standing access only after an incident review shows the identity had been over-permissioned for months.

How It Works in Practice

Effective JIT starts with identity inventory, then shifts authorisation from static entitlements to time-bounded task grants. For human users, that usually means an approval workflow, scoped role elevation, and automatic expiry. For NHI and AI-driven agents, the control plane should issue ephemeral credentials per workload or per job, with the shortest practical TTL and automatic revocation when the task completes. This aligns with the emerging guidance in the Ultimate Guide to NHIs and with cloud identity patterns that favour workload identity over shared secrets.

• Use workload identity first for non-human access, rather than embedding long-lived API keys in code or pipelines.
• Separate request, approval, and credential issuance so the granting event is auditable and time-limited.
• Bind access to context such as environment, target resource, ticket, or change record.
• Revoke automatically on completion, timeout, or policy violation, not just on a manual schedule.
• Continuously log and evaluate the session so misuse during the JIT window is visible.

For cloud-native execution, that often means integrating JIT with PAM for human elevation, OIDC-based workload tokens for machine access, and policy-as-code for real-time decisions. The important distinction is that the system authorises the request at runtime, not by assuming a role forever. That is why current practice increasingly favours ephemeral secrets and short-lived tokens over static credentials, especially when credentials can be copied, reused, or chained across tools. The Guide to NHI Rotation Challenges is a useful reminder that rotation alone does not solve over-privilege if the underlying access model remains static.

These controls tend to break down in hybrid environments where the same identity must reach SaaS, cloud control planes, and legacy systems that cannot consume short-lived tokens or enforce consistent revocation.

Common Variations and Edge Cases

Tighter JIT control often increases operational overhead, requiring organisations to balance speed against review burden and integration complexity. That tradeoff is real: teams can reduce standing privilege, but they may also slow incident response, break automation, or create approval fatigue if every routine task requires manual intervention. Best practice is evolving, and there is no universal standard for this yet, especially for AI agents that act autonomously and may need access that is temporary but highly dynamic.

One common edge case is break-glass access. Emergency access should still be time-bound, heavily monitored, and pre-approved in policy, but it should not depend on the same workflow used for routine access. Another is service-to-service access in CI/CD or orchestration layers, where human approvals are too slow and workload identity is the better primitive. In those cases, the control objective is not a human ticket, but a verifiable workload identity, a narrow scope, and a short expiry window.

Cloud-native JIT also becomes harder when organisations rely on shared accounts, inherited permissions, or manually rotated secrets. Those patterns obscure ownership and make revocation unreliable. The 52 NHI Breaches Analysis shows how often identity misuse is amplified by poor scoping and stale credentials. For implementation, the practical rule is simple: if the environment cannot prove who requested access, what it was for, and when it expired, it is not JIT in any meaningful security sense.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• What breaks when organisations cannot see unapproved access attempts from non-human identities?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?