NHI discovery needs context beyond static inventory lists

At a glance

What this is: This article argues that NHI discovery is only the first step and that security teams need contextual data, not just a periodically updated inventory.

Why it matters: For IAM, IGA, PAM, and NHI programmes, the difference between counting identities and governing them determines whether teams can enforce least privilege, detect anomalies, and safely decommission access.

👉 Read Oasis Security's blog on NHI discovery beyond inventory

Context

Non-Human Identity discovery is the process of finding service accounts, API keys, tokens, certificates, and workload identities across environments. The article’s central point is that discovery without context leaves teams with a roster, not governance, and that gap blocks ownership, review, and risk decisions.

That matters because NHI programmes fail when teams cannot answer basic questions about who owns an identity, what it can do, when it is active, where it runs, and why it exists. For identity teams, discovery has to feed lifecycle management, access policy enforcement, and anomaly detection rather than stopping at inventory.

Key questions

Q: How should security teams go beyond NHI inventory lists?

A: They should enrich discovery with ownership, permissions, activity, deployment context, and business purpose. A raw list tells you what exists, but not what is risky, who is accountable, or whether an identity still needs to be active. The practical goal is to turn discovery into a governed record that can feed review, rotation, and offboarding.

Q: Why do static NHI inventories fail in practice?

A: Static inventories fail because they capture presence without meaning. Without context, teams cannot tell whether an identity is stale, over-privileged, embedded in a critical workflow, or owned by anyone who can act on it. That leaves security teams unable to enforce least privilege or safely remove access.

Q: What breaks when NHI discovery does not include business context?

A: Governance breaks first, because recertification and ownership checks have nothing to validate against. Operational safety breaks next, because teams may disable or rotate identities without knowing which services depend on them. Discovery without context produces risk confusion instead of control.

Q: How do organisations safely act on NHI discovery findings?

A: They should route every enriched identity into lifecycle decisions, then validate dependencies before changing access. That means tying discovery to review, rotation, and offboarding workflows, and checking service impact before decommissioning or tightening privileges. The objective is to reduce exposure without breaking critical systems.

Technical breakdown

Why static NHI inventory is not enough

A static inventory tells you that an NHI exists, but not whether it is still needed, who is accountable for it, or whether its privileges match its use. In practice, many teams can script a list of service principals or pull records from directories and still miss the business and security context that makes the identity governable. Discovery becomes operationally useful only when it is normalised across identity providers, cloud platforms, SaaS, and PAM or IGA systems. Without that, teams cannot make safe decisions about rotation, decommissioning, or anomaly handling.

Practical implication: treat discovery output as an intake feed for governance, not as a finished control.

The 5 Ws of NHI context

The article frames useful discovery around five questions: who owns the identity, what it can access, when it was created or used, where it operates, and why it exists. Each question maps to a different governance control. Ownership supports accountability, permissions inform least privilege, activity reveals stale identities, environment shows blast radius, and purpose supports recertification. This is a context model, not just a reporting model, because each dimension changes whether an NHI is safe to keep active.

Practical implication: build discovery workflows that enrich every NHI with ownership, privilege, activity, deployment, and purpose data.

How NHI context supports lifecycle and risk decisions

Once context is attached to identities, teams can distinguish between a harmless low-privilege account and a high-risk identity embedded in a critical workflow. That is the difference between seeing an item in a list and understanding its operational dependency. It also changes the response to dormant or over-privileged NHIs, because the goal is not simply to find them but to decide whether they should be reviewed, rotated, constrained, or removed. In identity governance terms, discovery becomes the front door to lifecycle management and policy enforcement.

Practical implication: connect discovery to review, rotation, and offboarding processes so context triggers action.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static inventory is a visibility control, not an identity governance control. A list of NHIs can confirm that accounts exist, but it cannot prove accountability, necessity, or safe privilege boundaries. That makes inventory useful for enumeration and almost useless for governance unless it is enriched with ownership, usage, and purpose. Practitioners should treat basic discovery as a starting signal, not the control surface itself.

NHI governance fails when teams cannot answer the 5 Ws consistently. Who owns the identity, what it can do, when it was last active, where it operates, and why it exists are not reporting extras, they are the minimum context required to decide whether access should remain in place. This is where discovery becomes lifecycle management, because recertification and offboarding depend on context rather than counts. The practitioner conclusion is simple: if the 5 Ws are missing, governance is incomplete.

Context-aware discovery is the real control boundary for least privilege. Least privilege cannot be enforced against an identity that is not tied to a business purpose, a runtime location, and an accountable owner. The article correctly shows that discovery must span on-prem, cloud, SaaS, IGA, and PAM sources so teams can normalise identities across systems. Practitioners should view cross-environment enrichment as the mechanism that makes privilege review and risk triage possible.

Discovery without dependency mapping creates change risk as well as security risk. If teams rotate, disable, or remove an NHI without knowing where it is embedded, the result can be outages and broken integrations. That means discovery must surface operational dependencies, not just security attributes. The practitioner takeaway is to align NHI visibility with service impact analysis before any remediation campaign.

Identity enrichment layer: The article points toward a model where discovery is continuously enriched into an operational record of ownership, usage, and purpose. That concept matters because it turns passive inventory into an active governance layer that can drive review, enforcement, and remediation. Practitioners should think of enrichment as the bridge between finding an identity and being able to govern it.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 91% of former employee tokens remain active after offboarding, showing how lifecycle failure persists even after the identity relationship should have ended.
• For a broader view of the control gap, review NHI Lifecycle Management Guide for the operational steps that turn discovery into offboarding and rotation.

What this signals

Identity enrichment layer: Discovery will keep failing as a governance input until teams treat ownership, purpose, and runtime context as mandatory fields rather than optional metadata. That is where NHI programmes move from counting identities to controlling them, and it is the difference between seeing access and managing it.

The operational signal is that inventory-only programmes create false confidence. As identity estates span SaaS, cloud, and automation layers, the organisations that normalise discovery across systems will be better placed to recertify access, spot stale identities, and avoid breaking critical workflows when they remediate exposure.

The forward-looking move is to tie discovery into the broader governance stack and benchmark it against standards such as the NIST Cybersecurity Framework 2.0. That alignment matters because discovery is only useful when it drives protect, detect, and respond actions rather than a one-time report.

For practitioners

• Normalize discovery across identity systems Pull NHI records from cloud directories, SaaS applications, PAM, IGA, and infrastructure sources into one governed view so teams can compare identities using the same fields and naming logic.
• Attach an accountable owner to every NHI Require a named person or service owner for each service account, token, or certificate, and use that ownership record to drive review, rotation, and decommission decisions.
• Record business purpose and runtime context Capture why the identity exists, where it runs, and which workflows depend on it so security changes can be evaluated against operational impact before they are made.
• Use activity patterns to find stale identities Track creation date, last use, and usage drift so dormant accounts can be reviewed before they become long-lived attack paths or hidden dependencies.
• Link discovery to remediation workflows Route enriched NHI records into recertification, rotation, and offboarding processes so context results in action rather than another static report.

Key takeaways

• NHI discovery without context is an inventory exercise, not a governance control.
• The 5 Ws of identity context are the minimum inputs needed to judge ownership, privilege, activity, location, and purpose.
• Teams should connect discovery to lifecycle workflows so review, rotation, and decommissioning follow from the data they collect.

Key terms

• Non-Human Identity Discovery: The process of finding machine and workload identities across environments, including service accounts, API keys, tokens, certificates, and bots. In mature programmes, discovery is not just enumeration. It is the starting point for ownership, privilege, lifecycle, and anomaly management.
• Identity Context: The extra information that makes an identity governable, such as owner, privilege, activity, environment, and purpose. Context turns an identity from a name in a list into something security and operations teams can evaluate, review, and safely remediate.
• Lifecycle Management: The governance process that covers provisioning, review, rotation, and offboarding of identities. For NHIs, lifecycle management is critical because many accounts never expire on their own and can remain active long after their original purpose has ended.
• Identity Enrichment: The practice of attaching operational and governance attributes to discovered identities so they can be managed consistently across systems. Enrichment is what makes discovery actionable by connecting raw identity records to ownership, usage, and policy decisions.

Deepen your knowledge

NHI discovery, ownership, and lifecycle context are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governed discovery programme from the same starting point, it is worth exploring.

This post draws on content published by Oasis Security: NHI Discovery, Going Beyond Inventory. Read the original.