Cloud privileged access management best practices for cloud breaches

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: Privilege abuse still drives most major cloud breaches through over-permissioned and poorly reviewed identities.

Why it matters: It matters because IAM, PAM and cloud security teams need to govern machine, human and third-party access as one privilege problem, not as separate admin workflows.

By the numbers:

• 92% of identities are over-permissioned, and 62% are dormant.

Context

Cloud privileged access management is the discipline of discovering, controlling and continuously enforcing least privilege across identities that can perform high-impact actions in cloud environments. The problem is that cloud permissions scale faster than manual governance, so inherited access, dormant accounts and overly broad roles accumulate before teams can review them.

In this article, Sonrai Security frames cloud PAM as the response to that scale problem across human users, service accounts, machine roles, API keys and pipelines. The article is anchored in cloud identity governance, with post-merger cleanup, usage-based rightsizing and just-in-time access as the operational pressure points.

For IAM practitioners, the key issue is not whether privileged identities exist. It is whether access is continuously governed against actual usage, so that standing privilege does not become the default cloud security posture.

Key questions

Q: What breaks when cloud privileged accounts are not continuously discovered and managed?

A: When discovery is incomplete, organisations lose visibility into unknown admins, stale delegated access, and privilege changes that happen faster than manual review cycles. That gap weakens auditing, risk management, and enforcement of controls such as MFA and key rotation. It also leaves attackers with more time to exploit standing privilege across development and production environments.

Q: Why do standing privileges increase breach impact in cloud and enterprise environments?

A: Standing privileges enlarge the attacker’s options because one exposed administrative path can be reused for lateral movement, persistence, or broad operational control. In cloud environments, that risk is worse when human admins and machine identities both retain long-lived elevation. The practical result is higher blast radius from a single compromise.

Q: When should organisations prioritise workload IAM over extending PAM?

A: Organisations should prioritise workload IAM when privileged access is driven by CI/CD, cloud workloads or AI agents that need fast, repeatable access without human interaction. Extending PAM can help at the margins, but the architectural fit is weaker when the identity is ephemeral and the decision must happen at request time.

Q: What role do M&A events play in cloud privilege risk?

A: Acquisitions often import inherited roles, stale credentials and access standards that no longer match the acquiring organisation. That creates a governance gap where access remains active but no one can justify it cleanly. Teams should treat post-merger cleanup as a privileged access exercise, because leftover cloud access is one of the easiest ways for risk to persist.

Technical breakdown

Why cloud privilege becomes harder to govern at scale

Cloud privilege is broader than the traditional sysadmin model because any identity that can change policies, write to production, or access secrets can become high impact. That includes service accounts, Lambda functions, CI/CD pipelines and delegated roles, all of which can accumulate permissions faster than a manual review cycle can track. In cloud estates, the attack surface is defined less by named administrators and more by the permission combinations attached to every active identity. Once privilege is inherited, cloned, or left dormant after an organisational change, it becomes much harder to separate intended access from leftover access.

Practical implication: inventory every identity type that can take privileged cloud actions and treat inherited access as a governance defect, not an operational convenience.

How standing privilege turns credential theft into escalation

Standing privilege is dangerous because it gives an attacker immediate value after credential theft, whether the entry point is an exposed key, a leaked secret, or a phished account. The important mechanism is not just initial access, but what the compromised identity can do without further approval. If that identity can pass roles, create functions, modify policies, or read secrets, privilege escalation becomes a short path rather than a separate phase. Cloud PAM exists to compress that path by reducing what any single identity can do at rest.

Practical implication: map your highest-risk permissions to the identities that hold them and remove broad standing access where a stolen credential would otherwise become environment-wide control.

Why usage-based rightsizing beats role assumptions

Role-based access often drifts away from actual behaviour because access is granted for delivery speed and then never trimmed back. Usage-based rightsizing reverses that logic by asking what an identity has actually exercised, not what someone thought it might need at provisioning time. That matters because unexercised permissions are usually the first sign of privilege creep, especially after M&A, team changes, or long-lived automation. Cloud PAM becomes meaningful only when access reviews are tied to observed activity rather than abstract role templates and stale approvals.

Practical implication: right-size cloud access from observed usage data and quarantine identities whose permissions have not been exercised within a defensible review window.

Threat narrative

Attacker objective: The objective is to turn a single compromised cloud identity into broad control over workloads, policies, or sensitive data.

1. Entry typically begins with a stolen key, leaked secret, phished user, or misconfigured service account that grants initial cloud access.
2. Escalation follows when the compromised identity already holds broad permissions or can use role chaining, policy changes, or secret access to expand control.
3. Impact occurs when attackers use that expanded privilege to move across cloud resources, alter workloads, or extract data and secrets at scale.

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.

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

NHI Mgmt Group analysis

Cloud privilege has outgrown the traditional admin model: Cloud PAM now has to govern every identity that can perform high-impact actions, not just human administrators. That includes service accounts, pipelines, workload roles and delegated app identities. The field has moved from account management to permission economics, where the question is how much damage any one identity can cause if it is compromised. Practitioners should model privilege by capability, not by job title.

Standing privilege is the breach multiplier: Privilege abuse becomes most dangerous when access persists between tasks and is broad enough to be repurposed after compromise. That is why cloud breach patterns repeatedly collapse into escalation rather than clean initial access. The decisive governance issue is not simply that access exists, but that it remains usable long after the business need has passed. Teams should treat persistent high-risk access as a structural exposure, not a review backlog.

Usage-based rightsizing is the named concept that cloud PAM is missing: Privilege should be measured by what an identity actually does, not by what its role once justified. That assumption breaks after M&A, template cloning and developer-driven provisioning because access outlives the context that created it. The implication is that entitlement governance must be grounded in observed usage, or dormant permissions will continue to define the attack surface. Practitioners should re-centre cloud PAM on behaviour, not allocation.

Post-merger cloud estates expose the weakest governance assumptions: Inherited IAM roles and dormant service accounts are not edge cases, they are where cloud governance is most likely to fail. Acquisitions import access histories that rarely match the acquiring organisation's standards, and those leftovers persist if no one owns them. This is why post-M&A remediation is a cloud PAM problem as much as an integration problem. Security teams should assume the inherited estate is already privileged until proven otherwise.

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.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Usage-based rightsizing is becoming the control that separates real cloud PAM from compliance theatre: cloud environments change too quickly for role assumptions and quarterly review cadences to keep up. Access that is not exercised should not remain on the books, especially when it belongs to service accounts, pipelines or inherited roles that nobody actively owns.

Dormant privilege is the practical signal to watch: once an identity has been inactive long enough to be forgotten, its permissions usually outlive its accountability. That is why cloud teams need event-driven review triggers for M&A, role change and deployment change, not just scheduled recertification.

For IAM programmes, cloud PAM is now a control-plane problem as much as an access problem: the environment has to answer who can do what, when, and under whose ownership. If that answer is unclear for a privileged identity, the programme has already lost visibility.

For practitioners

• Inventory every privileged cloud identity Build a complete inventory of human users, service accounts, machine roles, APIs and delegated cloud identities that can perform high-impact actions. Include inherited accounts from acquisitions and dormant identities that still hold valid credentials.
• Right-size access from observed usage Review what each identity has actually exercised and remove permissions that have not been used. Replace role assumptions and cloned templates with rightsizing based on real activity data.
• Eliminate standing privilege for high-risk actions Move sensitive cloud permissions to just-in-time workflows so elevated access exists only for the duration of a task and is revoked automatically when it ends.
• Quarantine dormant and zombie identities Flag identities that have not logged meaningful activity but still retain privileged access, then deny their privileged permissions until ownership and need are revalidated.
• Trigger reviews on operational change Use event-driven access reviews for M&A, role changes, new deployments and anomalous usage instead of waiting for a quarterly cycle to catch drift.

Key takeaways

• Cloud breaches still frequently hinge on privileged access abuse, especially where access persists after the original business need has passed.
• The risk is amplified by dormant identities, inherited roles and broad permissions that can be repurposed after compromise.
• The strongest control response is to govern by actual usage, remove standing privilege where possible and trigger reviews when the environment changes.

Key terms

• Cloud Privileged Access Management: Cloud Privileged Access Management is the discipline of discovering and controlling identities that can make high-impact changes in cloud environments. It covers human and non-human identities alike, with continuous enforcement of least privilege, task-scoped access, and lifecycle ownership across accounts, roles, and automation.
• 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.
• Usage-Based Rightsizing: Usage-based rightsizing is the process of trimming permissions based on actual observed activity rather than assumed need. In cloud identity programmes, it helps distinguish active entitlements from leftover access that persists after team changes, M&A, or workload drift.
• Dormant Identity: A non-human identity that is no longer actively used but still has valid access. Dormancy is risky because it looks harmless while preserving credentials, permissions, and trust relationships that can still be abused or accidentally triggered.

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.