The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
Expanded Definition
Workload identity is the machine identity assigned to a running workload, not to a person, and it is used to prove which service, container, function, or agent is calling another system. In NHI operations, the term is often used alongside service identity, but usage in the industry is still evolving and definitions vary across vendors.
For modern systems, the practical value is that authentication can be tied to runtime context instead of static secrets. That matters for Kubernetes services, serverless functions, and distributed microservices where long-lived API keys create avoidable exposure. The SPIFFE workload identity specification is one of the clearest external references for this model, because it describes a portable identity for software workloads that can be verified and exchanged across platforms.
At NHIMG, workload identity should be understood as part of the broader Ultimate Guide to NHIs view of lifecycle, visibility, and governance. The most common misapplication is treating workload identity as a synonym for a hard-coded secret, which occurs when teams bind authentication to a token stored in code or a CI/CD variable.
Examples and Use Cases
Implementing workload identity rigorously often introduces deployment complexity, requiring organisations to weigh stronger authentication and revocation against setup overhead and platform coupling.
- A Kubernetes pod receives a short-lived identity at startup and uses it to call a database without embedding a password in the container image.
- A serverless function authenticates to a message queue through its runtime identity, reducing dependence on shared secrets and manual key rotation.
- A microservice-to-microservice call chain uses workload identity for mutual authentication, improving traceability across distributed requests.
- An AI agent with tool access uses workload identity to obtain scoped credentials only for the services it needs, limiting blast radius if execution is abused.
- A platform team aligns workload identity issuance with the patterns described in Guide to SPIFFE and SPIRE when it needs portable identity across clusters and environments.
These use cases become more important as organisations move from static service accounts to ephemeral infrastructure. In breach analysis, 52 NHI Breaches Analysis shows how frequently identity sprawl and weak secret handling become entry points. The SPIFFE workload identity specification is especially useful where federated clusters need consistent trust assertions without reissuing permanent credentials.
Why It Matters in NHI Security
Workload identity is foundational because it determines whether a system can authenticate software safely without relying on secrets that can be copied, leaked, or reused. When workload identity is absent or poorly governed, teams often fall back to shared tokens, broad service accounts, or static certificates that outlive the workload they were meant to protect.
That creates real operational risk. In Ultimate Guide to NHIs, NHIMG notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and that 79% have experienced secrets leaks. Those conditions are especially dangerous for workloads because the credential is often embedded in automation, replicated across environments, or inherited by downstream services. Workload identity reduces that exposure by making access more ephemeral, more attributable, and easier to revoke. It also supports Zero Trust patterns where each call is verified instead of trusted by network location alone.
Organisations typically encounter workload identity as an urgent issue only after a leaked token, a compromised service account, or a failed certificate rotation makes service-to-service trust 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 SPIFFE/SPIRE and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SPIFFE/SPIRE | Defines portable workload identities and trust domains for service authentication. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses secret sprawl and weak machine identity handling for workloads. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Supports per-request, least-privilege access for non-human service callers. |
Issue verifiable workload identities and exchange them through SPIFFE-aligned trust workflows.
