Non-Human Identity Management: Service Accounts, Machine Identities and Secrets

Ask most organizations how many employees they have and the answer arrives immediately. Ask how many service accounts they have and the answer is usually a pause, followed by an estimate, followed by a discovery scan that returns a number several times higher than the estimate.

This is the central problem with non-human identities. In most environments they already outnumber human users, they frequently hold broader access, and they are almost never reviewed. They are the least governed layer in the estate, and increasingly the layer attackers reach for — because a credential that never expires and that nobody watches is a better foothold than a user account with MFA.

What counts as a non-human identity

The category is broader than service accounts, which is part of why it goes ungoverned — different types are owned by different teams, and no single team sees the whole population.

• Service accounts. Accounts that run applications, scheduled tasks, integrations and database connections. Often created during a project, rarely retired after it.
• API keys and tokens. Credentials issued for system-to-system access, frequently embedded in code, configuration files or CI pipelines.
• Certificates. Machine identities that establish trust between systems, with the added failure mode of expiring at inconvenient moments.
• Cloud workload identities. Roles and identities assigned to compute resources, functions and containers, which can be created programmatically at a rate no manual process can track.
• AI agents and automation. The newest category, and the fastest growing. Agents that act on behalf of users need credentials and permissions, and most organizations have not decided who owns them.

Why they escape governance

Human identity management works because there are events to hang it on. Someone is hired, changes role, leaves. HR systems generate those events, and joiner-mover-leaver automation reacts to them.

Non-human identities have no equivalent. Nothing tells you an integration was decommissioned. Nobody files paperwork when a script is retired. The credential simply remains, valid and unused, until someone finds it.

Three specific gaps follow from that:

No owner. The engineer who created the account has moved teams. Because nobody can confirm what the account does, nobody is willing to disable it. This is why discovery scans find accounts that have not authenticated in years and are still enabled.

No lifecycle. Creation is easy and often self-service. Retirement has no trigger. The population only grows.

No review. Access certification campaigns are built around asking a manager to attest to a person’s access. Presented with a service account, most reviewers have no basis to judge and approve it — which is worse than not reviewing it, because now it carries an audit stamp.

The result compounds: over-permissioned accounts, credentials that have never been rotated, and shared secrets that multiple systems depend on so nobody dares change them.

What getting control actually looks like

Discover first, and expect to be surprised. You cannot govern a population you have not counted. Discovery across directories, cloud platforms, databases and CI systems is the necessary starting point, and the number it returns is usually the argument for funding the rest of the work.

Assign ownership before anything else. Every non-human identity needs a named human owner — not a team alias. This is the step organizations most often skip, and without it every subsequent control stalls, because nobody can approve a change.

Vault and rotate the credentials. Static credentials sitting in configuration files are the highest-value target in most environments — a credential that never expires is standing privilege by another name. Moving them into a vault with automated rotation removes an entire class of risk. This is core privileged access management work and the platforms handle it well.

Apply least privilege deliberately. Service accounts are routinely over-permissioned because broad rights were the fastest way to make something work during a deployment. Reviewing what they actually use, rather than what they were granted, usually allows significant reduction.

Build a retirement trigger. Since no event tells you an identity is obsolete, you have to manufacture one: periodic attestation by the owner, automated flagging of dormant credentials, or tying identity lifecycle to the system it serves.

Where it fits alongside your existing program

Non-human identity is not a separate product category so much as a gap that falls between two existing ones. Privileged access management handles the credentials — vaulting, rotation, session control. Identity governance handles the lifecycle — ownership, entitlement review, retirement. Neither covers it fully by default, and most implementations of both quietly exclude non-human accounts from scope.

That exclusion is usually deliberate and reasonable at the time: service accounts are complex, breaking one takes down a production system, and phase one has a deadline. The problem is that phase two rarely arrives. If your PAM or IGA program scoped out non-human identities, that decision is worth revisiting now rather than at the next audit.

For a practical starting point on the largest slice of the problem, our service account management work covers discovery through to retirement. If you do not yet know the size of your non-human population, a free identity audit will tell you — and that number is usually the thing that moves the conversation.