TL;DR: Cloud PAM often fails because teams try to time-bound user access while leaving permissions, roles, and group membership effectively standing, according to Sonrai Security. The practical shift is from JIT’ing people to JIT’ing permissions, because cloud least privilege only works when access is enforced at the permission layer, not the account layer.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Shift Left Is Dead for Cloud PAM”.
Key questions
Q: What breaks when organisations JIT users instead of permissions?
A: When organisations JIT users instead of permissions, the access window may shrink but the effective privilege often remains broad.
Q: When does cloud JIT create less risk than standing access?
A: Cloud JIT reduces risk only when the permission itself expires automatically after the task ends and the entitlement is issued at the native control plane.
Q: What are the signs that PAM is not working well in a cloud environment?
A: Common signs include lingering access after contractors or vendors finish their work, weak visibility into privileged sessions, and manual review processes that cannot keep up with cloud scale.
Practitioner guidance
- Audit whether your JIT process changes permissions or only access wrappers Map each access path to the exact permission change it produces.
- Remove expiry gaps at the cloud permission layer Require enforced expiration for the permission itself, not just for the workflow that grants it.
- Separate cloud service permissions from human checkout processes Design cloud PAM around policies, service actions, and permission sets so access can be issued for a task and removed without relying on directory timing or manual cleanup.
Bottom line: Cloud PAM fails when teams optimise who gets access without changing what that access can do in the cloud control plane.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Permission-layer governance is the real cloud PAM boundary: cloud access becomes safe only when the permission itself is time-bounded, not when the account or role wrapper is time-bounded. The article’s core point is that many teams confuse access delivery with privilege control, which leaves standing rights intact even when the workflow looks temporary. Practitioners should treat permission issuance, not user checkout, as the unit of control.
A few things that frame the scale:
- 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
A question worth separating out:
Q: How should IAM teams govern just-in-time access in cloud environments?
A: They should govern the permission stack, not only the login path. That means tying access to the specific cloud permissions needed for the task, enforcing automatic expiration, and avoiding models that rely on group sync, shared accounts, or role assumptions to do the real security work.
👉 Read our full editorial: Cloud PAM fails when teams JIT users instead of permissions