About the Author
This article is written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
Somewhere in your cloud environment right now, there’s probably a credential nobody remembers creating.
Maybe it’s an API key baked into a serverless function that hasn’t been touched since a hackathon eighteen months ago. It may be a certificate on an IoT sensor that shipped before the product team that built it was reorganized. Maybe it’s a service account with admin-level access that a contractor spun up to “test something quickly” and never cleaned up.
None of these have a name badge. Neither theygo through HR. None of them show up in an offboarding checklist when a project ends or a team disbands. And there are, by a wide margin, more of them than there are of you.
This is machine identity sprawl, and in 2026, it’s quietly become one of the largest unmanaged attack surfaces in enterprise IT.
What Is Machine Identity Sprawl?
Machine identity sprawl refers to the uncontrolled proliferation of credentials, API keys, tokens, certificates, service accounts, and secrets, issued to non-human entities such as serverless functions, microservices, containers, cloud workloads, and IoT devices. Unlike human user accounts, which are typically created and retired through a formal HR-linked process, these “non-human identities” (NHIs) are usually spun up automatically, embedded directly in code or configuration, and left to persist indefinitely because no one owns the job of shutting them down.
The term has moved from a niche IAM concern to a boardroom-level risk in the last two years, and the numbers explain why.
Knowledge Board
What is a non-human identity (NHI)?
A non-human identity is any digital identity assigned to something other than a person, including service accounts, API keys, OAuth tokens, machine certificates, serverless functions, microservices, containers, and IoT devices, used to authenticate and authorize access between systems.
The Numbers Are No Longer Subtle
Industry research on this topic disagrees on the exact multiple, but not on the direction. Depending on the source and the environment measured, non-human identities now outnumber human identities anywhere from roughly 17-to-1 on the conservative end to well over 100-to-1 in cloud-native environments, with several 2026 reports converging around a 45-to-1 average across typical enterprises. Palo Alto Networks’ 2026 Identity Security Landscape report, based on a survey of nearly 3,000 cybersecurity decision-makers, put the figure at 109 machine identities for every human one, up sharply from 82-to-1 just a year earlier, and projected machine identity growth to keep outpacing human identity growth over the following year.
Other findings reinforce the same pattern from different angles. Research summarized by the Cloud Security Alliance found NHIs reaching a 144-to-1 ratio in cloud-native environments specifically. GitGuardian’s State of Secrets Sprawl research reported an 80-to-1 ratio alongside a troubling detail: a large share of valid secrets detected years ago are still live and usable today, meaning credentials aren’t just proliferating, they’re persisting. Veza’s research separately identified hundreds of thousands of orphaned identities in a single dataset, a figure that had grown sharply year over year.
Whatever the precise multiplier in your own environment, the underlying story is consistent: the credential surface security teams are responsible for has grown far faster than the tooling and process built to govern it.
Knowledge Board
Why do non-human identities outnumber human identities?
Every cloud resource, microservice, SaaS integration, and IoT device typically needs its own credential to communicate with other systems, so as infrastructure has decomposed into smaller, more distributed components, the number of required identities has scaled with it, while the number of human employees has not.
Why It’s Happening: Three Architectures, One Blind Spot
Machine identity sprawl isn’t the result of one bad decision, it’s the byproduct of how modern infrastructure is built.
Serverless Functions
Serverless functions are designed to be ephemeral and are deployed constantly, often by individual developers with cloud console access, each function typically needing its own permissions to talk to databases, queues, or other services. Multiply that by every deployment, every environment (dev, staging, prod), and every function version, and the credential count climbs fast, with no equivalent to an HR system tracking who “owns” function number 4,000.
Microservices
Microservices split what used to be one application with one set of credentials into dozens or hundreds of independently deployed services, each authenticating to the others. Decomposing a monolith is good architecture; it’s also a multiplier on identity count, because every new service boundary is a new place a credential has to exist.
IoT Devices
IoT devices compound the problem physically. Sensors, gateways, and edge devices are often provisioned with long-lived certificates or hardcoded credentials at manufacture time, deployed into the field, and then effectively forgotten, sometimes for the hardware’s entire operational life, which can run into years or decades. There’s frequently no centralized inventory of which device holds which credential, let alone a process for rotating or revoking it when a device is decommissioned, sold, or compromised.
The Common Thread
What connects all three is the same structural gap: there is no offboarding process for machines. When an employee leaves, IT gets a ticket. When a serverless function is abandoned, a microservice is deprecated, or an IoT device is retired, nothing automatically happens to the credential it was issued. It just sits there, valid, often over-privileged, and invisible until someone goes looking for it, which usually happens only after an incident.
The Real Risk Isn’t the Count, It’s the Invisibility
A large number of credentials isn’t inherently dangerous. An unmanaged, unmonitored, un-rotated, and effectively invisible number of credentials is. Three specific failure patterns show up again and again in breach postmortems and industry research.
Orphaned Credentials
The human or team that created the credential leaves, gets reassigned, or the project ends, but the credential itself keeps working, with no owner accountable for it and no trigger to revoke it.
Over-Privileged Defaults
It’s faster to grant a service account broad permissions than to scope them precisely, and once something works, no one goes back to tighten it. A compromised low-value function with admin-level cloud permissions can become a launchpad for lateral movement across an entire environment.
Long-Lived, Unrotated Secrets
Human passwords get rotation policies and expiry warnings. Machine credentials frequently don’t, because rotating a hardcoded key can break production if it isn’t done carefully, so teams avoid it, and the credential quietly ages for years.
Security researchers have summarized the shift in attacker behavior bluntly: increasingly, breaches don’t involve sophisticated exploitation, they involve an attacker finding a valid, forgotten credential and simply logging in with it.
Knowledge Board
Why don’t machine identities get offboarded like human accounts?
Human offboarding is triggered by an HR event, a resignation, termination, or role change, that’s tied to a formal process. Machine identities have no equivalent trigger: when a function, service, or device is retired, nothing automatically revokes the credential it was issued, so it persists until someone manually finds and removes it.
Why Traditional IAM Doesn’t Solve This
Built for People, Not for Machines
Most identity and access management programs, single sign-on, multi-factor authentication, privileged access reviews, were architected around a simple assumption: an identity belongs to a person who logs in, gets prompted for a second factor, and can be reached by an access review email. None of that applies to a service account or an IoT certificate. Machine identities don’t respond to MFA prompts. They don’t attend quarterly access reviews. They authenticate silently, constantly, and at a volume that makes manual review impossible.
The False Sense of Coverage
Applying human-identity governance to machine identities isn’t just insufficient, it creates a false sense of coverage, where an organization believes its identity risk is managed because its human IAM program looks mature, while the much larger machine identity population goes essentially ungoverned.
Getting Machine Identity Sprawl Under Control
Closing this gap doesn’t require ripping out existing infrastructure. It requires treating machine identities as first-class citizens in identity governance, with the same lifecycle discipline applied to human accounts.
Know What You Have
- Inventory before you enforce anything. You cannot govern what you cannot see. Discovery tooling that scans cloud environments, code repositories, CI/CD pipelines, and device fleets for live credentials is the necessary first step, and it usually surfaces far more than teams expect.
- Assign explicit ownership to every credential. Every API key, service account, and certificate should map to a named owner or team, not just a system. Unowned credentials should be treated as a finding, not a footnote.
Automate the Lifecycle
- Build an actual offboarding trigger. Tie credential deprovisioning to concrete events: a deployment being torn down, a device being decommissioned, a project closing, a repository being archived. If nothing automatically happens when the underlying resource goes away, the credential will outlive it.
- Shorten credential lifespans by default. Short-lived, automatically rotated credentials shrink the window of usefulness for anything that leaks. Where long-lived certificates are unavoidable (some IoT hardware constraints), compensate with tighter scoping and more aggressive monitoring.
Shrink the Blast Radius
- Scope permissions to the task, not the convenience. Least-privilege by default is slower to configure and dramatically reduces blast radius when something inevitably does leak.
- Treat secrets in code as an incident, not a formatting issue. Hardcoded credentials in repositories, public or internal, should trigger the same response as a live exposure, because internal repositories have repeatedly been shown to be just as, if not more, likely to leak.
None of this is exotic. It’s the same governance rigor applied to human identities for two decades, extended to a population that has quietly become the majority of the enterprise’s digital footprint.
The Bottom Line
Machine identity sprawl isn’t a future risk to plan for, by every 2026 industry measure, it’s already the dominant identity population in most enterprise environments, and it’s growing faster than the human side of the house. The organizations closing the gap aren’t the ones with the most sophisticated threat detection; they’re the ones who simply decided that a credential without an owner is a problem worth fixing, whether it belongs to a person or a piece of code.
Sources referenced: Palo Alto Networks 2026 Identity Security Landscape report; Cloud Security Alliance / Entro Security non-human identity research; GitGuardian State of Secrets Sprawl 2026; Veza State of Identity & Access 2026; SecureW2 non-human identity analysis. Figures cited reflect ranges reported across these sources as of mid-2026 and vary by methodology and environment measured.
