Non-human identities now dominate cloud access and attack surface

At a glance

What this is: This is a Semperis analysis arguing that non-human identities have become the dominant identity class in modern cloud environments and therefore the larger security concern.

Why it matters: IAM teams need to treat workload identities, service principals, and emerging agent identities as primary governance objects because their scale and privileges now outstrip human accounts.

By the numbers:

• Today, there is one human identity for every 10 workload identities.
• Across customer environments analyzed in 2023, Entra Permissions Management identified 209 million cloud identities.

👉 Read Semperis's analysis of why non-human identities matter more than users

Context

Non-human identity has become a core IAM problem because software that crosses system boundaries must be trusted as a security principal, not just treated as code. In cloud environments, that means service accounts, applications, bots, and agents can hold permissions, appear in logs, and persist beyond the runtime that created them, which makes identity the control plane.

The governance gap is that most identity programmes were built around people first, then extended to machine identities as an afterthought. Once workload identities outnumber human users by an order of magnitude, visibility, privilege management, and lifecycle controls stop being edge cases and become the centre of IAM operations.

Semperis uses Microsoft Entra ID to illustrate the shift, but the underlying pattern is broader: modern systems rely on non-human identities for API access, orchestration, and state changes. That is why NHI governance now sits alongside human IAM rather than beneath it.

Key questions

Q: How should security teams govern workload identities at cloud scale?

A: Security teams should govern workload identities as first-class principals with an owner, purpose, permission boundary, and retirement path. The priority is visibility into what exists, then reduction of standing privilege, then lifecycle control. When workload identities outnumber users, manual review alone is not enough, so governance has to combine inventory, access scoping, and automated rotation or offboarding.

Q: Why do non-human identities create more risk than human accounts in cloud environments?

A: Non-human identities create more risk because they often exist in far greater numbers, run continuously, and hold persistent access to systems that human users rarely touch directly. A single compromised machine principal can expose APIs, data stores, and automation pipelines. The governance challenge is that many teams still treat them as implementation details rather than access-bearing identities.

Q: What breaks when service accounts have broad permissions and no clear owner?

A: When service accounts have broad permissions and no clear owner, accountability breaks first and containment breaks next. Teams cannot quickly determine why the identity exists, who should approve changes, or when it should be removed. That is how stale access persists long after the workload changes, and why ownership plus least privilege are operational controls, not paperwork.

Q: Who should be accountable for agent identities in IAM programmes?

A: Accountability should sit with both the technical team running the workload and the business owner that depends on it. Agent identities can initiate actions, so they need explicit ownership, scoped permissions, logging, and retirement criteria before production use. That combination ensures governance exists before the identity starts making meaningful changes.

Technical breakdown

Why machine identities become the control plane

A machine identity is the directory-backed principal a system uses to prove who or what is acting. Unlike code, which can move freely, the identity is what access control, audit, and policy engines evaluate. In cloud architecture, that makes the identity layer the enforcement point for API calls, state changes, and inter-service trust. The problem is not merely that there are many such identities. It is that they often accumulate permissions over time, persist longer than the workload they support, and remain invisible to teams that focus on user accounts.

Practical implication: inventory machine identities as first-class principals, not as implementation detail.

Workload identity sprawl and privilege concentration

Workload identity sprawl occurs when applications, service principals, tokens, and automation accounts proliferate faster than governance can track them. The security issue is compounded when those identities are granted broad or tenant-wide permissions, because compromise of one principal can expose large parts of the environment. In practice, this creates an access model where scale and privilege reinforce each other: more identities means more review burden, and more privilege means more urgent exposure. That combination is why visibility alone is not enough without entitlement reduction.

Practical implication: measure both the number of workload identities and the scope of their effective permissions.

Agent identities extend NHI governance into autonomous workflows

Agent identities are the next step in non-human identity design because they represent software that can initiate actions, call tools, and move across systems in an operational context. Even when they are not autonomous in the strict sense, they still behave like machine principals and therefore inherit the same governance burdens as service accounts, plus new questions about delegation and runtime scope. The important shift is that identity is no longer just supporting automation. It is increasingly the mechanism through which software makes decisions and changes state.

Practical implication: extend NHI policy, logging, and lifecycle controls before agent identities are widely embedded in production workflows.

NHI Mgmt Group analysis

Non-human identities are now the dominant identity class, not a side category. When there is one human identity for every 10 workload identities, the old assumption that user accounts define the main identity risk no longer holds. The control surface has shifted to machine principals that create access, move data, and trigger state changes at cloud scale. Practitioners must re-centre IAM on the identities that actually run the environment.

Identity governance was designed for slower human review cycles, and that model does not fit machine-scale execution. The operational pace of service accounts, applications, and agent-like workloads creates far more identities than manual review can absorb. That mismatch is why visibility, entitlement discipline, and automated lifecycle controls matter more than periodic user-centric recertification. The practical conclusion is that NHI governance must be designed for continuous churn.

High privilege in NHIs is the real blast-radius multiplier. The article’s data point about more than 83% of cloud identities being non-human matters because scale alone is not the risk. Risk concentrates when machine principals also carry broad access paths across environments. In NIST CSF and Zero Trust terms, the control objective is not just identification but containment. Practitioners should treat over-privileged NHIs as environment-wide exposure, not local misconfiguration.

Agent identities sharpen a broader NHI governance gap, not a separate product problem. The same lifecycle, visibility, and privilege issues that affect service accounts will apply to AI-enabled workload identities as they become more common. That means the discipline has to be built around the identity type and its operating model, not around whether the workload is branded as automation, application, or agent. The implication is clear: governance frameworks need to follow the principal, not the label.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• That visibility gap is why lifecycle control, ownership, and privilege reduction need to move together, as explored in Top 10 NHI Issues.

What this signals

Identity sprawl is becoming a governance problem, not just an inventory problem. Once cloud estates contain far more workload identities than people, programme leaders need a control model that can absorb continuous creation and retirement without waiting for quarterly review cycles. The operational question is not whether NHIs exist, but whether the IAM operating model can still see them, own them, and retire them before they become stale.

The strongest programmes will treat workload identities and agent identities as part of the same lifecycle discipline, with explicit ownership and permission boundaries from the start. That is where the practical edge now sits: not in discovering that NHIs are important, but in making them governable at the same speed the estate is changing.

For practitioners

• Inventory machine identities by function and privilege Build a current register of service accounts, application identities, tokens, certificates, and agent identities, then classify each by owner, workload, and access scope.
• Reduce standing privilege across workload principals Review cloud permissions for tenant-wide or resource-wide access, remove unnecessary role assignments, and require task-scoped access where the workload can tolerate it.
• Tie lifecycle ownership to every non-human principal Assign a business and technical owner to each machine identity, then make creation, review, rotation, and retirement part of the same governance record.
• Prepare governance for agent identities before adoption scales Extend policies, logging, and exception handling to identities that may call APIs or trigger workflows on their own, even when they are introduced through automation programmes.

Key takeaways

• Non-human identities are no longer a niche control issue because they now outnumber human identities at cloud scale.
• The biggest risk is not just volume but privilege concentration, which turns a single machine principal into broad environment exposure.
• IAM teams need ownership, visibility, and lifecycle discipline for NHIs before agent identities make the governance gap larger.

Key terms

• Non-Human Identity: A non-human identity is a security principal used by software, devices, or automation to authenticate and receive access decisions. It includes service accounts, applications, tokens, certificates, bots, and agents. In practice, it is the identity through which machine activity becomes visible, authorised, and auditable.
• Workload Identity: A workload identity is the identity assigned to a software workload so it can access APIs, data, and infrastructure without a person signing in. It often persists longer than the code that uses it, which makes ownership, rotation, and privilege scope essential to governance.
• Agent Identity: An agent identity is a machine identity associated with software that can act in an operational context, such as calling tools or triggering workflows. As agents become more capable, the identity itself becomes the control point for scope, accountability, and containment.

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 Semperis: Why non-human identities actually matter more than users. Read the original.