Governing Non-Human Identities: The Population Nobody Owns

Walk into most enterprises and ask who owns the service accounts. You will get silence, or a shrug, or a name of someone who left two years ago. Non-human identities (NHIs) — service accounts, application identities, API keys, OAuth tokens, certificates, workload identities — now vastly outnumber human users, often by an order of magnitude, and they are governed with a fraction of the rigour. That asymmetry is one of the clearest emerging risk classes in identity security.

Why NHIs are more dangerous than human accounts

A non-human identity typically has three properties that make it a prized target: it is often highly privileged (automation needs broad access), it is long-lived (rotating its credential might break a production pipeline, so nobody dares), and it is unmonitored (no one notices a service account behaving oddly the way they'd notice a human logging in at 3am). Privileged, persistent, and unwatched is the exact profile an attacker wants.

Every NHI needs a human owner

The foundational control is also the one most often missing: every non-human identity must map to an accountable human owner. Not a team mailbox — a person who can answer "what is this for, what should it access, and can we rotate or retire it?" Ownerless NHIs are the orphans that survive every clean-up because nobody dares touch what they don't understand. An NHI register with enforced ownership is step one, and it is harder than it sounds because discovering them all is genuinely difficult.

Right-size privilege and lifecycle

NHIs accumulate privilege the same way humans do — granted for a task, never revoked — but worse, because no joiner-mover-leaver process touches them. Apply the same discipline: least privilege scoped to what the workload actually does, regular review of whether the NHI is still needed, and a defined decommissioning path when the application it serves is retired. The dormant service account for a system you turned off last year is a live credential into your environment.

Secrets management and rotation

The credentials NHIs use — keys, tokens, certificates — belong in a managed secrets store, not in config files, code repositories, or someone's notes. And they must rotate. The fear of rotation breaking production is exactly why long-lived NHI credentials are so dangerous; the fix is automation that rotates secrets without human intervention and without downtime. Where the platform supports it, prefer short-lived, dynamically-issued credentials over static secrets entirely — a token that expires in an hour is a far smaller prize than a key that's been valid since 2021.

Human IAM is a mature discipline; non-human identity governance is roughly where human IAM was fifteen years ago. The organisations that get ahead of it — discovery, ownership, least privilege, lifecycle, rotation — will avoid a breach class that is going to define the next several years of incident reports.