Notifications
Clear all
Topic starter
25/06/2026 3:13 pm
TL;DR: Cloud privileged access has scattered across AWS, Azure and GCP, making it harder to see, govern and revoke, according to SecurEnds. Temporary access, automated reviews and better entitlement visibility are now core controls because standing privileges and forgotten service accounts turn routine cloud flexibility into persistent risk.
NHIMG editorial — based on content published by SecurEnds: cloud privileged access management in the cloud era
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory effective privileged access continuously Pull privileged roles, service accounts and delegated admin rights from each cloud control plane into one reviewable inventory.
- 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.
- 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.
What's in the full article
SecurEnds's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how its cloud PAM workflow discovers privileged roles and service accounts across AWS, Azure and GCP
- Practical guidance on setting up access review campaigns and revocation workflows for cloud administrators
- Examples of how the platform scores high-risk privileged accounts and prioritises what should be reviewed first
- The vendor's own discussion of how its PAM approach complements CIEM in day-to-day cloud governance
👉 Read SecurEnds's analysis of cloud privileged access governance →
Cloud privileged access governance: what IAM teams are missing?
Explore further
25/06/2026 4:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud privileged access governance is breaking under multi-cloud sprawl
