Topic starter
02/06/2026 7:00 pm
TL;DR: JIT permissions cut standing privilege by expiring entitlements automatically, but they do not prove access was properly authorised without Identity Governance and Administration, according to Omada Identity. Temporary access still needs discovery, policy checks, contextual approval, and audit evidence to keep its blast radius small.
Editorial analysis by NHI Mgmt Group, based on content published by Omada Identity: “Just-in-Time Permissions Explained: How JIT and IGA Together Enforce Least Privilege”.
Key questions
Q: Why does standing privilege still create so much identity risk?
A: Standing privilege keeps elevated access available long after the work that justified it has ended.
Q: What do teams get wrong about temporary access in user access reviews?
A: A common mistake is treating temporary access as low risk and then forgetting to revoke it when the task ends.
Q: When does just-in-time access fail to reduce privilege risk?
A: JIT fails when access is still broad, poorly logged, or not revoked after task completion.
Practitioner guidance
- Map all temporary access to entitlement source Trace each JIT permission back to the role, group, application right, or policy that made it eligible so that expiry is tied to a governed entitlement, not a one-off request.
- Separate session elevation from entitlement governance Use JIT access for session-level privilege and IGA for permission eligibility, because the article shows those controls solve different parts of the least-privilege problem.
- Review non-human identities for hidden standing privilege Prioritise service accounts, workloads, and AI agents that hold permissions without a lifecycle event forcing reassessment, since they are the hardest to catch in ordinary review cycles.
Bottom line: JIT permissions help reduce exposure, but they do not by themselves prove that access was properly authorised or appropriately scoped.
Glossary terms: Just-in-time permissions, Standing Privilege, Identity Governance and Administration (IGA), Least Privilege
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 8 hours ago by NHI Mgmt Group
02/06/2026 7:17 pm
JIT permissions are an expiry mechanism, not a least-privilege governance model. They reduce how long access exists, but they do not determine whether the entitlement was justified, scoped correctly, or compatible with policy. The distinction is fundamental for IAM teams because fast expiry without entitlement governance only shortens the window on a bad decision.
A few things that frame the scale:
- 92% of cloud identities are over-permissioned and 62% are dormant.
A question worth separating out:
Q: How should organisations govern JIT access for privileged machine identities?
A: Treat JIT as a control for task-scoped entitlement, not as a convenience feature. The access request should be tied to a specific use case, the privilege should expire automatically, and the identity should return to a non-privileged state after the job completes. That approach reduces standing access and makes privileged use easier to audit.
👉 Read our full editorial: JIT permissions need IGA to make least privilege real
This post was modified 8 hours ago by NHI Mgmt Group