TL;DR: Workload identities now outnumber human identities 10 to 1, while only 1% of permissions are actively used, according to Aembit citing Microsoft’s 2023 State of Cloud Permissions Risk report. That gap turns dormant machine access into the real governance problem, because standing privileges and exposed secrets can outlive the workloads they were created for.
At a glance
What this is: This analysis argues that workload identities now dominate cloud estates and that excessive, underused permissions make NHI governance the real problem.
Why it matters: It matters because IAM, PAM, and cloud teams need controls that govern machine access lifecycle, not just human authentication and password policies.
By the numbers:
- Workload identities are outnumbering human identities 10 to one, and just 1% of permissions are actively used.
Context
Workload identity is the machine equivalent of a user identity. It covers the service accounts, tokens, keys, and other credentials applications use to talk to APIs, databases, cloud services, and third-party systems without a human in the loop.
The governance problem is no longer whether these identities exist. In cloud-native environments they are now the dominant identity type, and their permissions are often broader and longer-lived than the tasks they actually perform, which creates a large NHI attack surface for IAM and PAM teams.
That is why traditional human-centric identity models miss the point. When machine identities outnumber human accounts and most permissions sit unused, the operational risk shifts from authentication friction to standing access, secret sprawl, and weak lifecycle control.
Key questions
Q: How should teams handle workload identities that outnumber human accounts by a large margin?
A: Teams should treat workload identities as a separate governance population, not a by-product of human IAM. That means inventorying them, assigning ownership, and using automation to manage issuance, review, and revocation. When machine identities scale faster than manual controls, lifecycle discipline becomes the only practical way to keep access aligned to actual workload need.
Q: Why do unused permissions increase identity risk so much?
A: Because unused access is still real access, and attackers look for accounts that already have privileges they do not need. Dormant entitlements expand the blast radius of credential theft, contractor drift and machine-account abuse. The more unused access you carry, the more paths an attacker can exploit after sign-in.
Q: What are the signs that workload identity management is failing in a large environment?
A: Common warning signs include dormant identities that have not been reviewed for months, permissions that far exceed workload requirements, and no reliable visibility into which accounts are active. Another signal is hard coded credentials inside workloads, because that usually means access is being maintained manually instead of governed through a lifecycle process. These patterns point to weak control, not just poor hygiene.
Q: What should organisations do when a workload secret is exposed?
A: They should revoke the secret, trace where it was reused, and assume any downstream integration that depended on it may also be compromised. The key is to contain the credential’s blast radius before attackers can pivot through connected systems. Waiting for a manual review only extends the exposure window.
Technical breakdown
Why workload identities create a different access model
Workloads do not authenticate like humans. They use non-human credentials such as service account tokens, API keys, certificates, and federated workload assertions to obtain access programmatically, often at deployment time or runtime. Because applications now call APIs, databases, and cloud services continuously, the identity is embedded in the service path rather than attached to a person. That means scope, duration, and revocation rules must be designed around machine execution patterns, not login sessions. The core problem is that many estates still treat these credentials as static infrastructure settings instead of governed identities with lifecycle and policy boundaries.
Practical implication: Map every workload credential to an owning system, an expiry rule, and a revocation path.
Why 10 to 1 changes the governance burden
A 10 to 1 ratio of workload identities to human identities means the scale of machine governance is structurally different from human IAM. The control challenge is not just inventory. It is entitlement sprawl, because a large number of identities can each carry permissions that are only occasionally used but still remain valid. In practice, this creates a long tail of dormant access that is hard to review manually and easy to overlook in cloud and DevSecOps pipelines. Low utilisation does not equal low risk when credentials remain active and reusable across automation paths.
Practical implication: Prioritise entitlement reduction and lifecycle governance before expanding another set of machine credentials.
Why standing permissions and exposed secrets remain the weak point
The article ties NHI risk to exposed credentials and broad permissions in repositories, pipelines, and integrations. That is the critical failure mode: a workload secret or token often grants access beyond the immediate task and persists long after the original context changes. If a repo, token, or integration is compromised, the attacker inherits the trust relationship the workload already had. This is where NHI governance differs from ordinary access management. The exposure is not just theft of a secret, but the reuse of persistent privilege attached to the secret itself.
Practical implication: Treat exposed machine secrets as active trust failures, not isolated hygiene issues.
Threat narrative
Attacker objective: The attacker wants durable non-human access that can be reused quietly across cloud and development environments.
- Entry occurs when attackers obtain a workload credential from a repository, token store, integration, or automation pipeline.
- Escalation follows when that credential grants broad standing access into cloud services, CI/CD systems, or third-party APIs.
- Impact comes from reusing the machine identity to access internal systems, source code, or sensitive operational data at scale.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- 17,000+ Secrets Exposed in Public GitLab Repositories: Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.
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 is now the dominant governance unit in cloud security. When machine identities outnumber human identities by an order of magnitude, the centre of gravity moves from user authentication to non-human lifecycle control. That changes what IAM, PAM, and cloud security teams must inventory, review, and retire. The practitioner conclusion is simple: if you cannot govern workload identity at scale, you cannot claim to govern the cloud estate.
Standing access is the real problem hidden inside machine sprawl. The article’s 1% utilisation figure points to a deeper issue than low efficiency. Permissions that exist but are rarely exercised still enlarge blast radius, and they do so silently because they look legitimate on paper. The implication for practitioners is that access governance must be driven by actual use, not by the assumption that issued access will stay proportionate.
Secret sprawl has become a lifecycle problem, not a storage problem. Workload credentials now appear in repositories, deployment tooling, SaaS integrations, and support systems, which means leakage can happen far from the original issuance point. The governing concept here is identity blast radius: once a machine secret is embedded in multiple operational layers, revocation and containment become cross-system events. Teams need to think in terms of propagation and revocation scope, not just secret hygiene.
Human-centric review cadences do not scale to machine identity behaviour. Access reviews, recertification, and periodic checks assume a stable account population and predictable usage patterns. Workload identities break that assumption because they proliferate faster than manual governance can keep up, especially when developers and DevOps teams own them informally. The practitioner conclusion is to move governance closer to issuance, automation, and runtime policy enforcement.
NHI governance is now inseparable from cloud operating model design. The article shows that machine identities sit inside CI/CD, SaaS connections, cloud consoles, and application workflows. That means entitlement design, secret handling, and workload authentication cannot be bolted on after deployment. The practical takeaway for the field is that workload identity must be treated as first-class infrastructure with ownership, monitoring, and offboarding built in from the start.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Identity blast radius: When machine credentials are embedded in CI/CD, SaaS integrations, and cloud workflows, a single exposed secret can reach far beyond the system where it was created. Governance needs to follow the credential across those paths, not stop at the vault or the repo.
A workload identity programme that still depends on manual review is already behind the operating model it is trying to control. The better signal is whether teams can issue, scope, and retire machine access at the same speed they create it.
For practitioners
- Inventory workload identities by owner and system Build a complete register of service accounts, tokens, API keys, certificates, and federated workload identities, then tie each one to an owning team and purpose.
- Reduce standing privilege on machine credentials Review workload entitlements for permissions that are broader than the task requires, and remove access that is not needed for current execution paths.
- Shorten credential lifetime and revoke on exposure Replace long-lived reusable secrets with short-lived credentials wherever possible, and define a fast revocation path for any token exposed in code, logs, or repositories.
- Separate DevOps ownership from security governance Assign clear governance for workload identities so developers can operate systems without also becoming the informal owners of access policy, rotation, and offboarding.
Key takeaways
- Workload identities have become the dominant non-human identity population in cloud estates, which changes the governance problem from login management to machine access lifecycle control.
- Low utilisation does not reduce risk when permissions remain active, because standing access still enlarges blast radius across cloud, CI/CD, and SaaS environments.
- The control that matters most is not secret storage alone, but ownership, scope, and rapid revocation for every workload credential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on broad, underused workload permissions and their cloud blast radius. |
| NHI-07 — Long-Lived Secrets | The article repeatedly links machine risk to reusable credentials that persist too long. | |
| Recommendation — Reduce workload entitlements to the minimum scope needed for each service path. Replace persistent workload secrets with short-lived credentials and enforce rapid revocation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 fits the lifecycle problem of issuing, rotating, and revoking machine authenticators. |
| Recommendation — Apply IA-5 to manage workload authenticators across issuance, rotation, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s central control issue is excessive and unused access permissions. |
| Recommendation — Use PR.AA-05 to review workload entitlements and remove permissions that no longer match need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern is credential theft followed by reuse across connected systems. |
| Recommendation — Map exposed workload secrets to credential access and lateral movement detections. | ||
Key terms
- 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.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org