The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
Expanded Definition
Machine identity is the credentialed identity assigned to a workload, device, or service so it can prove who it is before exchanging data or invoking another system. In practice, definitions vary across vendors: some treat it as a narrow certificate-first concept, while others fold it into the broader NHI umbrella used for service accounts, API keys, and agent credentials. That broader view is the one NHI Management Group uses in governance and risk discussions, and it aligns with how identities now appear across cloud, CI/CD, and runtime environments. For implementation context, the idea maps closely to workload identity models described by NIST Cybersecurity Framework 2.0, especially where authentication, asset visibility, and least privilege are operational requirements.
The practical distinction is important: a machine identity is not just a certificate file or a token string. It is the managed trust relationship behind the credential, including issuance, rotation, ownership, and revocation. The most common misapplication is treating machine identity as a one-time provisioning task, which occurs when teams issue credentials without lifecycle ownership or renewal automation.
Examples and Use Cases
Implementing machine identity rigorously often introduces operational friction, requiring organisations to weigh strong authentication and auditability against certificate renewals, rotation schedules, and service uptime.
- A Kubernetes workload uses a short-lived identity to call an internal API, reducing static secret exposure while preserving service-to-service trust. This is a common pattern in workload identity guidance and in the Ultimate Guide to NHIs.
- A CI/CD runner signs builds and pulls deployment permissions only for the duration of the job, which limits standing access but requires accurate orchestration and revocation logic.
- A TLS certificate identifies a gateway or microservice to downstream systems, but if renewal is manual, certificate expiry can become an outage trigger rather than a security control. See the machine identity management gaps discussed in The Critical Gaps in Machine Identity Management report.
- An AI agent with tool access presents a machine identity when calling APIs, yet its execution authority must still be constrained through policy, not just credentials.
- A third-party integration authenticates with an API key stored in a secrets vault, making inventory and ownership essential to prevent shadow machine identities from accumulating.
For standards alignment, teams often use the identity and trust principles reflected in NIST Cybersecurity Framework 2.0, then add machine-specific lifecycle controls where the platform requires them. The terminology is still evolving, so a certificate-managed service and a broader workload identity are not always identical in every stack.
Why It Matters in NHI Security
Machine identities matter because they are often numerous, invisible, and overprivileged. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and that lack of inventory makes it difficult to know which identities still exist, which are active, and which can be safely revoked. That visibility gap is one reason machine identities become a breach path, especially when rotation is delayed or certificates are left unmanaged. The broader NHI context reinforces the same risk pattern: excessive privilege, secrets sprawl, and weak offboarding. See the Top 10 NHI Issues and 52 NHI Breaches Analysis for recurring failure modes.
Operationally, machine identity failures rarely stay contained. A missed renewal can stop a pipeline, an expired certificate can interrupt production traffic, and a stale credential can provide an attacker with persistent access after a compromise. That is why machine identity work sits at the intersection of governance, availability, and Zero Trust. Organisations typically encounter the full cost of machine identity weakness only after an outage, an audit finding, or a compromise, at which point the identity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Machine identities are NHI assets that need inventory, lifecycle control, and least privilege. |
| NIST Zero Trust (SP 800-207) | SC-12 | Zero Trust requires strong authentication and continuous validation for non-human workloads. |
| SPIFFE/SPIRE | SPIFFE defines workload identities and secure issuance patterns for service authentication. |
Treat machine identities as continuously verified subjects, not trusted network residents.
