NHI governance gaps are widening as SaaS identities outgrow IAM

At a glance

What this is: This is an analysis of why non-human identities are becoming a larger attack surface and why standard human IAM controls do not govern them well.

Why it matters: It matters because NHI sprawl changes how teams design access reviews, rotation, privilege controls, and monitoring across machine, autonomous, and human identity programmes.

By the numbers:

• Non-human identities outnumber humans as much as 50 to 1.

👉 Read Hydden's analysis of why NHI governance is becoming harder

Context

NHI governance is becoming harder because machine identities are created for workload-to-workload access, not for human login patterns. In this model, service accounts, API keys, certificates, and OAuth tokens can live longer, carry broader privilege, and sit outside the normal joiner-mover-leaver process that protects employee accounts.

The core problem is that many IAM programmes still assume identities will be provisioned, reviewed, and decommissioned through human-centric workflows. That assumption fails when credentials are created in code, used continuously by systems, and rarely mapped back to a clean business owner, which leaves visibility and lifecycle control incomplete.

For practitioners, the article is a reminder that NHI governance is not a separate niche control set. It is part of the same identity programme, but the control design must reflect machine behaviour rather than employee behaviour.

Key questions

Q: How should security teams govern service accounts and API keys across cloud environments?

A: Treat service accounts and API keys as governed identities, not as implementation details. Assign ownership, define business purpose, enforce expiry or rotation, and remove access that is broader than the workload needs. Inventory first, then reduce scope, then review continuously. Without those steps, the account may remain active long after the system or team that created it has changed.

Q: Why do non-human identities increase lateral movement risk in SaaS environments?

A: Because machine identities often have persistent access, broad trust relationships, and weak lifecycle visibility. If one secret is exposed, attackers can reuse it directly or move through connected systems that trust the same credential. SaaS environments make this worse when tokens and service accounts are shared across integrations, because the blast radius extends beyond the original application.

Q: What do organisations get wrong about rotating NHI secrets?

A: They often assume rotation is the whole control. Rotation reduces exposure time, but it does not remove overprivilege, orphaned accounts, or stale integrations that still accept the credential. If the identity remains broadly trusted, a new secret value can still enable the same access path. Governance has to address scope and ownership, not just token freshness.

Q: Who is accountable when a compromised machine identity is used to reach sensitive systems?

A: Accountability should sit with the team that owns the workload and the identity lifecycle, not just with the security team that detected the abuse. If the credential was created, stored, or reused without clear ownership, the governance failure is shared across engineering, platform, and identity functions. Clear ownership is what makes review and remediation possible.

Technical breakdown

Why NHI lifecycle control breaks human IAM assumptions

Non-human identities are usually long-lived credentials used by applications, services, and workloads to talk to other systems. Unlike human users, they are often created outside standard onboarding, may not require interactive authentication, and can remain active long after the original deployment context changes. That makes lifecycle control harder because provisioning, review, and decommissioning are not naturally triggered by employee-style events. The operational issue is not just volume. It is that NHI ownership, scope, and expiry are often implicit rather than enforced in one governed workflow.

Practical implication: map every machine identity to an owner, purpose, and expiry rule before it can be treated as governed access.

Secret sprawl, privilege creep, and why rotation is not enough

NHIs depend on secrets such as API keys, tokens, and certificates, and those secrets are often embedded in code, pipelines, or SaaS integrations. Once exposed, they can be reused directly because the credential itself is the identity proof. Rotation helps reduce exposure time, but it does not solve overprivilege, orphaned accounts, or excessive standing access. If a credential is valid across multiple services or is tied to a high-privilege role, rotation only changes the token value while the underlying trust model remains weak.

Practical implication: pair rotation with privilege minimisation, scope reduction, and removal of stale machine accounts.

Why activity baselines are weaker for machine identities

Traditional anomaly detection works best when there is a stable human or business pattern to compare against. NHIs often run continuously, produce expected background traffic, and interact with the same systems at machine speed. That makes “normal” harder to define and reduces the value of tools that rely only on unusual login timing or location. For NHI governance, the better signal is not just behaviour deviation. It is whether the identity is still required, still owned, and still limited to a specific workload or integration.

Practical implication: prioritise inventory, ownership, and entitlement review over behaviour-only detection for machine accounts.

Threat narrative

Attacker objective: The attacker aims to convert weakly governed access into persistent, high-trust control over SaaS and cloud systems.

1. Entry occurs when attackers target exposed human credentials, dormant accounts, or weak SaaS supplier access paths to reach privileged environments.
2. Escalation follows when those human footholds are used to reach higher-privileged non-human identities or service accounts inside cloud and SaaS stacks.
3. Impact comes from lateral movement through trusted machine access, allowing data access, persistence, and broader compromise across critical systems.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

NHI governance is failing because many programmes still treat machine identities as a technical byproduct, not a governed identity class. That is the real gap behind secret sprawl, overprivilege, and orphaned access. When NHIs are created outside human onboarding workflows, lifecycle ownership becomes implicit and review coverage becomes partial. The implication is that identity governance cannot stop at employee accounts.

Secret sprawl is the operational symptom of broken identity ownership. API keys, OAuth tokens, and certificates become durable access paths when they are distributed through code, pipelines, and integrations without strong lifecycle control. Rotation alone does not fix that exposure if the identity still exists, still has broad scope, or still lacks a clear decommission trigger. Practitioners should read sprawl as a governance failure, not only a hygiene issue.

Baseline anomaly detection is a weaker control for NHIs than inventory and entitlement discipline. Machine identities often produce steady, expected activity that does not resemble human logon behaviour, which makes behavioural monitoring less decisive on its own. In NHI governance, the stronger control question is whether the identity is still needed and still constrained to the workload that created it. That is a lifecycle and scope problem first.

Identity blast radius: the governance risk is not just credential theft, but how far one compromised machine identity can reach. Once a service account or token is reused across multiple systems, one exposure becomes a cross-environment trust problem. That is why NHI controls must be evaluated by downstream reach, not credential count alone. The practitioner conclusion is to manage blast radius as a first-class identity metric.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how one identity failure can become a recurring access problem.
• For broader incident context, read 52 NHI Breaches Analysis to see how exposed credentials and poor lifecycle governance repeat across real cases.

What this signals

NHI sprawl is now a governance problem, not just a security finding. Teams that still track machine identities informally will struggle to prove ownership, expiry, and recertification coverage. That is why identity programmes need a named concept of identity blast radius, where the measure is not how many credentials exist but how far one compromised credential can travel across systems and services.

With 72% of organisations having experienced or suspecting a breach of non-human identities, per The 2024 ESG Report: Managing Non-Human Identities, the next maturity step is not more dashboards. It is tighter lifecycle enforcement, better entitlement scoping, and clearer integration ownership across engineering and identity teams.

If your programme already relies on OWASP Non-Human Identity Top 10 guidance, use this topic to push beyond secret rotation into access governance and service identity offboarding. That is where NHI risk becomes measurable and manageable.

For practitioners

• Build a complete NHI inventory Catalogue service accounts, API keys, tokens, certificates, and workload identities with owner, purpose, system dependency, and expiry data so no credential is invisible to governance.
• Tie every machine identity to a lifecycle owner Assign one accountable team for provisioning, review, rotation, and decommissioning so dormant credentials do not survive after projects, vendors, or workloads change.
• Reduce standing privilege on non-human accounts Split broad service roles into narrower task-specific permissions and remove cross-system reuse where one credential can reach multiple applications or environments.
• Review where secrets are created and stored Search source code, CI/CD systems, and integration layers for embedded credentials, then move them into controlled secret storage and rotate exposed values immediately.

Key takeaways

• Machine identities are now large enough and privileged enough to require dedicated governance, not just controls borrowed from human IAM.
• The scale of compromise is already material, which means poor NHI lifecycle control can translate quickly into repeated incidents and wider blast radius.
• Teams should focus on ownership, scope, expiry, and decommissioning if they want to reduce the risk created by service accounts, keys, tokens, and certificates.

Key terms

• Non-Human Identity: A non-human identity is a digital credential used by software, services, workloads, or automated processes rather than by a person. These identities include service accounts, API keys, tokens, and certificates. They often operate continuously, carry privileged access, and require lifecycle governance that is different from human account management.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, integrations, and storage systems. It increases the chance of exposure and makes it harder to know which secrets still matter, which have been copied, and which have outlived the workload they were created for.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, and data that can be reached if one identity is compromised. For NHIs, the measure is often larger than teams expect because one credential may be trusted by multiple services. Reducing blast radius means narrowing scope and removing unnecessary reuse.
• Lifecycle Ownership: Lifecycle ownership is the assignment of a responsible team or person for provisioning, reviewing, rotating, and decommissioning an identity. For machine identities, it is the control that prevents credentials from becoming orphaned after projects, vendors, or workloads change.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Hydden: NHI governance gaps are widening as SaaS identities outgrow IAM. Read the original.