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 cloud identity class and a larger attack surface than human users.

Why it matters: IAM and security teams need to treat workload identities, service accounts, and automation principals as first-class governed identities because scale and privilege now sit mainly outside user accounts.

By the numbers:

• Microsoft’s 2024 multicloud security data shows one human identity for every 10 workload identities.
• Across customer environments analyzed in 2023, Entra Permissions Management identified 209 million cloud identities.
• More than 83% of those 209 million identities were non-human.
• In the Entro NHI & Secrets Risk Report, non-human identities outnumber human identities by an average ratio of 144:1 across analyzed enterprise environments.

Context

Non-human identity is the governance problem hidden inside modern cloud scale. When software, workloads, and automation need to cross system boundaries, they do so through identities that can be granted permissions, evaluated in access control, and traced in logs, which makes them governable assets rather than background code.

This matters because the article’s core claim is not simply that NHIs exist in large numbers. It is that cloud environments now contain far more machine identities than human users, and many of the most privileged principals are not people at all. For IAM teams, that shifts the control plane from user authentication to identity inventory, privilege scope, and lifecycle discipline across workloads and automation.

Key questions

Q: What breaks when cloud identities are not centrally governed?

A: Shadow accounts, orphaned credentials and inconsistent role definitions emerge because no single process can see the whole access picture. That breaks least privilege, complicates incident response and makes compliance evidence harder to prove, especially when workforce and service identities are managed separately.

Q: Why do non-human identities increase privileged access risk in cloud environments?

A: Non-human identities increase risk because they often outnumber humans, operate continuously, and depend on credentials that are easier to reuse than to govern. When those identities retain broad or persistent access, attackers gain a faster path to cloud services, data stores, and automation layers. The risk is structural, not just operational.

Q: How can security teams tell whether NHI governance is actually working?

A: Look for evidence of ownership, expiry, scope, and rotation across the machine identity estate. If a team can quickly answer who owns each credential, what it is for, when it expires, and whether it can cross environments, governance is maturing. If those answers are missing, control is still fragmented.

Q: Why do IAM controls fail when non-human identities outnumber human users?

A: IAM controls fail when NHIs dominate because the governance model was built around stable human accounts with predictable owners, review cycles, and sign-in behaviour. Machine identities are created faster, reused more widely, and forgotten more easily, so the control problem shifts from authentication to lifecycle visibility and revocation discipline.

Technical breakdown

Why non-human identities become the control plane in cloud environments

In distributed systems, identity is the mechanism that lets software cross a trust boundary and still be governed. A workload identity, service principal, or agent identity is not just a label. It is a directory-backed security principal that can authenticate, receive authorization decisions, and leave an audit trail. Once that pattern becomes the default for APIs, scripts, and integrations, identity stops being a user-only concern and becomes the control plane for access, policy, and accountability across the environment.

Practical implication: inventory every workload-facing principal as a governed identity, not as application plumbing.

Why scale changes the risk profile of workload identities

The article’s scale argument is the real warning. When machine identities outnumber human identities by large multiples, manual oversight breaks down and privilege concentration becomes harder to see. That is especially dangerous because workload identities often operate continuously, across services, with persistent entitlements that no human checks daily. In practice, the risk is not just more identities. It is more invisible identities with broader reach and fewer natural review points than user accounts.

Practical implication: prioritise discovery, ownership, and entitlement review for workload identities before expanding controls elsewhere.

How super identities amplify non-human identity exposure

A super identity is a principal with access to all permissions and resources across the cloud estate. That is an authorization design, not a user type, and it is exactly why NHI governance cannot stop at account counts. If machine identities inherit broad roles, over-permissioned service accounts can traverse large parts of the estate without needing to break authentication. The technical failure is privilege scope that was never narrowed to the task or workload boundary.

Practical implication: map every high-privilege machine identity to a specific business function and remove estate-wide access where it is not essential.

Threat narrative

Attacker objective: The attacker’s objective is to operate inside the cloud estate through a valid non-human principal and use its standing access to reach services, data, or administrative functions.

1. Entry occurs when a workload, script, or service principal is provisioned with an identity that can be trusted by other systems without interactive human checks.
2. Credential access happens through tokens, keys, or persistent authentication material tied to the non-human identity, which can be reused outside the intended runtime context.
3. Escalation follows when that identity carries broad permissions or is reused across multiple services, allowing an attacker to move through cloud resources under a valid principal.
4. Impact is measured in unauthorized access, lateral movement across cloud services, and prolonged control of workloads that remain trusted by policy.

NHI Mgmt Group analysis

Non-human identity is now the primary cloud governance problem: The article is directionally correct that scale has shifted away from human users and toward machine principals. That means the old assumption that users are the main identity risk no longer holds. IAM programmes that still optimise around employee access reviews are governing the smaller half of the estate, not the more exposed one. The practitioner conclusion is simple: cloud identity governance must start with NHIs.

Super identities are the clearest sign that privilege, not authentication, is the real exposure: The article shows that many of the most powerful principals are workload identities with estate-wide reach. That is not an authentication problem alone. It is a privilege design problem where machine accounts inherit far more authority than the task requires. The governance issue is not whether the principal can log in, but whether its permissions were ever bounded to a real operating need.

Identity blast radius: the article exposes how one machine principal can carry disproportionate reach across cloud services. That creates a governance pattern where a single compromised workload identity can affect far more than a single application boundary. This is why NHI governance has to be measured in blast radius, not just in account count. Practitioners should treat each high-value workload identity as a potential multi-service trust anchor, because that is how cloud compromise scales.

Lifecycle discipline is the missing layer in most NHI programmes: The article points to identities that persist across systems, but it does not describe commensurate ownership, review, or offboarding discipline. That means the operational failure is not only over-provisioning, it is unmanaged persistence. When a workload identity outlives the application, pipeline, or automation it was created for, accountability weakens and access becomes structurally harder to retire. The practitioner conclusion is to govern NHIs as lifecycle-managed assets, not static configuration.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
• Read next: Ultimate Guide to NHIs — Why NHI Security Matters Now

What this signals

A cloud programme that still begins with human users is already behind the operating model described here. The sharper question is whether the organisation can explain who owns each workload identity, why it exists, and when it should be retired.

Identity blast radius: the practical measure of cloud identity risk is how far a machine principal can move once trusted, not how many accounts exist in total. Teams should expect governance pressure to shift toward entitlement scope, ownership evidence, and lifecycle closure rather than user-centric review cycles.

The presence of super identities suggests that privilege review must become more granular than a periodic access recertification. In environments where workload identities can span services continuously, the control that matters most is whether access is still justified by the workload’s current purpose.

For practitioners

• Build a complete NHI inventory Catalogue workload identities, service principals, automation accounts, and agent identities across cloud estates so ownership and scope are visible.
• Identify and review super identities Find principals with access to all permissions or all resources and require explicit business justification for each exception.
• Assign lifecycle ownership to every machine identity Tie creation, change, review, and offboarding of each non-human identity to a named owner and a documented service purpose.
• Reduce standing privilege for workloads Replace broad default entitlements with task-scoped access so tokens and service accounts cannot traverse the cloud estate by default.

Key takeaways

• Cloud identity governance is no longer centred on humans, because workload identities now account for a larger share of the access surface.
• The main risk is not identity count alone but the combination of persistence, privilege scope, and weak lifecycle ownership.
• Practitioners should inventory, justify, and retire machine identities with the same discipline already expected for human access.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Super Identity: A super identity is a principal with unusually broad access, sometimes reaching all permissions or all resources in an environment. In NHI governance, this is a high-risk pattern because it turns a single machine account into a major trust anchor whose compromise or misuse can affect large parts of the estate.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.