A non-human identity (NHI) is any identity that software uses instead of a person: service accounts, API keys, access tokens, certificates, and encryption keys used by applications, scripts, pipelines, and cloud services. OWASP, which published a Non-Human Identities Top 10 for 2025, illustrates the term with exactly these examples. The service account risk is that they are easy to create and easy to forget, often hold high privilege, and cannot answer an MFA prompt, so one leaked secret works for whoever holds it until someone notices.

Why they get overlooked

  • No person behind them: there is no joiner-mover-leaver process and no manager to ask whether it is still needed
  • Created for a project and kept forever: OWASP ranks improper offboarding first, meaning unused service accounts and access keys that are not deactivated or removed
  • Secrets travel: keys end up in source code, plain-text configuration files, and chat tools
  • Privilege creeps up: broad access granted to make something work, then never reduced
  • Outside processes built for people: access reviews and MFA programs usually count human users only

Standards reflect this split. NIST SP 800-63-4 (Digital Identity Guidelines, final in 2025) covers identity proofing, authentication, and federation for natural persons, and states that machine-to-machine authentication is out of scope. So the passkey and MFA guidance that comes from 800-63 is not the answer for machines. For machines and services, look to controls in NIST SP 800-53 such as IA-9 (uniquely identify and authenticate services before communicating), IA-5(7) (no embedded unencrypted static authenticators in applications or other static storage), AC-6 (least privilege, which also applies to processes acting on behalf of users), and AC-2 (account management, including monitoring account use and disabling accounts that are no longer needed).

The OWASP NHI Top 10 (2025)

OWASP's 2025 list names these ten risks. We grouped them into five themes in the graphic below to make them easier to act on.

  • NHI1 Improper Offboarding: unused service accounts and access keys are not deactivated or removed
  • NHI2 Secret Leakage: API keys, tokens, and certificates in source code, plain-text config, or chat tools
  • NHI3 Vulnerable Third-Party NHI: compromised IDE extensions or SaaS integrations expose the credentials they hold
  • NHI4 Insecure Authentication: deprecated or weak authentication methods
  • NHI5 Overprivileged NHI: far more access than the function needs
  • NHI6 Insecure Cloud Deployment Configurations: CI/CD pipelines with static cloud credentials, or OIDC setups that lack token validation and claim conditions
  • NHI7 Long-Lived Secrets: credentials that expire far in the future or never
  • NHI8 Environment Isolation: the same NHI shared across dev, test, staging, and production
  • NHI9 NHI Reuse: one NHI serving multiple applications
  • NHI10 Human Use of NHI: people using service identities for manual work, which hides who did what
INFOGRAPHIC
The OWASP NHI Top 10 in five themes
NHI risk
OWASP's ten, grouped by us
Lifecycle
NHI1, NHI7: never retired, never expires
Secrets handling
NHI2, NHI4: where kept, how used
Blast radius
NHI5, NHI8, NHI9: excess, shared
Supply chain and pipelines
NHI3, NHI6: integrations, CI/CD
Accountability
NHI10: people using machine IDs

A real example: a forgotten test app

In January 2024 Microsoft disclosed that the group it calls Midnight Blizzard used password spraying to compromise a legacy, non-production test tenant account that did not have MFA. From there, according to Microsoft, the actor compromised a legacy test OAuth application that had elevated access to the corporate environment and used it to grant the Exchange Online full_access_as_app role, which allows access to mailboxes. The lesson is that the weak point was a forgotten test app identity that still held elevated access, the pattern NHI1 and NHI5 describe.

INFOGRAPHIC
How a forgotten test app opened a path (Microsoft, 2024)
01
Password spray
old test account, no MFA
02
Legacy test OAuth app
elevated corporate access
03
Role granted
full_access_as_app
04
Mailbox access
some corporate mailboxes

Safer patterns: fewer secrets, shorter lives

The most effective change is to need fewer long-lived secrets. According to vendor documentation, cloud platforms now offer ways to prove a workload's identity without storing a password or key.

  • Platform-managed identities: Microsoft says Azure managed identities let applications get Microsoft Entra tokens without managing credentials, and that the credentials are not even accessible to you
  • Avoid downloaded keys: Google Cloud compares a service account key to a password, says attackers look for leaked keys in public repositories, public buckets, and breach dumps, and recommends a safer alternative whenever possible, such as an attached service account or Workload Identity Federation. If you must use keys, it suggests disabling key creation by organization policy and allowing exceptions
  • Short-lived tokens in pipelines: with OIDC in GitHub Actions, each job gets a token and exchanges it for a short-lived cloud token valid only for that job, so no long-lived cloud credentials need to be stored in GitHub
  • Short-lived tokens in Kubernetes: since v1.22, Pods get a short-lived, automatically rotating token through the TokenRequest API, while earlier versions used a long-lived static token in a Secret. The documentation also covers RBAC for least privilege and the automountServiceAccountToken setting to stop unneeded credential injection
  • Vault and rotate what remains: if a secret is unavoidable, use one per application and environment, give it an expiry, and rotate it. Google's guidance suggests a dedicated service account per application and a separate key per machine for traceability
INFOGRAPHIC
Credential shape, from riskiest to safest
Shared static key in code
easy to leak, hard to trace
Static key, never rotated
kept in config or plain storage
Vaulted and rotated
needs an expiry
Short-lived token on demand
OIDC, bound tokens
Platform-managed identity
no secret to handle
Higher riskLower risk

AI agents are the next wave of NHIs

AI agents and MCP servers hold tokens and call APIs on someone's behalf, so they are NHIs too. In February 2026, NIST's NCCoE released a concept paper on software and AI agent identity and authorization and asked for public input (comments closed April 2, 2026) on identification, authorization, auditing, and non-repudiation of AI agents. It was an early-stage proposal, and we have not verified progress since, so check the NCCoE project page for updates. For defenses you can apply now, see the MCP security guide and agentic AI security.

Common mistakes

  • Counting only human users: an access review that skips service accounts leaves a blind spot
  • Sharing one key across environments or apps: NHI8 and NHI9, where one leak reaches everything
  • Rotating nothing because it might break something: rotate in test first and make sure an owner knows what depends on each key
  • Vaulting a secret but never expiring it: storage is safer but the secret is still long-lived (NHI7)
  • Letting people log in as the service account: logs show the service account name, not who acted (NHI10)
  • Ignoring third-party integrations: OAuth apps and SaaS connectors hold standing access (NHI3)
  • Deleting accounts without checking dependencies: disable first, watch for breakage, then delete
INFOGRAPHIC
Typical state versus target state of an NHI

Typical today

  • No ownernobody can say who uses it
  • Shared across systemsone key, many apps and environments
  • Never expiresworks forever if leaked

Target

  • Named ownersomeone is accountable
  • One per app and environmenta leak has limited reach
  • Short life, reviewedexpires and is checked regularly

Start today

  • Inventory NHIs: service accounts, API keys, certificates, OAuth apps, CI/CD secrets, and cloud workload identities. Record owner, purpose, environment, and last use
  • Assign an owner to each one: those without an owner are the first candidates to disable
  • Hunt for leaked secrets: scan repositories, config files, and chat channels for credentials, and rotate any you find
  • Disable unused accounts first: check last sign-in and watch for impact before deleting
  • Cut privileges: start with those holding admin or owner rights
  • Pilot replacing one static key with a managed identity or short-lived token to set a pattern for the team

Check where your identity controls stand with the self-assessment, then pick two or three items from the list above to do first. Privileged human accounts have their own guidance in PAM Explained, and the architecture view is in Zero Trust Architecture: Components and Roadmap.

Certificates are machine identities too. See how to manage them in Certificate Lifecycle Management in the 47-Day Era.

Over-privileged program accounts in the cloud are something a CNAPP helps to check; see the overview in the CNAPP article.

The tokens and API keys that connect SaaS apps are machine identities. For reviewing connected apps, see SaaS Security and SSPM: Looking After SaaS Apps.

References and further reading