Non-human identity (NHI)

What is a non-human identity?

A non-human identity is a login that belongs to a piece of software instead of a person. The service account connecting your ERP to the webshop, the API key inside a nightly refresh, the certificate on a machine in the workshop, the token a deployment pipeline signs in with, the RPA bot that types invoices into the accounting package: each of those authenticates, carries permissions and turns up in a log under its own name.

The Cloud Security Alliance draws the line at what the thing can do rather than what it looks like. Something counts as a non-human identity when it can authenticate, prove who it is, and be authorised to reach a resource. Their July 2026 breakdown sorts them into service and integration accounts, workload and microservice identities, infrastructure identities for virtual machines and cloud instances, device identities for sensors and hardware, and agent identities for autonomous AI systems.

Microsoft cuts the same group a little differently. In Entra, workload identities are applications, service principals and managed identities, device identities sit beside them, and together they are what Microsoft calls machine or non-human identities.

The working test is shorter than either list. If it has a password, a key or a certificate, and it is not a colleague, it is a non-human identity.

Why there are far more of them than staff logins

In a May 2026 paper on identity governance and AI agents, the Cloud Security Alliance put the average at around forty-five non-human identities for every human user, and above a hundred to one in cloud-native environments. The exact multiplier matters less than the direction. You almost certainly have several times more of these than you have people.

The reason sits in how they get made. A person joins through HR, signs something, gets a mailbox and lands on a list. A non-human identity gets made by whoever is building the integration, halfway through a project, at the moment it is needed. It has no contract, no manager and no start date that anyone wrote down. Every SaaS tool you connect and every split between test and production adds another one, and none of them ever resign.

What makes them the weakest link

OWASP published a Non-Human Identities Top 10 in 2025. Read the ten entries together and the pattern is that almost nothing you rely on for staff accounts applies here.

The secret is the whole identity. There is no second factor behind an API key. Whoever holds the string is the identity, which is why leaked secrets sit near the top of the OWASP list.

The secret never changes. Long-lived secrets get an entry of their own, with figures showing most cloud keys are more than a year old and about half of organisations have no formal way to revoke one at all.

One identity does five jobs. Reuse across services means a single leak reaches everything that credential touches, and it takes away your ability to rotate, because you no longer know what would break.

Nobody owns it. OWASP calls the result improper offboarding: dormant services whose accounts stay active, and identities left orphaned when the person who created them moved on. No leaver process catches them.

People sign in with it. A developer who debugs through the service account is logged as the service account. The action is real, the accountability is gone, and any restriction on their own login is skipped.

Two ordinary situations show what those five points look like on a normal Tuesday.

A webshop link was built in 2021. The integration user in the ERP got broad rights so the project would not stall, the password went into a configuration file, and the project closed. Five years later the webshop runs on a different platform and the old link is switched off, but the account is still enabled with the same password and the same rights over orders and customers.

One API key drives five scheduled refreshes and a nightly export. The key ends up in a public repository. The logs cannot tell you which of the six was abused, because all six are the same identity, and you cannot rotate the key on Friday without finding out on Monday which reports stopped.

A non-human identity versus a human account

The two need different controls, and the gap shows up on three dimensions.

Second factor. A person can approve a prompt on their phone. A service account cannot, so multi-factor authentication is not available to it and the stored secret is the entire defence. The protection has to come from elsewhere: a credential that lives minutes instead of years, a rule about where the identity may sign in from, or a platform identity with no stored secret at all.

Joiners, movers and leavers. A human account rides on an HR process. Someone starts, someone changes role, someone leaves, and access follows. Non-human identities have no such trigger, which is why OWASP puts a review of the associated identities inside the employee offboarding procedure: check which ones the leaver created, hand over ownership, rotate the credentials.

Session expiry. A person's session times out and they sign in again without thinking about it. A machine credential is built to keep working unattended, so an ending is something you design in: a token measured in minutes, a certificate with a real expiry date, a key with a rotation job behind it.

What good looks like

1. One identity per workload. Every integration, pipeline and bot gets its own. This is what lets you read a log, remove a permission or rotate a key without holding your breath.

2. Short-lived credentials, or none. Managed identities and workload identity federation exist so a pipeline or a container can authenticate without a key in a configuration file. Where you do need a key, give it an expiry date.

3. An owner and an end date. The owner is a named person, because a team is nobody. The end date is the answer to a question that otherwise never gets asked.

4. Least privilege from the first day. Broad rights handed out to unblock a project never come back, because by then nobody can say what still depends on them.

5. A list you can open, and rotation nobody has to remember. Which identities exist, what each is for, who owns it, when it was last used. A rotation schedule that depends on memory stops after the second time.

Where AI agents change the picture

An AI agent is a non-human identity, so everything above already applies to it. Three things make it harder than a service account.

They get created by people who do not build software. A colleague in finance can wire up an agent in an afternoon without asking anyone, which is the same route by which shadow AI arrives. The identity behind it still lands in your tenant.

You cannot size the damage in advance. The Cloud Security Alliance describes agents acquiring permissions at runtime, spawning sub-agents, calling external APIs, writing and running code, and chaining actions together. Their conclusion is the part worth keeping: how far an agent credential can reach cannot be established at the moment you issue it.

Ownership is missing more often here than elsewhere. In that same paper, about half of organisations report no clear ownership of their AI identities, and a smaller share do not track when new ones get created.

Giving an agent a login of its own is what the agent identity entry covers, and the tooling that fronts a whole fleet of them is the agent control plane. The category question comes first though. If the ERP integration user sitting next to the agent has no owner either, the agent is not your biggest problem.

Where to start in a smaller company

None of this needs a platform. It needs a list, and an afternoon.

1. Open the user list of the systems that hold real money or real data. ERP, accounting package, webshop, bank connection, CRM. Mark every account that is not a person. The names give themselves away: api, integration, admin2, the name of a supplier, the name of someone who left.

2. Put a person next to each one. A team is not an owner and neither is IT. Write down what the identity does, and where nobody can say, disable it at a quiet moment and see who calls. That is cheaper than finding out from a breach report.

3. Give each one a review date, and split anything shared. Start with the credential the most systems depend on, since that is also the one you cannot rotate today.

4. Ask each vendor whether the stored key can be replaced. An awkward number of integrations already support a platform identity or an expiring token, and nobody switches over because the old key still works.