Non-Human Identity Is Now the Majority of Your Identities

Start with a counting exercise. It takes ten minutes and usually ends an argument.

Count your employees. Whatever your HR system reports is accurate to within a few days, because someone's job depends on that.

Now count the other kind. Service accounts in every environment. CI/CD credentials — one per pipeline, sometimes one per repository. API keys issued to partners, including from proofs of concept that never converted. Per-service TLS certificates. Cloud IAM roles, and separately the IAM users nobody deleted when you moved to roles. Database users, almost never the same list as your application service accounts. Kubernetes service accounts, multiplying per namespace. Scheduled jobs. Webhook signing keys. And now agents, which need identities distinct from the humans they act for.

Most organizations land between 10:1 and 50:1 against humans. The ratio isn't the interesting part. The interesting part is that almost nobody can produce the list at all — only fragments, because no system's job is to know the union and no person is accountable for the total.

That inability isn't a precursor to the finding. It is the finding. A population you cannot enumerate cannot be governed, and every control you believe you have over it covers only the subset you happen to remember.

Every discipline we built assumes a human

Identity governance is thirty years of accumulated machinery — joiner/mover/leaver, certification, segregation of duties, offboarding runbooks, MFA mandates. Good machinery, resting load-bearingly on one assumption: that some authoritative external system tells you when an identity's circumstances change.

For humans, that system is HR. Someone is hired and a record appears; changes teams and a field updates; leaves and a termination event reaches the IdP within minutes. Reviews are scheduled off that stream. Deprovisioning is triggered by it.

Machines have no HR.

Nothing in your infrastructure emits an event saying "the data migration finished; the credential issued for it in 2022 is no longer needed." The migration ended. The epic closed. The engineer who ran it changed teams. The credential is still valid, still has write access to the production database, and will remain so indefinitely, because no process exists whose job is to notice. That process didn't fail; it was never built.

That is the asymmetry underneath everything else here. Human identity governance is cheap because it rides on a business process that exists for payroll reasons. Machine identity governance has no carrier, so every part of it is paid for deliberately or not at all.

Nobody owns it, so nobody revokes it

Human identities are self-owning. Alice is accountable for Alice's account: if it behaves strangely there's someone to ask, and if it should go away, her departure says so.

Machine identities need a designated human owner, and designation is a weak bond. Owners change teams, or leave; teams get reorganized out of existence and their systems inherited by people who never asked for them. An orphaned service account — one whose owner you cannot identify — is the most common finding in credential audits, and usually the largest category by count.

The second-order effect is where the real damage is: nobody revokes a credential they can't attribute. Consider the engineer holding the audit spreadsheet. Revoking an unknown credential has unbounded downside — it might be load-bearing for billing, or a nightly reconciliation that fails visibly only at quarter-end. Leaving it has a diffuse downside that will never be traced back to them. Every rational actor leaves it.

So the list becomes a ticket, the ticket sits at "pending owner identification," and the credential outlives the auditor. The finding was correct and completely inert.

Permissions accrete and are never reviewed

Human access gets reviewed because regulators insist. SOX, SOC 2, and every campaign your GRC team runs answers one question: does this person still need this?

Machine permissions accrete monotonically. It's 3am, the fix is one IAM policy attachment away, someone adds it and says "temporary" in the channel. Nobody removes it — not from laziness, but because removal is epistemically harder than addition.

To confirm Alice no longer needs a permission, you ask Alice; she's a responsive subject who participates in her own review. A service cannot be asked. The only way to test whether it still needs a permission is to remove it and see what breaks — possibly weeks later, possibly at quarter-end, possibly in a code path that executes for one customer.

That's the deeper reason certification doesn't port to machines, and it isn't a tooling gap: access review presupposes an interrogable subject, and machines aren't one. Running the campaign anyway yields a spreadsheet that owners rubber-stamp — worse than nothing, since it produces evidence of a control that isn't operating.

No second factor, by construction

A human with a stolen password may still be stopped at the second factor — the strongest control in human identity, and it has no machine equivalent. A machine credential is single-factor by construction: possession is authentication, and there's no "something you are" for a container.

The partial answers, ranked honestly. Short-lived credentials shrink the window rather than closing it: real, but bounded.

Workload identity federation is the genuinely important development. Instead of holding a stored secret, the workload proves where it is running. The platform — GitHub Actions, EKS, GCE, a Kubernetes API server — issues it a short-lived, platform-signed OIDC token asserting its execution context: this repository, this branch, this environment, this namespace. Your authorization server trusts that issuer and exchanges the assertion for a credential. Nothing stored, nothing distributed, no secret to leak — which retires the rotation problem rather than automating it.

The part that trips teams up: security here rests entirely on how precisely you constrain the trust policy, and the failure mode is silent. The platform's issuer is shared across all its tenants — GitHub's OIDC issuer signs tokens for every repository on GitHub. If your policy checks the issuer and signature but matches the sub claim loosely, or omits the audience check, you haven't federated to your workload. You've federated to anyone on that platform, and it works perfectly in testing. Federation moves the secret out of your infrastructure and moves the security into a policy string no test will tell you is wrong.

Attestation — hardware roots of trust, TPM-backed keys, confidential computing — extends the idea down the stack, and is where high-assurance environments are going.

The lifecycle table

Read the second column as missing inputs rather than failures. Almost every gap is a missing event source, not missing will.

What actually works

Require a named owner and a purpose at creation. Not a team alias that outlives its members — a person, plus enough context to answer "what breaks if this dies." Re-attest ownership on departures, off the HR event stream you already have.

Require an expiry. A credential with no expiry is a permanent liability. Force renewal and unused credentials die by default, inverting the incentive: instead of proving a credential is unneeded, someone must prove it's still needed.

Track last-used timestamps. The highest-value telemetry in the domain, and chronically under-collected. It turns "is anything still using this?" from an unanswerable question into a query, after which a credential unused for 180 days can be revoked by someone who has never heard of the system. Without it, every revocation is archaeology.

Prefer federation to stored secrets, with a tightly constrained trust policy.

Treat registration as a governed action, closer to a change request than a button click, because nothing downstream will revisit the decision.

The honest counterargument

Machine identities genuinely cannot be governed the way humans are, and the failure mode of trying is real. They can't respond to a review or re-authenticate interactively when something looks suspicious. And getting it wrong differs in kind: locking Alice out is an inconvenience with a help desk ticket attached; revoking the wrong service credential is an outage, potentially customer-visible, potentially at 3am.

A team that ports the human program wholesale gets one of two outcomes. Either the controls have teeth and periodically cause outages, at which point the business revokes the program's mandate, usually permanently. Or they're softened until every owner approves every permission, producing audit evidence for a control that is not operating — more common, and more dangerous, because it's indistinguishable from success on a dashboard.

So: different controls, not the same controls applied harder. Humans get periodic attestation because they can be asked. Machines get expiry, usage telemetry, and provable execution context, because those work on a subject that cannot participate in its own review.

The inverted asymmetry

Identity practice was built when humans were the overwhelming majority of identities, and the machinery reflects that origin faithfully. The population inverted sometime in the last decade, one service account at a time. The governance didn't follow.

We apply our most mature controls — MFA, certification, automated deprovisioning — to the small minority of identities belonging to people who can be asked questions, and our least mature controls to the majority that can't be asked anything and never leave.

Start with the counting exercise. If you can't finish it, you've already learned the most important thing.