The review scope becomes incomplete because direct-login SaaS, department-owned tools, and shadow applications remain outside certification. That means reviewers can sign off on a partial identity surface while sensitive access persists elsewhere. Strong governance starts with discovery coverage, not with the approval step.
Why This Matters for Security Teams
Access reviews that only include apps bound to SSO create a false sense of coverage. The certification may look clean while direct-login SaaS, API keys, shared admin consoles, and department-owned tools remain outside the review boundary. That gap matters because the access review becomes an attestation of the directory, not an attestation of the actual identity surface.
This is especially dangerous for non-human identities, where access often exists as a token, service account, or embedded secret rather than as a user in the identity provider. NHIMG data shows that only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. When the review scope is too narrow, security teams can approve a partial population and miss the assets most likely to persist unnoticed.
The practical issue is not just missing software. It is missing ownership, missing telemetry, and missing revocation paths. The OWASP Non-Human Identity Top 10 treats visibility and lifecycle control as core risks because access that cannot be enumerated cannot be reviewed meaningfully. In practice, many security teams encounter risky access only after an audit request forces discovery, rather than through intentional governance.
How It Works in Practice
Effective review scope starts with discovery, then maps identities to systems, and only then moves to certification. For SSO-connected applications, the access review can lean on the directory and the identity provider. For everything else, the organisation needs a separate inventory of direct-login applications, locally managed admin accounts, service accounts, API keys, certificates, and embedded secrets.
A stronger process usually combines several controls:
- Classify applications by authentication model: SSO, direct login, machine-to-machine, or mixed.
- Reconcile application owners with identity owners so each access path has a accountable approver.
- Include privileged non-human identities in the same review cycle as human users, not in an afterthought queue.
- Pull evidence from logs, vaults, IAM, and cloud consoles to identify accounts that never appear in the SSO directory.
- Revocation must follow the review outcome, especially for dormant tokens and orphaned secrets.
That approach aligns with the lifecycle emphasis in the NHI Lifecycle Management Guide, where issuance, rotation, and offboarding are treated as governance steps rather than purely operational tasks. It also matches the direction of the OWASP Non-Human Identity Top 10, which pushes teams to review the whole machine identity estate instead of only the directory-backed portion.
Current guidance suggests that access reviews should be driven by the authoritative system of record for each access type, not by a single SSO report. These controls tend to break down when shadow IT uses local accounts and long-lived secrets because there is no reliable source of truth for the certifier to inspect.
Common Variations and Edge Cases
Tighter review scope often increases operational overhead, requiring organisations to balance completeness against review fatigue. That tradeoff is real, especially in environments with mergers, regional business units, or platforms that never integrated with central SSO. Current guidance suggests the answer is not to shrink the review, but to tier it by risk so the most sensitive direct-access systems are reviewed first.
There is no universal standard for this yet, but mature programs usually treat three cases differently. First, SaaS tools with no SSO are brought into a separate certification stream. Second, department-owned applications are added to an app inventory and assigned a formal owner before access review begins. Third, machine identities are reviewed through secret stores and workload inventories rather than user-centric attestations.
The key exception is high-churn engineering environments, where ephemeral credentials and automated pipelines can outpace manual review. In those settings, the review process should focus on policy, rotation, and revocation evidence rather than counting named accounts. The 52 NHI Breaches Analysis shows how often missed machine access becomes an incident path, which is why breadth of discovery matters as much as approval quality.
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-01 | Scope gaps hide non-human identities from review and certification. |
| NIST CSF 2.0 | PR.AC-1 | Identity inventory and access control depend on knowing all active accounts. |
| NIST AI RMF | Risk governance must cover all identity-bearing systems, not just SSO. |
Apply governance processes that include discovery, accountability, and ongoing monitoring for all access paths.
Related resources from NHI Mgmt Group
- What breaks when SaaS app rationalisation is not tied to identity reviews?
- What breaks when governance relies only on quarterly access reviews?
- Why do shadow IT apps create identity risk even when users still have valid SSO access?
- Why do unmanaged SaaS apps create access risk even when SSO is in place?
