Non-Human Identities (NHI) and Secrets Management 2026

A non-human identity (NHI) is any credential or identity that authenticates software rather than a person: service accounts, API keys, OAuth tokens, managed identities or roles. They are the biggest security blind spot of 2026, and the numbers prove it: in Entro Labs' H1 2025 analysis of 27 million non-human identities across observed environments, the ratio was 144:1, up from 92:1 in H1 2024. While organizations invest in MFA, training and password management for their employees, a silent army of service accounts, API keys and tokens operates with excessive privileges, long-lived credentials and almost no oversight. From an offensive standpoint, that army is exactly where we get in.

What are non-human identities (NHI)?

A non-human identity is any credential or identity that authenticates software, not people. Unlike a user, an NHI does not type a password or solve a second factor. One point that is often misunderstood: NOT every NHI has a persistent secret. How an NHI proves who it is varies widely. Some present a static secret (an API key or a long-lived token). Others (managed identities, workload identity federation and assumable roles) obtain temporary credentials on demand without ever storing a static secret. This distinction matters, because the most secure measure is not to protect the secret better, but to eliminate it. The main categories you will find in any audit are:

• Service accounts: machine accounts in Active Directory, Entra ID, Google Workspace or Linux systems that run services, scheduled tasks or batch processes.
• API keys: static strings that authenticate an application against a service (Stripe, AWS, GitHub, OpenAI). They are the most frequently leaked type of secret.
• OAuth tokens and refresh tokens: credentials an app uses to act on behalf of a user or itself against a SaaS API without logging in again.
• Certificates and private keys: key pairs used in mTLS, code signing and machine-to-machine communication.
• Infrastructure secrets: database credentials, connection strings, Kubernetes tokens, CI/CD secrets.
• AI agent credentials: the emerging vector. Every autonomous agent, copilot or RAG pipeline needs keys to call models, vector databases and internal tools. In 2026 this category grows faster than any other.

If you want the equivalent human framework, our guide on what IAM (identity and access management) is covers authentication, authorization, RBAC and the enterprise stack. NHIs are the neglected sibling of that model.

Why NHIs are the biggest blind spot of 2026

The problem is not that NHIs exist, it is that they are poorly governed. Four factors make them a prime target for an attacker.

They outnumber human identities

With ratios reaching 144:1 in the environments Entro Labs analyzed in H1 2025, keeping a complete inventory of machine identities is a real challenge. What is not inventoried is not protected. Every new microservice, every SaaS integration and every AI agent adds credentials that are rarely decommissioned. This phenomenon has a name: NHI sprawl.

They are over-privileged

97% of NHIs have excessive privileges, according to the 2025 State of Non-Human Identities. A service account created "just to make it work fast" gets a broad role (often a wildcard) and no one ever narrows it down. In AWS this translates into overly permissive IAM policies that enable pivoting and escalation, which we cover in detail in AWS IAM privilege escalation. The principle of least privilege, so widely preached for humans, is almost never applied to machines.

They are long-lived and never rotate

47% of NHIs are more than one year old with no credential rotation. An API key generated in 2023 may still be valid today. Unlike a user password, which expires or gets changed after an incident, many machine secrets live indefinitely because breaking them breaks production. That persistence is a gift to an attacker.

They have no MFA and are barely monitored

An NHI cannot solve a second factor by design. When it authenticates with a persistent secret, the entire defense rests on protecting that secret and detecting its anomalous use. That is why the most secure measure, where the platform allows it, is to eliminate the secret: replace static keys with managed identities, workload identity federation or roles that issue short-lived credentials. A secret that does not exist cannot be leaked or stolen. But a compromised service account's activity looks just like its legitimate activity, and there are rarely alerts for it. This is where the Zero Trust philosophy becomes essential: never trust by default, not even an internal process holding a valid credential.

Real risks: how machine credentials get exploited

At Secra we treat machine credentials as one of the most profitable paths in an offensive engagement. These are the patterns we see over and over.

Secrets leaked in Git, logs and containers

The largest and oldest surface. In 2025, 28.65 million hardcoded secrets were added to public GitHub repositories, a 34% year-over-year increase (GitGuardian). And that is only the public side: in private repos, commit histories, environment variables, .env files, application logs and Docker image layers the density is even higher. A git log -p or a simple grep over history usually returns active keys. The commit that "removes" the key does not delete it: it stays in history.

Stolen tokens that bypass MFA

This is the 2025-2026 paradigm shift. An already-authenticated OAuth or session token does not need to go through login, so stealing it bypasses MFA entirely. The attacker inherits the authenticated context and operates without ever seeing a login screen. Unlike attacks against humans such as MFA fatigue or push bombing, here there is no victim to trick: the stolen token is already everything. Per the Verizon DBIR 2025, within its subset of Microsoft 365 attacks aimed at bypassing MFA (among the report's contributor records), token theft accounted for 31%.

The most notorious case was the Salesloft-Drift breach of August 2025: the UNC6395 group used OAuth tokens stolen from the Drift integration to access more than 700 Salesforce organizations, exfiltrate data and hunt for high-value secrets like AWS keys and Snowflake tokens. Not a single compromised password, not a single expired MFA: just valid machine tokens used by the wrong party. If your mental model of defense is still centered on login, understand why phishing-resistant MFA protects human access but does not save an NHI whose token is already circulating.

Lateral movement and chaining

A leaked secret is rarely the final target: it is the first domino. A CI/CD key grants access to the pipeline, the pipeline has a service account with cloud permissions, that account can read a secret manager, and there sit the production database credentials. The chaining of over-privileged NHIs is what turns a minor leak into a total breach. These secrets are also the doorway to software supply chain attacks, when the compromised secret belongs to a vendor or a dependency.

API token abuse

Modern APIs rely on tokens (JWTs, bearer tokens, keys) to authenticate every call. A poorly validated token, with no expiration or with an excessive scope, is directly exploitable. Understanding how these tokens are signed and validated is key: our JWT security guide details the common failures (the none algorithm, weak secrets, missing signing rotation), and in REST and GraphQL API penetration testing we show how these tokens get abused in practice.

How to manage NHIs: vault, rotation and least privilege

The good news is that NHI governance is a solvable problem with discipline. This is the program we recommend, in order of effectiveness.

Eliminate the persistent secret (the most secure measure)

Before you think about a vault or rotation, ask whether the secret needs to exist at all. On most modern cloud platforms, it does not. Managed identities (Azure), assumable IAM roles (AWS) and service accounts with federated identity (Google Cloud) let a workload authenticate without storing any static key: the platform issues short-lived temporary credentials and revokes them on its own. Workload identity federation extends this to CI/CD and to workloads outside the cloud, which exchange a trusted token for ephemeral credentials instead of holding a long-lived key. It is the same federated-trust principle behind SAML sign-in for humans, brought to the machine-to-machine plane. A secret that does not exist cannot leak into Git, be stolen from a log, or be reused months later. This should always be the first option; the vault and rotation are for the secrets you cannot eliminate yet due to technical constraints.

Secrets vault

No secret should live in code, in a configuration file or in a persistent environment variable. Centralize everything in a vault: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault or Google Secret Manager. The application requests the secret at runtime, with audited access, and never stores it on disk. The end goal is dynamic secrets: short-lived credentials the vault generates on demand and revokes automatically.

Automatic rotation

A secret that does not rotate is a time bomb. Automate the rotation of API keys, service account passwords and certificates on a short cadence. If rotating a secret breaks a service, that coupling is itself the problem to solve. Rotation drastically limits the useful window of a stolen credential.

Least privilege for machines

Grant each NHI the exact permission it needs, nothing more. No wildcard roles, no Administrator "just in case." Review permissions periodically and remove the ones that go unused. Cloud providers' access analyzer tools show which granted permissions are never exercised: those are the first to eliminate.

Secret scanning

Build secret scanning into the development flow: pre-commit hooks that block the commit before the secret enters history, continuous scanning of the repository and container images, and monitoring of public repos in case something leaks out. Tools like GitGuardian, TruffleHog or GitHub's native secret scanning cover these layers. This control is an essential part of a mature DevSecOps culture.

NHI governance: inventory and lifecycle

Everything starts with inventory. You cannot govern what you cannot see. Discover every NHI in your environment, assign each one a responsible human owner, document what it is for and establish a full lifecycle: provisioning, periodic review and decommissioning. An NHI with no owner and no recent use should be disabled. It is the same identity governance discipline we apply to humans with IGA, finally extended to machines.

Runtime anomaly detection

Because a compromised NHI behaves almost identically to a legitimate one, detection requires context: why is that service account accessing a new resource? Why is that OAuth token connecting from an unusual IP or country? Why did the call volume suddenly multiply? Establishing a behavioral baseline per NHI and alerting on deviations is what would have shortened the Salesloft-Drift breach window.

NHI, Zero Trust and the new perimeter

Identity is the new perimeter, and in 2026 that identity is mostly non-human. A Zero Trust model that only verifies humans is incomplete: every service, every agent and every API call must authenticate with a strong identity, be authorized with least privilege and be subject to continuous verification. The same three Zero Trust questions (who are you? what can you do? are you still behaving as you should?) apply in full to a service account or an AI agent.

With the explosion of agentic AI, this problem will only grow. Every autonomous agent is an NHI with access to data and tools, often able to act without a human in the loop. Governing their credentials, limiting their permissions and auditing their actions is the frontier of identity security for the coming years. The secrets these agents handle are also a direct target for credential-theft malware like infostealers, which no longer chase only human passwords but also session tokens and keys.

Frequently asked questions

What is the difference between a human identity and a non-human identity?

A human identity belongs to a person who authenticates interactively, usually with a password plus a second factor (MFA). A non-human identity (NHI) is a principal assigned to a workload, service, application, device or automation rather than a person, and it operates with no human intervention and no MFA. How it proves who it is depends on authentication mechanisms that are separate from the identity itself: it may present a secret (an API key or a token), a certificate or ephemeral tokens, or authenticate with no static secret at all through managed identities, workload identity federation or assumable roles. NHIs tend to be far more numerous, more privileged, longer-lived and much less monitored than human ones.

Why does a stolen OAuth token bypass MFA?

Because MFA is checked during the login process, and an OAuth token already represents an authenticated session that comes after that login. If an attacker steals a valid token (from a log, a compromised integration or a machine's memory), they present it directly to the API and inherit the authenticated context without going through access again. That is why defense shifts to protecting, shortening the life of, and monitoring the use of tokens, not just hardening login.

What is a secrets vault and why do I need one?

A secrets vault is a centralized, encrypted system that stores machine credentials and delivers them to applications at runtime, with audited access and, ideally, short-lived dynamic secrets. You need it so that no secret lives in code, configuration files or logs, where they eventually leak. Examples: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault and Google Secret Manager.

How often should I rotate machine credentials?

The shorter, the better. The ideal is ephemeral dynamic secrets generated on demand. When that is not possible, rotate API keys, service account passwords and certificates automatically and periodically (weeks, not years). Remember that 47% of NHIs have gone more than a year without rotation: that is exactly the state an attacker hopes to find.

How do I start governing NHIs if I have no visibility?

Start with discovery and inventory. Locate every machine identity in your environment (cloud, on-premise, SaaS, CI/CD), assign each one a human owner and document its function. From there, prioritize by risk: the over-privileged and long-lived ones first, apply least privilege, enable rotation and deploy secret scanning. A red team exercise helps validate which NHIs are actually exploitable before an attacker finds out.

Put your non-human identities to the test

At Secra we assess NHIs from the perspective of whoever attacks them: we hunt for leaked secrets, excessive permissions and exploitable tokens before a real adversary does. If you want to know which machine credentials expose your organization, explore our penetration testing service or contact our team to design a tailored assessment.