Start with discovery across cloud, SaaS, source control, and automation layers, then compare what exists to what IAM knows about. The goal is to identify active apps, accounts, keys, and certificates with no owner or lifecycle record. Use the output as a governance backlog, not just a discovery report, and link it to remediation ownership so hidden access gets closed.
Why This Matters for Security Teams
Unonboarded identities are often the first sign that access has escaped governance. These are not just orphaned accounts; they can be API keys in source control, service principals in cloud tenants, OAuth grants in SaaS, or certificates issued outside normal provisioning. When security teams cannot see them, they cannot rotate, revoke, or attest them, which turns hidden access into a persistent attack path.
The problem is broader than classic IAM hygiene because discovery must span cloud, SaaS, automation, and developer tooling. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that asset visibility is foundational to risk management, yet many organisations still treat non-human identities as an afterthought. NHIMG research shows the confidence gap is real: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for human identities, according to The State of Non-Human Identity Security.
In practice, many security teams discover these identities only after a repository leak, an over-permissioned OAuth app, or a cloud audit has already exposed them.
How It Works in Practice
Effective discovery starts with building an inventory from the outside in. Security teams collect identity signals from cloud IAM, SaaS admin consoles, source control, CI/CD pipelines, secrets managers, certificate authorities, and automation platforms. The goal is to compare what exists in the environment against what IAM, CMDB, or ticketing systems believe exists, then flag anything with no owner, no business service mapping, or no lifecycle record.
This is where NHI-specific discovery differs from human identity reviews. A human account usually has a named owner and HR record. An NHI may exist as a token, webhook secret, workload identity, machine certificate, or robot account with no obvious business owner. Current practice is to normalise these records into a single inventory and enrich them with metadata such as last use, privilege scope, creation source, and expiration. Controls in The State of Non-Human Identity Security show why this matters: lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, and inadequate monitoring and logging is close behind.
- Start with cloud APIs and SaaS admin exports, then add code scanning for embedded secrets.
- Correlate identity records with usage logs to find active access that was never formally onboarded.
- Tag each finding by owner, system, privilege level, and expiry state so remediation can be assigned.
- Prioritise identities that can reach production data, automation pipelines, or third-party integrations.
For implementation discipline, teams often align the workflow to the NIST Cybersecurity Framework 2.0 concepts of Identify, Protect, and Detect, then use discovery results to drive revocation, rotation, or onboarding corrections. This guidance tends to break down in highly fragmented multi-cloud estates where shadow IT and local admin privileges prevent complete telemetry.
Common Variations and Edge Cases
Tighter discovery often increases operational overhead, requiring organisations to balance visibility against the friction of collecting data from many control planes. That tradeoff is real, especially when business units run their own tooling or when DevOps teams create short-lived identities faster than central IAM can record them.
One common edge case is ephemeral automation. Some identities are intentionally short-lived and may never appear in a traditional onboarding flow. Current guidance suggests these should still be registered through workload identity patterns, but there is no universal standard for this yet across all platforms. Another edge case is third-party OAuth access, where the “identity” is really delegated application access rather than a user account. NHIMG research highlights the visibility problem here: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, as described in The State of Non-Human Identity Security.
Operationally, teams should also watch for secrets exposed in developer workflows. The JetBrains GitHub plugin token exposure and Azure Key Vault privilege escalation exposure are useful reminders that identities can be created, leaked, or over-scoped outside formal IAM workflows. The right response is not just cleanup, but a recurring discovery process tied to ownership and revocation SLAs.
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 and CSA MAESTRO address the attack and risk surface, while 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 | Discovery and inventory are core to finding unmanaged non-human identities. |
| CSA MAESTRO | I-1 | MAESTRO covers visibility and governance for autonomous and non-human workloads. |
| NIST AI RMF | AI RMF governance supports accountability for automated identities and agents. |
Build and continuously reconcile an NHI inventory so unknown identities are flagged for owner assignment or removal.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
