Three to One: The Identity Ratio No One Is Governing
Machine identities now outnumber humans by three to one — and almost no board knows who owns the risk.
By 2026, non-human identities — APIs, bots, service accounts, IoT devices, AI agents, CI/CD tokens, container workloads — outnumber human users in most enterprises by roughly three to one. In heavily automated environments, the ratio climbs to ten to one or higher. Every one of those identities has credentials, permissions, and access to something a person would need a manager’s sign-off to touch.
If you run a risk committee, an audit committee, or a board, the implication is uncomfortable: the majority of your organisation’s identity surface is not human, is not reviewed on a joiner-mover-leaver cycle, and is almost certainly not reflected in your cyber risk register.
Why the governance model breaks
Human identity governance is a broadly solved problem. We have decades of precedent. HR initiates an account when a person is hired. Access is reviewed quarterly. Permissions change when people move teams. Accounts are disabled on the last day of employment. Annual recertifications catch the drift. Auditors tick boxes. The board sees a dashboard.
Non-human identities fit none of this.
A service account is created by a developer, often in a rush, often with broader permissions than needed, often without a lifecycle owner. When the developer leaves, the account doesn’t. When the application it serves is decommissioned, the account rarely is. When a contractor spins up an integration for a six-week project, it lingers for six years. There is no HR system for machines. There is no quarterly access review. There is no joiner-mover-leaver workflow unless someone has built one deliberately.
The result is a population of credentials larger than your workforce, more privileged than most employees, and governed by approximately nobody.
How attackers are exploiting the gap
The attack chain I have seen most often this year goes roughly like this. An adversary targets a developer — increasingly through recruitment fraud, where a fake job posting or trojanised coding challenge delivers malware. The developer’s workstation yields their personal GitHub or GitLab token. That token grants access to internal code repositories. Inside those repositories are hardcoded credentials, API keys, and service account tokens — the machine identities. From there, the attacker moves laterally using those credentials, which typically have far more privilege than the compromised developer.
The developer is the foothold. The non-human identities are the payload.
This is not a theoretical threat model. Identity security researchers have documented the pattern through multiple incidents in the past twelve months. In most cases, the breached organisations had strong human IAM — MFA, SSO, conditional access — and catastrophic machine identity hygiene. The perimeter that mattered was the one they had not measured.
The disclosure question most boards haven’t asked
There is a second, quieter governance concern.
Since the SEC’s November 2025 decision to terminate its long-running SolarWinds CISO litigation, the Commission has refocused on material misrepresentations in cyber disclosures that harm investors. That is a narrower but sharper standard. The accuracy of your Form 8-K cyber disclosures — and what your audit committee knew when they approved them — is now a live legal question.
If a material breach originates from a machine identity your organisation cannot account for, and your public disclosure describes your identity posture in terms of your human workforce, you have a problem that a regulator can reach. The board cannot comfortably rely on “we didn’t know” if the inventory was never commissioned in the first place.
This is why I treat non-human identity governance as a board-level disclosure issue, not just an operational IAM issue.
Where governance needs to catch up
Three shifts are required, and the first two are structural rather than technical.
First, non-human identities need a named owner. Every service account, API key, and machine credential needs a named human accountable for its lifecycle — provisioning, permissions, rotation, and decommissioning. The failure mode I see repeatedly is “owned by the team”, which in practice means owned by nobody. Attach each identity to a person, and when that person leaves, reassign it explicitly. This is the single highest-leverage change available to most organisations, and it costs nothing but discipline.
Second, NHIs need to appear on the risk register in language the board understands. Not “we have 11,000 service accounts” but “42% of those accounts have privileged access, and 18% have not been authenticated in over 12 months.” The board’s job is to judge whether that level of unmeasured privilege is acceptable. They cannot do that with a headcount figure alone.
Third, the joiner-mover-leaver process needs a machine analogue. When an application is decommissioned, its identities should be decommissioned with it. When a developer leaves, the credentials they created should be reviewed, not only the ones assigned to them. This is dull, unglamorous governance work. It is also what the SEC, the ICO, and your cyber insurer will ask about after an incident.
Questions for your next risk committee
A handful of questions worth raising at your next risk or audit committee meeting.
Do we have an inventory of non-human identities, and when was it last verified independently? If the answer is “the identity team maintains one,” that is different from an audit.
Who owns the lifecycle of any given machine identity — is there a named person, or a team?
How many of our machine identities have privileged access, and how many have been dormant for more than 90 days?
If a breach originated from a service account tomorrow, could our disclosure accurately describe our identity governance posture?
When did the board last see an identity figure that included non-human identities?
The answer to that last question, in my experience, is almost always “never.”
That is the governance gap. Closing it does not require new technology. It requires the board to ask for a number it has not previously asked for, and to keep asking until someone owns it.