What is the first step in managing non-human identities at scale?

Why This Matters for Security Teams

The first step matters because scale magnifies every hidden identity problem. If teams do not know what exists, they cannot decide what should be rotated, revoked, vaulted, or monitored. That is why inventory is the prerequisite to lifecycle control, and why current guidance treats visibility as the foundation for all NHI governance. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which explains why so many programmes stall before they can enforce policy consistently. See Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now for the broader risk context. NIST also reinforces that asset and identity visibility are prerequisites for managing cyber risk, not optional extras, as reflected in the NIST Cybersecurity Framework 2.0. When the inventory is incomplete, ownership disputes, orphaned secrets, and stale certificates tend to accumulate in the gaps between teams. In practice, many security teams encounter NHI abuse only after a breach review exposes undocumented accounts, rather than through intentional discovery and control design.

How It Works in Practice

A workable starting point is to build a continuously refreshed inventory of every non-human identity across cloud, code, CI/CD, infrastructure, and third-party integrations. That inventory should classify each item by type, owner, business service, privilege scope, secret location, expiry, and rotation method. The goal is not just to count identities, but to understand which ones can authenticate, what they can reach, and whether they are still needed. Practitioners usually begin by correlating data from IAM, vaults, certificate authorities, orchestration platforms, source control, and observability tools. Then they reconcile that data into a single register with ownership and lifecycle status. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide both emphasise that discovery only becomes useful when paired with ownership, expiry, and offboarding rules. NIST CSF 2.0 is useful here because it frames asset management and access governance as operational disciplines, not one-time projects. The inventory should answer a few simple questions:

• What is the identity?
• Who owns it?
• What workload, application, or agent uses it?
• Which secrets or certificates does it depend on?
• When was it last used, rotated, or reviewed?

Once that baseline exists, teams can prioritise the highest-risk items first, such as long-lived API keys, certificates with no expiry policy, and service accounts with broad access. This guidance breaks down when environments are highly ephemeral and identities are created faster than discovery tooling can reconcile them, because stale records can look authoritative when they are already obsolete.

Common Variations and Edge Cases

Tighter inventory control often increases operational overhead, requiring organisations to balance better visibility against the cost of continuous reconciliation. That tradeoff becomes especially visible in fast-moving DevOps, multi-cloud, and agentic AI environments, where identities can be created automatically and disappear just as quickly. In those settings, best practice is evolving rather than settled, and there is no universal standard for how much metadata is enough. For autonomous systems, the inventory should extend beyond traditional service accounts to include AI agents, tool credentials, workload identities, and short-lived secrets. In agentic pipelines, the first step is still discovery, but the inventory must also capture what the agent is authorised to do at runtime, not just what static role it was given at deployment. That is where Ultimate Guide to NHIs — What are Non-Human Identities becomes useful for defining the scope of NHI inventory beyond legacy service accounts, while NIST Cybersecurity Framework 2.0 provides the governance language for ongoing control. Edge cases usually include third-party-managed identities, certificates embedded in pipelines, and identities owned by teams that no longer exist. The practical takeaway is simple: if ownership cannot be assigned, the identity should be treated as an exception until it is validated or retired. Where organisations skip that step, they often discover the problem during incident response or audit, not during planned hygiene work.

Related resources from NHI Mgmt Group

• What is the difference between managing human identities and non-human identities?
• How should security teams govern non-human identities at scale?
• What are the three elements of a non-human identity?
• What is the difference between managing human accounts and non-human identities?