Non-human identity security in 2025 is a visibility and governance gap

At a glance

What this is: This is an independent analysis of the five biggest non-human identity security challenges in 2025, with visibility, lifecycle control, and least privilege emerging as the core governance gaps.

Why it matters: It matters because IAM, PAM, and IGA teams now have to govern NHIs that are created faster than they are inventoried, with consequences across cloud, DevOps, AI, and third-party access.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Oasis Security's breakdown of the five critical NHI security challenges in 2025

Context

Non-human identity security is the discipline of governing service accounts, API keys, tokens, certificates, and automation identities that operate outside a human login flow. The challenge is that these identities are often created on demand, used across cloud, SaaS, DevOps, and AI systems, and then left outside the normal identity governance process. The primary keyword here is non-human identity security, and it describes a control problem, not just a secrets-management problem.

Oasis Security frames the issue around five practical pressure points: visibility, DevOps pipelines, AI-driven systems, legacy environments, and third-party integrations. That structure reflects how most enterprises encounter NHI risk in the wild, first as missing inventory, then as fragile operational dependencies, and finally as exposure to external access paths that were never designed for human-centric governance.

Key questions

Q: How should security teams handle non-human identity sprawl in cloud and SaaS environments?

A: Security teams should start with discovery that spans cloud, SaaS, code, and automation systems, because NHI sprawl rarely exists in one place. Once identities are found, every service account or token needs ownership, purpose, and expiry so inventory becomes governable rather than merely descriptive.

Q: Why do service accounts and API keys create more governance risk than human identities?

A: Service accounts and API keys are often created outside formal identity workflows, reused across systems, and left active after the original need changes. That makes them harder to review, harder to revoke cleanly, and more likely to carry broad standing access across cloud and DevOps environments.

Q: What breaks when secrets are hardcoded into DevOps pipelines?

A: Hardcoded secrets break rotation, ownership, and offboarding at the same time. They become embedded in repositories, build systems, and configuration files, which means the credential can survive long after the workflow changes. That creates hidden persistence and makes remediation dependent on finding every copy first.

Q: Who is accountable when a third-party integration keeps an NHI active after the business need ends?

A: The accountable organisation is the one that allowed the external identity to retain access without an offboarding process. Third-party machine identities should have explicit owners, review dates, and revocation criteria so access does not outlive the relationship or the operational purpose.

Technical breakdown

Why NHI discovery fails in cloud and SaaS estates

NHIs are rarely born through a formal identity request process. They appear through application integrations, cloud automation, scripting, and service orchestration, which means they are often distributed across platforms without a single source of truth. Discovery fails when security teams rely on directory-centric controls that were built around humans and cannot see API keys, ephemeral service accounts, or embedded credentials in runtime systems. The result is blind entitlement growth, weak ownership, and unreliable access review data.

Practical implication: build discovery that scans cloud, SaaS, and code-connected environments together, then bind every discovered NHI to an owner and expiry state.

Secrets sprawl in DevOps and automation pipelines

DevOps pipelines depend on machine credentials to authenticate builds, tests, deployments, and release automation. The security problem is not automation itself but the tendency to hardcode secrets, reuse service accounts, and over-provision access so pipelines keep working under pressure. Once credentials are embedded in code or CI/CD tooling, they become difficult to rotate cleanly and easy to miss during reviews. That creates long-lived trust where short-lived trust should exist.

Practical implication: move pipeline credentials into managed vaults, enforce rotation, and remove unused service accounts before they become invisible dependencies.

Third-party NHI exposure and delegated trust

Third-party integrations extend the identity perimeter beyond systems the enterprise directly controls. Each external vendor, SaaS connector, or API integration may introduce an NHI that can authenticate into internal data, workloads, or administrative interfaces. The failure mode is delegated trust without continuous oversight. If the organisation cannot track which external identities exist, what they can reach, and whether they are still justified, the access path remains open long after the business need changes.

Practical implication: require documented ownership, scoped permissions, and periodic offboarding checks for every external machine identity.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Visibility failure is the foundational NHI governance gap. If a team cannot enumerate its service accounts, API keys, and automation identities, it cannot govern them. That is not an operational inconvenience, it is a structural break in IAM control design. The broader implication is that directory-based governance is incomplete for modern machine estates, and practitioners need identity inventory to become a live security control, not a periodic audit artifact.

Secrets sprawl is a lifecycle problem, not a storage problem. Credentials that live in code, CI/CD tools, or configuration files outlast the task they were meant to support. Once that happens, rotation and offboarding become inconsistent, and the organisation inherits credentials it no longer understands. The important conclusion is that secret location matters less than secret lifespan, ownership, and revocation discipline.

Third-party access without lifecycle offboarding is a named failure mode, not a generic risk. External integrations create NHIs that often remain valid after the business relationship or integration need changes. That means access can outlive accountability, which is the exact condition attackers and opportunistic misuse depend on. Practitioners should treat vendor-connected NHIs as governed assets with exit criteria, not permanent technical plumbing.

AI systems add a new layer of machine identity pressure before most governance programmes are ready. When organisations say they need to clean up NHIs before rolling out AI, they are describing a sequencing problem, not a future aspiration. AI-driven systems inherit the same identity weaknesses already present in cloud and DevOps, then amplify them through more frequent access events and broader integration scope. The implication is that AI governance will inherit the state of NHI governance as it exists today.

Identity blast radius is now the more useful management concept than identity count. An enterprise can have a relatively small number of machine identities and still carry severe exposure if those identities have broad scope, poor ownership, and weak revocation. That is why least privilege, lifecycle control, and entitlement boundaries matter more than headline inventory volume. Practitioners should manage the reach of each NHI before they focus on the total number discovered.

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 Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For lifecycle control context, Ultimate Guide to NHIs also shows that only 20% have formal processes for offboarding and revoking API keys, which is why expiry and revocation need to be treated as core controls.

What this signals

Secret sprawl is now a governance signal, not just a hygiene issue. When credentials live outside managed stores, teams lose the ability to tie access to purpose, owner, and expiry. That makes NHI control look healthy on paper while leaving operational exposure untouched. The practical response is to treat the credential location itself as a risk indicator and to prioritise the highest-blast-radius secrets first, especially in CI/CD and integration layers.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, external access review has become a supply-chain governance issue, not a narrow IAM task. Security teams should expect vendor-linked machine identities to outlive contracts unless offboarding is explicitly tested.

Identity blast radius: the size of the damage a single machine identity can cause when its permissions, reach, and lifetime are not constrained. This concept matters because many programmes focus on counting identities rather than narrowing what each identity can actually touch. Teams should watch for broad scopes hidden inside pipeline credentials, API integrations, and AI-connected workloads.

For practitioners

• Inventory machine identities across every control plane Scan cloud accounts, SaaS platforms, CI/CD systems, and legacy environments together so service accounts, API keys, and tokens are all captured in one governed inventory.
• Bind each NHI to ownership and expiry Assign a named owner, purpose, and review date to every discovered machine identity so orphaned credentials can be identified before they become permanent dependencies.
• Move pipeline secrets out of code Replace hardcoded credentials in repositories and automation tooling with vault-managed secrets and rotation policies that can be enforced without manual exceptions.
• Reassess third-party trust paths quarterly Review every external integration for scope, use, and offboarding criteria so third-party NHIs are revoked when the business need or vendor relationship changes.
• Treat AI-facing identities as governed workloads Before deploying AI or automation systems, confirm the underlying machine identities have least privilege, expiry, and monitoring that match the business impact of the workflow.

Key takeaways

• Non-human identity security now fails first at visibility, because organisations cannot govern what they cannot enumerate.
• The biggest exposure is not just the number of machine identities, but the combination of hardcoded secrets, broad access, and weak offboarding.
• Practitioners should treat discovery, ownership, expiry, and revocation as the minimum operating model for NHI governance.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, systems, or automation rather than a person. In practice, this includes service accounts, API keys, tokens, certificates, bots, and AI-connected workloads that authenticate, authorize, and act inside enterprise environments.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, configuration files, CI/CD tools, and other unmanaged locations. It creates hidden copies, weak ownership, and inconsistent rotation, which makes revocation and auditability difficult even when the original credential source is known.
• Identity Blast Radius: Identity blast radius is the amount of damage a single identity can cause if it is misused, compromised, or left over-privileged. It reflects scope, lifetime, and downstream reach, so a small number of poorly governed machine identities can still create disproportionate enterprise risk.
• Lifecycle Governance: Lifecycle governance is the discipline of assigning, reviewing, expiring, and revoking identities throughout their usable life. For non-human identities, it means tying each credential to an owner, a purpose, and a retirement path so access does not survive the business need.

Deepen your knowledge

NHI discovery, secrets rotation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still trying to get inventory and ownership under control, it is a practical place to start.

This post draws on content published by Oasis Security: Breaking Down Non Human Identity Security: 5 Critical Challenges in 2025. Read the original.