Seven-stage NHI maturity shows why workload IAM is the destination

At a glance

What this is: This analysis maps non-human identity security across seven maturity stages, from unauthenticated access to workload IAM, and shows how enterprises still depend on static credentials and fragmented control points.

Why it matters: It matters because IAM teams cannot govern AI agents, service accounts, and workloads with human-centric processes when authentication, rotation, and auditability remain inconsistent.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 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.

👉 Read Aembit's analysis of seven stages of non-human identity security maturity

Context

Non-human identity security is the discipline of governing service accounts, API keys, tokens, certificates, workloads, and AI agents so they only access what they need. The core problem is that many organisations still manage machine access with long-lived secrets and manual review processes that were designed for people, not autonomous software.

This maturity model matters because workload identity has moved from a niche engineering concern to an IAM governance issue. The article’s seven stages show a familiar pattern: organisations reduce one risk only to inherit another, until they move from secret handling to policy-based identity control. For teams building that transition, the NHI Lifecycle Management Guide is the right reference point for provisioning, rotation, and offboarding.

Most enterprises are still in the middle of that shift. That is typical, not exceptional, which is why the governance question is no longer whether workloads need identity controls, but whether current IAM processes can keep up with their scale and speed.

Key questions

Q: How should organisations reduce risk from long-lived non-human credentials?

A: Start by inventorying every credential that a workload, service account, or automated pipeline uses, then rank them by privilege and exposure. Replace the highest-risk credentials with short-lived, centrally issued access paths first. Rotation alone is not enough if the secret still exists in code or multiple environments. The goal is to shrink the number of persistent trust points.

Q: What is the difference between secrets management and workload IAM?

A: Secrets management stores and rotates credentials, while workload IAM removes as many persistent secrets as possible and ties access to identity plus policy. Secrets management is still useful, but it often preserves the same trust model. Workload IAM changes the model by making access ephemeral and context-aware. That is the more durable control for autonomous software.

Q: When does NHI sprawl become an operational risk for IAM teams?

A: NHI sprawl becomes operationally risky when teams can no longer inventory identities, understand ownership, or prove which credentials are active. At that point, access reviews become incomplete and incident response slows down. If your environment depends on spreadsheets or ad hoc exceptions, the programme is already behind the scale of the problem.

Q: How can security teams govern AI agents and service accounts together?

A: Use the same governance principles for both: unique identity, least privilege, short-lived access, auditable issuance, and clear ownership. The implementation will differ by platform, but the control objectives should not. Treat every autonomous actor as a non-human identity with a lifecycle, not as a special case outside IAM.

Technical breakdown

Why static credentials fail as non-human identity scales

Static credentials create a durable trust problem because they are reusable, long-lived, and hard to scope cleanly across services. Hardcoded secrets and configuration secrets improve convenience, but they expand exposure wherever code, pipelines, or logs can leak them. Once a secret is copied into multiple systems, rotation becomes an orchestration problem rather than a simple reset. That is why immature NHI environments tend to accumulate invisible access paths that are difficult to inventory or revoke. Practical implication: reduce long-lived machine credentials wherever possible and treat each embedded secret as a governance defect, not just a configuration issue.

Practical implication: inventory and eliminate embedded machine credentials before you can credibly claim control.

How identity and access separation changes workload authentication

Identity and access separation means a workload proves who it is, then receives short-lived credentials that are only valid for a narrow action set. This is materially different from a static password or API key, because the access token can expire quickly and can often be revoked without changing the underlying identity. The result is smaller blast radius and better auditability. But this model still depends on the integrity of the initial identity credential and on consistent policy enforcement across providers. Practical implication: use short-lived access tokens to limit exposure, but do not mistake token expiry for complete NHI governance.

Practical implication: pair short-lived tokens with central policy and audit, or the control remains incomplete.

What workload IAM changes in the operating model

Workload IAM shifts enforcement out of application code and into the platform layer, where identities can be tied to deployment context and access can be granted just in time. That reduces secret sprawl and removes a common source of brittle, hand-built authentication logic. The architectural change is not only stronger security. It also improves reliability because fewer apps need custom credential handling. However, the model works only when teams standardise identity sources, revocation paths, and logging across cloud and on-prem environments. Practical implication: design workload IAM as a platform control, not a per-application workaround.

Practical implication: centralise policy enforcement at the platform layer instead of bolting authentication into apps.

Threat narrative

Attacker objective: The objective is to turn one machine credential into durable access that can bypass human-facing controls and expand into production systems.

1. Entry begins when attackers reach exposed application credentials, hardcoded secrets, or weakly governed service accounts in code, CI/CD, or configuration.
2. Escalation follows when those credentials are reused across environments or grant broader access than the workload actually needs.
3. Impact occurs when stolen NHI credentials enable lateral movement, unauthorized API calls, or direct access to sensitive systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 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

Static secrets are not a transitional control, they are technical debt with security impact. The maturity model makes clear that organisations often start with hardcoded credentials or configuration secrets because they are easy to implement. But every one of those choices creates a larger governance burden later, especially when discovery, rotation, and offboarding are inconsistent. The practical lesson is that teams should treat every persistent credential as an exception that must be reduced over time.

Identity blast radius is the right way to think about NHI risk. The article shows that the main difference between maturity stages is not simply whether authentication exists, but how far a credential can reach if it is compromised. Once workloads begin using scoped, short-lived access, the blast radius narrows. Practitioners should measure machine identity controls by the damage a single secret can do, not by the number of secrets they have issued.

Workload IAM is becoming the governance baseline for autonomous software. AI agents, service accounts, and automated workflows now behave like operational actors, which means IAM must govern them as first-class identities. Human-centric joiner-mover-leaver processes do not map cleanly to software that is deployed, replicated, and retired by machines. The field should expect policy-based workload identity to become the default expectation for serious NHI programmes.

NHI maturity is uneven by design, and that is the real management problem. Most organisations will not move from stage one to stage seven in a straight line. Legacy systems, cloud-native services, and experimental AI workloads will coexist for years, each with different identity patterns. Practitioners need a segmentation strategy so governance can advance without waiting for the entire estate to modernise at once.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding should work across the NHI lifecycle.

What this signals

Identity blast radius will become a more useful planning metric than raw secret counts. When machines and AI agents outnumber people by 25x to 50x, the programme question is not how many credentials exist, but how much damage each one can do if exposed.

The governance challenge will increasingly sit at the boundary between platform engineering and IAM. Teams that keep workload identity separate from human identity processes will struggle to enforce ownership, revocation, and exception handling at the pace autonomous systems require.

As NHI estates mature, security leaders should expect policy, not password management, to become the control plane. The organisations that can enforce short-lived access and traceable ownership will have the clearest path to reducing operational and breach risk.

For practitioners

• Classify machine identities by maturity stage Map workloads, service accounts, API keys, and certificates to the maturity stage they actually use, then assign remediation priority by exposure and privilege.
• Eliminate hardcoded and duplicated secrets Scan source code, CI/CD pipelines, and configuration stores for embedded credentials, then replace them with centrally managed issuance and rotation paths.
• Reduce blast radius with short-lived credentials Where platform support exists, move workloads to ephemeral credentials and scope access to the minimum actions and resources required.
• Build a workload offboarding process Extend identity lifecycle controls to non-human identities so revoked applications, retired jobs, and decommissioned agents lose access immediately.
• Anchor policy in platform identity Use cloud, Kubernetes, or runtime-native identity as the control point, then enforce central logging and access review for every workload.

Key takeaways

• Non-human identity security fails when organisations treat machine access like a human login problem.
• The main risk is not just more credentials, but more credentials with unclear ownership and excessive reach.
• Teams should prioritise lifecycle control, short-lived access, and platform-native identity before expanding manual secrets management.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software rather than a person. That includes service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. In governance terms, these identities need ownership, lifecycle control, and access scope just like human users do.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential or account can cause if it is misused or stolen. For NHIs, this is often the more useful risk measure than credential count because one exposed secret can unlock multiple systems, environments, or automation paths.
• Workload IAM: Workload IAM is the practice of applying identity and access management controls to software workloads instead of relying on static secrets. It uses platform-native identity, policy, and short-lived credentials so access can be verified, scoped, and audited without embedding long-term secrets in applications.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, configuration files, pipelines, logs, and manual runbooks. It creates visibility gaps, makes rotation inconsistent, and increases the chance that one exposed secret leads to multiple downstream compromises.

Deepen your knowledge

NHI lifecycle management and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from the same starting point, it is worth exploring.

This post draws on content published by Aembit: 7 Stages of Non-Human Identity Security Maturity. Read the original.