Machine identities now outnumber human ones by a staggering 40,000 to 1 in some cloud-native environments. Created automatically by microservices, automation tools, CI/CD pipelines, and AI agents, these non-human identities (NHIs) keep modern cloud systems running — quietly authenticating workloads, accessing data, and orchestrating infrastructure behind the scenes.
But the more powerful and pervasive they’ve become, the more invisible they are to the security teams meant to govern them.
Secrets are scattered across environments. Permissions are often granted once and never revisited. Most organisations don’t know how many digital or non-human identities they have — or what half of them can access. And that’s a problem, because attackers do.
As cloud infrastructure grows more ephemeral, distributed, and interconnected, the challenge isn’t just keeping up with new threats — it’s recognising how fast identity itself has changed. So what does cloud security look like in a world where most credentials don’t belong to people at all?
Cloud Identity Sprawl and the Expanding Attack Surface
Cloud identity sprawl isn’t just a byproduct of digital transformation — it’s the natural result of how we build and scale cloud environments. Every automated workload, integration, and AI function needs credentials to operate.
But as cloud infrastructure becomes more widespread and shadowy, those identities are multiplying faster than most teams can manage them. And the more fragmented they become, the harder it gets to see where risk is accumulating.
How machine identities scale faster than security policies
Every new service account, API connection, or workload spins up another identity. Most are created automatically by CI/CD pipelines, automation scripts, or container orchestrators; and designed to operate without human oversight. That’s the point. But it’s also the problem.
In dynamic environments, secrets like API keys and tokens are embedded, copied, cached, and forgotten at scale. With no centralised visibility or lifecycle enforcement, they accumulate in shadow systems. And as artificial intelligence becomes increasingly agentic and autonomous, the number of identities accelerates even faster.
According to Orca Security’s 2025 State of Cloud Security Report, 84 per cent of organisations now run AI workloads in the cloud, and each of those agents or orchestrators generates its own trail of non-human access. These identities often live for minutes — and still carry privileged credentials.
Why cloud-native architecture complicates oversight
In theory, identity should be the easiest control point in the cloud. In practice, it’s fragmented across platforms, services, and ownership silos.
Machine identities aren’t confined to a single IAM dashboard — they’re scattered across Kubernetes manifests, secrets managers, GitHub actions, runtime containers, and vault integrations. Some are created by developers. Others by automation tools. Many live in third-party environments with little to no governance.
The result? A sprawling web of access no one fully owns or audits.
Analysis of millions of real-world NHI secrets by Entro Security Labs reveals that 91 per cent of non-human identities created by former employees remain active, continuing to operate in the background long after the people who created them have left. In multi-cloud and hybrid environments, these orphaned tokens often bypass standard access controls altogether.
Where Machine Identities Live in the Cloud
Machine identities don’t live in a single system. They’re embedded throughout the cloud — stitched into pipelines, embedded in containers, and scattered across SaaS connectors and service meshes.
Most aren’t visible in traditional IAM tools, and many aren’t consistently tracked at all. To secure them properly, you need to understand how they’re used, where they live, and what they actually do inside a modern cloud stack.
Service accounts and microservices in motion
Most modern infrastructure doesn’t wait for a human to give it instructions. It acts on its own: provisioning resources, transferring data, calling APIs. Each of those operations is authenticated by a non-human identity.
Service accounts are at the core of this. Whether it’s an AWS IAM role connecting workloads, an Azure service principal accessing a database, or a Kubernetes pod reaching out to an internal API, each identity carries credentials that enable it to act autonomously.
That’s what makes them so powerful. And so easy to overlook.
These identities often serve routine purposes: spinning up new environments, running backups, scaling microservices. But because they’re part of the background machinery, their access is rarely revisited. And in highly dynamic architectures, they’re created and destroyed so quickly that they’re often never logged properly in the first place.
API keys, tokens, and the secrets that power SaaS
Service accounts govern internal operations. External integrations, though, rely on secrets. OAuth tokens, API keys, and session credentials form the connective tissue between cloud services, SaaS platforms, and third-party tools.
It’s a system built on trust. And too often, that trust is implicit.
Hardcoded credentials are still turning up in public GitHub repositories. Secrets shared in plaintext are still stored in configuration files. And once exposed, they can live on for years. GitGuardian’s State of Secrets Sprawl report found that 70 per cent of leaked secrets remain active more than three years after exposure — long enough for attackers to discover and weaponise them.
The more these secrets are embedded across codebases and platforms, the harder it becomes to track who has access, when it was granted, and whether it should still exist at all.
Key Security Risks of Non-Human Identities in the Cloud
When machine identities are left unmanaged, risk builds silently in the background. Secrets remain in circulation long after they should expire. Access privileges extend further than anyone intended. Tokens get repurposed, reused, or orphaned — all without detection.
These aren’t edge cases. They’re core weaknesses in cloud security postures, and they’re being exploited more often than most teams realise.
Secrets sprawl and credential leakage
Secrets are everywhere. Tokens, certificates, and API keys are passed between scripts, stored in environment variables, copied across deployment pipelines, and embedded in configuration files. Each one is a point of access, and every one of them needs to be tracked, rotated, and eventually revoked.
Most aren’t.
In many environments, secrets are created without defined expiration dates or lifecycle controls. They’re hardcoded, shared across systems, or left in place “just in case.” The longer they remain, the more attractive they become to attackers.
OWASP’s Top 10 for Non-Human Identities lists Secret Leakage and Long-Lived Credentials as two of the most critical risks facing machine identity security today. And with good reason. These credentials often hold privileged access to critical systems — and once exposed, they’re difficult to trace and even harder to shut down quickly.
Over-permissioning and privilege escalation
When it comes to non-human identities, the principle of least privilege is rarely applied as consistently as it should be. Service accounts and machine credentials are often granted broad access up front, in case they might need it later — and rarely reviewed after that.
Palo Alto Networks Unit 42 reported that 99 per cent of service accounts are over-permissioned, often with administrative privileges far beyond what their functions require.
That makes them a perfect entry point.
If an attacker compromises a machine identity, they don’t need to guess passwords or trick users. They can move laterally across systems, escalate privileges quietly, and avoid many of the alerting mechanisms designed for human behaviour. NHIs don’t get locked out for suspicious logins. They don’t fail MFA challenges. They just work — until someone notices they shouldn’t be.
Inactive or orphaned identities
Cloud infrastructure moves fast. People leave. Workloads change. But non-human identities often stay behind.
Orphaned machine identities — those created by former employees or tied to deprecated systems — tend to linger in the background, still connected, still authorised, and still invisible to most audit processes.
This becomes especially risky in complex environments where the same credentials are reused across development, staging, and production. A token that was once low-risk in test could end up with unexpected access to live systems without ever being reclassified or revoked.
Without a clear lifecycle strategy, machine identities drift from active to abandoned, all while retaining their access. That’s not just a governance problem. It’s a breach waiting to happen.
Challenges in Managing Machine Identities at Scale
Identifying the risks is only part of the problem. Managing machine identities in the cloud requires visibility, ownership, and governance. These are three things that are still missing from most environments.
Credentials are created across teams, automated without audit, and rarely assigned clear ownership. And as AI-driven automation accelerates identity creation, most organisations are struggling to maintain even basic oversight.
Tooling silos and fragmented governance
In most organisations, identity security is distributed across teams that rarely share the same tooling or even the same priorities. DevOps manages service accounts to keep deployments moving. IAM teams handle human users and group policies. Security, meanwhile, is often left reacting to incidents after access has already been granted.
It’s a disconnect that leads to gaps in governance.
There’s often no single system of record for machine identities. No unified inventory. No contextual understanding of what each credential was created for, who requested it, or whether it’s still being used. The result is shadow access: credentials that exist, that work, but that no one is really tracking.
This isn’t just an issue of oversight. It’s a structural problem. And in multi-cloud environments, data silos like this scale fast.
Automation without accountability
Cloud environments run on automation but they’re not always built to govern it.
Each time a script runs or a pipeline executes, new credentials can be created. Some live for seconds. Others stick around for years. Most never go through a formal approval process. There’s simply no time.
This becomes even more complex with the rise of agentic AI. Autonomous systems now generate actions based on prompt chains, decision trees, or environmental triggers — and every one of those actions can require machine-level authentication. The more sophisticated the AI, the more unpredictable its access footprint becomes.
Without clear rules for identity ownership and lifecycle, and without oversight baked into the automation layer, even well-intentioned workflows can introduce risk. At scale, those risks are no longer theoretical. They’re inevitable.
How Cloud Security Leaders Can Regain Control
Machine identities aren’t going away. If anything, they’re only becoming more critical and more complex. The question isn’t whether to secure them, but how.
A modern cloud security posture can’t treat non-human identities as exceptions. They have to be inventoried, monitored, and governed with the same precision as human users — in some cases, more. That means building an identity-first strategy designed for automation, scale, and continuous change. One that starts with visibility and ends with enforcement.
Start with discovery and contextual inventory
You can’t secure what you can’t see. That’s where most machine identity strategies fail.
The first step is building a real-time inventory that maps where machine identities exist, what systems they interact with, and how their access changes over time. Traditional IAM tools aren’t built for this. You’ll need support from Cloud Infrastructure Entitlement Management (CIEM) platforms, secrets scanning tools, and vault integrations that can track identities across cloud providers and workloads.
But visibility on its own isn’t enough. It has to be contextual. You need to understand why each identity exists, what risk it introduces, and whether it’s being used the way it was intended.
Automate rotation, expiration, and access reviews
Every machine identity should have a defined lifecycle. Creation. Usage. Expiry.
What you want to avoid are long-lived secrets that remain valid far beyond their useful window. Static credentials — especially those embedded in code — are among the most common attack vectors in cloud environments. Yet they’re still widely used, rarely rotated, and often overlooked during audits.
Enforcing credential rotation schedules, applying expiration policies, and conducting regular access reviews are foundational practices. But at scale, they can’t rely on manual enforcement. These tasks need to be automated and built into your pipelines and tooling. Otherwise, they won’t happen consistently.
Apply Zero Trust and policy-as-code
Trust nothing by default. That’s the core of Zero Trust, and it applies just as much to machines as it does to people.
Every action performed by a non-human identity should be verified based on context. That means assessing the request, validating the environment, and limiting the scope of access to the bare minimum required. Role-based access and workload identity enforcement are key here, especially in multi-cloud environments.
Policy-as-code helps operationalise this. By codifying access requirements and embedding them into your infrastructure workflows, you can enforce consistent controls at every layer — and adapt them dynamically as your systems evolve.
Final Thoughts: Cloud Security Starts Where Identity Ends
Machine identities aren’t a niche concern. They’re the fastest-growing threat vector in modern cloud environments and still one of the least governed.
While most organisations have invested heavily in human identity and access management, non-human identities have quietly overtaken them in volume, complexity, and risk. Credentials are being created faster than they can be tracked. Permissions are granted with no expiry. And the systems that rely on these identities are often the ones with the greatest access to sensitive data and infrastructure.
The future of cloud security will depend on whether organisations treat machine identities as background noise or as critical infrastructure. Because that’s what they are.
Visibility, rotation, and enforcement can’t be handled manually. These controls need to be embedded at the infrastructure level, built into your automation, and governed like any other production asset.
To stay ahead, leaders need to adopt identity-first strategies that account for how the cloud really works now — not how it worked five years ago. That means asking better questions, implementing sharper controls, and staying informed.
For more on securing the modern enterprise and staying ahead of identity-driven risks, explore the latest research and insights across EM360Tech.
Comments ( 0 )