The 144:1 Problem: A Practitioner's Guide to Non-Human Identity Security in 2026

May 13, 2026 · 9 min read cybersecuritycloudsecurityiamnon-human-identitysecrets-management

The 144:1 Problem: A Practitioner’s Guide to Non-Human Identity Security in 2026

If your IAM strategy in 2026 is still built around employees and contractors, you are defending the wrong perimeter. The modern attack surface is machine. Service accounts, OAuth apps, CI/CD runners, API tokens, AI agents, function-as-a-service execution roles — every one of them is an identity that can authenticate, authorize, and act. Most of them have more privilege than the engineer who created them, and roughly none of them are watched.

The hard number is this: across surveyed cloud environments in 2025, non-human identities (NHIs) outnumber human identities by 144 to 1 — a 44% jump in twelve months. 97% of those NHIs hold excessive privilege. 71% are never rotated within policy. 44% of secrets are exposed somewhere in Jira, Confluence, Teams, or a git history. And 91% of tokens belonging to ex-employees remain active months after offboarding. Those numbers come from the 2026 NHI Reality Report and the CSA State of Non-Human Identity Security survey, and they are the reason the OWASP NHI Top 10 launched as an awareness standard.

This post is a practitioner’s playbook for fixing it. Not theory — what to do this quarter.

What Counts as a Non-Human Identity (and What Breaks Most Often)

NHI is an umbrella term. In a typical AWS-plus-Kubernetes-plus-SaaS estate, the inventory includes IAM roles assumed by Lambda or ECS tasks, EC2 instance profiles, GitHub Actions and GitLab CI OIDC subjects, IRSA service accounts on EKS, Workload Identity bindings on GKE, SaaS-to-SaaS OAuth apps (the Slack-reads-Jira class), managed identities on Azure, third-party SaaS API keys stored in Secrets Manager, personal access tokens belonging to engineers but living in pipelines, and now LLM agents holding tool-use credentials. The thing they have in common: no manager runs a quarterly access review for them, and most identity governance platforms cannot enumerate them at all.

The OWASP Non-Human Identities Top 10 — released in 2025 and now the de-facto standard — categorizes the failure modes. The top of the list, in the order practitioners see them break:

  • NHI1 — Improper Offboarding. A service account outlives the project. The repo gets archived; the IAM role remains. 91% of tokens belonging to former employees are still active.
  • NHI2 — Secret Leakage. API keys end up in Jira tickets, screenshots in Confluence, debug logs, container layers, and (most commonly) committed git history. GitGuardian’s 2025 numbers put the rate at one leaked secret per twenty commits in public GitHub.
  • NHI3 — Vulnerable Third-Party NHIs. An OAuth integration with one-click “approve” grants mail.read and files.write, then the vendor gets breached. The NHI lives on inside your tenant with the original scopes.
  • NHI4 — Insecure Authentication. Static long-lived keys (AWS access keys, GCP JSON keyfiles) where short-lived OIDC tokens belong. This is the single biggest leverage point — fixing it makes the next three risks structurally smaller.
  • NHI5 — Overprivileged NHIs. 97% — 99% by some counts — of cloud identities are over-permissioned. Wildcards in IAM policies (s3:*, Resource: *) are usually the smoking gun.
  • NHI6 — Insecure Cloud Deployment Configurations. The CI/CD trust policy that accepts any subject from any branch (token.actions.githubusercontent.com:sub: "*"). One forked PR away from a tenant compromise.
  • NHI7 — Long-Lived Secrets. The 90-day rotation policy that no one runs. 71% of NHIs are never rotated on schedule.
  • NHI8 — Environment Isolation. Dev keys with production access. The same service principal in staging and prod.
  • NHI9 — NHI Reuse. One IAM role shared by five microservices because “they all need DynamoDB anyway.” Now a vuln in any one of them is a vuln in all.
  • NHI10 — Human Use of NHIs. Engineers aws sts assume-role into a service identity and run interactive commands. Audit logs now show “the deploy bot did it.”

The Five Controls That Move the Needle in 2026

If you have one quarter, do these five. In order. They compound.

1. Inventory before you remediate

You cannot govern what you cannot list. Pull every IAM role, service account, OAuth grant, and access key across every cloud and SaaS tenant into one place. For AWS, IAM Access Analyzer’s unused access analyzer is now table-stakes — it continuously evaluates roles and users against an unused-access age threshold (90 days is a sane starting point) and emits findings. For Azure, use the Entra ID workload identity report. For GCP, Recommender’s IAM recommendations. For SaaS, you will need an NHI-aware tool — GitGuardian, Astrix, Aembit, Entro, Oasis, Token Security, and Permiso are the names that surface most often in 2026 evaluations. Pick one. Cover the gap.

The output of this step is a single deduplicated list with: identity name, cloud, owning team, last-used timestamp, current effective permissions, attached secrets (if any), and rotation age. If you can answer those six questions for every NHI, you are ahead of 80% of enterprises.

2. Replace static credentials with short-lived federation

The structural fix for NHI4 and NHI7 in one move. Anywhere a CI/CD runner currently authenticates with a stored long-lived key, switch to OIDC federation. GitHub Actions, GitLab CI, CircleCI, Buildkite, and Jenkins all support it. AWS calls the receiving end “IAM Roles for Service Accounts” (IRSA) on EKS, “EKS Pod Identity” (now GA and preferred for new clusters in 2026), and “OIDC Identity Provider” for external CI. GCP calls it Workload Identity Federation. Azure calls it Federated Identity Credentials.

The token lifetime should be ≤ 1 hour. The trust policy should pin the OIDC subject claim to the specific repository and branch — never sub: "*". A trust policy like this is the minimum acceptable shape:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:cloudkonsult/cssdaily:ref:refs/heads/main"
  }
}

That one change eliminates an entire class of static-key leakage incidents. It is the highest-ROI security work in most cloud estates.

3. Right-size permissions with usage data, not intuition

Wildcards lose their grip when you have real telemetry. IAM Access Analyzer’s policy generation feature reads CloudTrail and produces a least-privilege policy based on what the role actually called over the lookback window. Run it against every role flagged in step 1 as over-permissioned. Apply the refined policy. Then turn on the unused permissions analyzer to keep it tight.

The same pattern works in GCP (IAM Recommender) and Azure (Entra Permissions Management, formerly CloudKnox). Schedule the analyzer findings as a recurring ticket queue with an SLA. Treat unused-permission findings the same way you treat critical CVEs: tracked, owned, closed within a deadline.

4. Detect human-on-NHI behavior

Even with federation, engineers will assume roles interactively when something breaks at 2 AM. NHI10 is impossible to prevent — but it is detectable. The signal is simple: a role with no normal interactive use suddenly producing aws sts assume-role events from a workstation IP, followed by ad-hoc API calls. Wire that into your SIEM. The rule is one line in most query languages. Alert, do not block — but every alert should produce a ticket asking who, why, and what did they fix.

5. Build the offboarding pipeline

NHI1 is a process problem, not a technical one. When a project is decommissioned or a vendor contract ends, who deletes the IAM role, revokes the OAuth grant, and rotates the shared secret? In most organizations the answer is “no one — it stays until someone notices.” Build an offboarding checklist and bind it to the existing change-management process. Tie every NHI in the inventory from step 1 to a project or vendor identifier. When the project closes, the NHI closes with it.

Impact Assessment

The economics are uncomfortable. The 2026 Verizon DBIR and Sophos identity-breach data converge on a single point: 71% of organizations had at least one identity-related breach in the past twelve months, averaging three incidents each. Stolen credentials and over-privileged service accounts are the dominant initial-access vectors. Mean detection time when the compromised identity is an NHI is materially longer than when it is a human — because no one notices a service account behaving slightly oddly, and most user-behavior-analytics platforms were not built to baseline machine behavior.

Affected platforms: all of them. AWS, Azure, GCP, Kubernetes, GitHub, GitLab, Snowflake, Databricks, every SaaS with an OAuth surface, every CI/CD platform. The risk rating is high for any organization at >50 engineers operating in a multi-cloud or cloud-plus-SaaS estate; critical if you are deploying AI agents that hold tool-use credentials, because agentic NHIs combine NHI4, NHI5, and NHI10 into one identity by design.

CloudShieldSecure Perspective

This is exactly the visibility problem we built CloudShieldSecure to solve. The platform inventories non-human identities across AWS, Azure, GCP, and Kubernetes in a single graph — not as a flat list, but as a privilege-reachability graph. From any NHI you can answer the question that actually matters: what can it touch, and what could it touch if it got one hop further? That is the difference between knowing a role is over-permissioned and knowing it is over-permissioned and within two hops of your customer database.

CloudShieldSecure correlates the IAM Access Analyzer feed with runtime telemetry, so an unused-permissions finding gets the additional context of the workload that holds it is internet-exposed — and gets escalated. We surface human-on-NHI events as a first-class detection. And the offboarding gap — the NHI1 problem — is handled by linking every identity to an owning workload, project tag, and last-active timestamp, so the decommissioning workflow has a single source of truth.

The product is built around the principle that in 2026, the identity perimeter is not your employees. It’s everything your employees told a machine to do on their behalf.

Recommended Actions — Do This Quarter

A practitioner checklist, ordered by impact:

  1. Run an NHI inventory across every cloud, Kubernetes cluster, and major SaaS this week. Use IAM Access Analyzer for AWS, Entra ID for Azure, IAM Recommender for GCP, plus an NHI-aware tool for the SaaS surface.
  2. Identify every long-lived static credential held by a CI/CD system. Replace the top ten by EOQ with OIDC federation.
  3. Run IAM Access Analyzer policy generation on every role flagged as over-permissioned. Replace wildcard policies with the generated least-privilege output. Set the unused-access analyzer to 90 days and treat findings as recurring tickets.
  4. Add a detection rule for human-initiated sts:AssumeRole (or cloud equivalent) against roles tagged service-only. Route to your SOC.
  5. Audit OIDC trust policies for any condition that accepts sub: "*" or any branch. Pin to specific repositories and branches.
  6. Tie every NHI in the inventory to an owning project or vendor. Build offboarding into change management. Schedule a quarterly review of NHIs with no recent activity.
  7. For AI agents holding tool-use credentials: scope tools to least-privilege, time-bound the agent’s session, log every tool invocation as a first-class identity event, and rotate the underlying credentials at session boundaries.

Sources & References

Assess your security posture today

CloudShield Secure scans, validates, and prioritises threats across your entire attack surface.

Explore CloudShield Secure →
← Copy Fail (CVE-2026-31431): The Linux Kernel Flaw … Ni8mare Decoded: How CVE-2026-21858 Turns Public … →