Teams often treat discovery as the end state when it is only the first step. A complete inventory without relationships, permissions, and usage context cannot show risk, because the same identity may be harmless in one workflow and highly exposed in another.
Why Security Teams Misread Discovery as the Finish Line
Discovery is useful, but it is not a risk model. Security teams often celebrate that they have found service accounts, API keys, workload tokens, and OAuth apps, then stop before answering the harder questions: what each identity can reach, who issued it, whether it still belongs to a live workflow, and how it behaves under automation. That gap is why the Ultimate Guide to NHIs emphasizes lifecycle and context, not just inventory.
This mistake is especially common because discovery data looks complete on a dashboard even when the underlying permissions are stale, excessive, or orphaned. NHI Management Group’s research shows only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in many environments. The lesson is consistent with the NIST Cybersecurity Framework 2.0: asset awareness matters, but protection depends on governance, access control, and continuous monitoring. In practice, many security teams discover identity sprawl only after an incident reveals that the inventory was accurate but operationally misleading.
What Complete NHI Discovery Actually Requires
Effective discovery must map more than objects. It should connect each NHI to its owner, workload, secret type, scope, rotation status, authentication path, and downstream dependencies. A service account in CI/CD, for example, has very different risk characteristics from an OAuth app used by a third party, even if both appear as simple entries in a directory. The practical goal is to understand identity relationships, not just count identities.
That means building discovery around questions security teams can act on:
- Which NHIs are active, dormant, or orphaned?
- What permissions does each identity actually use versus what it is allowed to use?
- Where are secrets stored, how are they rotated, and who can revoke them?
- Which identities are tied to third-party access or production pipelines?
Current guidance suggests pairing inventory with continuous validation, because a discovered identity can still be dangerous if it holds standing privilege or long-lived credentials. The State of Non-Human Identity Security report highlights the visibility gap well: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That is why discovery should feed policy, rotation, and remediation workflows rather than sit as a reporting layer. The most reliable programmes also align discovery output to the controls described in CISA Zero Trust Maturity Model and similar guidance, because identity context is only useful when it drives enforcement. These controls tend to break down when discovery cannot correlate identities across cloud, code, and third-party SaaS because the same NHI appears under different names or ownership records.
Common Edge Cases That Break Simple Inventory Thinking
Tighter discovery often increases operational overhead, requiring organisations to balance visibility against speed and change frequency. That tradeoff is unavoidable in CI/CD, ephemeral infrastructure, and multi-cloud environments where identities are created and destroyed continuously. Best practice is evolving, but there is no universal standard for how much behavioural context should be attached to each NHI record yet.
Several edge cases routinely defeat simplistic discovery models. Ephemeral build agents may never show up as persistent assets, yet they can mint secrets and reach production systems. Shared service accounts can mask multiple workflows, making ownership unclear and revocation risky. Third-party OAuth grants may look low risk until a vendor compromise turns them into a lateral movement path. Even well-documented NHIs can be misleading if teams ignore the relationship between the identity and the workload that uses it.
Security teams should therefore treat discovery as the start of a control loop: identify, correlate, validate, then enforce. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce the same operational lesson: the risky part is usually not that an identity exists, but that no one can say what it is doing, who depends on it, or how quickly it can be removed. In practice, discovery fails hardest when teams optimise for completeness of the list instead of completeness of the relationships.
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 CSA MAESTRO 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 | Discovery gaps start with missing inventory and unknown NHI ownership. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is the baseline, but it must include NHIs and dependencies. |
| CSA MAESTRO | AM-2 | Agent and workload discovery must capture relationships, permissions, and usage. |
Extend asset management to service accounts, tokens, and OAuth grants with dependency mapping.
