CyberArk's identity research puts machine identities at roughly 82 per human. Other published figures for the same measure range from 45 to 1 up to 144 to 1, which tells you the field has not agreed what counts as one identity.
Ignore the ratio. The finding underneath it is the one that matters: 88% of respondents said the word privileged applies only to human identities, while 42% of machine identities hold privileged or sensitive access.
That is not a tooling gap. It is a vocabulary gap, and no product fixes it.
What actually happens when you buy first
The pattern is consistent enough to predict.
A discovery tool goes in. Within a week it produces a number, usually in the thousands, that shocks whoever asked for it. The number goes in a board update. Then the work starts, and the work is not technical.
Somebody has to decide who owns a service account created in 2021 by an engineer who left in 2023, used by a job nobody can name, holding write access to a production bucket. The tool cannot answer that. It can tell you the key exists, when it was last used, and what it can reach. It cannot tell you whether the job matters, and it certainly cannot tell you who should be woken up if you rotate the credential and something stops.
Multiply by eleven thousand. That is the actual project, and it is roughly nine parts organizational to one part technical.
Why the count is not the problem
Every conversation in this category starts with a number, and the number is a distraction that costs organizations a year.
Counts are large because modern platforms mint identities cheaply, which is a good architectural property. A system issuing a fresh short-lived credential per workload will report a far higher number than one using three shared long-lived keys, and the second is dramatically more dangerous. A count optimizes toward the worse architecture.
What matters is the intersection of three properties: the credential is long-lived, it has meaningful reach, and nobody owns it. That population is almost always small. In estates where I have seen the exercise actually done, the genuinely dangerous set is dozens, not thousands, and it is findable in a couple of weeks once the question is framed that way.
Framing it as a count problem is what produces the eleven-thousand-row spreadsheet that nobody acts on. Framing it as an ownership problem with a reach filter produces a list somebody can work through by Friday.
The short answer
Three decisions before any purchase.
Decide what counts as one identity. A container token, a certificate, a service principal, and an API key are not the same object, and treating them as one population produces a count nobody can act on. Pick a definition, write it down, and accept it will be wrong at the edges.
Decide the ownership rule. Not who owns each identity, which is the discovery work. The rule: does ownership follow the workload, the team, the repository, or the cost centre? Every organization has a natural answer already implied by how it does on-call, and the identity rule should match it rather than inventing a parallel structure.
Decide the default for the unclaimed. What happens to an identity with no owner after ninety days? Options are disable, rotate and monitor, or accept with a documented exception. There is no right answer, but an organization without a stated default accumulates orphans forever, because nobody wants to be the person who broke production.
Make those three decisions and the tool becomes useful in month one. Skip them and the tool produces a number that stays in a slide for two years.
The five categories, because they need different answers
Treating non-human identity as one population is the reason programs stall. These behave differently enough that a single policy fails all five.
Human-created service accounts. A person made it, usually years ago, usually for a job that may or may not still run. Highest orphan rate, lowest automation. This is the category the ownership rule is actually for.
Platform-issued workload identities. A container gets a token, a function assumes a role, a pod has a service account. Created and destroyed automatically, often thousands per day. Governing these individually is meaningless. Govern the template that mints them and the permissions it grants.
Integration credentials. API keys held by a software-as-a-service product to reach your systems, or by yours to reach theirs. Frequently invisible to both identity and security, because they live in a vendor's configuration screen. This is where third-party breach exposure actually sits.
Machine certificates. TLS, code signing, mutual authentication. A separate lifecycle problem with its own tooling and its own failure mode, which is expiry causing an outage rather than compromise causing a breach.
Agent identities. New, growing fastest, and structurally different because an agent takes actions that were not specified in advance.
Five categories, five owners, five lifecycles. A program that writes one policy covering all of them has written a policy that engineering will ignore, correctly, because it does not describe what they actually operate.
The discriminating variables
Do you have an asset inventory that identities can attach to?
The test: can you name the owning team for a randomly chosen production service? If not, identity ownership has nothing to attach to and the identity project will end up doing the service inventory project first, at three times the cost and under the wrong budget line.
Is the secrets problem separable?
The test: are most of your unowned credentials long-lived static secrets, or short-lived issued tokens? A static secrets sprawl problem is often better solved by a vault rollout and a rotation policy than by a governance program. Short-lived workload identity is the case where governance is the only lever.
Who signs off, and can they?
The test: name the person who can decide to disable an unowned production credential. If that person is you and you have no operational authority over the services affected, the program has no enforcement path and will stall at the inventory stage.
Decision table
| Situation | Do this first | Not this |
|---|---|---|
| No asset inventory | Service ownership map | Identity discovery |
| Static secrets everywhere | Vault and rotation | Governance tooling |
| Cloud-native, short-lived tokens | Ownership rule, then discovery | A policy document |
| Audit finding on service accounts | Discovery scoped to the finding | A platform purchase |
| AI agents appearing in production | Authorization rule for agents | Waiting for an agent tool |
What ninety days of real work looks like
Sequenced, because the ordering is what most programs get wrong.
Weeks 1 to 2: pick one category and one environment. Human-created service accounts in your primary cloud account is the usual right answer, because it has the highest orphan rate and the clearest ownership question. Resist the pull toward completeness.
Weeks 3 to 4: write the three decisions. What counts as one identity, how ownership is assigned, and what happens to the unclaimed. One page, circulated to engineering leadership for objection rather than approval. Objections here are cheap and objections in month six are not.
Weeks 5 to 8: enumerate, in that scope only. Cloud provider console, infrastructure-as-code repositories, and the identity provider. You do not need a product for this at one-environment scope, and doing it manually the first time teaches you what the product would need to do.
Weeks 9 to 10: assign what is assignable. Expect to name owners for sixty to eighty percent quickly, because the workload is recognizable. The remainder is the real project.
Weeks 11 to 12: apply the default to the rest. Whatever you decided in week three. Disable with a fast reinstate path is the most common workable answer, and the reinstate path is what makes it politically survivable.
Ninety days, one scope, a written rule, and a defensible number. That is a program you can extend. Twelve months of enterprise-wide discovery producing an eleven-thousand-row spreadsheet is not, and the second is what happens by default when the tool arrives first.
What the tool is actually good for
None of this is an argument against buying one. It is an argument about ordering, and the tools do things the manual approach cannot.
Continuous discovery. A manual enumeration is accurate on the day you do it. Non-human identities are created constantly, and by month three your spreadsheet is wrong in ways you cannot see.
Last-used telemetry. This is the single most valuable thing these products provide and it is very hard to assemble by hand across providers. An identity unused for ninety days is a different decision from one used hourly, and that distinction is what makes the unclaimed pile tractable.
Reachability analysis. What can this credential actually get to, accounting for role chains and trust relationships. Nobody computes this correctly by hand, and it is what separates a critical orphan from a harmless one.
So the sequence is not "governance instead of tooling". It is: decide ownership rules, enumerate one scope by hand to learn the shape, then buy the tool with a clear view of which of those three capabilities you are actually paying for.
What changes the answer
A live audit finding. If an auditor has already named service accounts, scope discovery narrowly to what the finding covers and do the ownership work only there. A finding-scoped project ships. An enterprise-wide one does not.
Agents in production. An AI agent with credentials is a non-human identity with a novel property, which is that it takes actions nobody explicitly requested. The ownership question becomes harder and more urgent at the same time, which is why this desk treats agent authorization as its own decision rather than a subsection of this one.
Under fifty engineers. The ownership rule can be a spreadsheet and a quarterly review. Buying a governance platform at that size funds a category of work that does not exist yet.
The metric that tells you it is working
One number, tracked quarterly: the share of non-human identities in scope that have a named human owner.
Not the total count, which goes up forever and measures architecture rather than governance. Not the number of unused credentials found, which is a one-time discovery figure. Ownership coverage, in a defined scope, over time.
It works because it is the thing the whole program is for, it moves in response to actual work, and it is honest about scope in a way that a total count is not. A program reporting "we have 11,000 non-human identities" has said nothing. A program reporting "84% of service accounts in the production account have a named owner, up from 61% last quarter" has said everything, including how big the remaining problem is.
What to do Monday
Pick ten service accounts at random from your cloud provider's console. For each one, try to name the owning team in under two minutes.
The proportion you can name is your actual starting point, and it is almost always lower than the number you would have guessed. Take that proportion, not the vendor's total identity count, into the conversation about what to buy.