NHIs exist wherever software authenticates to access resources: CI/CD pipelines, Kubernetes service accounts, cloud IAM systems, SaaS integrations, and application code with hardcoded credentials. Discovery must actively look in all of these locations — no single scanner covers the full estate.
Why This Matters for Security Teams
NHIs are not tucked away in one predictable system. They appear wherever software needs to prove who or what it is: build pipelines, cloud IAM, Kubernetes service accounts, SaaS integrations, and application code. That distribution makes discovery a governance problem, not just a tooling problem. The risk is amplified by scale: NHIs outnumber human identities by 25x to 50x in modern enterprises, and the Ultimate Guide to NHIs shows how visibility gaps and overprivilege combine into a broad attack surface.
Security teams often misjudge the estate because they start with a single scanner, a vault inventory, or cloud console reports and assume coverage is complete. In reality, secrets are also embedded in code, config files, CI/CD tools, and service mesh components, which means the true footprint is distributed across engineering and infrastructure layers. The current guidance in NIST Cybersecurity Framework 2.0 supports asset visibility and access governance, but NHI discovery still requires domain-specific collection methods.
In practice, many security teams encounter hidden NHIs only after a token leak, service outage, or lateral movement event has already exposed the gap.
How It Works in Practice
Discovery has to follow the authentication flow, not just the asset register. Start where software proves identity: Kubernetes service accounts, workload identity providers, cloud roles, secrets managers, source repositories, CI/CD runners, and SaaS-to-SaaS integrations. Then trace where credentials are issued, copied, cached, and reused. That approach is consistent with the broader lifecycle and visibility guidance in The 2025 State of NHIs and Secrets in Cybersecurity, which highlights how often secrets are duplicated or stored outside controlled systems.
- Inventory infrastructure identities separately from application secrets, because they age, rotate, and fail differently.
- Inspect code, pipeline variables, container specs, and deployment manifests for embedded credentials.
- Map third-party integrations and machine-to-machine APIs, including business apps that use service accounts invisibly.
- Correlate secret usage with privilege and rotation posture, rather than assuming every discovered secret is actively managed.
This is where workflow evidence matters. For example, the Top 10 NHI Issues discussion aligns with common failure patterns such as overexposed credentials and weak offboarding. If an organisation wants a concrete benchmark, NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and only a small minority have full service-account visibility. Pair that with NIST Cybersecurity Framework 2.0 to anchor inventory, protection, and recovery in an auditable program.
These controls tend to break down when development teams create ad hoc service accounts in fast-moving CI/CD environments because credentials are provisioned faster than governance can track them.
Common Variations and Edge Cases
Tighter discovery often increases operational overhead, requiring organisations to balance full visibility against platform noise and engineering friction. That tradeoff is real in multi-cloud, hybrid, and heavily automated environments where workload identities change frequently and secrets may be intentionally short-lived. There is no universal standard for exactly how every NHI should be classified yet, so current guidance suggests using source, runtime context, and privilege level together rather than relying on a single taxonomy.
Some edge cases are especially easy to miss. Ephemeral build tokens may exist for minutes, but still expose high-value production paths. Shared service accounts can make ownership unclear even when the account itself is visible. SaaS integrations may appear benign until a forgotten API key continues to work long after an application owner has moved on. The Ultimate Guide to NHIs — Why NHI Security Matters Now is useful context here because it frames why visibility and lifecycle control must extend beyond classic IAM. A second useful reference is 52 NHI Breaches Analysis, which shows how breaches often start with overlooked machine credentials rather than sophisticated exploitation.
Where organisations have strong platform engineering and explicit workload identity, discovery gets easier. Where teams rely on shared secrets, legacy scripts, and undocumented integrations, the answer becomes fragmented and the estate is harder to prove complete.
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 SPIFFE/SPIRE 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 enterprise. |
| NIST CSF 2.0 | ID.AM | Asset management is the closest CSF anchor for locating distributed NHIs. |
| SPIFFE/SPIRE | Workload identity helps identify where machine identities live and how they authenticate. |
Extend asset inventory to machine identities, secrets, and service accounts across all platforms.
