Non-human identity
In identity security, a non-human identity is an account used by software rather than by a person: a service account, a workload identity, an API key, an automation credential or an autonomous agent. In most estates these now outnumber human accounts, and they have no manager, no starter form and no leaving date.
How it works
They come in several shapes with very different properties. A directory service account is an ordinary account with a password, which is why it is subject to kerberoasting. A cloud workload identity attaches a role to a running resource so credentials are issued dynamically and never stored. A static API key or client secret is a bearer credential in a configuration file. A federated workload credential lets a workload in one platform present a short-lived assertion to another and receive temporary credentials, which is the pattern that removes long-lived secrets entirely.
The direction of travel is from stored secrets to issued ones, and it matters because most of what we recover on engagements is a stored secret that has been valid for years.
What goes wrong
Nobody owns them. A human account has a manager who will notice when the person leaves; a service account has a closed ticket from a project that ended years ago. So they are not reviewed, not rotated, not disabled, and they accumulate permissions because the fastest way to fix a broken integration at midnight is to grant more.
Then there is where the credential lives. Committed to a repository, baked into a container image layer, present in a build variable that is printed to a log, embedded in a mobile application, or sitting in a configuration file readable by everyone on the host. A long-lived access key is the single most useful thing we find in a cloud engagement, because it is valid, it is not rotated and it is often extremely privileged.
The 2026 version of the problem is agents: automation that authenticates on a user’s behalf and holds delegated permissions across several systems, frequently broader than any individual needs and with no session an administrator would recognise. That is a governance question with an IAM answer, and most estates have not asked it yet.
Where this shows up in an audit
We enumerate machine identities and resolve their effective permissions, then we look for the credential in the places credentials leak rather than in the vault. The finding names the identity, where the credential was found, when it was issued, and what it could reach, since age is usually the most persuasive number in the report. The recommendation is normally federation and short-lived credentials rather than better storage for the long-lived ones. This is part of how we enumerate machine identities and their effective reach.