What is workload identity?
By Identra · Updated
Workload identity is a verifiable identity assigned to a software workload, such as a pod, virtual machine, container, or serverless function, that lets it authenticate to other systems without static secrets. In its strongest form, the workload proves what it is through platform-attested, short-lived credentials issued and rotated automatically; in many platforms the identity is anchored in Kubernetes or cloud service accounts.
Key numbers
- Machine identities outnumber human identities 82 to 1 in the enterprise (CyberArk Identity Security Landscape, 2025)
- 23.8 million secrets leaked on public GitHub in 2024 (GitGuardian State of Secrets Sprawl, 2025)
- 70% of secrets leaked in 2022 were still active as of the 2025 report (GitGuardian State of Secrets Sprawl, 2025)
- SPIFFE and SPIRE graduated from the CNCF in 2022 (CNCF graduation announcement, 2022)
How does a workload assert an identity?
A workload cannot type a password, tap an MFA prompt, or walk to the help desk. Its identity has to be derived from facts the platform can verify about it. This process is called attestation: a trusted authority such as the Kubernetes API server, a cloud metadata service, or a hardware root of trust vouches for observable properties of the workload, including which node it runs on, which namespace and service account it belongs to, and which container image it was started from.
An identity provider then issues a credential based on those attested properties rather than on possession of a secret. Not every workload identity system goes this far: many are anchored in Kubernetes service accounts or cloud-native service identities with varying degrees of attestation. At its strongest, the model inverts the traditional one. A static API key says only that the caller once had access to a string. An attested workload identity says the caller is, right now, a specific piece of software running in a specific place, and the claim was verified by the platform itself.
What are SPIFFE and SVIDs?
SPIFFE, the Secure Production Identity Framework for Everyone, is the open standard for workload identity. It defines a uniform naming scheme, the SPIFFE ID, written as a URI such as spiffe://prod.example.com/payments/api, and a credential format called the SVID, or SPIFFE Verifiable Identity Document. An SVID is delivered as either an X.509 certificate or a JWT, is short-lived by design, and is rotated automatically without developer involvement.
SPIRE is the reference implementation that performs node and workload attestation and issues SVIDs. Both projects graduated from the Cloud Native Computing Foundation in 2022, a maturity signal reserved for production-proven infrastructure. Service meshes such as Istio issue SPIFFE-compliant identities natively, which is why many teams already run SPIFFE identities without having deployed SPIRE directly.
- SPIFFE ID: a stable, platform-neutral name for a workload
- SVID: a short-lived X.509 or JWT credential that proves the ID
- Trust bundle: the keys a workload uses to verify peers across trust domains
- Workload API: the local endpoint where a workload fetches its own identity
How does workload identity federation work in the cloud?
Every major cloud ships a native form of workload identity, and federation connects them. The common pattern is token exchange: the local platform issues the workload a signed OIDC token asserting who it is, and the target cloud's token service verifies that token and returns short-lived credentials scoped to a role. No long-lived key is ever created, stored, or copied between environments.
This is how a GitHub Actions job can deploy to AWS without a stored access key, how a Kubernetes pod on one cloud can read a bucket on another, and how a CI pipeline can sign artifacts with credentials that expire minutes later. The identity travels as a verifiable claim, not as a secret to protect.
- AWS: IAM roles for service accounts and instance profiles map platform identity to temporary credentials
- Google Cloud: workload identity federation exchanges external OIDC and SAML tokens for short-lived access
- Azure: managed identities and workload identity federation remove credentials from application code
- CI/CD: OIDC tokens from providers like GitHub Actions replace stored deploy keys
Why replace static secrets with short-lived credentials?
Static secrets fail in predictable ways: they get committed to repositories, pasted into tickets, baked into images, and forgotten. GitGuardian found 23.8 million secrets leaked on public GitHub in 2024 alone, and 70% of the secrets it detected leaking in 2022 were still active years later. A leaked static credential works for anyone who holds it, from anywhere, until someone notices and revokes it.
Short-lived attested credentials change the economics of theft. A stolen SVID or federated cloud token expires on its own, typically within minutes to an hour, so the damage window is bounded by cryptography rather than by detection speed. Rotation is continuous and automatic, which also removes the operational fear that makes teams avoid revoking credentials in the first place.
| Property | Static secret | Workload identity |
|---|---|---|
| Proof of identity | Possession of a string | Platform-attested properties |
| Lifetime | Months to years, often unbounded | Minutes to hours |
| Rotation | Manual, often skipped | Automatic and continuous |
| Theft blast radius | Valid until noticed and revoked | Expires on its own |
| Audit trail | Shared keys blur attribution | Per-workload, per-issuance |
What workload identity does not solve
Attestation is a point-in-time check at issuance. It proves what the workload was when the credential was minted, not what it is doing an hour later. A compromised pod holding a perfectly valid SVID is still a compromised pod, and workload identity alone says nothing about whether its behavior matches its purpose.
Scale compounds the gap. CyberArk's 2025 study found machine identities outnumber human identities 82 to 1, and workloads increasingly act on behalf of other identities: a human triggers a pipeline, the pipeline invokes a service, the service calls an AI agent. Workload identity names each link but does not govern the chain, the delegation, or the drift between granted access and actual use. That governance is a runtime problem.
How Identra thinks about it
Workload identity is the right foundation for the non-human majority, and adopting SPIFFE-style attested, short-lived credentials should be table stakes. But identity established at issuance is not identity secured at runtime. The credential proves what a workload was at minute zero; it cannot tell you that the same workload started reading secrets it never touched before at minute ninety, or that an AI agent is exercising a delegation no human intended. Identra treats the issued identity as the starting point and continuously verifies what human, non-human, and AI-agent identities actually do with it while they run.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between workload identity and a service account?
A service account is a standing account with a credential that software presents, and that credential is often a long-lived password or key. Workload identity replaces the stored secret with attestation: the platform verifies observable properties of the running workload and issues a short-lived credential based on them. The workload proves what it is right now, instead of proving it once held a string.
What is a SPIFFE ID?
A SPIFFE ID is a platform-neutral name for a workload, written as a URI such as spiffe://prod.example.com/payments/api. It is defined by SPIFFE, the Secure Production Identity Framework for Everyone, a CNCF-graduated open standard. The ID is proven by an SVID, a short-lived X.509 certificate or JWT that the SPIRE runtime or a service mesh issues and rotates automatically.
How does a GitHub Actions job deploy to AWS without stored keys?
Through workload identity federation. GitHub issues the running job a signed OIDC token asserting its repository, branch, and workflow. AWS verifies that token against a configured trust policy and returns temporary STS credentials scoped to a role: an access key ID, secret access key, and session token that expire shortly after the job finishes. No long-lived IAM access key is ever created or stored, so there is nothing durable to leak.
Does workload identity eliminate the need for secrets management?
Not entirely. Attested short-lived credentials remove static secrets from workload-to-platform authentication, which is the largest and leakiest category. But third-party APIs that only accept static keys, legacy systems, and cross-organization integrations still require managed secrets. Most programs run both: workload identity wherever the platform supports it, and vaulted, rotated secrets for everything that remains.