Workload identity outnumbers humans 10 to 1 in modern cloud

At a glance

What this is: This is an analysis of how workload identities have become a larger and more exposed access layer than human users, with weak visibility, broad permissions, and reusable secrets driving breach risk.

Why it matters: It matters because IAM teams must now govern machine access at the same rigor as human access, or cloud, DevOps, and AI pipelines will keep expanding blast radius faster than review cycles can contain it.

By the numbers:

• workload identities are outnumbering human identities 10 to one
• just 1% of permissions are actively used

👉 Read Aembit's analysis of workload identity exposure and secret sprawl

Context

Workload identity is the machine-to-machine access layer that lets applications, services, APIs, and cloud resources authenticate and call one another. In cloud-native environments, that layer now often outnumbers human identity, which means the governance problem has shifted from user login to machine trust, privilege scope, and secret exposure.

The article argues that modern applications increasingly rely on persistent non-human credentials embedded in repositories, pipelines, and integrations. That creates a broader identity security problem for IAM, NHI governance, and DevSecOps, because the access path is now distributed across code, cloud, and third-party services rather than concentrated in a single user session.

Key questions

Q: How should security teams govern workload identities in cloud-native environments?

A: Treat workload identities as production identities with an owned lifecycle, not as implementation details. Inventory every service account, API key, token, and certificate, then tie each one to an explicit owner, purpose, scope, and expiry. The goal is to make machine access reviewable, revocable, and auditable before a breach forces the issue.

Q: Why do long-lived machine credentials create outsized breach risk?

A: Long-lived credentials expand the replay window. If an attacker steals a token or secret, they can use it quietly until revocation occurs, and that delay often outlasts detection. The risk grows when the credential also carries access into pipelines, cloud consoles, and third-party services, because one compromise can unlock several systems at once.

Q: What do teams get wrong about workload secret rotation?

A: They often rotate the secret without fixing the places it has already spread. If the credential exists in repositories, logs, build artifacts, and integration configs, rotation only solves one copy of the problem. Real control requires removal from all storage locations, plus a way to stop the old credential from being replayed.

Q: How should organisations respond when a third-party integration has broad access?

A: Treat the integration like a privileged identity and review it on a lifecycle basis. Confirm why it needs access, whether its scope matches the current business purpose, and whether the token can be narrowed or replaced with short-lived access. If the answer is unclear, revoke first and reissue only after the access model is proven.

Technical breakdown

Why workload identities expand the attack surface

Workloads do not authenticate like people. They rely on service accounts, tokens, API keys, certificates, and OAuth grants to talk to other services, often at high frequency and across multiple environments. That makes the access model durable, reusable, and easy to overextend. When those credentials are long-lived or broadly scoped, a compromise in one system can become a pivot into CI/CD, cloud administration, or downstream SaaS. The core issue is not just exposure. It is that machine credentials often carry trust far beyond the original task context.

Practical implication: inventory every workload identity, map its trust path, and remove any credential that can still be replayed after the original workflow ends.

Why standing privilege is the real problem

Standing privilege means a workload retains access even when it is not actively performing a task. In practice, this creates an invisible reserve of privilege that attackers can abuse after token theft, repository exposure, or integration compromise. Because workloads often need broad access to operate across code, data, and infrastructure, teams tend to tolerate excess permission as a convenience. That convenience becomes liability when permissions are never narrowed back down. The issue is not workload automation itself. It is the accumulation of durable access that remains valid long after the need has passed.

Practical implication: treat unused permissions as an exposure problem and enforce task-scoped access with explicit expiry wherever possible.

How secret sprawl turns integrations into breach paths

Secret sprawl happens when credentials are scattered across repositories, scripts, environment variables, deployment artifacts, and third-party integrations. Once that pattern takes hold, discovery and rotation become disconnected from the systems that actually consume the secret. Attackers prefer those environments because they can harvest credentials quietly and then use legitimate access paths instead of noisy exploits. This is especially dangerous in cloud-native and DevOps settings, where a single exposed token can connect to source code, infrastructure, and customer data. Secret management is therefore not a storage problem alone. It is an access governance problem.

Practical implication: centralise secret issuance, classify every secret-bearing system, and eliminate reusable credentials from places developers can accidentally publish.

Threat narrative

Attacker objective: The attacker wants durable machine-to-machine access that can be reused quietly to reach sensitive code, infrastructure, and data.

1. entry: Attackers gain access through exposed credentials, stolen tokens, or compromised third-party integrations tied to workload identities.
2. escalation: The stolen machine credential is reused to reach GitHub, CI/CD systems, cloud consoles, or SaaS administration paths with broader privilege.
3. impact: The attacker can extract source code, environment variables, tokens, customer data, or infrastructure details and then pivot further into connected services.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Workload identity has become the default enterprise access layer, not a niche control problem. When machine identities outnumber human identities by an order of magnitude, the centre of gravity for identity governance shifts from user authentication to service-to-service trust. That means IAM, DevOps, and security teams are now managing a much larger population of non-human credentials with far less visibility than they have for employees. The practical conclusion is simple: if machine identities are not in your core governance model, your governance model is incomplete.

Secret sprawl is not an operational inconvenience, it is a structural governance failure. Repositories, pipelines, and configuration stores have become accidental credential warehouses because modern delivery systems mix code, identity, and infrastructure state. Once a secret is copied into multiple places, rotation no longer restores control, it only proves how widely the secret has propagated. Teams should read this as an identity lifecycle problem, not just a developer hygiene issue.

Persistent delegation is the named concept that best captures this risk. OAuth grants, long-lived tokens, and inherited workload permissions create access that survives well beyond the original approval moment. That assumption was designed for stable, reviewable relationships, but it fails when integrations, pipelines, and cloud services keep acting with broad authority after the initiating event has passed. The implication is that access governance must be built around expiry, scope, and revocation discipline, not trust persistence.

Machine identity security now sits at the intersection of NHI, cloud governance, and DevSecOps. The article shows that compromise often starts where those domains overlap: a token in source control, a secret in a repository, or a grant on a SaaS integration. In practice, the organisations that reduce loss fastest will be the ones that treat workload credentials as first-class identities with the same lifecycle discipline applied to human access.

Reusable secrets are becoming the weakest part of modern identity architecture. A secret that can be copied, replayed, and forgotten is a liability once applications depend on it for routine access. That is why the field is moving toward short-lived, identity-driven access patterns and away from static credentials embedded in workflows. Practitioners should assume the replay window, not the original compromise, determines the blast radius.

From our research:

• workload identities are outnumbering human identities 10 to one, according to the 2026 Infrastructure Identity Survey.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why credential exposure keeps recurring across code and pipelines.
• For a wider lifecycle view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding discipline.

What this signals

Secret lifecycle discipline is now the difference between isolated exposure and repeat compromise. When credentials are copied into repositories, build logs, and deployment artifacts, the control surface extends far beyond the original system. Teams should assume that any static secret may already exist in multiple places, and make revocation, discovery, and replacement a single operational workflow, not separate tickets.

The next maturity jump is moving from secret storage to identity issuance. That means prioritising short-lived credentials, tightening partner access, and aligning access reviews with the actual systems that consume machine identity. The same discipline applies whether the identity is a workload, a SaaS integration, or an AI-driven automation path.

For teams building cloud and AI programmes, the practical signal is clear: if access cannot be explained in terms of owner, scope, and expiry, it is already outside governance. The organisations that close this gap will reduce blast radius faster than those that only expand monitoring.

For practitioners

• Build a complete workload identity inventory Record every service account, token, certificate, API key, and OAuth grant that can reach production data or infrastructure. Include where each credential is stored, who can rotate it, and which systems still accept it after use.
• Shorten credential replay windows Replace long-lived secrets with short-lived, task-scoped credentials wherever the workflow allows it. Prioritise integrations that connect source control, CI/CD, cloud administration, and third-party SaaS because those paths carry the widest blast radius.
• Remove secrets from places developers publish Search repositories, pipeline logs, exported configuration files, and deployment artifacts for embedded credentials. Pair scanning with revocation so that discovery is immediately followed by invalidation, not just ticket creation.
• Review standing access on third-party integrations Audit OAuth grants and partner-issued tokens for overbroad scopes, unused permissions, and stale approvals. Revoke anything that is no longer needed and make reauthorization part of the integration lifecycle, not an exception process.

Key takeaways

• Workload identities now represent a larger identity population than human users, so IAM programmes must treat machine access as a core governance domain.
• Long-lived tokens, broad OAuth grants, and secret sprawl create the replay conditions that turn a single exposure into a multi-system incident.
• The control that matters most is lifecycle discipline for machine credentials, including inventory, expiry, revocation, and removal from every storage location.

Key terms

• Workload Identity: A workload identity is the machine-side credential set used by applications, services, APIs, and automation to authenticate to other systems. It can include service accounts, tokens, certificates, or federated assertions. The governance challenge is lifecycle control, because these identities often outlive the task they were created for.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across repositories, logs, pipelines, scripts, and configuration files. The problem is not just storage, but replay risk and weak revocation discipline. Once a secret exists in many places, cleanup becomes slower than attacker use.
• Standing Privilege: Standing privilege is access that remains valid whether or not it is actively needed. For machine identities, it usually appears as persistent tokens, broad OAuth grants, or long-lived service credentials. It increases blast radius because a stolen credential can be reused without waiting for a new approval.
• Task-scoped Access: Task-scoped access is permission granted only for the duration and scope of a specific job. In machine identity programmes, it is the practical alternative to durable secrets because it reduces replay value and limits how far a compromised credential can move through connected systems.

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 Aembit: Workload identity outnumbers humans 10 to 1 in modern cloud. Read the original.