Start by discovering every system that can authenticate without a person present, including workloads, APIs, service accounts, certificates, and tokens. Assign an owner, purpose, and expiration state to each identity. An inventory only becomes useful when it can drive lifecycle actions such as rotation, review, and offboarding.
Why This Matters for Security Teams
An NHI inventory is not a spreadsheet exercise. It is the control surface for deciding what can authenticate, what should still exist, and what must be revoked before it becomes a breach path. Without a reliable inventory, teams cannot separate active workloads from orphaned service accounts, expired certificates, or forgotten API keys. That creates blind spots in rotation, review, and offboarding, which is exactly where NHI risk accumulates. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which explains why discovery efforts so often understate the real exposure. See the JetBrains GitHub plugin token exposure case for how a single token can turn into broad access when identity ownership is unclear, and compare that with the control expectations in the NIST Cybersecurity Framework 2.0, where asset visibility and access governance are foundational. In practice, many security teams encounter the full scope of their NHI sprawl only after a credential leak, not through intentional inventory design.
How It Works in Practice
A useful inventory starts by defining what counts as a non-human identity in the environment, then mapping each identity to a business function and an accountable owner. Security teams should gather data from cloud IAM, CI/CD, Kubernetes, secret managers, certificate authorities, OAuth apps, monitoring tools, and code repositories, because NHIs rarely live in one system. Each record should capture the minimum fields needed to drive action: identity type, system of record, owner, workload or application, authentication method, privilege scope, dependency links, last use, rotation date, expiration date, and offboarding status.
That data only becomes operational when it is normalised. For example, a service account in production, a certificate used by an API gateway, and a token issued to a build pipeline are different objects, but they should all map into the same lifecycle process. Best practice is evolving toward combining inventory with policy checks so that a new identity cannot exist without ownership, purpose, and expiry. This aligns with the visibility and governance emphasis in the NIST Cybersecurity Framework 2.0 and the discovery-first logic reflected in the JetBrains GitHub plugin token exposure incident pattern, where overlooked credentials became the real problem. Where possible, tie the inventory to PAM, secrets management, and JIT provisioning so that identities are reviewed in the same system that issues or revokes them.
- Classify identities by type: workload, API, service account, certificate, token, or agent.
- Require ownership and business purpose before an identity is approved.
- Track expiry, rotation cadence, and last authenticated use.
- Link each identity to the systems, pipelines, or services it can reach.
- Flag orphaned, over-privileged, or externally shared identities for remediation.
These controls tend to break down in large cloud-native environments with rapid CI/CD churn because identities are created faster than teams can reconcile them.
Common Variations and Edge Cases
Tighter inventory control often increases operational overhead, requiring organisations to balance visibility against engineering speed. That tradeoff is most visible in ephemeral environments, multi-cloud estates, and partner-integrated workflows, where identities may exist for minutes or be created by automation that never pauses for manual registration. Current guidance suggests prioritising high-risk identities first, especially those with production access, broad API reach, or third-party exposure, rather than trying to perfect the entire estate at once.
There is no universal standard for how much detail every NHI record must contain, but the inventory should always support action. In some environments, a certificate authority may be the authoritative source for certificates, while a secrets manager governs API keys and a cloud IAM platform governs service accounts. The inventory does not replace those systems; it connects them. For agentic or autonomous software entities, the same inventory logic should extend to workload identity and runtime authority, because the identity may be a tool-using agent rather than a simple background job. That makes continuous review more important than one-time discovery, which is consistent with the governance direction in JetBrains GitHub plugin token exposure lessons and the control lifecycle approach in NIST Cybersecurity Framework 2.0.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers discovery and inventory of non-human identities across the estate. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation depends on knowing which secrets and identities exist. |
| NIST CSF 2.0 | ID.AM | Asset management underpins reliable NHI visibility and ownership. |
Map all NHIs into your asset inventory so ownership and lifecycle actions stay auditable.
