Machine Identities: The Security Problem Humans Cannot Solve Alone

Identity programs were built around people. Joiner, mover and leaver processes, manager attestations, MFA and password policy all assume a person at the other end. Machine identities have none of that structure. They are created by engineers in minutes, they rarely have a named owner, and nothing happens when the project that needed them ends. So they accumulate, and the accumulation is where attackers go.

Vendors publish ratios of machine to human identities, and the numbers differ because each vendor counts different things. No standard count exists. What matters for a security leader is simpler: the machine population is large, growing, and rarely inventoried in one place.

What counts as a machine identity

Any non-human principal that authenticates or holds access:

• Service accounts in directories and applications.

• API keys and personal access tokens.

• OAuth applications and service principals, including those granted consent by a user or administrator.

• Cloud workload roles and managed identities.

• Certificates and keys, for transport security, code signing and device identity.

• Credentials used by build and deployment pipelines.

• Automation, bots and AI agents acting on behalf of users or systems.

The last item is new in scale, not in kind. An agent that calls APIs on someone’s behalf raises the same three questions as any other machine identity. Who owns it, what can it do, and when does its access end?

What the incidents show

An old test application with real power. Microsoft disclosed that the actor it tracks as Midnight Blizzard compromised a legacy, non-production test tenant account that had no MFA, using password spraying. The actor then used a legacy test OAuth application that held elevated access to Microsoft’s corporate environment, created further malicious OAuth applications, and obtained access to corporate mailboxes. The weak point was not a person. It was an application identity that nobody had retired and nobody was watching.

A key that could reset passwords. Press reporting on the US Treasury Department breach says attackers used a stolen API key for a remote support vendor’s cloud platform to reset passwords on local application accounts, and then reached agency computers remotely through it. One machine credential did the work of a privileged administrator.

Tokens that outlive everything. Mandiant’s latest M-Trends report describes attackers harvesting long-lived OAuth tokens, and compromising third-party SaaS vendors to obtain hard-coded keys and personal access tokens that open customer environments. Its recommendations include routing SaaS through a central identity provider, enforcing least privilege and auditing SaaS integrations.

The pattern across these is consistent. A credential with no human attached, broad access and a long life is more useful to an attacker than most user accounts, and it triggers fewer controls.

Why people alone cannot manage this

• Scale. The population is too large and changes too fast for periodic review by managers.

• No natural owner. A person joins and leaves. A pipeline credential does neither, so no event prompts review.

• No lifecycle trigger. Nothing marks the end of the project that needed the account.

• Hidden dependencies. Teams are afraid to rotate or delete a credential because they do not know what will break. That fear keeps old credentials alive.

• Fragmented visibility. Each platform sees its own piece: the directory, cloud IAM, the secrets store, the code repository, the SaaS marketplace. Nothing joins them.

Where common tooling stops

Identity governance platforms were designed for employees. Privileged access vaults only protect the secrets someone has onboarded. Secrets scanners find some credentials in code, not those in SaaS-to-SaaS grants. Each tool covers part of the problem. The posture question, which identities exist and which could do the most damage, usually falls between them.

What good looks like

1. Discover continuously, from every source. Directory, cloud IAM, identity provider app registrations, secrets stores, code repositories, CI/CD systems and SaaS integrations.

2. Attach an owner and a purpose. A named person or team, a business reason and an expiry or review date for every identity. Unowned identities are the first ones to disable or investigate.

3. Shrink the estate. Remove what is unused. This is the cheapest risk reduction available.

4. Replace static secrets with short-lived, federated credentials wherever the platform supports it. Cloud providers offer managed identities and workload identity federation for this purpose. Where static secrets must remain, store them centrally, scope them narrowly and rotate them.

5. Limit what each identity can do. No application should hold organization-wide administrative roles because that was quicker to configure. Control who can grant consent.

6. Watch behavior. Alert when a machine identity is used from an unexpected network, calls APIs it has never called, or appears after long inactivity.

7. Prepare the response. Know how to find every use of a leaked key, revoke it and rotate dependents, before the day it leaks.

Trade-offs

• Rotating before you understand dependencies causes outages. Discover, assign owners and monitor first. Rotate and reduce after.

• Legacy applications often cannot use federated credentials. Isolate them, scope them tightly and monitor them harder.

• Ownership is partly a political problem. Platform teams, application teams and security will each hope another owns it. Decide the rule and enforce it.

• A secrets vault concentrates risk. Treat it as a top-tier asset.

Where humans decide and automation works

The title is the argument. People should decide who owns an identity, what risk is acceptable and which exceptions are justified. Automation should do the discovery, expiry, rotation and anomaly detection. Reversing that split, with people doing the inventory and tools making the risk decisions, fails on both counts.

A first posture assessment

Five questions give a usable picture without a large program:

1. How many machine identities do we have, and from which sources did we count?

2. Which of them can administer anything, in cloud, directory or SaaS?

3. Which have no named owner?

4. Which rely on static, long-lived secrets, and how old are those secrets?

5. Which can be used from any network, with no restriction on source?

Track these over time: share of identities with an owner, share using short-lived credentials, median credential age, count with administrative permissions, and time to revoke after exposure.

Sources

1. Microsoft Security Blog — Midnight Blizzard: Guidance for responders on nation-state attack

2. Google Cloud / Mandiant — M-Trends report, latest edition

3. BleepingComputer — US Treasury Department breached through remote support platform

4. NIST — SP 800-53 Rev. 5, Security and Privacy Controls (AC-6, IA-5)