Security teams should start by inventorying service accounts, API keys, tokens, and certificates across applications, CI/CD, cloud, and third-party integrations. Then they should map ownership, privilege level, rotation status, and usage patterns. The practical goal is to identify identities that exist without governance, because unmanaged NHIs create hidden access paths and make containment, auditing, and offboarding much harder.
Why This Matters for Security Teams
Unmanaged non-human identities are not just inventory gaps. They are live access paths that bypass normal joiner-mover-leaver controls, often with broader privileges and weaker oversight than human accounts. In application environments, that means a forgotten API key in CI/CD, a service account tied to no owner, or a third-party OAuth grant can become the easiest route to data exposure or lateral movement. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which shows how much risk remains hidden until an incident forces discovery. NIST CSF 2.0 reinforces that asset visibility and access governance are foundational, not optional, for resilient operations, especially in application and cloud estates where identities are machine-generated and machine-consumed. Security teams often underestimate how quickly unmanaged NHIs accumulate across build systems, SaaS integrations, and automation scripts. In practice, many teams discover the real scope only after a secrets leak, suspicious token use, or an offboarding failure has already expanded the blast radius.
How It Works in Practice
A useful assessment starts by treating every application integration as a potential identity owner and every secret as a governed asset. Teams should enumerate service accounts, API keys, OAuth grants, certificates, workload tokens, and CI/CD credentials, then tie each one back to an application, a human owner, a business purpose, and a rotation method. The highest-risk unmanaged NHIs usually share three traits: no clear owner, excessive privilege, and long-lived credentials that remain valid far beyond the task they support.
Current guidance suggests assessing unmanaged NHI risk across four dimensions: exposure, privilege, lifecycle, and detectability. Exposure asks where the identity lives, including source code, build logs, containers, secret stores, and third-party apps. Privilege asks what it can reach and whether it can pivot across environments. Lifecycle asks whether the credential is rotated, expired, or still embedded in automation. Detectability asks whether logs, alerts, and audit trails can show who or what used it. This aligns with The State of Non-Human Identity Security, which found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and over-privileged accounts.
Practitioners often pair this review with NIST Cybersecurity Framework 2.0 functions to anchor ownership and response. The practical control goal is to reduce unmanaged identities to a short exception list, then force each exception into a lifecycle: issue, use, rotate, monitor, and revoke. These controls tend to break down when applications rely on hard-coded secrets in legacy pipelines because the credential source is scattered across code, build artifacts, and environment variables, making complete revocation difficult.
Common Variations and Edge Cases
Tighter NHI governance often increases operational overhead, requiring organisations to balance rapid delivery against stronger lifecycle control. That tradeoff is most visible in application environments that depend on third-party integrations, ephemeral test systems, or legacy scripts that were never built for secret rotation. In those cases, the question is not whether every secret can be eliminated immediately, but which unmanaged identities create unacceptable exposure and must be prioritised first.
One common edge case is shadow automation. Teams may find service accounts created by developers, platform engineers, or SaaS products that never enter the formal identity register. Another is delegated access through OAuth apps, where the visible application looks harmless but can inherit broad data access through consent. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both highlight that unmanaged credentials are often discovered only after they have already been overused or exposed. Best practice is evolving, but current consensus is clear that unmanaged NHIs should be scored by business criticality, privilege, exposure window, and revocation complexity, not by whether they are “known” to one platform team. In highly distributed microservice estates, this approach still gets imperfect because service-to-service trust chains can hide the original credential source.
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, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged service accounts and keys are core NHI inventory and governance gaps. |
| NIST CSF 2.0 | ID.AM | Asset management supports finding hidden application identities and secrets. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero trust access decisions help constrain unmanaged identities at runtime. |
| CSA MAESTRO | GOV-2 | Agent and workload governance principles apply to unmanaged machine identities in apps. |
| NIST AI RMF | GOVERN | Risk governance is needed to score unmanaged identities by impact and exposure. |
Inventory every non-human identity, assign ownership, and remove or govern anything without a lifecycle owner.
Related resources from NHI Mgmt Group
- How should security teams handle non-human identity risk when traditional IAM tools do not cover service accounts and APIs well enough?
- How should security teams prioritise non-human identity security in executive cyber risk programmes?
- How should security teams govern non-human identities in cloud environments?
- How should aviation security teams reduce identity blind spots across human, non-human, and agentic AI accounts?
