Non-human identities complicate discovery because they create access paths that do not appear in traditional asset inventories. Service accounts, tokens, bots, and AI agents can hold permissions long after the original business owner has moved on. That means teams need lifecycle and ownership data alongside discovery data to understand actual exposure.
Why This Matters for Security Teams
Non-human identities complicate IT asset discovery because the thing being discovered is not always a device, application, or user account in the traditional sense. Service accounts, API keys, bots, certificates, and agent identities can exist outside CMDB coverage, yet still create real access paths into production systems. That gap matters because discovery tools often track infrastructure, while exposure is shaped by who or what can authenticate, call tools, and move data.
NHI Management 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. That scale makes blind spots routine rather than exceptional. Current guidance from the NIST Cybersecurity Framework 2.0 supports asset visibility, but NHI discovery requires identity context, ownership, and lifecycle data alongside the asset record. The practical issue is not just finding more objects, but understanding which identities can still act long after the business process that created them has changed. In practice, many security teams encounter the exposure only after an audit, incident, or cloud review reveals that the “missing” asset was actually an active identity.
How It Works in Practice
Effective NHI discovery starts by expanding the inventory model beyond hosts and applications. Teams need to correlate service accounts, workload identities, secrets, certificates, CI/CD tokens, and agent credentials with the systems and pipelines that use them. That means pulling data from identity providers, secret managers, source control, container platforms, cloud control planes, and observability tools, then normalising it into one view. The goal is to answer four questions at once: what the identity is, what it can reach, who owns it, and whether it is still needed.
The NHI Lifecycle Management Guide and the Lifecycle Processes for Managing NHIs emphasize that visibility without lifecycle state is incomplete. A token discovered in a repo may be more important than the repository itself if it still grants production access. Likewise, a service account attached to a decommissioned workload may remain valid in IAM even after the workload disappears from CMDB records. This is why NHI discovery should be joined to rotation history, last-use telemetry, offboarding status, and business ownership.
- Tag identities by type, environment, owner, and expiration date.
- Link secrets back to code, pipelines, and runtime workloads.
- Compare discovery results against offboarding and rotation workflows.
- Prioritise identities with production access or broad privilege.
When this is done well, discovery becomes an exposure-management function rather than a static inventory exercise. These controls tend to break down in fast-moving cloud-native environments because identities are created dynamically, reused across pipelines, and left behind when workloads are destroyed.
Common Variations and Edge Cases
Tighter discovery often increases operational overhead, requiring organisations to balance visibility against engineering speed. That tradeoff is especially visible in ephemeral infrastructure, where short-lived containers, CI jobs, and AI agents may create identities that never appear in traditional asset management workflows. Best practice is evolving here, and there is no universal standard for how much runtime identity telemetry should be retained versus summarised.
One important edge case is third-party and delegated access. NHIMG research shows that 92% of organisations expose NHIs to third parties, which means discovery may need to include vendor-managed secrets, partner API keys, and shared automation accounts. Another edge case is dormant but still-valid credentials: the Top 10 NHI Issues resource highlights how excessive privileges and poor offboarding turn “unknown” identities into persistent risk. Where secrecy is embedded in code or config, discovery must extend into repositories and deployment artefacts, not just IAM consoles.
The practical rule is simple: if an identity can authenticate, it belongs in discovery even when no human thinks of it as an asset. That is why NHI visibility should be treated as part of asset governance, not a separate hygiene project.
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 | Discovery gaps come from unmanaged non-human identities and hidden access paths. |
| NIST CSF 2.0 | ID.AM | Asset management requires identifying identities that affect exposure, not just hardware. |
| NIST AI RMF | AI RMF matters when autonomous agents create dynamic identities and access paths. |
Extend asset inventories to include service accounts, tokens, and workload identities with ownership metadata.
