Machine Identities Now Outnumber Your Employees 80 to 1. Who's Managing Them?
October 5, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A machine identity is any credential that lets an application, script, service, or AI agent authenticate without a person typing a password, and in most companies these now outnumber employee accounts by more than 80 to 1. Almost none of them are inventoried, rotated, or reviewed the way human accounts are, which makes them the least governed part of the environment and one of the fastest-growing attack surfaces in it.
Why do machine identities now outnumber human identities in most companies?
Every API integration, container, CI/CD pipeline, and cloud function needs its own credential to talk to other systems, and cloud-native architectures multiply that need automatically. CyberArk's 2025 Identity Security Landscape study, based on a survey of security decision-makers, found that machine identities, driven primarily by cloud and AI, now vastly outnumber human identities within organizations, and nearly half have sensitive or privileged access.
That last detail is the operational problem. A human employee account gets a manager, a review cycle, and an offboarding checklist. A service account created three years ago by a contractor who has since left rarely gets any of that, yet it can still hold privileged access to production data. The same CyberArk research notes that the race to embed AI into environments has created identity security risks centered on unmanaged and unsecured machine identities, and that agentic AI is about to make the sprawl worse, not better, because every autonomous agent needs its own credential to act on a user's behalf.
What happens when nobody owns a service account?
Nobody notices when it leaks, and the credential keeps working long after anyone remembers what it does. That is the pattern behind two of the most consistent findings in recent breach research: credentials are the top initial access vector, and once leaked, they stay valid for a long time.
Verizon's 2025 Data Breach Investigations Report, which analyzed more than 22,000 incidents, found that 22 percent of breaches began with credential abuse and 16 percent began with phishing, and separately that 30 percent of corporate-managed devices and 46 percent of unmanaged devices in infostealer logs contained company credentials. Infostealer malware does not care whether a credential belongs to a person or a script. It just harvests whatever is sitting in a browser cache, a config file, or an environment variable.
The persistence problem is worse for machine credentials specifically. GitGuardian's State of Secrets Sprawl 2025 report found that 23.8 million secrets were leaked on public GitHub repositories in 2024, a 25 percent year-over-year increase, and that a large share of those leaked credentials remain active long after discovery because nobody assigned to rotate them. A stolen human password gets reset the moment someone reports it missing. A hardcoded API key in an old repository can outlive the project it was written for.
How is a workload identity actually different from a user account?
A workload identity is a credential assigned to software rather than a person, and Microsoft Entra groups these into three types: applications, service principals, and managed identities. Microsoft's own documentation explains that the service principal object defines what resources an application can access, and a managed identity is a special type of service principal that eliminates the need for developers to manage credentials directly.
That distinction matters because the usual controls built for people, like multifactor prompts and conditional access based on device compliance, do not map cleanly onto a workload. Microsoft's documentation on conditional access for workload identities is direct about this gap, noting that these differences make workload identities harder to manage and put them at higher risk for compromise. You cannot ask an API key to complete an MFA challenge. You have to control it a different way: scoped permissions, network location restrictions, short credential lifetimes, and automated rotation instead of human judgment at login time.
This is not only a private-sector problem. Federal guidance has started explicitly treating machine accounts as a distinct identity category rather than an edge case. CISA's Hybrid Identity Solutions Guidance defines its scope broadly, stating that in identity architecture documents, a "user" may refer to a human or a non-human entity, such as an automated administrative service, interacting with the system. Once a federal architecture standard writes non-human entities into its definition of "user," it stops being a niche concern and becomes a baseline expectation for anyone managing identity in a regulated environment.
What does an identity administrator actually have to do about this day to day?
The job splits into four repeatable tasks, and none of them is optional if machine identities already outnumber human ones in your environment.
- Build and maintain an inventory of every service principal, managed identity, API key, and automated account, including who requested it and what it can reach.
- Apply least-privilege scoping to workload credentials the same way you would to a privileged user account, rather than defaulting to broad permissions because "it's just a service."
- Set rotation and expiration policies for secrets and keys, and track which ones are past due, since a credential with no expiration date is a credential nobody has to answer for.
- Extend conditional access and risk-based monitoring to workload identities specifically, using the controls built for that purpose instead of trying to force human-account tooling onto machine accounts.
This is now a formal, tested skill set rather than an ad hoc responsibility. Microsoft's SC-300 exam devotes an entire domain to it: planning and implementing workload identities makes up roughly a fifth to a quarter of the exam's skills measured, alongside user identity management, authentication, and identity governance, according to the official SC-300 study guide. That weighting reflects where the actual work has moved. If you're building toward that role, Forge University's SC-300 certification prep walks through workload identity configuration, conditional access scoping, and governance review cycles as core material, not an afterthought bolted onto user account management.
Where this leaves the identity function
Treating machine identities as a second-class category is how organizations end up owning credentials nobody can explain, sitting on privileges nobody reviewed, in systems nobody is watching. The fix is not a new tool bought once a year. It is a discipline applied continuously, the same way patch management or backup verification became continuous disciplines instead of quarterly checklist items.
If your team is still managing service accounts through a spreadsheet someone updates when they remember, that gap is worth closing before it shows up in an incident report instead of an audit finding. Forge University's certification resources hub has a curriculum breakdown for identity-focused paths if you want to see how workload identity topics fit alongside broader access administration skills. And if you're mapping out where to start, you can start training toward the identity administrator role that increasingly owns this problem, whether or not "identity" was ever in your job title before.
The ratio of machines to humans in your environment is not going to shrink. Every new automation, integration, and AI agent adds another credential that needs an owner. The organizations that get ahead of this are the ones that assign a name and a process to machine identities now, before the next infostealer log or leaked repository does it for them.