Access reviews become incomplete the moment they ignore apps, accounts, or grants created outside IT workflows. The programme may certify the directory while missing actual permissions in downstream systems. That creates false assurance, because the control is validating only the visible part of the identity estate.
Why This Matters for Security Teams
Identity reviews that stop at managed applications create a blind spot between what the directory says and what downstream systems actually allow. That matters because modern environments often include service accounts, API keys, CI/CD grants, SaaS app roles, and machine-to-machine permissions that never pass through the same joiner-mover-leaver workflow. The result is a review that certifies paperwork, not effective access.
NHIs are now a core part of that gap. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. When reviews ignore unmanaged grants, teams miss the permissions most likely to persist after projects, deployments, or vendor changes. That weakens audit defensibility and leaves stale access in place far longer than intended.
The operational mistake is treating the directory as the control boundary. In practice, many security teams encounter privilege drift only after an incident response or audit exception exposes access that was never in scope for review.
How It Works in Practice
Effective access review has to cover the full identity estate, not just managed applications. The first step is inventory: map every place identities are created, delegated, synchronized, or stored, including SaaS admin consoles, cloud roles, automation pipelines, secrets stores, and application-local accounts. NIST’s Cybersecurity Framework 2.0 is useful here because it forces an asset-and-access view rather than a directory-only view.
From there, review evidence should be collected from the source system that enforces the permission, not only from the HR or IAM layer. For example, a service account in a database, a token in a deployment pipeline, or a role in a cloud tenant may all grant access that is invisible to the managed-application catalog. That is why NHI-specific governance matters. The Top 10 NHI Issues and the NHI Lifecycle Management Guide both emphasize lifecycle visibility, rotation, and offboarding as controls that must extend beyond human-centric provisioning.
- Build review scopes from discovered identities, not from application lists alone.
- Separate human entitlements, service accounts, API keys, and delegated app permissions.
- Require system-of-record evidence for each permission under review.
- Flag unmanaged grants for remediation, not just certification.
- Track review coverage as a percentage of actual access paths, not directory records.
This approach is also where many programmes discover their real exposure. A review can look complete while still missing high-impact secrets, third-party grants, and automation accounts that were never onboarded into the managed workflow. These controls tend to break down in hybrid estates with self-service SaaS, developer-owned tooling, and shadow automation because no single directory contains the full permission chain.
Common Variations and Edge Cases
Tighter review scope often increases operational overhead, requiring organisations to balance completeness against evidence collection effort. That tradeoff is real, especially in large environments where some systems cannot export clean entitlement data or where application owners manage access outside central IAM.
Current guidance suggests treating those gaps as risk, not as an excuse to narrow the review. For high-risk systems, manual attestation may still be necessary if automated extraction is incomplete. For lower-risk systems, teams may accept sampling, but best practice is evolving toward continuous entitlement discovery rather than periodic certification alone. The key distinction is whether the review can prove who can act, not merely who was on a managed app roster.
This is especially important where secrets and non-human identities dominate the workload. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities, which is why unmanaged service accounts and API keys must be part of the same control conversation as user accounts. Managed-only reviews miss the very identities most likely to retain standing access after teams think they have cleaned up.
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 | Unmanaged service accounts and keys are NHI blind spots in access reviews. |
| NIST CSF 2.0 | PR.AC-1 | Access reviews must cover every identity source, not only managed apps. |
| NIST AI RMF | GOVERN | Governance requires accountability for hidden or unmanaged access paths. |
Establish ownership for uncovered grants and track remediation through governance processes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
