Non-human identities outnumber employees—count them before governing them

Your biggest identity problem is probably not human

A Fortune 500 security team recently found 4.8 million non-human identities across cloud, SaaS, CI/CD, and internal platforms—while the company had only 182,000 employees and contractors. That ratio was not a typo; it was a governance failure hiding in plain sight. If your identity program still starts with people, you are already behind.

Non-human identities now drive most of the access activity in modern enterprises: deployment bots, Kubernetes service accounts, workload identities, API clients, secret-backed integrations, RPA agents, and ephemeral compute roles. In many environments, they outnumber human identities by 20:1 or more, and the ratio keeps climbing as teams adopt AI agents, event-driven automation, and multi-cloud architectures. The hard truth is simple: you cannot govern what you cannot count.

If you do not have a machine-identity inventory, your IAM program is managing a shadow workforce.

Why non-human identities outnumber employees in 2026

The explosion is not theoretical. A single platform team can create thousands of identities in a month without realizing it: one Kubernetes namespace per app, one cloud role per microservice, one CI job token per pipeline, one SaaS integration per team. Add AI copilots that call internal APIs, and the count spikes again.

Here is what that looks like in practice:

• A retail enterprise with 60,000 employees may have 1.2 million cloud IAM roles, service principals, and workload identities.
• A SaaS company running 1,400 microservices can generate 15,000 to 40,000 service accounts across Kubernetes, message queues, and deployment tooling.
• A bank with 300 engineers may have 8,000 GitHub App tokens, Jenkins credentials, and ephemeral OIDC trust relationships.

The issue is not just volume. Non-human identities are often over-privileged, long-lived, and poorly attributed. Human access reviews catch a manager name and a title; machine access reviews often show a cryptic string, a legacy token, or a role attached to three different workloads.

The 2026 reality: identity sprawl is now infrastructure sprawl

In 2026, cloud-native platforms generate identities as part of normal operations. Kubernetes service accounts, AWS IAM roles for service accounts, Azure workload identities, Google Cloud service accounts, and OIDC-federated CI/CD tokens are standard. The problem is that each system uses different semantics, naming, and lifecycle rules.

A typical enterprise now has identities in:

• Cloud control planes
• Kubernetes clusters
• CI/CD systems
• Secret managers
• SaaS integrations
• Data platforms
• AI agent frameworks and tool-calling middleware

If your inventory lives in spreadsheets, it will be outdated before the meeting ends.

Start counting before you start governing

Governance begins with a complete inventory, not a policy document. If you skip discovery, you will miss the identities that actually matter: stale keys in production, orphaned service accounts, and machine-to-machine trust paths that bypass your approval workflows.

Build a machine-identity census

Your first goal is not perfection. It is a defensible count with enough context to act. Track at least these fields for every non-human identity:

• Identity type: service account, workload identity, API key, bot, token, certificate, role
• Owner: team, system, or service accountable for it
• Issuer: cloud, CI/CD, IdP, secret manager, SaaS vendor
• Scope: environment, namespace, subscription, project, account
• Privilege level: read, write, admin, impersonation, cross-account trust
• Expiration: explicit TTL or last rotation date
• Usage: last seen, call frequency, and target systems

A simple inventory schema can start in a warehouse or graph database. The key is to normalize identities across platforms.

identity:
  id: "svc-payments-recon-prod"
  type: "workload_identity"
  owner_team: "payments-platform"
  issuer: "gcp"
  environment: "prod"
  scopes:
    - "pubsub.subscriber"
    - "bigquery.dataViewer"
  last_seen: "2026-07-29T14:22:11Z"
  rotation_ttl_hours: 24
  risk_score: 82

Use graph relationships, not flat lists

Flat inventories miss the real risk: trust chains. A token might look harmless until you see it can assume a role that can mint another token that can access customer data. Graph modeling exposes these paths.

A practical enterprise architecture often looks like this:

[CI Pipeline OIDC] -> [Cloud Role] -> [Kubernetes Deploy SA] -> [Secrets Manager] -> [Database]
           |                                  |
           v                                  v
      [Artifact Registry]               [Observability API]

When you map identities as nodes and trust relationships as edges, you can answer the questions auditors and incident responders always ask: who can assume what, from where, and under which conditions?

How to govern machine identities without slowing delivery

Counting is necessary, but governance is where teams usually overcorrect. If you lock everything down with manual approvals, engineers will route around you. The better model is policy-driven automation with guardrails that fit the velocity of software delivery.

Set different controls by identity class

Not every non-human identity needs the same treatment. Separate them into classes and apply controls accordingly:

• Ephemeral workload identities: short TTL, automatic issuance, no static secrets
• Long-lived service accounts: owner required, quarterly review, least privilege, rotation enforced
• Privileged automation identities: just-in-time elevation, approval gates, session recording where possible
• External integrations: vendor attestation, scoped access, network restrictions, revocation playbooks

This is where modern IAM platforms, cloud-native workload identity federation, and secretless patterns matter. In 2026, static secrets are the exception you should phase out, not the default you accept.

Enforce least privilege with measurable targets

A good governance program sets numeric targets, not vague aspirations. For example:

• 90% of production workloads use short-lived federated credentials
• 100% of machine identities have an accountable owner
• 95% of non-human identities rotate or re-issue credentials in under 24 hours
• 0 production service accounts retain admin permissions longer than 7 days without exception

One global SaaS provider reduced standing privileges by 68% in 90 days by replacing static API keys with OIDC federation and scoped service roles. Their mean time to revoke a compromised machine identity dropped from 4.5 hours to 11 minutes because revocation moved from secret rotation to trust-policy update.

Prefer policy-as-code over ticket queues

Manual governance breaks at scale. Policy-as-code lets you enforce rules at creation time and continuously validate them afterward.

package machine_identity

default allow = false

allow {
  input.identity.type == "workload_identity"
  input.identity.owner_team != ""
  input.identity.rotation_ttl_hours <= 24
  input.identity.risk_score < 70
}

violation[msg] {
  input.identity.type == "service_account"
  input.identity.owner_team == ""
  msg := "service account missing owner"
}

With controls like this, teams can provision identities quickly while still meeting governance requirements. The policy is evaluated by automation, not by a security analyst reading a Jira ticket three days later.

What to measure so the program survives contact with reality

If you cannot measure machine identity risk, your governance effort will drift into theater. The most useful metrics are operational, not abstract.

Track these benchmarks

Use a monthly dashboard with at least the following numbers:

• Identity count by class: human vs non-human, by platform
• Orphan rate: identities with no owner or no recent usage
• Privilege concentration: percentage of identities with write/admin scope
• Secret age: median and 95th percentile age of static credentials
• Revocation time: time from detection to disablement
• Federation coverage: percentage of workloads using short-lived credentials

Realistic 2026 benchmark ranges for mature enterprises:

• Orphan rate below 3% is strong; above 10% is a red flag
• Median secret age under 30 days is workable; over 90 days is risky
• Revocation time under 15 minutes is achievable with automated trust controls
• Federation coverage above 80% indicates real progress; under 40% means static secrets still dominate

A sample control loop

A practical control loop looks like this:

flowchart LR
A[Discover identities] --> B[Normalize metadata]
B --> C[Score risk]
C --> D[Apply policy]
D --> E[Rotate or revoke]
E --> F[Monitor usage]
F --> A

That loop should run continuously, not quarterly. In high-change environments, a 24-hour scan cadence is acceptable; in regulated production systems, 4-hour cadence is better.

Common Pitfalls

Teams make the same mistakes over and over when they start counting non-human identities.

Mistake 1: Treating service accounts as "just technical"

That mindset guarantees orphaned access. Every service account needs an owner, a purpose, and an expiry or review date. If nobody can name the accountable team, the identity should be disabled after a grace period.

Mistake 2: Counting only cloud IAM

Cloud roles are only part of the picture. You also need Kubernetes, CI/CD, SaaS integrations, data platforms, and AI agent credentials. One enterprise found that 41% of its non-human identities lived outside cloud IAM entirely.

Mistake 3: Relying on static secrets because they are familiar

Static API keys are easy to issue and hard to govern. They are also hard to attribute, hard to revoke cleanly, and often copied into places you do not monitor. Replace them with federation, signed assertions, or short-lived tokens wherever possible.

Mistake 4: Building governance before discovery

Policy without inventory creates false confidence. You will spend weeks writing rules for identities you never found, while the risky ones keep running.

Mistake 5: Ignoring AI agent identities

In 2026, AI agents are not just chat surfaces. They call tools, query data, trigger workflows, and sometimes act on behalf of teams. If your agent framework can access production APIs, it is a non-human identity and needs the same controls as any other.

The operating model that works in 2026

The best programs combine discovery, ownership, and automation. They do not ask security to manually approve every machine credential. They make identity creation observable and revocation fast.

A practical operating model has four layers:

1. Discovery: continuously enumerate identities from cloud, CI/CD, Kubernetes, SaaS, and secret stores.
2. Normalization: map every identity to a common schema and owner.
3. Policy enforcement: block risky creation patterns and flag privilege drift.
4. Lifecycle automation: rotate, expire, and revoke based on usage and risk.

If you need a starting point, pick one high-volume domain first. CI/CD tokens are often the fastest win because they are numerous, easy to inventory, and easy to migrate to OIDC federation. Many teams cut static credential counts by 50% to 70% in the first quarter by focusing there.

Key Takeaways

• Count every non-human identity across cloud, Kubernetes, CI/CD, SaaS, and AI agents before writing governance policy.
• Build a normalized inventory with owner, issuer, scope, last seen, privilege, and expiry for each identity.
• Model trust relationships as a graph so you can see how one credential reaches sensitive systems.
• Replace static secrets with short-lived federation wherever possible; target at least 80% federation coverage.
• Track orphan rate, revocation time, secret age, and privilege concentration as core operating metrics.
• Start with one high-volume domain, such as CI/CD tokens, and automate discovery plus policy enforcement there first.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.