How should security teams handle access reviews when SaaS discovery is incomplete?

Why This Matters for Security Teams

Incomplete SaaS discovery turns access reviews into a false assurance exercise. If directory, SSO, HR, and direct application records do not line up, reviewers cannot reliably tell whether an account is active, orphaned, over-privileged, or even known to the business. That makes certification a documentation activity instead of an actual control, which is exactly how hidden access survives review cycles.

This is especially risky because SaaS sprawl often includes direct logins, OAuth grants, and shadow admin accounts that do not appear in the usual identity stack. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The same visibility problem affects human access reviews when discovery is incomplete.

Security teams should treat the gap as a control failure, not a reviewer training problem. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research both point to the same operational reality: if the inventory is wrong, the review outcome will be wrong too. In practice, many security teams discover toxic access only after an audit exception, breach, or finance reconciliation exposes systems the review process never saw.

How It Works in Practice

The practical response is to pause certification until the organisation can build a defensible access population. That does not mean waiting for perfect visibility. It means reconciling enough authoritative sources to answer three questions: who has access, what they can do, and whether the account is still justified.

A workable process usually starts with a source-of-truth comparison. Directory groups, SSO assignments, HR status, app-native admin lists, and direct-local accounts should be matched and deduplicated. Any account that cannot be tied back to a person, contractor, or approved service should be marked for investigation rather than approved by default. This is also where NHIMG’s NHI Lifecycle Management Guide is useful, because the same lifecycle discipline applies to human and non-human accounts when ownership, onboarding, and offboarding are incomplete.

• Freeze certification for in-scope apps until discovery reaches a minimum confidence threshold.
• Reconcile identity sources against app-native user lists and privileged roles.
• Flag orphaned, dormant, and directly provisioned accounts for immediate remediation.
• Require reviewers to attest only on verified records, not on assumed completeness.
• Escalate unknowns as exceptions with remediation dates and owners.

This aligns with the general direction of modern identity governance, but there is no universal standard for the exact threshold that should trigger a pause. The right bar depends on regulatory exposure, app criticality, and whether the application holds sensitive data or administrative power. Teams handling cloud and SaaS entitlements should also cross-check identity evidence against the NHI patterns described in the Ultimate Guide to NHIs — Key Challenges and Risks, because stale access and hidden credentials often travel together.

These controls tend to break down in environments with multiple tenant-specific admins, direct database accounts, and app-created shadow users because those identities are not reliably represented in central directories.

Common Variations and Edge Cases

Tighter discovery controls often increase review workload and remediation volume, so organisations must balance certainty against operational churn. That tradeoff is real: a stricter certification process can slow down business approvals, but it is still better than certifying access that cannot be evidenced.

Some environments will not achieve full coverage through SaaS discovery tools alone. M&A activity, contractor-heavy operations, and older business applications often retain local administrators, embedded service accounts, or manually created users outside the identity governance platform. In those cases, best practice is evolving toward risk-based certification: review the highest-impact apps first, require compensating evidence for low-visibility systems, and document the blind spots explicitly rather than treating them as approved.

For NHI-heavy SaaS environments, the same logic applies to API keys, OAuth grants, and automation users. NHIMG’s research on the State of Non-Human Identity Security shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a strong warning that incomplete discovery is not a niche problem. In those cases, access reviews should include app authorisation grants, not just named users, and should separate human entitlements from machine access paths.

Where discovery remains incomplete across several cycles, the issue should be escalated as an identity governance defect with executive ownership, not repeatedly deferred into the next review period.

Related resources from NHI Mgmt Group

• How should security teams handle access reviews for financial reporting systems?
• How should security teams run access reviews for non-human identities?
• How should teams handle stale Active Directory objects before access reviews?
• How should security teams handle access requests when ITSM tools are already in place?