The Non-Human Identity Gap: Why Your Fastest Growing Identity is your Least Governed

Ask a CISO how many people can reach the payment database, and the answer comes with names attached: a role, a manager who approved it, a date it was last reviewed. Ask how many service accounts, API keys, and OAuth grants can reach that same database, and in most organizations the honest answer is a shrug. The identities are there. Nobody is quite sure who's responsible for them.

Security teams spent the better part of a decade getting good at governing the first group. Onboarding workflows tied to HR systems, MFA on every login, quarterly certifications that ask a manager to confirm someone still needs the access they have. Human identity governance is genuinely one of the more mature disciplines in enterprise security today. The population that actually needs governing moved somewhere else while that work was happening: into service accounts, API keys, OAuth applications an employee authorized once and forgot about, workload identities, TLS certificates, CI/CD tokens. None of these are people, and almost none of them show up in a governance program built around people.

Palo Alto Networks' 2026 Identity Security Landscape report puts the current ratio at 109 machine identities for every human one, up from 82 to 1 the year before. Other vendors count it differently. Veza puts the broader enterprise average closer to 17 to 1. Entro Labs, measuring cloud-native and DevOps environments specifically, puts it past 140 to 1. The gap between those numbers matters less than what they agree on: whichever way you count it, the population nobody's built to govern is growing faster than the one everybody already knows how to govern.

The real risk indicator is accountability: how many of those identities have a name attached if someone asks who owns them.

Why HR-Based Governance Breaks

Traditional identity governance runs on an HR-shaped lifecycle. Someone joins, HR kicks off provisioning, a manager signs off on access. Someone leaves, HR shuts it down. A developer spinning up a service account with a few lines of Terraform never touches that workflow. Neither does a cloud engineer wiring a workload identity to a storage bucket so a compute instance can read from it, or a marketer clicking Allow on a new OAuth connection between the CRM and a scheduling tool. There's no HR record for any of it, and no manager sitting in a quarterly access review who can vouch for whether the access is still needed, because nobody was ever assigned to ask in the first place.

Four Breaches, One Missing Control

A stolen human credential usually trips something: an MFA prompt the real user never approved, a "new sign-in from an unrecognized device" email. A compromised service account trips nothing. It authenticates exactly the way it's supposed to, at the time of day it usually runs, from infrastructure that looks legitimate because it is legitimate. That asymmetry is why machine credentials have become attackers' preferred way in.

Four incidents make the pattern hard to miss.

Codecov's Bash Uploader script ran inside thousands of CI pipelines, fetched and piped straight into a shell with a single command. On January 31, 2021, an attacker who'd pulled a credential out of a misconfigured Docker image used it to alter that script so it also shipped every environment variable in the pipeline to a server the attacker controlled. The change sat there for two months, surfacing only when a customer happened to check the script's hash against the one published on GitHub and noticed they didn't match. Codecov listed roughly 29,000 customers on its site at the time; the organizations later confirmed to have had credentials exposed, including HashiCorp, Confluent, and Twilio, numbered in the hundreds.

CircleCI's version of the same failure started with a single laptop. On December 16, 2022, malware on an engineer's machine stole a session cookie that had already cleared two-factor authentication, letting the attacker impersonate that engineer without ever needing a password or an MFA prompt. From there, the attacker reached production systems and pulled customer environment variables, tokens, and encryption keys. CircleCI didn't find out until December 29, when a customer flagged suspicious GitHub OAuth activity. Every customer was told to rotate everything they'd ever stored on the platform.

Microsoft's incident shows how far the same failure can travel up an org chart. In late November 2023, the Russian state-sponsored group Midnight Blizzard used a password-spray attack to get into a human account inside a legacy, non-production test tenant, an environment nobody had gotten around to decommissioning. A forgotten, over-privileged OAuth application sitting inside that same test tenant is what let them go further: the group used its permissions to grant themselves broad read access to Exchange Online mailboxes, reaching accounts belonging to Microsoft's senior leadership team and its cybersecurity and legal staff. Microsoft detected the activity on January 12, 2024, and filed a Form 8-K a week later.

The largest of the four never touched a human login at all. Between August 8 and 18, 2025, a group tracked as UNC6395 used OAuth tokens tied to the Salesloft Drift chatbot's Salesforce integration to systematically query and export data from more than 700 Salesforce customer environments, including Cloudflare, Zscaler, and Palo Alto Networks. Cloudflare's own disclosure noted it had rotated 104 internal tokens exposed in the process. The connection the attackers rode had been authorized once, months earlier, by someone clicking Allow, and never looked at again. There was no MFA prompt anywhere on that path, because the integration's authentication model was never built to have one.

Privilege creep is what turns an incident like any of these from contained into catastrophic. Under deadline pressure, usually mid-incident while a pipeline is actively breaking, a developer grants a service account broader permissions than it needs to make the immediate problem go away. Rarely does anyone come back afterward to narrow that scope once the fire is out. A service account provisioned to read one database table picks up write access, then broader admin rights, then the ability to assume a more privileged cloud role, each step justified in the moment and never revisited.

Secrets Management Solves a Different Problem

Plenty of security leaders treat a secrets manager as the fix for machine identity risk. A secrets manager does real work: it encrypts an API key at rest, injects it into a runtime securely, rotates it on schedule, and logs who retrieved it and when. That work is authentication. It proves the credential presenting itself really is the credential it claims to be.

Authorization is a separate question entirely: whether the thing holding that credential still needs the access it has, whether it's still in active use, who's accountable if it goes wrong. A secrets manager has no opinion on any of that. It will rotate an API key with administrative access to production every thirty days indefinitely, without ever being asked whether that key should have administrative access to begin with. It can report exactly who pulled a credential last Tuesday. It cannot report who owns that credential, or whether the application behind it was quietly decommissioned six months ago.

Governance covers ownership mapping, least-privilege enforcement, lifecycle management, and a behavioral baseline for what an identity normally does. A secrets vault covers none of that, and was never built to.

This Is Already a Board-Level Question

Microsoft's response to its own breach shows how far this has already moved up the org chart. The company detected the Midnight Blizzard intrusion on January 12, 2024, cut off access within a day, and filed a Form 8-K on January 19 telling investors directly what had happened. A test application nobody had bothered to decommission is what gave the attackers their way in.

That filing exists because of Item 1.05 of Form 8-K, a rule the SEC adopted on July 26, 2023. It requires public companies to disclose a material cybersecurity incident within four business days of determining the incident is material, a clock that starts at the materiality determination rather than at discovery. An attacker reaching customer data through an orphaned service account or a forgotten OAuth grant qualifies just as much as one who compromises a person's laptop.

Europe's NIS2 Directive has moved past the theoretical stage too. By mid-2026, most EU member states have transposed it into enforceable national law, and regulators have already started issuing fines: roughly €185,000 in Belgium, €450,000 in Italy, €78,000 in Hungary. Auditors working against NIS2, SOC 2, and ISO 27001 increasingly ask to see the same evidence for a service account that they'd ask for a privileged human administrator: who owns it, what it can touch, when it was last reviewed.

An organization that can't produce a current inventory of active service accounts, can't name the owner of every OAuth app connected to its SaaS estate, and can't show that dormant API keys actually get revoked is carrying real disclosure risk. An auditor or a regulator will be the one to surface that gap, and by then it's already a finding.

The Metric That Actually Predicts Risk

The metrics that mattered for human identity governance don't transfer cleanly here. Mean-time-to-provision tells you almost nothing about a population of identities that provisions itself through code.

Start with ownership coverage: the percentage of non-human identities with a named, active human owner. Cloud Security Alliance research published in January 2026 found that fewer than a quarter of organizations have documented, formally adopted policies for creating or removing AI identities, and 51% report no clear ownership or accountability for the ones they already have. A separate CSA survey found that only 20% of organizations have a formal process for even offboarding and revoking API keys. OWASP didn't publish a Non-Human Identity Top 10 until 2025, and Improper Offboarding tops that list at number one, ahead of secret leakage and insecure authentication. Practitioners rank an identity nobody remembered to shut off as the bigger risk, ahead of a leaked key.

Track mean-time-to-revoke for identities tied to decommissioned workloads, too. When a microservice gets sunset, its identity should expire within hours, not sit dormant for months. Orchid Security's Identity Gap: 2026 Snapshot, published in May, found that 40% of non-human accounts across the enterprise environments it studied were orphaned: the person or process that created them was already gone, while the account and its access stayed active. Sophos's 2026 identity research found that only 34% of organizations regularly audit or rotate their service accounts and non-human identities at all.

None of that changes what the ratio is actually good for. It's a scale indicator, useful for making the case for budget and headcount. Chasing it down as a risk metric burns a quarter for no security benefit, because it keeps climbing regardless of what any single security team does. Set a target for ownership coverage instead. That's the number that predicts whether an auditor, a board, or an incident report finds your organization first.

Three Ways These Programs Fail

Most organizations don't have a real NHI governance program yet. Everything from here assumes a team that's past pretending otherwise.

The most common failure treats governance as a cleanup project instead of an ongoing discipline. A team runs a script, flags every API key older than ninety days, rotates them, trims a handful of overprivileged service accounts, and calls it finished. Two months later the same accounts are back, because nothing changed about how developers are allowed to create identities in the first place. Only the identities that already existed got cleaned up.

A close second hands the entire problem to DevOps and expects it to self-govern. Developers should own the application logic. They shouldn't be the only backstop on the policy layer. If someone can hardcode an admin-scoped token into a CI/CD pipeline and no automated approval step catches it, the governance model has already failed, regardless of how thorough the last cleanup sprint was.

The third failure waves off OAuth sprawl as a SaaS hygiene issue. Employees connect hundreds of third-party apps to corporate SaaS suites, often granting sweeping scopes: read every email, access every file. Once someone clicks Allow, that grant never touches MFA again. If nobody checks six months later what those apps can still do, the organization is holding open exactly the kind of connection UNC6395 walked through in August 2025.

Closing the Loop Between Governance and Detection

Closing this gap means identity governance can't operate on its own. A platform that only tracks what an identity was provisioned to do is working from half the picture. It also needs to know what that identity is actually doing, which means governance has to stay connected to Security Information and Event Management and Extended Detection and Response, not just to HR.

Conclusion

Fixing this starts with a simple rule: treat every service account, workload identity, and OAuth grant the way a new hire gets treated. Someone owns it. Its access is scoped to what it actually needs. There's a process for retiring it the day it stops being useful, not the day someone happens to notice it's still there.