Non-Human Identity on Linux

What Is a Non-Human Identity on Linux?

A non-human identity on Linux is any account, key, or credential that authenticates to a system without a person behind it — a service account that runs a daemon, an SSH key that lets one host reach another, an API token a script uses to call a controller. It is the machine equivalent of a user, and on a modern Linux estate there are far more of them than there are people.

The scale is easy to underestimate. Palo Alto Networks' 2026 Identity Security Landscape report puts the enterprise average at 109 machine identities for every human identity — up from 82:1 the year before — drawn from a survey of 2,930 cybersecurity decision-makers. On Linux specifically, those machine identities are not abstractions in a directory: they are files, entries, and processes scattered across every host, created by whoever installed the software and rarely tracked afterwards. Understanding them as identities — things that hold access and must be governed — is the first step toward controlling them.

And the gap is widening, not closing. The same report projects machine identities to keep growing faster than human ones over the year ahead, as automation, cloud workloads, and AI-driven agents each spin up credentials of their own. Every new pipeline, container image, and integration adds identities to the estate — almost always faster than any team retires the old ones.

Service Accounts, SSH Keys, Tokens and Agents

The machine identities on a Linux host wear several disguises, and each is managed by a different mechanism. Service accounts are ordinary system users — often created with a low UID, no login shell, and an entry in /etc/passwd — that own and run daemons such as nginx, postgres, or a custom application. They frequently hold group memberships and sudo rights that outlast the reason they were granted.

SSH keys are the connective tissue between hosts. A single authorized_keys file can grant a remote identity persistent, password-free access, and because keys are copied by hand during setup they accumulate in places no inventory records. Tokens and secrets — API keys, database passwords, cloud credentials — live in environment files, systemd units, and application config, granting access that never appears in any user list at all. Agents round out the picture: CI runners, configuration-management clients, monitoring collectors, and increasingly automated tooling that acts on the host under its own credentials. Every one of these is a non-human identity, and every one is a path an attacker can take if it is over-privileged or forgotten.

What makes these identities dangerous is not that they exist but that they are rarely retired. A credential created for a one-off migration, a key added to debug an incident, a token minted for a proof of concept — each is meant to be temporary, and each tends to survive indefinitely because nothing on the host forces a review. Containers and short-lived workloads add a further twist: identities appear and vanish on their own schedule, so a picture taken last quarter no longer describes what is running today. And the riskiest of them are often the quietest: a service account left with UID 0, or a NOPASSWD sudo rule added "just for now," grants full root without ever prompting for a credential — exactly the kind of standing privilege a review is supposed to catch and almost never does.

Why Directories Never See Them

Most organisations believe they already govern identity, because they run an identity provider — Active Directory, Okta, an LDAP tree — that holds every employee and enforces joiner-mover-leaver reviews. The problem is that almost none of the machine identities above are enrolled in it. A service account created by a package installer, an SSH key dropped into a home directory, a token pasted into a systemd unit — none of these are provisioned through the directory, so none of them appear in an access review.

The result is a governance blind spot precisely where the ratio is most lopsided. The identities your directory manages are the minority; the identities that actually hold root-equivalent access on your Linux fleet are the majority, and they sit outside the one system built to review access. Directory-centric IAM answers "who are our people and what can they reach" — it was never designed to answer "what non-person credentials exist on host 214, and should they."

Cloud and containerised estates make the blind spot worse. Instance roles, Kubernetes service accounts, and workload identities are provisioned by the platform, not the directory, and they inherit access the moment they start. A directory review that samples employees once a year has no visibility into a service account that was created, used, and destroyed between two of its checkpoints — yet that account may have held exactly the privileges an attacker needs while it lived.

Ownership and the Review Problem

The defining weakness of a machine identity is that no one owns it. A human account has a manager who can attest to it at review time; a service account has an application, a team that has since reorganised, and a comment in a runbook nobody has opened in two years. When an auditor asks who approved a credential's access and when it was last reviewed, the honest answer for most machine identities is that it has never been reviewed at all.

This is where compliance regimes and real risk converge. Frameworks from SOX ITGC to PCI DSS to the UK NCSC CAF all expect access to be granted deliberately, owned by someone, and reviewed on a schedule — and they make no exception for accounts that happen not to belong to a person. An orphaned service account with sudo, or an SSH key whose owner left the company, is both an audit finding and a standing invitation to lateral movement. Assigning a responsible owner to every credential, and re-checking that ownership regularly, is the control that closes the gap — but it is impossible until you can see the credentials in the first place.

The pattern shows up in real incidents. An attacker who lands on a single host rarely stops there; they look for a forgotten service account with broad sudo, or an SSH key that still trusts a decommissioned jump box, and use it to move sideways to the next system. Because the credential is legitimate and unowned, nothing flags the activity as unusual. The identities no one is watching are precisely the ones that turn a contained foothold into a fleet-wide compromise.

Discovering Non-Human Identities on a Linux Estate

Because these credentials are not in a directory, discovery has to happen on the hosts themselves. That means enumerating the system and service accounts in /etc/passwd, the privileged group memberships in /etc/group, the sudo grants in /etc/sudoers and /etc/sudoers.d, and every authorized_keys file across the fleet — then correlating those findings into a single picture of which non-person credentials hold which access on which hosts. Done by hand across a representative estate of 412 servers, this is a project that is stale before it finishes.

The workable answer is continuous, host-level discovery: agents that inventory accounts, keys, and privileges on every Linux host, reconcile them against a known-good baseline, and surface any change — a new service account, an added SSH key, a fresh NOPASSWD sudo rule — within about 60 seconds of it appearing. That turns an unknowable population of machine identities into a live, ownable inventory, and turns access review from an annual guess into something you can actually evidence.

Evidence is what separates a controlled estate from a hopeful one. For each non-human identity an auditor — or an incident responder — wants to answer three questions: what access does it hold, who is accountable for it, and when was that access last confirmed as still needed. A live inventory that records those answers, and the history of every change to them, turns "we think that account is fine" into a defensible record. It also shortens investigations, because the first question after any alert is which identity acted and what it was allowed to do.

For a fuller treatment of how this maps to regulatory obligations, see the Linux access controls evidence guide, which walks through the access-control expectations of NIS2, DORA, and the EU AI Act for IT teams.

FAQ

What counts as a non-human identity on Linux?

Any credential that authenticates without a person behind it: system and service accounts in /etc/passwd, SSH keys in authorized_keys files, API tokens and secrets in config or systemd units, and automated agents such as CI runners and monitoring collectors. Each holds access to a host, which is why each must be governed like a user account.

Why don't machine identities show up in our identity provider?

Active Directory, Okta, and LDAP govern the people your organisation provisions through them. Service accounts, SSH keys, and tokens are created directly on hosts by installers, engineers, and scripts, so they are never enrolled in the directory. They hold real access but sit outside the one system built to review it, creating a governance blind spot.

How many machine identities does a typical organisation have?

Palo Alto Networks' 2026 Identity Security Landscape report puts the enterprise average at 109 machine identities for every human identity, up from 82:1 the prior year. On a Linux estate those identities are spread across every host as accounts, keys, and tokens, which is why they so often outnumber and outlast the people who created them.

How do you find non-human identities across a Linux estate?

Discovery has to happen on the hosts, not in a directory: enumerate service accounts, privileged group memberships, sudo grants, and every authorized_keys file, then correlate them. Continuous host-level agents make this practical by inventorying each host against a baseline and flagging any new account, key, or sudo rule within about 60 seconds.