Cloud privileged access governance is breaking under multi-cloud sprawl

At a glance

What this is: This is an analysis of how cloud privileged access becomes difficult to govern as environments span multiple clouds and accumulate standing rights, service accounts and delayed offboarding.

Why it matters: It matters because IAM, PAM and cloud security teams need a model that can control privileged access at cloud speed without losing visibility across human and non-human identities.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read SecurEnds's analysis of cloud privileged access governance

Context

Cloud privileged access management is the discipline of controlling elevated rights across cloud services, workloads and administrative roles. The problem is no longer a small set of known administrators. It is a moving inventory of cloud IAM admins, DevOps engineers, service accounts and temporary privileges spread across AWS, Azure and GCP, where access can persist long after the original need has changed.

The governance gap is not just scale. Cloud programmes create hidden privileged access through shadow IT, forgotten entitlements and long-lived service accounts that no one reviews consistently. That is why cloud privileged access has become a PAM, CIEM and lifecycle issue at the same time, not a simple role assignment problem.

Key questions

Q: What breaks when cloud privileged access is left standing too long?

A: Standing cloud privilege creates a durable attack path because access survives long after the original task, owner or project has changed. The result is weak accountability, larger blast radius and slower containment when a credential is exposed. In cloud environments, every persistent admin path should be treated as an exception that requires active justification and expiry.

Q: Why do cloud environments make privileged access harder to govern?

A: Cloud environments spread privilege across multiple control planes, identity models and automation layers, so no single console tells the full story. That makes discovery incomplete, reviews slower and revocation easier to miss. The governance challenge is not only who has access, but where effective authority exists across AWS, Azure, GCP and service identities.

Q: How do security teams know if privileged access governance is working?

A: It is working when privileged entitlements are continuously discovered, reviewed on a fixed cadence and reduced quickly when business need changes. Useful signals include fewer standing admin accounts, fewer dormant service accounts and shorter time to revoke unused rights. If access remains visible only at audit time, governance is not operational.

Q: Who is accountable when a cloud privileged account is misused?

A: Accountability should sit with the business owner of the privilege, the platform team that granted it and the governance function that approves its persistence. In practice, shared accountability fails when service accounts and administrative roles are left without clear ownership. Frameworks such as the NIST Cybersecurity Framework 2.0 support clearer access governance and review discipline.

Technical breakdown

Why cloud privileged access becomes a visibility problem

Cloud privilege expands faster than manual governance can track. In traditional environments, privileged access was concentrated in a smaller set of admins. In cloud, the same power is distributed across native IAM roles, service accounts, automation pipelines and delegated administrative permissions. That creates an attribution problem as much as an access problem. If the organisation cannot reliably map who or what holds effective privilege, then review, revocation and segregation of duties all become partial controls. Practical control failure usually starts with incomplete inventory rather than bad intent.

Practical implication: establish continuous discovery of privileged roles, service accounts and dormant entitlements before relying on periodic review.

Just-in-time access versus standing privilege in cloud

Just-in-time access works by reducing the lifetime of elevated permissions to the shortest possible task window. Standing privilege does the opposite. The security difference is not only duration, but recoverability. A long-lived privileged account can be forgotten, repurposed or inherited across projects, which makes its exposure harder to contain. In cloud, this problem is amplified because permissions are often layered across multiple services and identity providers, so a single stale role can retain broad operational reach. The control question is whether privilege exists by default or only when explicitly needed.

Practical implication: make temporary elevation the default for admin and high-risk cloud actions, with automatic expiry as a governance requirement.

Why CIEM and PAM must work together

Cloud Infrastructure Entitlement Management is useful for discovering effective permissions and over-privilege, while PAM is useful for governing access to high-risk operations and enforcing approval, session control or elevation rules. Used separately, each leaves a gap. CIEM can reveal excessive entitlement, but it does not always change behaviour. PAM can enforce tighter control, but it depends on accurate entitlement context. In cloud environments, the strongest control model combines visibility with enforcement so that discovered privilege can be reviewed, reduced and operationally constrained rather than simply documented.

Practical implication: connect entitlement discovery to privileged access controls so that review findings can trigger immediate reduction or expiration.

Threat narrative

Attacker objective: The attacker aims to turn one valid privileged credential into broad cloud control, data exposure or service disruption.

1. Entry begins when an attacker or insider obtains valid cloud credentials through exposed secrets, over-permissioned service accounts or forgotten administrative access.
2. Escalation occurs when standing privilege allows those credentials to reach storage, infrastructure or pipeline resources without an approval gate or session boundary.
3. Impact follows when the actor uses privileged reach to move laterally, alter cloud resources or access sensitive data at scale.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Cloud privileged access has become a lifecycle problem, not a role-management problem. The article is right that access is no longer static enough for once-and-done administration. In cloud environments, privilege appears, changes hands and outlives the original business need far faster than manual governance cycles can absorb. The implication is that access review, expiration and revocation have to be treated as operational controls, not compliance paperwork.

Standing privilege is the real failure mode cloud governance keeps inheriting. The article repeatedly points to temporary access, auto-expiry and automated review because persistent access remains the easiest path to overreach. This is the control gap most cloud programmes still normalise: the organisation knows a privilege is powerful, but leaves it in place because revocation is harder than issuance. Practitioners should treat every long-lived admin path as an exception that requires active justification.

Multi-cloud creates identity blast radius because privilege does not map cleanly across control planes. AWS, Azure and GCP each expose different entitlement models, so a single person or service account can accumulate overlapping authority that no single console fully describes. That is why discovery without governance is incomplete. The practical conclusion is that cloud identity risk is determined by the union of all effective permissions, not the label on one role.

Privileged access governance must cover humans and service accounts with the same lifecycle discipline. The article correctly calls out service accounts as easy to miss, and that is where many cloud programmes fail. Human admins leave, project access changes, but machine credentials often persist. The implication is that offboarding, recertification and expiration must apply equally to people and non-human identities, or the governance model leaves the most durable privilege untouched.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to GitGuardian & CyberArk.
• For a broader control view, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives for how access oversight maps to audit and governance obligations.

What this signals

Cloud privilege governance will increasingly be judged by revocation speed, not review volume. If an organisation can name every privileged role but cannot retire stale access quickly, its control posture is still brittle. The practical signal to watch is whether entitlement discovery is driving actual reduction in access scope across the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, not just generating reports.

Service accounts deserve the same lifecycle discipline as human administrators. Cloud teams often underestimate how much durable risk sits in automation identities, API keys and forgotten administrative accounts. The governance signal is whether offboarding, recertification and ownership checks are applied to non-human access with the same seriousness as human access.

CIEM without enforcement will plateau as a visibility layer. The organisation may see more, but it will not necessarily control more. That is why cloud identity programmes should tie discovery to expiry, review and remediation workflow, using the NIST Cybersecurity Framework 2.0 as the common language for govern, protect and respond.

For practitioners

• Inventory effective privileged access continuously Pull privileged roles, service accounts and delegated admin rights from each cloud control plane into one reviewable inventory. Reconcile what the organisation thinks exists against what is actually active, including dormant and inherited permissions.
• Default high-risk access to time-bound elevation Replace always-on admin rights with temporary elevation for cloud operations that change infrastructure, storage or security policy. Use automatic expiry so access cannot outlive the task that justified it.
• Link entitlement discovery to enforcement Feed CIEM findings into PAM workflows so over-privileged accounts can be reduced, disabled or re-certified without waiting for the next scheduled review.
• Review service accounts on the same cadence as human admins Apply joiner-mover-leaver logic to cloud service accounts, API keys and automation identities. If ownership, use case or workload changes, the credential should be revalidated or retired.

Key takeaways

• Cloud privileged access is now a lifecycle and enforcement problem because privilege is distributed, persistent and hard to trace across control planes.
• The evidence points to a familiar pattern of delayed remediation, overconfidence and weak developer hygiene around credentials and secrets.
• Practitioners should combine continuous discovery, time-bound elevation and lifecycle offboarding so privileged access can be reduced as quickly as it is created.

Key terms

• Cloud Privileged Access: Cloud privileged access is any permission that can change infrastructure, security policy, data access or identity settings across cloud services. In practice, it includes admin roles, delegated permissions, service accounts and automation identities that can have broad operational impact if left standing too long.
• Just-In-Time Access: Just-in-time access is a governance pattern that grants elevated rights only for the duration of a specific task and removes them automatically afterward. In cloud environments, it reduces the time window in which privileged credentials can be abused and makes standing access exceptions easier to see.
• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management is the practice of discovering, analysing and reducing effective permissions across cloud platforms. It focuses on over-privilege, inherited access and dormant entitlements, giving security teams a visibility layer that can feed PAM, review and remediation workflows.
• Service Account: A service account is a non-human identity used by software, scripts or automation to authenticate and act in a system. In cloud environments it often carries durable permissions, so ownership, lifecycle control and revocation matter as much as they do for human administrators.

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.

This post draws on content published by SecurEnds: cloud privileged access management in the cloud era. Read the original.