The NHI Explosion: Why 2026 Is the Year of Non-Human Identity

Every enterprise has an identity problem it hasn't named yet. The humans are counted, provisioned, reviewed, deprovisioned. The workloads — the Kubernetes pods, the CI/CD runners, the Lambda functions, the AI agents, the service-to-service calls, the third-party SaaS webhooks, the database replication jobs — outnumber them forty to one, and in most organizations nobody owns their lifecycle.

That's the non-human identity (NHI) problem. It's been building for a decade, but 2026 is the year it became a category. Analyst coverage caught up — Gartner published its first NHI Market Guide in late 2025; the Cloud Security Alliance ran a dedicated NHI working group through the first quarter of 2026. Funding caught up — Astrix, Entro, Oasis, Clutch, and half a dozen smaller pure-plays raised rounds on the category thesis. Compliance caught up — SOC 2 auditors started asking for "machine identity inventory" as a distinct line item. And attackers caught up: the 2025 Snowflake, Cloudflare, and Microsoft incidents all pivoted on leaked or undermanaged non-human credentials.

If you're evaluating an identity stack in 2026 and NHI isn't a first-class concern, you're planning for the wrong decade.

Why the 40-to-1 ratio is conservative

The "NHIs outnumber humans 40:1" figure gets repeated in vendor decks, but it understates the problem. The ratio counts active workloads. It doesn't count:

• API keys and tokens issued to third-party SaaS integrations that no human can list.
• Service accounts in AD, Okta, and cloud IAM that were created for a one-off script in 2019 and never reviewed since.
• Certificates for service-to-service TLS that live on a mutual-TLS mesh nobody has audited.
• Embedded credentials in container images, baked into builds years ago.
• AI agent identities — a newer problem, and the fastest-growing. A single LLM-powered application often spawns dozens of ephemeral tool-invocations per user session, each needing its own authorization context.

Once you count these honestly, the ratio is closer to 200:1. And every one of them is a credential an attacker would love to get their hands on.

Why traditional IAM tools fail at NHI

Okta, Entra ID, Ping, OneLogin — the identity providers that dominate the workforce identity category — were built around humans. The primitives show it. You have users with profiles who log in through interactive flows with MFA and occasional access reviews. Bolt NHI support onto that foundation and three things break:

1. The lifecycle model is wrong. Human identities last for years — hire to retire. Workload identities often last for minutes (a serverless function's execution), or are ephemeral by design (a Kubernetes pod that's rescheduled). Treating them as long-lived user accounts puts a stale credential on the wire for the entire lifespan of the underlying compute.
2. The authentication model is wrong. You can't MFA a Lambda function. The credentials workloads use are minted by the platform they run on — the kubelet, the EC2 metadata service, the cloud IdP — and the job of an NHI system is to verify those platform-minted credentials, not to issue its own.
3. The authorization model is wrong. Human RBAC usually assumes a user has a session. Workloads don't. Their authorization needs to be evaluated per-request, on evidence they present each time, without a long-lived session cookie.

The NHI category exists because these three gaps can't be closed by "adding a checkbox" to a workforce IdP.

What a modern NHI system looks like

A 2026-appropriate NHI platform should answer these questions cleanly:

1. Can it verify platform-minted credentials?

The workload's credential isn't a password or an API key — it's a JWT signed by the platform (Kubernetes service account token, AWS instance identity, Azure Managed Identity, GCP identity token, SPIFFE JWT-SVID). Your NHI system must verify these against the platform's JWKS, with pinned trusted issuers, expected audiences, and expected claims. Anything else is a pre-shared-secret workflow with extra steps.

CoreLink's NHI subsystem does this natively for Kubernetes, AWS, Azure, and GCP. A workload hits /api/v1/nhi-agent/connect with its platform JWT, the platform verifies it against the configured issuer, and returns a short-lived session. No secret ever lives in the workload's config.

2. Can it auto-register new workloads based on policy?

At enterprise scale, pre-registering every NHI by hand is a non-starter. A Kubernetes deployment might spin up a hundred pod replicas; writing an NHI record for each is a non-starter. Modern NHI platforms support workload templates: a policy like "any pod in namespace prod with SA myapp-* auto-registers with scopes X, Y, Z". The first attested connect from a matching workload provisions the NHI; subsequent ones reuse it.

CoreLink ships workload templates with claim matchers (equals, prefix, glob) and cap enforcement. We wrote about the full flow recently.

3. Can it federate across trust domains?

Multi-cluster Kubernetes, multi-account AWS, multi-tenant SaaS all create federation boundaries. A workload in cluster A needs to authenticate to a service in cluster B. SPIFFE trust bundles are the emerging standard: each cluster publishes a JWKS, peer clusters verify incoming SVIDs against the peer's bundle.

CoreLink accepts federated SVIDs at Connect time and at mTLS, with an immutable trust_domain per peer and a full JWKS refresh path. The /federation_peers admin surface is how operators register new trust relationships.

4. Can it exchange tokens for other identity platforms?

NHIs rarely exist in isolation. The workload may already have an OIDC token from a customer's own IdP that needs to be exchanged for a CoreLink session. RFC 8693 (OAuth 2.0 Token Exchange) is the standard for this. A modern NHI platform should implement it as a first-class grant type — inbound (accept an external JWT, return a local session) and outbound (mint a JWT-SVID, exchange against AWS STS / Azure federation / GCP workload pool).

CoreLink does both. The inbound path is at POST /oauth/token with grant_type=urn:ietf:params:oauth:grant-type:token-exchange; the outbound federation covers AWS AssumeRoleWithWebIdentity, Azure workload identity federation, and GCP workload pools.

5. Can it inventory every NHI and flag the rot?

The answer to "how many NHIs do we have" should be a number, not a wave of the hand. Modern NHI platforms must enumerate every registered workload identity, show last-connect times, flag stale ones (no connect in 90 days), and surface which cloud roles or secret scopes each one has access to. That's the NHI equivalent of an access review — and auditors are starting to ask for it by name.

What 2026 buyers are asking that 2024 buyers weren't

• "What happens when an NHI is compromised?" — Good answer: instant revocation via session token cycling + NHI lockout, plus audit-event backtrace of every resource the NHI touched in the last N days.
• "How do we prove to auditors that our NHIs follow least privilege?" — Good answer: scoped sessions, short TTLs (15 minutes default), explicit scope-narrowing on token exchange, and hash-chained audit trails.
• "Can we federate with our customer's SPIFFE trust domain?" — Good answer: yes, with a one-click peer registration and automatic JWKS refresh.
• "Does it handle AI agents?" — This is the 2026-specific question. LLMs invoking tools are NHIs with a new characteristic: the credential needs to be delegated from a human principal on whose behalf the agent acts, and the delegation scope needs to be explicit. MCP (Model Context Protocol) is the emerging standard for this; we'll dig into it in a separate post.

Where to start

If you're just beginning an NHI evaluation:

1. Inventory first. Pull every service account, API key, and cloud IAM role in your organization. The count is almost always 10x higher than the team expects.
2. Classify by platform. Kubernetes pods, cloud functions, CI/CD runners, and SaaS-to-SaaS integrations all have different attestation paths.
3. Prioritize by blast radius. An NHI with AdministratorAccess in your prod AWS account is more urgent than an internal reporting job with read-only S3.
4. Evaluate platforms against the five questions above.

We built CoreLink to answer all five with a single product. If you want to see it work, the NHI use-case page walks through the K8s operator flow end to end, and the passwordless workload authentication post covers the four cross-cloud paths we closed recently.

2026 is the year NHI gets named. The enterprises that inventory and govern their non-human identities this year will spend the rest of the decade telling the ones that didn't about the incident that cost them everything.