Least privilege in multi-cloud fails when access stays standing

At a glance

What this is: This solution brief explains how to roll out least privilege across AWS, GCP, and Azure, and argues that standing access remains the main blocker to workable cloud governance.

Why it matters: It matters because IAM, PAM, and NHI programmes all fail in the same place when permissions outlive the task, the user, or the workload.

👉 Read P0 Security's guide to rolling out least privilege in AWS, GCP, and Azure

Context

Least privilege is simple in principle but difficult in cloud reality: identities should only have the access required for the task, and only for as long as the task lasts. In multi-cloud environments, that promise breaks down when permissions accumulate across IAM layers, identity providers, and operational shortcuts.

The governance gap is not abstract. Standing privileges, over-provisioned roles, and incomplete offboarding create a durable attack surface for both human and non-human identities, which is why least privilege must be treated as a lifecycle problem rather than a one-time hardening exercise.

Key questions

Q: What breaks when standing privileges are left in place for cloud infrastructure changes?

A: Standing privileges increase the chance that a routine change can affect shared systems far beyond the intended task. In cloud environments, that can turn one valid administrative action into a production outage, a security incident, or both. The problem is not just misuse by attackers. Persistent access expands the blast radius of legitimate work.

Q: Why do overprivileged cloud identities increase risk even when teams think access is needed for productivity?

A: Overprivileged identities widen the range of actions an attacker or misconfigured workflow can take. In cloud environments, standing access often persists long after the task changes, which makes privilege creep and accidental misuse more likely. Limiting access to what is actually used reduces the chance that benign convenience becomes a security incident.

Q: How do security teams know whether least privilege is actually working?

A: Least privilege is working when identities have narrowly scoped permissions, unused credentials are removed or quarantined, and repeated access reviews consistently shrink entitlements. A good signal is whether a compromised identity would be unable to move beyond one bounded workflow. If broad resource reach still exists, the control is not effective.

Q: What happens when offboarding does not remove access promptly?

A: When offboarding is slow or incomplete, departing employees can keep access to sensitive systems and data after they no longer need it. That creates avoidable exposure, especially where accounts span multiple applications or branches. Security teams should treat revocation as a required control, because delayed removal turns a normal personnel change into a standing access risk.

Technical breakdown

Why standing privileges persist across AWS, GCP, and Azure

Cloud platforms make access easy to grant and hard to unwind because permissions are distributed across roles, policies, service accounts, and identity provider layers. That fragmentation encourages administrators to keep access standing so work can proceed without repeated approvals. In practice, the problem is not just over-permissioning but control drift, where the access model becomes detached from the task model and no longer reflects what each identity actually needs.

Practical implication: map every identity to its effective entitlements, not just its assigned role, before attempting least-privilege reduction.

How policy analyzers and trail logs expose excess access

Policy analyzers can identify unused or excessive permissions, but they often need support from trail logs to resolve ambiguous usage. That pairing matters because an entitlement may look unused in one tool while still being exercised indirectly in another context. Correlating findings with activity history turns least privilege from a static review into evidence-based scoping, which is the only way to distinguish real access from inherited access.

Practical implication: combine permission findings with usage logs before removing access, especially in multi-cloud estates.

What just-in-time permissioning changes in cloud identity control

Just-in-time access replaces persistent privilege with task-scoped elevation, so the identity begins with little or no standing access and receives permissions only for the approved window. That model works across humans and NHIs because it changes the control point from provisioning to issuance. The key architectural shift is that access becomes an event, not a state, which sharply reduces the period during which a compromised or misused identity can act.

Practical implication: treat JIT as the enforcement layer for privileged cloud tasks, not as a substitute for inventory and entitlement review.

Threat narrative

Attacker objective: The objective is to turn excess cloud access into broad operational impact by abusing permissions that were never narrowed to the task.

1. Entry occurs when a human or non-human identity is provisioned with standing permissions that exceed what the task requires.
2. Escalation follows when an attacker or misused account leverages those excess privileges to reach resources such as production data, admin controls, or sensitive cloud services.
3. Impact appears as unauthorized changes, data exposure, ransomware execution, or offboarding failures that let access persist after the identity should have been removed.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Least privilege in cloud is a lifecycle control, not a permission-setting exercise. The article shows that teams fail when they treat access as something to assign once and revisit later. In AWS, GCP, and Azure, the effective control is whether privilege can be scoped, reviewed, and revoked as usage changes. Practitioners should stop describing least privilege as a configuration state and start managing it as an entitlement lifecycle.

Standing privilege is the control failure that turns routine cloud access into disproportionate exposure. Once identities can keep permissions after the task ends, the attack surface expands for both accidental misuse and deliberate abuse. This is exactly why access reviews alone do not solve the problem if they are not tied to live usage evidence. The practical conclusion is that persistence of privilege is the risk variable, not merely the size of the role.

Ephemeral cloud access creates an identity blast radius problem. When permissions are granted only for the work window, the programme must control how wide that window can be and how quickly it closes. That changes the governance conversation from “who has access” to “how long can this identity remain powerful enough to matter”. Teams should reframe privilege management around blast-radius containment across human and non-human identities.

Inventory, usage correlation, and JIT form one control chain, not three separate projects. The brief’s sequence is important because each step corrects a different blind spot: inventory shows what exists, trail logs show what is actually used, and JIT enforces the narrowed state. Breaking that chain leaves the programme with either blind entitlements or unenforced reductions. Practitioners should govern the full chain as one operating model.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Privileged Access Management Guide

What this signals

Standing privilege is the easiest way for cloud governance to drift out of sync with real work. Once permissions are granted broadly and left in place, access reviews become lagging paperwork instead of a live control. Teams should expect the strongest risk reduction when privilege is measured against actual use, not just role design.

Least privilege for NHIs and human users now hinges on the same control pattern. The difference is not the principle but the enforcement point: the programme must know what each identity can do, when it last did it, and when elevated access should disappear. That is why entitlement cleanup, usage correlation, and JIT should be governed together, not separately.

Privilege persistence is the named risk to watch. When access remains valid after the task ends, the organisation inherits an identity blast radius that no cloud vendor setting can fix on its own. The operational answer is tighter issuance, faster revocation, and a cleaner link between identity lifecycle and permission lifecycle.

For practitioners

• Inventory all human and non-human identities Build a complete list of users, service accounts, roles, and service principals across each cloud and the identity provider layer. Least privilege cannot be enforced against unknown principals or undocumented role assignments.
• Right-size permissions with usage evidence Review unused and excess permissions against trail logs and policy analyzer findings, then remove access that has not supported real work within the review window. This avoids stripping permissions that still matter but were not visible in a single tool.
• Replace standing privilege with just-in-time elevation Move privileged actions to task-scoped access requests so elevated roles attach only for the approved duration and retract automatically after completion. Apply the same model to admin users and high-risk workloads.
• Correlate offboarding with entitlement cleanup Tie leaver workflows to cloud access revocation so identities do not retain access after employment ends, team changes, or workload retirement. Offboarding gaps turn dormant accounts into standing risk.
• Monitor the identity provider layer as part of cloud governance Include identity provider actions in cloud access reviews because administrators often bypass resource-level controls there. If the identity provider remains outside the least-privilege programme, access can stay broader than the cloud console suggests.

Key takeaways

• The core problem is not cloud access itself but access that stays standing after the task is done.
• The article shows that unused permissions, trail-log ambiguity, and offboarding gaps all contribute to over-privilege.
• Least privilege works best when inventory, usage correlation, and just-in-time elevation operate as one governed lifecycle.

Key terms

• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Policy Analyzer: A tool for understanding why an identity can access a given resource and what relationships make that access possible. It maps identity, role, and resource connections so teams can trace effective permissions, validate policy design, and investigate unexpected exposure. This is especially useful in large cloud estates with layered inheritance.

What's in the full article

P0 Security's full resource covers the operational detail this post intentionally leaves for the source:

• Step-by-step permission analyzer setup for AWS, GCP, and Azure
• Hands-on guidance for correlating cloud trail logs with policy findings
• Implementation detail for just-in-time elevation in each cloud
• The portal workflow for continuous monitoring and right-sizing

👉 P0 Security's full brief covers the cloud-specific steps for inventory, analysis, and just-in-time enforcement.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.