Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: AWS just-in-time access is presented as a response to the failure of static permission models in cloud environments, where access creep, excess privilege, and delayed revocation leave organisations exposed, according to Ploy. The real issue is not temporary access itself but whether IAM programmes can govern time-bound entitlement, visibility, and offboarding with enough discipline to reduce standing privilege.
NHIMG editorial — based on content published by Ploy: Understanding AWS Just-In-Time Access: A New Era in Cloud Security
By the numbers:
- 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks.
Questions worth separating out
Q: How should security teams implement just-in-time privileged access in cloud environments?
A: Start with the most sensitive administrative paths, then require approval, session bounds, and automatic expiry for each elevation event.
Q: When does JIT access create more risk than it reduces?
A: JIT creates more risk than it reduces when teams assume expiration alone is enough and skip assurance around the requester.
Q: What breaks when static cloud access models are left in place?
A: Static models break because they assume permissions stay aligned to current need.
Practitioner guidance
- Map where standing access still exists Identify cloud roles, break-glass paths, partner grants, and service credentials that remain active beyond the task that justified them.
- Define expiry as a control, not a preference Set mandatory expiration for temporary access and require automatic revocation when the task window closes.
- Align JIT with access review and offboarding Tie every temporary grant to an access review record and a revocation event so reviewers can confirm that the privilege was removed as intended.
What's in the full article
Ploy's full insight article covers the operational detail this post intentionally leaves for the source:
- A step-by-step discussion of how AWS JIT access fits into cloud access workflows and approval paths.
- A fuller explanation of implementation trade-offs between security, usability, and collaboration in project-based access.
- More detail on integrating dynamic access with existing cloud systems and security tooling.
- Additional examples of temporary access use cases for cross-functional and third-party collaboration.
👉 Read Ploy's analysis of AWS just-in-time access and cloud security →
AWS just-in-time access: are static IAM controls still enough?
Explore further
02/09/2026 1:30 pm
Standing privilege is the real failure mode, not temporary access itself. Static cloud IAM models fail because they assume access remains valid until manually removed, even though modern work is project-based, cross-functional, and time-bounded. That assumption turns every forgotten entitlement into latent attack surface, especially when service accounts and delegated access are layered into the same environment. Practitioners should treat standing privilege as the core governance problem, not just an access convenience issue.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the same research.
A question worth separating out:
Q: How do organisations know whether temporary access is actually working?
A: Temporary access is working only when expiry is enforced in the directory and the effective entitlement disappears from every system that consumes it. The main signal is not the policy setting but the removal outcome. If access remains usable after expiry, the control is cosmetic rather than operational.
👉 Read our full editorial: AWS just-in-time access exposes the limits of static IAM
