Cloud user access reviews are failing in SaaS ecosystems

At a glance

What this is: This is an analysis of why cloud user access reviews need a different operating model in SaaS and multi-cloud environments, with the core finding that distributed identities and rapid permission change make manual certification unreliable.

Why it matters: It matters because IAM, IGA, and PAM teams must govern human users, service identities, and privileged cloud access together or accept growing audit, security, and accountability gaps.

👉 Read SecurEnds' analysis of cloud user access reviews across SaaS and multi-cloud environments

Context

Cloud user access review is the practice of validating whether people, service accounts, and privileged entitlements still match current business need across SaaS and cloud platforms. In modern environments, access no longer lives in one system or changes at one pace, which makes traditional review cycles easy to outrun.

The governance problem is not just scale. SaaS tools, cloud infrastructure, and connected applications create distributed identity relationships that accumulate privilege over time, especially where approvals, project work, and integrations move faster than certification cadences. For IAM teams, that turns access review from a periodic control into a continuous visibility problem.

Key questions

Q: How should security teams implement cloud user access reviews across SaaS and multi-cloud environments?

A: Start with a single inventory of identities, entitlements, and connected applications across your cloud estate, then segment reviews by risk and identity type. Human users, shared accounts, and service accounts need different certification logic, because ownership, expiry, and remediation differ. The goal is not just approval, but provable removal of access that no longer matches business need.

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. In cloud environments, risk accumulates through integrations and role chaining, so the biggest exposure often sits outside the obvious user list. If the inventory is incomplete, certification will be incomplete too.

Q: What breaks when cloud access reviews are still run like on-premise recertifications?

A: You lose pace, coverage, and evidence quality. On-premise review models assume slower change, clearer ownership, and fewer identity relationships than modern SaaS and cloud ecosystems actually have. That mismatch leaves temporary access, orphaned accounts, and overprivileged integrations in place long after the business need has changed.

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.

Technical breakdown

Why cloud access review breaks across SaaS and multi-cloud

Traditional access review assumes a bounded system, stable roles, and permissions that change slowly enough for periodic certification. SaaS and multi-cloud platforms do the opposite. A single user may hold access through app roles, cloud policies, shared workspaces, third-party integrations, and federated identities, all of which evolve independently. The result is a review problem that is distributed rather than hierarchical. Manual spreadsheets cannot reliably capture inherited permissions, temporary elevation, or app-to-app trust relationships at enterprise scale.

Practical implication: map access review coverage to every cloud and SaaS control plane, not just the identity provider.

Privilege sprawl, dormant access, and service account risk

Privilege sprawl happens when access is granted for speed and then retained after the original need disappears. In cloud environments, that often includes temporary admin rights, former employee accounts, unused project permissions, and service accounts that continue to carry broad authority. Service identities are especially difficult because ownership is often unclear and their permissions can outlive the workflow that created them. Once that happens, the certification problem becomes one of lifecycle governance, not just review cadence.

Practical implication: review dormant access and non-human identities as separate populations with their own ownership and expiry rules.

Access certification evidence in regulated cloud environments

Audit pressure changes the design of access review because regulators and auditors want proof, not intent. In cloud settings, that means demonstrating that privileged accounts were reviewed, inactive identities were removed, and segregation of duties was enforced across systems that change continuously. A certification programme that cannot produce reliable evidence for who approved what, when remediation happened, and what access remained after review will struggle in SOX, HIPAA, GDPR, ISO 27001, and SOC 2 contexts.

Practical implication: build review workflows that retain reviewer decisions, remediation status, and exception history as audit artefacts.

Threat narrative

Attacker objective: The attacker or insider seeks persistent access to cloud data and administrative functions by exploiting stale permissions and weak certification.

1. Entry begins when employees adopt SaaS tools, integrations, and cloud services faster than the central governance model can inventory them.
2. Escalation occurs when temporary rights, inherited permissions, and service account access become permanent standing privilege across multiple platforms.
3. Impact is excessive exposure, stale access, and audit failure, which expands the attack surface for misuse, compromise, and unauthorized data access.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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 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.

Privilege sprawl is the failure mode that cloud certification programs are really trying to contain. Temporary access becomes permanent, former employees remain active, and service accounts keep broad rights long after the workflow that created them. That is a lifecycle failure as much as a review failure, because the access was never forced back to an explicit owner or expiry condition. The practitioner conclusion is that entitlement drift has to be treated as a standing governance exception, not an occasional cleanup task.

Shadow IT turns access review into an incomplete inventory problem before it ever becomes a certification problem. If the organisation cannot see every SaaS platform, it cannot certify access consistently or prove that review coverage is complete. This is why visibility across approved and unapproved cloud services is a prerequisite control, not a reporting nice-to-have. The practitioner conclusion is that hidden applications should be treated as ungoverned identity domains until inventoried.

Service account accountability is the weakest point in many SaaS governance models. The article correctly highlights that non-human identities often retain elevated privileges indefinitely and are difficult to assign to a business owner. That is the governance assumption that fails: access review frameworks were designed for identities with clear human ownership and a leaver event. The practitioner conclusion is that NHI review must be explicit, or cloud certification will miss the identities most likely to carry persistent risk.

Continuous certification is becoming the only workable model for cloud identity assurance. In cloud and SaaS environments, roles, permissions, and integrations shift too often for annual or quarterly review alone to provide credible assurance. That does not eliminate recertification, but it changes its function from the primary control to one component of continuous governance. The practitioner conclusion is that teams should measure review coverage, remediation speed, and orphaned access reduction together.

From our research:

• 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.
• See NHI Lifecycle Management Guide for how lifecycle controls reduce the chance that stale cloud credentials remain certified after they should have been removed.

What this signals

Privilege sprawl is no longer just an IAM hygiene issue, it is a cloud operating condition. Once organisations run dozens of SaaS platforms plus cloud infrastructure, access review must evolve into continuous entitlement governance. The practical signal is that teams need one review model for people and a different one for service identities, or certification will keep missing the accounts with the longest risk tail.

With 4.6% of public GitHub repositories containing at least one hardcoded secret, according to The State of Secrets Sprawl 2025, hidden credentials remain a structural input to access review failure. That figure is a reminder that cloud governance is not only about approving access, but also about discovering where access has already been embedded outside formal workflows. Teams should pair certification with continuous secret discovery and ownership mapping.

Shadow SaaS and unowned service identities point to the same underlying gap: visibility collapses before control can begin. The next step for mature programmes is not more spreadsheet review, but better entitlement telemetry across approved and unapproved platforms. That is where Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both help teams connect inventory, governance, and response.

For practitioners

• 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.
• Track remediation as part of the review record Record reviewer decisions, revocations, exceptions, and completion status in the same workflow so audit evidence shows both the decision and the control outcome.

Key takeaways

• Cloud access review fails when organisations apply stable on-premise certification models to fast-changing SaaS and multi-cloud identities.
• The clearest risk signals are privilege sprawl, orphaned access, shadow IT, and service accounts that keep broad rights without explicit ownership.
• Effective programmes combine central visibility, identity-type separation, and audit-ready remediation tracking rather than relying on periodic manual review alone.

Key terms

• Cloud Access Certification: Cloud access certification is the process of validating whether permissions across SaaS and cloud platforms still match business need. It is broader than a user-only review because it must include inherited permissions, shared access, and non-human identities that can retain authority long after the original request has changed.
• Privilege Sprawl: Privilege sprawl is the accumulation of excess permissions as users move between projects, applications, and responsibilities. In cloud environments it often appears as temporary access that becomes permanent, broad administrator roles, and service accounts that keep more authority than the workflow requires.
• Service Account: A service account is a non-human identity used by software, integrations, or automation to access cloud resources. Unlike a human user, it may lack obvious ownership, making lifecycle control, review, and revocation harder unless governance explicitly assigns responsibility and expiry conditions.
• Shadow SaaS: Shadow SaaS is cloud software adopted outside formal IT approval or governance workflows. It creates an identity problem as much as a procurement problem, because access, data, and administrative rights can exist in systems that security teams never fully inventory or certify.

Deepen your knowledge

Cloud user access review across SaaS and multi-cloud environments is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is dealing with privilege sprawl, service accounts, and audit evidence at the same time, this is a relevant starting point.

This post draws on content published by SecurEnds: cloud user access reviews across SaaS and cloud applications. Read the original.