Zombie Accounts: The IAM Blind Spot in Offboarding

6 Min. Read Time

A microservice is shut down, the documentation archived, and the team moves on. The service account it ran on remains active, with rights that no one oversees anymore. OWASP calls this exactly the number one blind spot in machine identities, and attackers have long known this.

Key Takeaways

Machines outlive their offboarding: Service accounts, API keys, and workload identities remain active long after the associated service is gone. For humans, there is an HR process; for machines, there usually isn’t.
OWASP ranks it number one: In the Non-Human Identities Top 10, Improper Offboarding is listed as risk NHI1. Orphaned identities are a preferred path for lateral movement in practice.
The lever is a lifecycle: Whoever inventories machine identities, assigns an owner, and ties them to the service’s lifespan closes the gap before the AI wave further increases the number of accounts.

Why Machine Accounts Outlive Their Own Demise

When an employee leaves the company, a process kicks in. The HR department reports the departure, the account is deactivated, and permissions are revoked. For human identities, this process is well-established, even if it doesn’t always work smoothly. For machine identities, it often doesn’t exist in many organizations.

What is a machine identity? It is everything with which a system authenticates instead of a human: service accounts, API keys, tokens, certificates, or the identity of a workload in the cloud. These accounts are created incidentally when a service is set up. However, they don’t disappear incidentally when the service is shut down. Shutting down affects the code and infrastructure, rarely the identity with which both ran.

Exactly here is where OWASP comes in. In the Non-Human Identities Top 10 from 2025, Improper Offboarding ranks number one, ahead of secret leakage and over-privileged accounts. The definition is straightforward: the insufficient deactivation or removal of machine identities when they are no longer needed. Behind the straightforward formulation lies a practical problem. No one feels responsible for shutting down an account whose existence they are not aware of.

In practice, such an account is created in seconds and survives for years. A developer sets up a service account for an integration, deposits an API key in the pipeline, and the job runs. When the integration is later replaced, the team takes care of the new path, not the trail left behind by the old one. The key remains valid, the account remains authorized, and both appear in no exit process because there is no exit for a machine. Over time, layers of identities accumulate that no one can assign a purpose to anymore.

How a Forgotten Account Becomes an Attack Path

An orphaned service account is not a theoretical risk. It’s a valid identity with valid rights that no longer receives attention. For an attacker, this is the ideal starting point. Anyone who takes over such an account moves through the network without triggering an alarm, because the account is legitimate and its activity is no longer monitored.

This situation is exacerbated by two additional points on the OWASP list, which rarely occur alone. Long-Lived Secrets, i.e., access data without an expiration date, keep an orphaned account usable indefinitely. Overprivileged machine identities grant it more rights than the original service ever needed. Both together turn a forgotten account into a comfortable location for lateral movement, i.e., the lateral movement from one compromised system to the next.

The difference from human identity is fundamental, and it explains why established offboarding routines do not apply here.

Aspect	Human Identity	Machine Identity
Trigger for Offboarding	Departure, reported by HR	Service shutdown, often unreported
Owner	The person themselves plus supervisors	Often unclear or orphaned
Lifespan of Credentials	Linked to employment	Often without an expiration date
Visibility after Termination	Account deactivated, access blocked	Remains active, usage appears legitimate

The Second Pitfall: When Humans Use Machine Accounts

There is a variant of the problem that is less frequently discussed and listed as NHI10 on the OWASP list: Human Use of NHI. This refers to the case where an administrator uses a service account for a manual task because it is readily available and has the necessary rights. At the moment, this saves time. Afterwards, the audit trail is compromised, and an account with often extensive machine rights lies uncontrolled in human hands.

Documentary photo of an unattended machine account in a server room - an attack path without alarm. — Forgotten accounts silently open the door to the network for attackers.

As soon as a human action runs under a machine identity, it is no longer possible to cleanly separate what was automated and what was triggered by a person. For the forensic analysis of an incident, this is a real problem. Exactly at the moment when a clear trail is needed, privileged machine and human activity mix in a single log. In hybrid environments with shared admin accounts, this reflex is still everyday, while oversight and regulation demand traceable tracks.

What a Clean NHI Lifecycle Needs

None of these gaps require a new product. They demand a lifecycle that human identities have long had. Three building blocks make up the largest part.

The first is an inventory. You can’t shut down what you don’t know about, and in most organizations, there is no complete list of active machine identities. The second is ownership. Each machine identity needs a responsible person or team; otherwise, the underlying problem repeats itself with every shutdown. The third is linking to the service lifecycle. When a service is discontinued, its identity must be deactivated in the same step, not in a later one that never comes.

The pressure on this topic is growing because the number of machine identities with AI agents and automated pipelines is increasing faster than any manual offboarding routine. If you only set up the lifecycle when the accounts are already unmanageable, you first have to clean up what has long since become overgrown. Starting now is significantly cheaper than later.

Frequently Asked Questions

What is a Machine Identity?

A machine identity, often referred to as a Non-Human Identity, is anything that authenticates a system instead of a human: service accounts, API keys, tokens, certificates, or the identity of a workload in the cloud. It enables services to communicate with each other and with resources.

What does Improper Offboarding mean for Machine Identities?

Improper offboarding describes the inadequate deactivation or removal of a machine identity when it is no longer needed. OWASP lists it as risk NHI1, i.e., in first place, in the Non-Human Identities Top 10 of 2025.

Why are Orphaned Service Accounts so Dangerous?

They are valid identities with valid rights that no one monitors anymore. An attacker who takes over such an account moves through the network without triggering an alarm because the activity appears legitimate. This makes orphaned accounts a preferred path for lateral movement.

How do I Find Orphaned Machine Identities?

The first step is an inventory of all active machine identities, including the associated service and owner. Identities without a recognizable active service or without an owner are the first candidates for examination and deactivation.

What does AI have to do with the Problem?

AI agents and automated pipelines generate new machine identities at a high rate. As a result, the number of accounts grows faster than manual offboarding processes can keep up, and the blind spot increases if no lifecycle is established.