Notifications
Clear all
Topic starter
04/06/2026 6:50 pm
TL;DR: SaaS environments are breaking traditional user access review models because access now spans distributed applications, service accounts, APIs, and rapidly changing permissions, according to SecurEnds. Access review programmes that assume stable roles and static systems can no longer keep pace with privilege sprawl, shadow IT, and orphaned access.
NHIMG editorial — based on content published by SecurEnds: cloud user access reviews across SaaS and cloud applications
Questions worth separating out
A: Start with a single inventory of identities, entitlements, and connected applications across your cloud estate, then segment reviews by risk and identity type.
Q: Why do SaaS access reviews often miss the highest-risk access?
A: They usually focus on named users and miss inherited permissions, shadow IT, and service accounts with long-lived privileges.
Q: What breaks when cloud access reviews are still run like on-premise recertifications?
A: You lose pace, coverage, and evidence quality.
Practitioner guidance
- Centralize entitlement inventory across cloud and SaaS platforms Pull identities, roles, permissions, and connected applications into one certification view so reviewers can see inherited and indirect access before approval decisions are made.
- Separate human, service, and shared account reviews Create distinct certification workflows for employees, service accounts, and shared credentials because each population has different ownership, expiry, and evidence requirements.
- Prioritize high-risk applications first Run more frequent reviews for production infrastructure, finance systems, customer data platforms, and administrator roles before expanding to lower-risk tools.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform review patterns for Microsoft 365, Salesforce, AWS, GCP, ServiceNow, Slack, and GitHub
- Practical examples of which entitlements to certify in each environment, including admin roles, service accounts, and shared access
- Workflow guidance for automated review routing, escalations, and evidence capture
- Implementation detail on how to prioritize high-risk applications without losing governance coverage
👉 Read SecurEnds' analysis of cloud user access reviews across SaaS and multi-cloud environments →
Cloud access certification in SaaS: what IAM teams are missing?
Explore further
04/06/2026 7:03 pm
Cloud access review is now a distributed governance problem, not a periodic checkbox. The article's core point is that SaaS ecosystems change too quickly for human-paced certification to stay complete. Access now spans application roles, cloud policies, service identities, and third-party integrations, so the control surface is fragmented by design. The practitioner conclusion is that review scope must follow the identity graph, not the application list.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- 15% of commit authors have leaked at least one secret in their contribution history, according to the same research.
A question worth separating out:
Q: Who is accountable when stale cloud access causes a security or audit failure?
A: Accountability should sit with both the application owner and the identity governance function, because one owns the business need and the other owns the control evidence. For service accounts and shared credentials, a named technical owner is essential. Without ownership, remediation stalls and auditors will treat the gap as an unmanaged control failure.
👉 Read our full editorial: Cloud user access reviews are failing in SaaS ecosystems
