Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Static permissions remain a weak fit for cloud environments, and Ploy argues that Google Cloud Platform just-in-time access reduces exposure by issuing temporary permissions only when needed. The real issue is not access speed but whether IAM programmes can replace persistent privilege with time-bound control and auditability.
NHIMG editorial — based on content published by Ploy: GCP Just-In-Time Access: Navigating the New Era of Cloud Security
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 just-in-time access reduce cloud risk?
A: Just-in-time access reduces cloud risk when standing privilege is the main problem and the baseline permissions are already tightly scoped.
Q: Where does JIT access fail in practice?
A: JIT fails when it is bolted onto a programme that still tolerates standing privilege, broad default roles, or weak approval boundaries.
Practitioner guidance
- Map every standing cloud permission to a task it actually supports Identify roles, service accounts, and emergency entitlements that persist beyond their operational purpose, then classify which ones can be converted to time-bound access.
- Require revocation evidence for every JIT grant Make expiry, removal, and log retention part of the same control objective so teams can prove that temporary access really ended.
- Standardise JIT policy across cloud platforms Define one access intent model for GCP, AWS, Azure, and any internal platforms, then prevent local exceptions from weakening the control.
What's in the full article
Ploy's full insights article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for configuring GCP IAM roles and temporary access workflows
- Operational discussion of how Access Transparency can support JIT audit trails
- Implementation considerations for teams running hybrid and multi-cloud access models
- Practical discussion of user resistance, change management, and policy exceptions
👉 Read Ploy's analysis of GCP just-in-time access and cloud IAM risk →
GCP just-in-time access: are static IAM controls still enough?
Explore further
02/09/2026 1:30 pm
JIT access is best understood as a response to standing privilege, not as a standalone cloud feature. The article correctly frames the core problem as excess permission persistence in dynamic environments. That is the same structural issue seen across NHI governance, where access granted for convenience becomes an attack surface once it outlives the job it was meant to support. Practitioners should read JIT as a lifecycle control, not a feature toggle.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- That same survey found that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree governance is critical.
A question worth separating out:
Q: What is the difference between just-in-time access and standing privilege?
A: Just-in-time access grants privilege only for a defined task window, while standing privilege remains active until someone removes it. JIT reduces exposure by shrinking the time an identity can be abused, but standing privilege creates a constant attack surface. For NHI programs, the difference is often the difference between contained risk and persistent exposure.
👉 Read our full editorial: GCP just-in-time access exposes the limits of static permissions
