Security teams should inventory NHIs continuously across every system that can create or store them, not only the directory or PAM layer. The goal is a complete account-level view that includes service accounts, API keys, tokens, certificates, and workload credentials, along with where they live, what they access, and who owns them.
Why This Matters for Security Teams
An NHI inventory is the foundation for everything that follows: ownership, rotation, access review, offboarding, and incident response. Without a complete inventory, teams usually protect only the identities that are easiest to see, such as directory objects or PAM-managed accounts, while missing API keys in code, certificates in CI/CD, OAuth grants, and workload credentials in cloud platforms. That leaves blind spots where compromise can persist long after a control appears to exist.
Current guidance aligns with a continuous, system-wide approach rather than a periodic spreadsheet exercise. The NIST Cybersecurity Framework 2.0 stresses asset visibility and risk-based governance, and NHI Management Group research shows why that matters: only 5.7% of organisations report full visibility into service accounts, while 96% store secrets outside secrets managers in vulnerable locations. The same research also highlights real-world exposure patterns such as the Ultimate Guide to NHIs and the State of Non-Human Identity Security.
In practice, many security teams discover the inventory gap only after a breach, a failed offboarding event, or an audit request that forces them to reconcile identities across too many systems at once.
How It Works in Practice
Build the inventory from multiple telemetry sources, not from one authoritative system that does not exist. Service accounts in IAM directories, API keys in source control, OAuth app grants, certificates in secret stores, cloud workload identities, CI/CD variables, and agent credentials all need to be reconciled into a single account-level view. The operational goal is to answer four questions for each NHI: what it is, where it exists, what it can access, and who owns it.
That usually means combining discovery, normalization, and continuous validation. Discovery finds candidate NHIs across cloud accounts, code repositories, ticketing systems, vaults, and identity providers. Normalization groups duplicates and maps each credential or token to a canonical record. Validation checks whether the identity still exists, whether it is active, whether its privileges match its purpose, and whether it has an owner and a rotation policy. NIST guidance on inventory and governance under the NIST Cybersecurity Framework 2.0 supports this type of continuous tracking, not a one-time attestation.
Practically, high-value fields should include:
- Unique identifier and credential type
- System of record and any shadow locations
- Business or technical owner
- Associated application, workload, or integration
- Privilege scope and downstream access
- Creation date, last used date, and expiry or rotation date
- Offboarding and incident-response status
Teams should also flag secrets that are embedded in code or pipeline variables, because NHI Mgmt Group research found that 30.9% of organisations store long-term credentials directly in code. The JetBrains GitHub plugin token exposure is a useful reminder that inventory blind spots often begin in developer tooling, not in identity governance tools. These controls tend to break down when identities are created outside central platforms, such as ad hoc scripts, partner integrations, or autonomous build pipelines, because no single owner is consistently notified.
Common Variations and Edge Cases
Tighter inventory controls often increase operational overhead, requiring organisations to balance complete visibility against engineering speed and temporary exceptions. That tradeoff is especially visible in cloud-native and platform-heavy environments, where identities are short-lived, dynamically created, or inherited from orchestration layers.
Best practice is evolving for some edge cases. For example, there is no universal standard yet for how to model ephemeral workload identities that exist only for a few minutes, but current guidance suggests they still belong in the inventory if they can authenticate, call tools, or reach data. The same applies to third-party OAuth apps and delegated access: the inventory should capture the external principal, the internal resource owner, and the revocation path, even if the app is not “owned” by the security team.
Inventory quality also depends on lifecycle discipline. A record that cannot tell whether a credential was rotated, revoked, or orphaned is not operationally reliable. That is why NHI Mgmt Group’s research on the State of Non-Human Identity Security is so relevant: only 1.5 out of 10 organisations are highly confident in securing NHIs. The practical answer is to treat the inventory as a living control plane, not a reporting artifact, and to define exception handling for shared service accounts, vendor-managed integrations, and inherited cloud roles.
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 | Inventory is the prerequisite for finding and tracking all non-human identities. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is directly aligned to identifying identity assets across the environment. |
| NIST AI RMF | AI governance needs inventory of agent identities, tools, and access paths. |
Inventory every agent identity, tool connection, and credential source before granting operational authority.
