Least privilege in multi-cloud fails when access stays standing

At a glance

What this is: This brief explains why least privilege is difficult to sustain across AWS, GCP, and Azure when standing permissions, excess access, and weak offboarding persist.

Why it matters: It matters because IAM and IGA teams have to govern cloud access as a living lifecycle across humans and NHIs, not as a one-time cleanup exercise.

👉 Read P0 Security's solution brief on enforcing least privilege in AWS, GCP and Azure

Context

Least privilege is the principle that each identity should hold only the access it needs, only for as long as it needs it. In multi-cloud environments, that principle becomes harder to enforce because permissions can be granted through cloud-native policies, identity provider layers, and temporary elevation paths that drift into standing access.

The governance gap is not simply cloud complexity. It is the assumption that access reviews and manual cleanup can keep pace with real usage when developers, admins, service principals, and other NHIs accumulate permissions faster than teams can re-evaluate them.

When offboarding, usage correlation, and just-in-time elevation are handled separately, identities retain privileges after the task has ended. That is the condition that turns least privilege from a policy into an aspiration.

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 excessive user permissions create security risk?

A: Excessive permissions expand the amount of data, apps, and administrative capability a single account can reach, so any misuse or compromise has a larger blast radius. In IAM terms, the issue is not simply too much access on paper. It is access that is no longer justified by role but still remains active in production systems.

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: How should security teams handle just-in-time access for humans and NHIs?

A: Teams should treat just-in-time access as the operational form of least privilege, not a separate convenience feature. The goal is to start from zero standing privilege, grant access only for the task, and revoke it as soon as the task ends. That model has to cover both human users and non-human identities.

Technical breakdown

Why standing access defeats least privilege

Standing access keeps permissions attached to an identity between tasks, which means the identity carries more authority than the immediate job requires. In cloud environments, that standing state often emerges from convenience, because admins prefer persistent roles, developers want fewer approval delays, and identity provider shortcuts make it easy to bypass cloud-native controls. The result is not just more privilege but a longer exposure window, since the permissions remain usable until someone notices and removes them. In practice, least privilege fails when entitlement duration is treated as an implementation detail instead of part of the control itself.

Practical implication: move entitlement duration into the access policy, not into informal admin habit.

How unused and excess permissions accumulate across AWS, GCP, and Azure

Cloud platforms expose multiple policy layers, so excess privilege can hide in roles, permission sets, service accounts, and identity provider mappings at the same time. Usage-based analysis helps because it compares granted access with actual activity and can reveal permissions that have not been exercised for long periods. That matters because unused access often looks harmless until an identity is compromised or repurposed. A 90-day unused-access window is useful only if the organisation treats it as a trigger for revocation, not as a reporting metric. Without that follow-through, excess privilege simply becomes documented risk.

Practical implication: correlate entitlement data with usage evidence before leaving any permission in place.

Why just-in-time elevation has to be tied to offboarding

Just-in-time access reduces privilege by making access temporary and task-scoped, but it only works when the identity lifecycle is clean. If joiner-mover-leaver processes are weak, the same identity can still accumulate dormant access outside the elevation window, and offboarding gaps can leave accounts usable after departure. That is especially important for NHIs, where service principals, roles, and keys can persist far beyond the original workflow. Least privilege is therefore not just about how access is granted. It is about whether access is withdrawn reliably when the task, role, or owner changes.

Practical implication: treat JIT, recertification, and offboarding as one lifecycle control for all identities.

Threat narrative

Attacker objective: The objective is to convert excess cloud privilege into broader operational control, data access, or destructive actions.

1. Entry occurs when an identity keeps standing privilege instead of receiving only task-scoped access.
2. Privilege escalation follows when over-privileged roles let the identity perform actions beyond its operational need.
3. Impact appears when that excess access enables deletion, data access, customer disruption, or abuse after offboarding.

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.
• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege is the governance failure least privilege is really trying to eliminate. The article shows that the problem is not simply excess permission count, but access that survives longer than the task that justified it. That makes duration, not just scope, the decisive control variable. Practitioners should treat persistent entitlement as a lifecycle defect, not a cloud hygiene issue.

Least privilege in multi-cloud fails when usage review and permission issuance are disconnected. Cloud policy analyzers can show excess access, but they do not remove the governance burden of deciding when a permission is no longer defensible. Correlating trail data with policy findings is what turns observation into control. The practitioner lesson is that entitlement evidence must drive revocation, not just reporting.

Standing access for NHIs is especially dangerous because offboarding is often under-governed. Service principals, roles, and other machine identities can outlive their original purpose if ownership and cleanup are not explicit. That creates dormant authority that is hard to notice and easy to inherit. Identity teams should govern NHI access as a lifecycle discipline, not as a static permission set.

Just-in-time elevation only works when the surrounding identity model assumes zero standing privilege. The article’s strongest point is that JIT is not a separate feature layer, but the enforcement expression of least privilege itself. If the baseline remains permanently over-provisioned, temporary elevation becomes a patch over a bad model. Practitioners should redesign cloud access so that persistent privilege is the exception, not the operating norm.

From our research library:

• 92% of cloud identities are over-permissioned and 62% are dormant.
• Read next: NHI Lifecycle Management Guide

What this signals

Persistent privilege is the real cloud governance debt. The article makes clear that least privilege fails when access duration is left to habit rather than policy. For IAM and IGA teams, that means the next control maturity step is not another review cycle, but the ability to revoke access cleanly as soon as business need ends.

Entitlement review must become evidence-driven rather than calendar-driven. When trail data, policy analysis, and offboarding are not connected, cloud teams keep discovering the same excess rights after they have already become normal. The practical signal is simple: if access cannot be tied to current use, it should not remain standing.

Standing access turns cloud identity into accumulated blast radius. That is why least privilege in multi-cloud should be measured by how quickly organisations can reduce unused permissions and retire dormant authority, not by how many policies they can enumerate. The governance test is whether access is temporary by design, not temporary by hope.

For practitioners

• Inventory every cloud principal List users, groups, roles, service accounts, and service principals across AWS, GCP, and Azure before attempting any rightsizing or JIT rollout.
• Correlate permissions with real usage Compare policy grants with trail logs and analyzer results so you can see which permissions have been unused for long periods and which are still required.
• Remove standing access from high-risk roles Replace persistent elevated access with time-bound elevation for administrative and production-impacting actions, especially where users can affect databases or customer services.
• Fold offboarding into access revocation Make leaver processing remove both human and NHI entitlements, including roles inherited through identity provider shortcuts and cloud-native permissions.
• Set a revocation threshold for unused access Use a defined inactivity window, such as 90 days where appropriate, to force review of permissions that no longer map to day-to-day work.

Key takeaways

• Least privilege in multi-cloud fails when privilege persists beyond the task, especially across both human and non-human identities.
• The article ties the risk to unused permissions, weak offboarding, and the need to correlate trail logs with policy analysis.
• The practical response is to govern inventory, usage review, and just-in-time elevation as one lifecycle control.

Key terms

• 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.
• Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
• 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 solution brief covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for inventorying users, roles, service accounts, and service principals across AWS, GCP, and Azure
• Platform-specific walkthroughs for identifying unused permissions with IAM analyzers and policy insight tools
• Hands-on steps for setting up just-in-time elevation and removing standing privileges after task completion
• Azure Permissions Management retirement context and the migration considerations it creates for existing governance workflows

👉 P0 Security's full brief includes the cloud-specific inventory, analyzer, and JIT workflow details behind this analysis.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security 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 access governance in your organisation, it is worth exploring.