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.
Why This Matters for Security Teams
SaaS access reviews miss high-risk access because the review unit is often wrong. Teams certify named users, but the real exposure sits in service accounts, OAuth apps, inherited group membership, delegated admin paths, and long-lived secrets that never appear on a simple user roster. That gap is especially dangerous in environments with heavy integration sprawl, where one app can quietly carry access into many others.
NHIs also outnumber human identities by a wide margin, so a human-centric review process cannot realistically capture the full attack surface. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why certification programs keep missing the riskiest entitlements. The issue is not that reviews are absent. The issue is that inventory, ownership, and privilege chaining are incomplete. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both point toward better asset visibility and access governance, but those controls only work if the identity inventory is real. In practice, many security teams discover the highest-risk access only after a third-party integration, API key, or dormant service account has already been abused.
How It Works in Practice
The failure usually starts with scope. Access review tools are fed lists of employees, roles, and applications, then asked to confirm whether access is still appropriate. But the dangerous entitlements often come from non-obvious paths: an app has its own service account, that account inherits permissions through a nested role, and the role itself is authorized through a stale group or an admin-consented integration. If the reviewer never sees the workload identity, the review cannot challenge its privileges.
That is why NHI lifecycle controls matter. The Ultimate Guide to NHIs - Key Challenges and Risks and NHI Lifecycle Management Guide both emphasise visibility, rotation, and offboarding as core controls, not optional hygiene. In practice, a stronger review process should:
- inventory service accounts, API keys, OAuth apps, and machine-to-machine tokens alongside human accounts;
- map inherited permissions and delegated trust paths before certification begins;
- separate standing access from just-in-time access, then flag anything with no expiry;
- assign an accountable owner for every NHI, including vendor-managed integrations;
- require evidence that secrets are rotated and revoked after business purpose ends.
For programme design, the OWASP Non-Human Identity Top 10 is useful for framing failure modes, while NIST Cybersecurity Framework 2.0 helps translate them into repeatable governance outcomes. These controls tend to break down when SaaS administrators can create integrations without central registration because the review team never learns those identities exist.
Common Variations and Edge Cases
Tighter review scope often increases operational overhead, requiring organisations to balance better assurance against slower certification cycles. That tradeoff becomes more visible in tenant-to-tenant migrations, shadow IT, and multi-cloud SaaS estates where ownership is fragmented across business units and external vendors.
There is no universal standard yet for how to certify every NHI path in SaaS, so current guidance suggests using risk-based prioritisation. Start with identities that can write data, impersonate users, call external APIs, or mint secrets for other systems. High-risk cases often include refresh tokens with broad scopes, service principals linked to privileged admin roles, and integrations that can be reauthorized without security approval. The 52 NHI Breaches Analysis and the Snowflake breach show how quickly hidden machine access can become enterprise-wide exposure when secrets and permissions are not tightly governed.
Current guidance also favors treating service accounts as first-class identities, not exceptions to IAM policy. That means access reviews must include ephemeral credentials, secret expiry, and workload ownership, even when the SaaS platform offers limited reporting. The hardest edge case is federated access through vendors, because the customer may see only a generic app entry while the effective privilege sits in the supplier’s automation layer.
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 | Calls for complete NHI inventory and ownership before review. |
| NIST CSF 2.0 | PR.AC-4 | Supports access governance across users, apps, and machine identities. |
| NIST AI RMF | Useful where autonomous tooling and AI-driven workflows create hidden access paths. |
Inventory all service accounts and secrets, then certify access only after ownership is confirmed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
