Eighty machine identities per human, and not one has a signature behind it
The non-human identity category has converged on a metric — the ratio of machine identities to humans — and a remedy — discovery and rotation. The metric is real. The remedy addresses inventory and leaves the question of accountability entirely untouched.
Does any of your machine identities have a human behind it?
Apply the test: pick one, find the owner field, and see whether it names a person who still works there and can say why it exists. Most non-human identity programmes end with a spreadsheet of thousands of identities whose owner field holds a team name, a departed employee, or nothing.
- 2026 research put NHI-to-human ratios between 45:1 and beyond 100:1, and reported ratios differ by more than tenfold because each vendor counts a different population.
- Every NHI programme discovers identities whose owner field is populated. Populated is not the same as accountable, and the sector's metrics do not distinguish them.
- Five properties separate ownership metadata from ownership evidence, and most estates satisfy one of them.
Part of Machine and signing identity
Read the ratios carefully before using them
2026 research produced a range of figures: one vendor reported NHI-to-human ratios of 45:1 from its telemetry, another reported machine identities outnumbering humans 80:1, and a 2026 identity outlook reported organisations citing machine-to-human ratios of 100:1 with some reaching 500:1. A separate analysis found that a large majority of active production identities in monitored cloud environments were non-human.
Those figures differ by more than an order of magnitude, and they are not in conflict. Each counts a different population: some count cloud workload identities, some count every credential in a secrets manager, some count service principals in a directory. A ratio without a counting rule is a headline rather than a measurement.
What survives all of them is directionally unambiguous: machine identities vastly outnumber humans, and the gap is widening as AI services proliferate.
Why discovery is not the answer it appears to be
An NHI programme follows a predictable arc. Deploy discovery, produce an inventory, find far more identities than expected, prioritise by privilege, rotate the worst offenders, and report coverage to the board.
Every step is worthwhile. At the end, the organisation knows what exists and has reduced credential age. What it still cannot do is answer the question that every incident starts with: who is accountable for this identity?
An inventory tells you what exists. It does not tell you who should be answering the phone about it.
Populated is not accountable
NHI tooling reports owner-field coverage as a maturity metric. It is the wrong metric, and the substitution is worth making explicit.
| Owner field content | Counts as covered? | Actually accountable? |
|---|---|---|
| A team distribution list | Yes | No — no individual is answerable |
| A departed employee's name | Yes | No |
| The name of whoever ran discovery | Yes | No |
| A manager two reorganisations removed | Yes | Unlikely |
| A named engineer who created it and still owns it | Yes | Yes |
Four of five rows count as covered in a maturity report. One is evidence.
The Accountable Ownership Test
Five properties. Run it against a sample of fifty identities and count how many satisfy all five.
- Named individual. The owner is a person, not a team, a queue or a system.
- Affirmative act. The owner did something to become the owner — signed for it — rather than being assigned by a script.
- Scope stated. The record says what the identity is authorised to do, not merely that it exists.
- Expiry. The ownership lapses and must be renewed, so it decays visibly rather than silently.
- Externally verifiable. Someone outside the platform — an auditor, an incident responder — can confirm it without trusting the platform's own database.
Most estates satisfy the first property and none of the others. That is the finding worth taking to a steering committee, and it costs an afternoon to produce.
Why the owner field decays
Machine identities are created as a side effect of building systems. A pipeline needs a token, an integration needs a key, an agent needs a credential. Creation is an engineering act inside a platform, not an authorisation act by a principal.
Ownership metadata is captured once, at creation, as free text. It then decays at the rate of organisational change — reorganisations, departures, team splits — which in most engineering organisations is faster than any rotation cycle.
The issuance receipt
The fix is to make creation an authorisation act.
{
"type": "manav-stmt/1",
"action": "machine_identity_issued",
"identity": "[principal identifier]",
"purpose": "[what it exists to do]",
"scope": "[permissions granted]",
"systems": "[what it can reach]",
"notAfter": "[expiry]",
"owner": "[named individual, credential assertion]"
}Now ownership is an act with a signature and an expiry. When the owner leaves, their identities surface as a query rather than as an archaeology project, and the renewal cycle forces a periodic decision rather than permitting silent decay.
Where this connects to the breach data
Verizon's 2026 breach analysis attributed roughly 48% of breaches to third-party and supply chain paths. A substantial share of those paths run through machine identities — integration credentials, service accounts, tokens held by a vendor.
An organisation that cannot name an accountable owner for those identities cannot make a decision about them quickly during an incident, which is when the decision matters.
The three-question test
| Question | Pass condition |
|---|---|
| Does the owner field name a person? | Not a team, not a mailbox |
| Does that person still work here? | Check the directory |
| Can they say why it exists? | Without research |
A programme that passes all three on ten random identities is in good shape. Most fail on the first, and almost all fail on the third — which is the one that matters, because an owner who cannot explain an identity cannot decide whether to remove it.
Objections and honest limits
“Rotation is the priority.” Rotation improves hygiene and changes nothing about accountability. A rotated secret for an identity nobody can explain is a fresh secret for an unexplained identity.
“Teams are the right owner for shared services.” Teams reorganise, and a team name in an owner field is a way of recording that nobody in particular is responsible. Name a person and let them delegate.
Establishing accountable ownership
- Run the three-question test on ten at random. It takes an hour and sets the baseline.
- Require a named person, never a team. With an explicit successor on departure.
- Require a stated purpose at creation. Written by the creator, not inferred later.
- Expire identities without an accountable owner. Rather than carrying them forward indefinitely.
Terms used here
- Non-human identity
- A service account, workload identity, API key or agent credential — outnumbering human identities by an order of magnitude.
- Accountable owner
- A named person who can explain why an identity exists and decide whether it should continue.
- Orphaned identity
- One whose owner has departed or whose purpose is unknown — the majority in most estates.
Frequently asked questions
Which NHI ratio should we use? Your own. Count the population you care about — identities with write access to production, for instance — and report it with the counting rule stated. Published ratios are not comparable to each other.
Does this replace discovery tooling? No. You cannot assign ownership to identities you have not found. Discovery is the prerequisite and this is the step after it.
What about identities created by automation? The automation runs under a delegation issued by a human, and identities it creates inherit that chain. The accountable human is the one who authorised the automation's scope.
How long should ownership last before renewal? Short enough that decay is caught — typically six to twelve months — and long enough that renewal does not become a rubber stamp, which is its own failure mode.
What is the three-question test? Does the owner field name a person, does that person still work here, and can they say why the identity exists without research.
Why is rotation not enough? It improves hygiene. A rotated secret for an identity nobody can explain is a fresh secret for an unexplained identity.
Why not let teams own identities? Teams reorganise. A team name in an owner field records that nobody in particular is responsible.
Where this fits in Manav
Manav anchors every machine and agent identity to a named human through a signed delegation with scope, expiry and enforced revocation — so the chain from an action to a person survives the identity outliving its creator.