Machine identity, workload identity and non-human identity (NHI) are used as if they mean the same thing, and programmes that never settle the terms end up with inventories that miss whole classes of credential. The three terms overlap but they are not synonyms: they differ in what they cover, which standards define them and which controls they imply. This guide sets out a working definition of each, compares them side by side, shows where the boundaries sit (devices, certificates, API keys, AI agents) and explains how to use the terms in scope statements, policies and tooling decisions. It is for identity architects, NHI programme leads and auditors who need a scope that holds up. For the field overview see the Non-Human Identity (NHI) Guide, and for the human side of the line the Human vs Non-Human Identity page.
Key takeaways
- NHI is the widest term. It covers every identity that is not a person: service accounts, workloads, devices, API keys, tokens, certificates, bots and AI agents. NIST's older equivalent is the non-person entity (NPE).
- Workload identity is the narrowest and best defined. It means an identity issued to running software, ideally through attestation and short-lived credentials, and it has real specifications behind it: SPIFFE and the IETF WIMSE architecture draft.
- Machine identity has two meanings. In the PKI market it means certificates and keys that identify machines; in cloud and Microsoft usage it is a synonym for non-human identity. Say which one you mean.
- The words drive the scope. A "workload identity" programme that ignores static API keys, legacy service accounts and third-party tokens leaves the credentials most often leaked out of scope.
- Use all three, in layers. NHI for governance scope, workload identity as the target issuance pattern, and machine identity (in the PKI sense) for certificate lifecycle. One inventory, three lenses.
The short answer
Non-human identity is the umbrella: any digital identity that acts in your systems but is not a human user. Machine identity is either a synonym for NHI or, in its older and narrower sense, the cryptographic identity of a machine (an X.509 certificate and its private key, an SSH host key). Workload identity is a subset of NHI: the identity of a running piece of software, such as a container, function, virtual machine process or pipeline job, preferably issued at runtime by the platform rather than stored as a secret.
A rule of thumb that works in most organisations: if it is a person, it is human identity; if it is software at runtime, it is workload identity; if it is a physical or virtual device, it is device identity; everything that is not a person (all of the above plus keys, tokens, bots and agents) is NHI. Machine identity then sits wherever your organisation decides, so write the decision down.
Where each term comes from
Non-human identity (NHI)
NHI is a practitioner term that became mainstream through the OWASP Non-Human Identities Top 10 (2025). OWASP does not give a one-line definition; it describes production environments made up of many applications that need to be identified, each tied to secrets that act as credentials, and its examples include service accounts, access keys, API keys, tokens, encryption keys, certificates and the OIDC tokens that CI/CD pipelines use to reach cloud services. Its ten risks (NHI1 Improper Offboarding through NHI10 Human Use of NHI) are about the identities and their secrets together, which is why NHI programmes usually inventory credentials as well as accounts.
The closest standards term is NIST's non-person entity (NPE): an entity with a digital identity that acts in cyberspace but is not a human actor, covering organisations, hardware objects, software objects and information artefacts (CNSSI 4009-2022, used in NIST SP 800-207). NPE is broader than most NHI programmes, because it includes organisations and data artefacts.
Workload identity
Workload identity has the most precise specifications:
- SPIFFE: defines a workload as a single piece of software deployed with a particular configuration for a single purpose. Its identity is a SPIFFE ID of the form
spiffe://trust-domain/workload-identifier, carried in an X.509-SVID or a JWT-SVID and delivered through the Workload API, so no authentication secret has to be deployed with the workload. See the SPIFFE and SPIRE Guide. - IETF WIMSE: the architecture draft (draft-ietf-wimse-arch-08, an Internet-Draft dated 6 July 2026, intended as Informational and still subject to change) describes a workload as an independently addressable and executable software entity, and builds workload identity from three blocks: a trust domain, a workload identifier and workload identity credentials (X.509 certificates or Workload Identity Tokens, optionally bound to a key). See the WIMSE Workload Identity Architecture Guide.
- Cloud platforms: Microsoft Entra defines a workload identity as an identity assigned to a software workload (an application, service, script or container) and implements it as applications, service principals and managed identities. AWS IAM roles, Google Cloud service accounts with Workload Identity Federation and Kubernetes service accounts fill the same role.
- NIST SP 800-207A: the zero trust model for cloud-native applications says access policy must be tied to application and service identities, not only network location, and names SPIFFE as an example identity infrastructure.
Machine identity
Machine identity has no single standards-body definition. It grew up in the certificate management market, where it meant the TLS certificates, code signing keys and SSH keys that let machines prove who they are. NIST's NCCoE TLS server certificate management project covers exactly this ground (inventory, ownership, monitoring, automation and crypto agility for certificates) without using the phrase. Cloud vendors later broadened it: Microsoft describes workload identities and device identities together as "machine (or non-human) identities". Both readings are in active use, which is why the term causes most of the scope arguments. For the PKI reading see the Machine Identity, PKI and Certificate Lifecycle Guide.
Side-by-side comparison
| Dimension | Machine identity | Workload identity | Non-human identity (NHI) |
|---|---|---|---|
| Scope | Narrow sense: certificates and keys of machines. Broad sense: same as NHI | Running software: containers, functions, VM processes, pipeline jobs, services | Everything that is not a person, including keys, tokens, bots and AI agents |
| Main reference | Industry usage; PKI and certificate lifecycle practice | SPIFFE, IETF WIMSE (draft), NIST SP 800-207A, cloud provider docs | OWASP NHI Top 10 2025; NIST NPE as the formal cousin |
| Typical credential | X.509 certificate and private key, SSH host key | Short-lived X.509-SVID, signed token (JWT-SVID, cloud OIDC token), platform-issued role credentials | Any: passwords, API keys, OAuth tokens, PATs, certificates, cloud access keys |
| How identity is established | Certificate issued by a CA after enrolment | Attestation of the runtime (node, pod, cloud instance metadata) by the platform | Varies: often a human creates an account or key and hands it over |
| Lifetime | Certificate validity period (public TLS validity is being shortened) | Minutes to hours, rotated automatically | Anything from minutes to "never expires" |
| Who owns it | PKI or infrastructure team | Platform engineering | Shared: IAM, security, application owners |
| Typical failure | Expired or unknown certificates, stolen signing keys | Over-broad roles, unattested or shared identities | Leaked static secrets, orphaned accounts, no owner |
| Best used for | Certificate lifecycle and cryptographic policy | Target pattern for new software-to-software access | Governance scope, inventory and risk reporting |
Boundary cases that cause arguments
| Item | Is it NHI? | Is it workload identity? | Is it machine identity? | Practical call |
|---|---|---|---|---|
| Static API key used by a cron job | Yes | It authenticates a workload, but it is a stored secret, not a runtime-issued identity | Broad sense only | In NHI scope; target for migration to workload identity |
| Active Directory service account | Yes | Rarely: usually a shared account with a password | Broad sense only | In NHI scope; consider gMSA (see the Group Managed Service Accounts (gMSA) Guide) |
| Kubernetes service account | Yes | Yes when using short-lived TokenRequest tokens; legacy static token Secrets behave like stored secrets | Broad sense | Workload identity, with checks for legacy tokens |
| TLS server certificate | Yes | Yes when issued to a workload (for example an X.509-SVID) | Yes in both senses | PKI lifecycle plus NHI inventory |
| Laptop or IoT device certificate | Yes | No: identifies hardware, not software | Yes | Device identity, tracked with the asset inventory |
| Human-owned personal access token | Debated: it acts as a person | No | No | Track as an NHI credential tied to a human owner |
| AI agent | Yes | Its runtime is a workload; its delegated authority is more than that | Broad sense | NHI with extra agent controls (see the Agent Identity and Access Guide) |
The two hardest cases are human-owned tokens and AI agents. Personal access tokens act with a person's rights but run unattended in scripts, so treating them only as human credentials hides them from NHI controls, and treating them only as NHIs hides who is accountable. Record both. AI agents run as workloads but act on delegated human intent, which brings in consent, scope of delegation and audit of each action, so a workload identity alone is necessary but not sufficient.
Why the choice of term matters
- Inventory scope: a programme scoped as "workload identity" tends to count cloud roles, managed identities and Kubernetes service accounts, and to miss SaaS API keys, AD service accounts and third-party OAuth grants. Those are where much of the OWASP NHI Top 10 risk sits (NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI7 Long-Lived Secrets). See NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
- Tool selection: certificate lifecycle tools, workload identity platforms and NHI security platforms solve different problems. Buying against the wrong term leaves gaps that look covered on paper.
- Ownership: PKI teams, platform teams and IAM teams each assume another owns the grey areas. Naming the umbrella (NHI) and assigning each sub-type to an owner closes that. See the NHI Ownership Guide.
- Audit language: NIST SP 800-53 separates organisational users (IA-2), devices (IA-3) and services (IA-9), and CSF 2.0 PR.AA-01 covers identities and credentials for users, services and hardware. Mapping your terms to these makes evidence easier to present.
- Target architecture: workload identity describes where you want to get to (attested, short-lived, no stored secret); NHI describes everything you have today. Confusing the two produces roadmaps that declare victory after the easy migrations.
Security trade-offs of each lens
| Lens | What it does well | What it misses if used alone |
|---|---|---|
| Machine identity (PKI sense) | Certificate expiry, key strength, CA trust, crypto agility | Passwords, API keys, OAuth grants, entitlements and ownership of non-certificate identities |
| Workload identity | Removes stored secrets through attestation and short-lived credentials; strong authentication between services | Legacy and SaaS credentials; authorisation sprawl (a well-authenticated workload with an admin role is still a risk); humans using workload identities |
| NHI | Complete inventory, ownership, lifecycle and risk across every non-human credential | Can stay at the governance level unless paired with a concrete target pattern for issuance |
Workload identity improves authentication, not authorisation. The Capital One breach used temporary role credentials issued by the platform, exactly the pattern workload identity recommends, and the damage came from a role that could read far more storage than a firewall needed. Pair every workload identity rollout with least privilege work (see the Least Privilege Techniques Guide).
How the three work together
A workable model uses NHI as the governance boundary and the other two as engineering patterns inside it.
- Define the umbrella in policy. Write one sentence in your identity policy: "A non-human identity is any account, credential or identity used by software, devices or automated processes rather than directly by a person, including service accounts, workload identities, API keys, tokens, certificates and AI agents." The NHI Policy Template has a starting point.
- Classify by sub-type. Give every inventory record a type: workload identity, service account, API key or token, certificate or key, device identity, agent. Record whether the credential is runtime-issued or stored.
- Assign owners per sub-type. Platform engineering for workload identity, PKI for certificates, IAM for directory service accounts, application owners for API keys, with the NHI programme owning the inventory and the risk view.
- Set workload identity as the default for new builds. New software-to-software access uses platform-issued, short-lived credentials (cloud roles, managed identities, federation, SPIFFE) unless an exception is approved. See the Cloud Workload Identity Guide.
- Migrate stored secrets by risk. Use NHI risk scoring to pick which static credentials move first: internet-exposed, privileged and long-lived ones. Roll out per application with the old credential kept disabled, not deleted, for a short rollback window, then revoke it.
- Keep the PKI lens for certificates. Certificates issued to workloads and devices stay in certificate lifecycle tooling for expiry and crypto agility, and link back to the NHI record for ownership.
Detection and measurement
Monitoring is the same whichever term you use; what changes is the denominator. Log credential creation, use and deletion for every sub-type (cloud audit logs, directory events, SaaS audit logs, CA issuance logs) and watch for workload identities used from unexpected places, which maps to ATT&CK T1078.004 Cloud Accounts and T1528 Steal Application Access Token. See Detection Engineering for Non-Human Identities Guide.
- Coverage by sub-type: percentage of NHI records with a type, an owner and a credential kind recorded.
- Runtime-issued share: share of software-to-software authentications using platform-issued, short-lived credentials rather than stored secrets.
- Static secret count and age: number of long-lived secrets in scope and their median age, trending down.
- Unowned NHIs: count of identities with no accountable owner, target zero for privileged ones.
- Certificate visibility: certificates found by discovery that were not in the inventory.
Common failure patterns
- Scoping by the vendor's word. Adopting a product category name as the programme scope, then discovering half the credentials sit outside it.
- Calling static secrets "workload identity". An API key stored in a pipeline variable authenticates a workload but has none of the properties (attestation, short life, automatic rotation) that make workload identity safer. The Toyota T-Connect key exposure shows how long such a key can stay valid once it leaks: almost five years in a public repository.
- Treating machine identity as certificates only. The certificate inventory is excellent and the thousands of API keys and service account passwords are unmanaged.
- Ignoring human-owned tokens. Personal access tokens fall between the human and NHI programmes and nobody reviews them.
- Stopping at authentication. Moving to workload identity and leaving the attached permissions untouched, so a compromised workload still reaches everything.
- Bolting agents on later. AI agents get created under whichever identity is easiest, often a shared service account, instead of their own identity with delegation recorded.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials for users, services and hardware are managed: covers all three terms |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, managed and reviewed with least privilege |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication | Workload and service identity |
| NIST SP 800-53 Rev. 5 | IA-3 Device Identification and Authentication | Device identity, machine identity in the PKI sense |
| NIST SP 800-53 Rev. 5 | IA-4, IA-5, AC-2, AC-6 | Identifier and authenticator management, account management and least privilege for every NHI |
| NIST SP 800-53 Rev. 5 | SC-12, SC-17 | Key management and PKI certificates |
| CIS Controls v8.1 | Safeguard 5.5 | Establish and maintain an inventory of service accounts |
| ISO/IEC 27001:2022 Annex A | A.5.16, A.5.17, A.5.18, A.8.5 | Identity management, authentication information, access rights, secure authentication |
| MITRE ATT&CK | T1078.004, T1528, T1552.001 | Abuse of cloud accounts, stolen application tokens, credentials in files |
| OWASP NHI Top 10 2025 | NHI1 to NHI10 | Risk catalogue written for the NHI umbrella |
Practitioner checklist
- Write one-sentence definitions of NHI, workload identity and machine identity into your identity policy and glossary.
- State which sense of machine identity your organisation uses, and stick to it in reports.
- Scope the NHI programme to the umbrella, not to a product category.
- Tag every inventory record with a sub-type and whether its credential is runtime-issued or stored.
- Assign an owning team per sub-type and an accountable owner per identity.
- Make platform-issued, short-lived workload identity the default for new services, with an exception process.
- Pair each workload identity migration with a permission review.
- Track human-owned tokens and AI agents explicitly, with both the human owner and the non-human credential recorded.
- Report the runtime-issued share and static secret count to leadership each quarter.
Standards and references
- OWASP: Non-Human Identities Top 10 2025
- SPIFFE: SPIFFE Concepts
- IETF: Workload Identity in a Multi System Environment (WIMSE) Architecture, Internet-Draft
- NIST: SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
- NIST CSRC Glossary: Non-Person Entity
- Microsoft Learn: What are workload identities?
- Kubernetes: Service Accounts
- NIST NCCoE: TLS Server Certificate Management
Related NHI Mgmt Group resources: Non-Human Identity (NHI) Guide, Cloud Workload Identity Guide, Machine Identity, PKI and Certificate Lifecycle Guide, API Keys vs OAuth Tokens Guide, NHI and IAM Glossary.