A non-human identity (NHI) is any digital identity used by software, rather than a person, to authenticate and gain access: service accounts, API keys, OAuth applications, tokens, certificates, workload identities, bots and AI agents. NHIs do most of the work in a modern estate and hold much of its access, yet they have no HR record, no manager and no second factor, so they are created quickly, rarely reviewed and often never retired. This page is the NHI Mgmt Group overview of the whole field: what counts as an NHI, how NHIs authenticate, how their lifecycle and ownership work, the OWASP NHI Top 10 (2025) risks at a glance, the controls that matter at each maturity level and where the standards sit. It is written for identity, cloud, platform and security leaders who need one map of the subject, and it links every deeper NHI guide we publish rather than repeating them.
Key takeaways
- An NHI is defined by who uses it, not by its format. A service account, an API key, a client secret, an X.509 certificate and an AI agent's token are all NHIs because software presents them to gain access.
- Credentials are the identity. Most NHIs authenticate by possession of a secret or key, so a leaked secret is a stolen identity, and MFA does not help. Removing static secrets is the strongest single control.
- Ownership is the missing control. NHIs have no natural lifecycle trigger, so every one needs a named human owner, a purpose and an expiry, or it becomes orphaned and stays valid after the project or person has gone.
- The OWASP NHI Top 10 (2025) is the shared risk language. Offboarding, secret leakage, third-party NHIs, weak authentication and overprivilege head the list, and the major NHI breaches map onto it cleanly.
- Govern NHIs as a programme, not a tool. Inventory, ownership, credential hygiene, least privilege, monitoring and decommissioning have to work together; the NHI Governance Maturity Model gives a way to measure progress.
What the field covers
Non-human identity security is the part of identity and access management that deals with identities used by machines and software. NIST SP 800-63-4, the main digital identity standard, is explicitly scoped to natural persons, and it does not set rules for machine-to-machine authentication. NHI security fills that gap. It overlaps with several neighbouring disciplines, and it helps to be precise about the boundaries.
| Discipline | What it focuses on | Where it meets NHI |
|---|---|---|
| Workforce IAM and IGA | People: joiners, movers, leavers, access reviews | Service accounts and app registrations live in the same directories; NHIs need review campaigns designed for machines |
| Secrets management | Storing, issuing, rotating and scanning for secrets | The credential layer of most NHIs; see the Secrets Management Guide |
| Machine identity and PKI | Certificates, keys and their lifecycle | Certificates authenticate servers, workloads and devices; see the Machine Identity, PKI and Certificate Lifecycle Guide |
| Cloud and workload identity | IAM roles, managed identities, federation | Platform-issued identities are the secretless form of NHI; see the Workload Identity Federation Guide |
| Privileged access management | Admin accounts, sessions and elevation | Many NHIs are privileged by default; humans often borrow them |
| SaaS and OAuth governance | Connected apps, consents and scopes | Third-party integrations hold refresh tokens into your tenants |
| Agentic AI identity | AI agents acting on tools and data | Agents are NHIs that act for a person; see the Agent Identity and Access Guide |
For a side-by-side comparison of people and machines across ownership, authentication, lifecycle and review, see Human vs Non-Human Identity.
Core concepts
Types of non-human identity
| NHI type | Typical examples | Usual credential | Main weakness |
|---|---|---|---|
| Directory service accounts | Active Directory service accounts, gMSA and dMSA, Entra ID service principals | Password, managed password, client secret or certificate | Non-expiring passwords, interactive logon, broad group membership |
| Cloud identities | AWS IAM users and roles, Azure managed identities, Google Cloud service accounts | Access keys, service account keys, or platform-issued short-lived tokens | Long-lived keys, IAM-write permissions, cross-account trust |
| API keys and tokens | SaaS API keys, GitHub personal access tokens, Slack bot tokens | Bearer string | No expiry, broad scope, copied into code and chat |
| OAuth applications | Connected apps, app registrations, machine-to-machine clients | Client secret or private key JWT; refresh and access tokens | Over-broad scopes, forgotten consents, vendor compromise |
| Workloads | Kubernetes service accounts, containers, functions, CI/CD jobs | Projected tokens, OIDC federation, SPIFFE SVIDs | Default tokens mounted everywhere, loose federation conditions |
| Certificates and keys | TLS server certificates, mTLS client certificates, SSH keys, code-signing keys | Private key | Unknown expiry, unmanaged authorized_keys, key reuse |
| Bots and automation | RPA bots, scheduled scripts, chat bots | Stored user credentials or service accounts | Run as a human account, shared between processes |
| Devices | IoT sensors, OT controllers, network devices | Device certificates, shared keys, SNMP strings | Factory defaults and shared secrets across a fleet |
| AI agents | Coding agents, assistants with tool access, MCP clients | Delegated OAuth tokens, API keys | Borrowed user credentials, unclear delegation, prompt-driven misuse |
Identity, credential and permission
Three things are often confused. The identity is the account or principal (a service principal, an IAM role). The credential is what proves it (a secret, key, token or certificate). The permission is what it can do (roles, scopes, policies). One identity may have several credentials, and one credential may be copied into many places. Inventory has to cover all three, because rotating a credential without knowing its consumers breaks production, and removing an identity without checking its permissions can leave an orphaned role that something else can assume.
How NHIs authenticate
- Shared secrets: passwords, API keys and client secrets. Simple and universal, but bearer-only: whoever holds the string is the identity.
- Asymmetric keys and certificates: mutual TLS, private key JWT client authentication and SSH keys. The private key never leaves its holder, but expiry and issuance must be managed.
- Platform-issued and federated identity: cloud instance roles, Kubernetes projected service account tokens, GitHub Actions OIDC tokens exchanged for cloud credentials, and SPIFFE workload identities. No static secret is stored; credentials last minutes or hours.
- Delegated tokens: OAuth access and refresh tokens that let an application or agent act for a user or another service.
The direction of travel is from the first group to the third. See the NHI Authentication Guide and the Machine-to-Machine OAuth (Client Credentials) Guide.
The NHI lifecycle
- Request and create: record purpose, owner, environment, data touched and an expiry date at creation, ideally through infrastructure as code or a self-service workflow.
- Issue credentials: prefer federated or short-lived credentials; where a secret is unavoidable, issue it into a vault, never into a ticket or chat.
- Grant access: least privilege from the start, scoped to one workload and one environment.
- Operate and rotate: rotate on a schedule and on events (owner leaves, suspected exposure, vendor breach), and monitor use against a baseline.
- Review and attest: owners confirm the NHI is still needed and correctly scoped. See the NHI Ownership Attestation Campaigns Guide.
- Decommission: revoke credentials first, then disable, then delete after a hold period, and check nothing still depends on it. See the NHI Offboarding and Decommissioning Guide.
Secrets and their sprawl
A secret is any credential that grants access when presented. Secrets spread into source code and Git history, .env files, container image layers, CI/CD variables, infrastructure state files, wikis, tickets and chat. Each copy is a new place to leak from and a consumer that breaks when the secret is rotated. Secret sprawl is why leaked credentials (ATT&CK T1552.001 Credentials In Files, T1552.004 Private Keys) remain one of the most common ways into cloud estates. For numbers on the scale of the problem see the Non-Human Identity and Secrets Statistics Guide, and for measuring your own see the Secret Sprawl Measurement Guide.
Main threats
The OWASP NHI Top 10 (2025) at a glance
The OWASP Non-Human Identities Top 10 is the standard reference list of NHI risks. Each entry links to our planned per-risk deep dive.
| ID | Risk | What it means in practice | Deep dive |
|---|---|---|---|
| NHI1 | Improper Offboarding | NHIs and credentials stay valid after the app, project or owner has gone | NHI1 guide |
| NHI2 | Secret Leakage | Keys and tokens exposed in code, images, logs or chat | NHI2 guide |
| NHI3 | Vulnerable Third-Party NHI | Vendor integrations and extensions holding tokens into your tenant | NHI3 guide |
| NHI4 | Insecure Authentication | Deprecated or weak methods, shared static keys | NHI4 guide |
| NHI5 | Overprivileged NHI | Admin or owner rights granted "so it works" and never reduced | NHI5 guide |
| NHI6 | Insecure Cloud Deployment Configurations | Static cloud secrets in pipelines, loose OIDC trust | NHI6 guide |
| NHI7 | Long-Lived Secrets | Credentials with no expiry or multi-year lifetimes | NHI7 guide |
| NHI8 | Environment Isolation | The same NHIs or trust spanning test and production | NHI8 guide |
| NHI9 | NHI Reuse | One identity shared across many workloads | NHI9 guide |
| NHI10 | Human Use of NHI | People signing in as or holding machine credentials | NHI10 guide |
Our own ranking by breach evidence, with first controls for each, is in the Top 10 NHI Risks.
How attackers use NHIs
- Harvest secrets: scan public and private repositories, images and storage for keys (T1552.001).
- Use valid cloud accounts: sign in with stolen access keys or tokens, which looks like normal automation (T1078.004 Cloud Accounts).
- Steal and replay tokens: take OAuth tokens from a vendor or an endpoint and use them against SaaS APIs (T1528 Steal Application Access Token, T1550.001 Application Access Token).
- Abuse trusted relationships: enter through a supplier's integration that already holds access (T1199 Trusted Relationship).
- Persist with new credentials: add a key or secret to an existing service principal or IAM user (T1098.001 Additional Cloud Credentials).
Common failure patterns
- Rotation that skips "unused" credentials: after the Okta support system breach, Cloudflare rotated thousands of credentials but left one service token and three service accounts it believed were unused, and a likely nation-state attacker used them in November 2023 to reach Confluence, Jira and Bitbucket. See the Cloudflare Thanksgiving breach. Rotate everything in scope, and prove an NHI is unused before skipping it.
- Keys committed by a supplier: a Toyota T-Connect subcontractor pushed source code containing a data server access key to a public GitHub repository in December 2017, and it stayed public until September 2022. See the Toyota T-Connect key exposure. Scanning and push protection must cover contractors' repositories too.
- One service account with production-wide reach: at Dropbox Sign, an attacker reached a back-end service account through an automated system configuration tool, and its production privileges exposed customer API keys, OAuth tokens and MFA details. See the Dropbox Sign breach.
- Inventory limited to one platform: teams count Active Directory service accounts and miss cloud keys, SaaS tokens and OAuth apps, which is where most exposure now sits.
- Owner equals creator: ownership is recorded as whoever made the NHI, so it lapses as soon as that person moves team.
- Vaulting without removing the copies: a secret is moved into a vault but still lives in old config files and Git history, so it is now managed in one place and leaked in five.
Key controls by maturity
The NHI Governance Maturity Model developed by NHI Mgmt Group describes five levels: Ad hoc, Developing, Defined, Managed and Optimised. The table summarises the controls that characterise each stage; the model itself scores eight dimensions separately.
| Level | Inventory and ownership | Credentials | Access | Monitoring and response |
|---|---|---|---|---|
| 1 Ad hoc | No inventory, no owners | Secrets in code and config | Broad standing permissions | Found through incidents |
| 2 Developing | Discovery on main platforms; owners for top-risk NHIs | Secrets scanning, vault for part of the estate | Admin NHIs identified | Leaked-secret alerts triaged manually |
| 3 Defined | Inventory across cloud, directory, SaaS and code; every in-scope NHI owned | Policy for storage, rotation and lifetime | Least-privilege standard; NHIs in access reviews | NHI activity logged; leak playbook adopted |
| 4 Managed | Owner assigned at creation; attestation campaigns | Federated and short-lived by default; automated rotation | Right-sizing from activity data | Behavioural baselines and alerts |
| 5 Optimised | Continuous discovery including third-party and agent NHIs | Largely secretless, ephemeral credentials | Just-in-time, task-scoped access | Automated revocation on high-confidence detections |
A phased programme
- Discover (weeks 1 to 6): pull NHIs from the identity provider, each cloud's IAM, Kubernetes, CI/CD, source control, the vault and the top SaaS platforms. Record identity, credential type, age, last use and permissions. Use the Service Account Inventory Template as the record format.
- Stop the bleeding: turn on secrets scanning with push protection, revoke any secret found exposed (revoke first, then clean history), and follow the Leaked Credential Response Playbook.
- Assign owners: start with NHIs holding admin, owner or IAM-write rights. Unowned NHIs that nobody claims go into a quarantine path: disable, wait, then delete. See the NHI Ownership Guide.
- Publish policy: adopt the NHI Policy Template covering creation, ownership, maximum credential lifetimes, rotation and decommissioning.
- Replace static secrets: move CI/CD to OIDC federation and cloud workloads to managed identities, highest-privilege first. Test each change in a non-production environment and keep the old credential disabled, not deleted, for a short rollback window.
- Right-size and monitor: remove unused permissions based on 60 to 90 days of activity, baseline NHI behaviour and alert on deviations. Prioritise with the NHI Risk Scoring Guide.
Small and large organisations
- Small teams and start-ups: use the cloud provider's native federation and secret store, ban personal access tokens for automation, and keep one spreadsheet inventory with owners. The Startup Identity and Secrets Security Guide lists the first controls.
- Large enterprises: expect tens of thousands of NHIs across several clouds and hundreds of SaaS tenants. A dedicated NHI security platform becomes worthwhile when discovery, ownership mapping and posture checks cannot be kept current by scripts. See the NHI Security Platform Buyer's Guide.
- Build or buy: native cloud tools are usually enough for one cloud and a handful of SaaS apps; cross-platform correlation of an identity, its secrets and its consumers is where commercial tools earn their cost.
Detection and measurement
Log and alert on: NHI sign-ins from new IP ranges, regions or autonomous systems; interactive sign-ins by service accounts; new keys or secrets added to existing principals; use of a credential after its owner has left; and API calls outside an NHI's normal set. Useful metrics:
- Percentage of NHIs with a named, current owner.
- Number of static secrets older than the policy maximum, by platform.
- Percentage of workloads using federated or short-lived credentials.
- Mean time to revoke a leaked credential, from detection to revocation.
- Number of NHIs holding admin-level permissions, and days since last review.
- Stale or orphaned NHIs found and removed per quarter.
Roles and ownership
Most NHI problems are accountability problems. A workable model separates three roles and records them for every NHI.
| Role | Typical holder | Accountable for |
|---|---|---|
| Business or application owner | Product or service owner | Whether the NHI should exist and what data it may touch; signs off attestations |
| Technical owner | Engineering team (a team, not an individual) | Configuration, rotation, consumers and decommissioning |
| Programme owner | Identity or security team | Policy, inventory, tooling, metrics and exception handling |
| Platform teams | Cloud, Kubernetes, CI/CD and SaaS administrators | Guardrails that make the secure path the default, such as blocking key creation |
| Executive sponsor | CISO or CIO | Risk acceptance and reporting to the board; see Board Briefing: NHI Risk |
Record the owning team rather than one person, map it to the HR or org-chart system so leavers trigger a transfer, and treat a lapsed owner as a finding with a deadline.
Standards and frameworks
No single standard governs NHIs, but the main frameworks already contain the right controls once you read "users, services and devices" literally. NIST CSF 2.0 PR.AA-01 says identities and credentials for authorised users, services and hardware are managed by the organisation. The NCSC zero trust principles ask organisations to identify every user, service and device uniquely. NIST SP 800-207 bases access on the identity of the requester rather than its network location.
| Framework | Controls that apply to NHIs | NHI interpretation |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, PR.AA-05, GV.RR-02 | Manage, authenticate and authorise services and hardware; assign responsibility |
| NIST SP 800-53 Rev. 5 | IA-4, IA-5, IA-9, AC-2, AC-6, SC-12, SC-17, AU-6 | Identifier and authenticator management, service authentication, account management, least privilege, key and certificate management, log review |
| CIS Controls v8.1 | 5 Account Management, 6 Access Control Management, 3 Data Protection | Inventory and manage service accounts; restrict their access |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, 8.2 Privileged access rights, 8.5 Secure authentication | Apply the same controls to machine identities and their secrets |
| OWASP NHI Top 10 (2025) | NHI1 to NHI10 | Risk taxonomy for prioritisation and reporting |
| MITRE ATT&CK v20 | T1078.004, T1552.001, T1528, T1550.001, T1098.001, T1199 | Detection engineering for NHI misuse |
For workload-to-workload authentication in microservices, NIST SP 800-204A describes service mesh patterns with a secure token service and key management. AI agents add their own framework layer; see the Agent Identity and Access Guide.
Where to go next
New to Non-Human Identity (NHI)? These are the foundational guides to read first.
Start here
- Human vs Non-Human Identity: how machine identities differ from people across every governance dimension.
- Top 10 NHI Risks: the ten NHI risks ranked by breach evidence, mapped to OWASP.
- NHI Governance Maturity Model: five levels and eight dimensions to assess and plan.
- NHI Policy Template: a usable policy for ownership, credentials, rotation and retirement.
- NHI Ownership Guide: assigning and maintaining owners for machine identities.
- Service Account Security Guide: finding, reducing and governing service accounts.
- NHI Authentication Guide: moving machines from shared secrets to stronger methods.
- Machine Identity, PKI and Certificate Lifecycle Guide: certificate inventory, issuance and renewal.
- CI/CD Pipeline Identity Security Guide: pipeline credentials, OIDC federation and runner identity.
- Leaked Credential Response Playbook: responding to an exposed secret or credential.
- NHI Security Platform Buyer's Guide: requirements and questions for NHI tooling.
- OWASP NHI Top 10 NHI1 Improper Offboarding Guide to OWASP NHI Top 10 NHI10 Human Use of NHI Guide: one guide per risk, linked from the table above.
Browse all Non-Human Identity (NHI) guides
Practitioner checklist
- Build an NHI inventory across directory, every cloud, Kubernetes, CI/CD, source control, vaults and the top SaaS platforms.
- Record for every NHI an owning team, a purpose, an environment and an expiry date.
- Turn on secrets scanning with push protection everywhere code lives, including supplier repositories you control.
- Set maximum lifetimes per credential type and alert on anything older.
- Replace static cloud keys in pipelines and workloads with federation or managed identities, highest-privilege first.
- Find NHIs with admin, owner or IAM-write rights and right-size them from activity data.
- Block interactive logon for service accounts and alert on human use of NHI credentials.
- Issue separate identities per workload and per environment; never share one across production and test.
- Include rotation of every NHI in scope in vendor-breach and leaver workflows, and prove an NHI is unused before skipping it.
- Score yourself against the NHI Governance Maturity Model and report the six metrics above quarterly.
Standards and references
- OWASP: Non-Human Identities Top 10
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: SP 800-207, Zero Trust Architecture
- NIST: SP 800-204A, Building Secure Microservices-based Applications Using Service-Mesh Architecture
- NCSC: Zero trust architecture design principles
- CIS: Critical Security Controls v8.1
- MITRE ATT&CK: Valid Accounts: Cloud Accounts
Related NHI Mgmt Group resources: Top 10 NHI Risks · NHI Governance Maturity Model · Secrets Management Guide · Workload Identity Federation Guide · Human vs Non-Human Identity