They often review users without reviewing the apps, integrations, and privilege paths those users can reach. In SaaS environments, access review must include delegated access, third-party connections, and standing privileges, or the review only captures part of the real risk surface.
Why SaaS Access Reviews Miss the Real Risk
SaaS reviews often focus on named users and groups while ignoring the apps, API tokens, OAuth grants, delegated admin paths, and service-to-service connections that actually move data. That creates a false sense of assurance: the user may be removed from one role, yet a connected integration still has standing access. The risk is especially acute in environments where secrets and tokens outlive the people who created them, a pattern discussed in the Ultimate Guide to NHIs and reflected in the OWASP Non-Human Identity Top 10.
NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, which explains why access recertification often stops at the human layer. When reviews do not include the identity-bearing objects behind SaaS access, teams miss privilege paths that can still reach customer data, admin consoles, and downstream integrations. In practice, many security teams discover the problem only after an offboarded user still has active reach through a forgotten app connection, rather than through a clean review cycle.
How to Review SaaS Access as a System, Not a User List
Effective SaaS access reviews should treat each application as a bundle of identities and entitlements, not just a roster of employees. That means reviewing who can sign in, which apps can act on behalf of users, which integrations have OAuth consent, which service accounts are still valid, and which administrators can re-grant access without additional approval. Current guidance suggests that access review should be tied to actual privilege paths, not merely directory group membership.
A practical review flow starts with inventory, then expands into delegated access and machine access. Teams should reconcile the SaaS tenant’s internal roles with connected identities, external collaborators, and any third-party tools that hold tokens or long-lived API keys. The NHI Lifecycle Management Guide is useful here because it frames provisioning, rotation, and offboarding as linked steps rather than separate tasks. For deeper breach context, the 52 NHI Breaches Analysis shows how compromise frequently follows weak visibility into non-human access.
- Review user access and app consents in the same cycle.
- Map every integration to an owner and an expiration date.
- Check delegated admin, support access, and break-glass paths separately.
- Validate whether service accounts and tokens are still required.
- Revoke access that has no business owner or no time limit.
Where this guidance breaks down is in sprawling SaaS estates with shadow IT, unmanaged OAuth grants, and no central log source, because the review team cannot reliably see the full privilege graph.
Common SaaS Edge Cases That Skew the Review
Tighter access review often increases operational overhead, requiring organisations to balance recertification rigor against review fatigue and business disruption. The most common edge case is “indirect access,” where a user appears low risk but can trigger sensitive actions through a connected app, automation, or vendor integration. Another is shared admin tooling, where one approval covers multiple SaaS tenants and hides the true blast radius. There is no universal standard for this yet, but best practice is evolving toward reviewing the privilege path itself, not just the person at the keyboard.
This is where breach patterns matter. The Salesloft OAuth token breach illustrates how a valid integration can expose downstream data even when user access appears controlled. The broader lesson aligns with the Ultimate Guide to NHIs — Key Challenges and Risks: standing privileges, stale tokens, and third-party exposure are often the real control failures. Organisations should treat every SaaS review as a question of who can act, through what credential, for how long, and with whose approval.
In practice, reviews go wrong when they certify a user as clean while leaving the integration that user created fully active.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Access reviews must catch stale non-human credentials and standing privileges. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege review applies to users, service accounts, and delegated access paths. |
| NIST AI RMF | Governance should cover the full access path, including autonomous or integrated workloads. |
Validate each SaaS entitlement against least privilege and remove unused or overbroad access.
