What is workload identity?

Workload identity is a cryptographic identity issued to a piece of software (a container, function, VM or CI job) by the platform it runs on, after the platform attests what the workload is. The credential is short-lived and renewed automatically, so there is no long-lived secret to store, rotate or leak.

What is the difference between SPIFFE and SPIRE?

SPIFFE is the specification: the spiffe:// identifier format, the SVID credential formats (X.509 certificate or JWT) and the Workload API. SPIRE is the production implementation that attests nodes and workloads and issues SVIDs. Other systems, including service meshes, also issue SPIFFE-format identities.

Should I use X.509-SVIDs or JWT-SVIDs?

The SPIFFE project advises using X.509-SVIDs whenever possible, because bearer tokens are susceptible to replay if intercepted. JWT-SVIDs make sense when an L7 proxy or load balancer sits between two workloads and terminates TLS, so mutual TLS end to end is not possible.

What is workload identity federation?

Workload identity federation lets a workload exchange a token from its own platform (Kubernetes, GitHub Actions, another cloud) for a short-lived access token in a target cloud. AWS uses AssumeRoleWithWebIdentity, Google Cloud uses its Security Token Service following RFC 8693 token exchange, and Microsoft Entra uses federated identity credentials that match on issuer, subject and audience.

WIMSE (Workload Identity in Multi System Environments) is an IETF working group standardizing how workload identity is expressed and authenticated across call chains that span platforms. As of November 2026 its documents are Internet-Drafts, including an architecture, a workload identifier, mutual TLS and HTTP signature authentication, and a workload identity practices document in IETF Last Call. None is an RFC yet.

Workload identity 101: replacing long-lived secrets

Workload identity replaces long-lived secrets (API keys, client secrets, service account passwords) with short-lived credentials that the platform issues to a workload after verifying what it is. Instead of "here is my API key," the workload presents "here is a credential, valid for minutes, proving I am the payments service in the production cluster." Nothing long-lived is stored, so there is nothing to commit to git, paste into a CI variable, or forget to rotate. Use SPIFFE/SPIRE when you need one identity across platforms, and your cloud's native mechanism when the workload only talks to that cloud.

This guide is for platform and security engineers retiring static secrets. For the wider context, see what is machine identity and non-human identity security.

Why static secrets keep failing

A static secret authenticates whoever holds it, from anywhere, until someone rotates it. The breach record is consistent about what follows:

A credential extracted from a Docker image let attackers modify Codecov's Bash Uploader and collect CI secrets from customer pipelines (Codecov, 2021).
A compromised GitHub Action printed runner secrets into workflow logs (tj-actions/changed-files, 2025).
An admin token created with no expiry and stored in plaintext in a config repository opened a shared cluster (Zeabur, 2026).
An operator signed in to Microsoft Entra ID as applications using stolen client secrets across dozens of organizations (Entra app secrets, 2026).

The techniques behind these are documented in static API key abuse and secrets in repositories and CI.

How workload identity works

Attest. The platform proves what the workload is. In SPIRE, an agent on each node first proves the node's identity to the server (for example with an AWS EC2 instance identity document or a Kubernetes service account token), then attests each local process using selectors such as Kubernetes namespace and service account, or Unix uid, gid and path.
Issue. The identity authority issues a short-lived credential bound to that identity.
Present. The workload uses it to call another service or exchanges it for a cloud access token.
Verify. The receiver validates it against a trust bundle or the issuer's published signing keys.
Renew. The credential expires and the workload gets a fresh one without human involvement.

The building blocks

SPIFFE. The SPIFFE concepts define a SPIFFE ID as a spiffe:// URI made of a trust domain and a workload path, for example spiffe://prod.example.com/ns/payments/sa/api. The credential is an SVID in one of two formats, an X.509 certificate or a JWT. The Workload API delivers SVIDs to the workload, and it "does not require that a calling workload have any knowledge of its own identity." A trust bundle is the set of CA root certificates used to verify other workloads' SVIDs. The project's guidance is to "use X.509-SVIDs whenever possible," since JWTs are replayable if intercepted; JWT-SVIDs fit when an L7 proxy sits between workloads.

Kubernetes projected service account tokens. Legacy auto-mounted service account tokens did not expire. Per AWS's IRSA documentation, Kubernetes 1.12 added projected service account tokens: OIDC JWTs with the service account identity and a configurable audience, which external systems can validate through the cluster's OIDC discovery endpoint.

Cloud workload identity federation. Each major cloud accepts external tokens and returns short-lived cloud credentials.

Cloud-native options compared

Mechanism	How trust is set up	What the workload gets	Watch for
AWS IRSA	IAM OIDC provider per cluster; role trust policy on the token	Temporary credentials via STS `AssumeRoleWithWebIdentity`	EKS rotates the OIDC signing key every 7 days; external validators must refresh keys
AWS EKS Pod Identity	Association of role to service account in EKS; trust principal `pods.eks.amazonaws.com`	Credentials from the node's Pod Identity Agent	Up to 5,000 associations per cluster; Linux EC2 nodes only, not Fargate; associations are eventually consistent
Google Cloud WIF	Workload identity pool and provider; attribute mapping and conditions in CEL	Federated token from STS (RFC 8693), then a short-lived access token	Granting a whole pool "can incur risk"; restrict with attribute conditions
Microsoft Entra WIF	Federated identity credential on an app or user-assigned managed identity	Access token via client credentials with the external JWT	`issuer`, `subject` and `audience` must match case-sensitively; only the first 100 IdP signing keys are stored
SPIFFE/SPIRE	SPIRE server per trust domain; federation between domains	X.509-SVID or JWT-SVID	You operate the server, its datastore and signing keys

Sources: EKS Pod Identity, Google Cloud Workload Identity Federation, Microsoft Entra workload identity federation.

The options compose. Entra accepts SPIFFE IDs as federated credentials, and Google Cloud lists AWS, Entra ID, GitHub, GitLab, Kubernetes and any OIDC or SAML 2.0 provider as pool providers. A common pattern is SPIFFE inside the mesh and federation at the cloud edge, so a workload holds one identity and exchanges it where needed.

Choosing a starting point

Your situation	Start with
Kubernetes on EKS calling AWS only	EKS Pod Identity (IRSA where Pod Identity is not supported)
CI pipelines deploying to cloud	The CI platform's OIDC token plus cloud federation; delete stored cloud keys
Service-to-service across clusters or clouds	SPIFFE/SPIRE with mutual TLS
Workloads outside any cloud calling Azure or Google	Federation from your own OIDC issuer or SPIRE
Legacy app that only accepts a password	Keep it in a secrets manager with automated rotation until it can be replaced

Rollout checklist

Inventory static credentials by owner, scope, age and where they are stored. Scanners in the secrets category help.
Pick the first target: CI-to-cloud deploy keys are usually the highest-risk, lowest-effort win.
Scope the new identity tightly. Write the trust condition on the exact repository, branch, namespace or service account, never the whole issuer or pool.
Right-size permissions instead of copying the old key's grants.
Run both in parallel, confirm the workload uses the new credential (cloud audit logs show the federated principal), then revoke the static secret.
Monitor for any use of revoked keys and for new static keys being created.
Repeat per workload class.

What it does not replace

Authorization. Workload identity says which service is calling, not whether the call is allowed. Pair it with policy; see RBAC to ReBAC.
End-user identity. Requests that originate from a person still need delegated user context, for example through token exchange.
Isolation. AWS states plainly that "containers are not a security boundary." If the node's instance metadata service is not restricted, pods may reach the node role's credentials.

Standards to watch: WIMSE

The IETF WIMSE working group is standardizing how workload identity travels across multi-system call chains, building on SPIFFE concepts. Per the WIMSE document list, as of November 2026 the HTTP signatures document has been submitted to the IESG as a Proposed Standard, the workload identity practices document is in IETF Last Call, and the architecture, workload identifier, mutual TLS, workload credentials and workload proof token documents are working-group drafts. None is an RFC yet.

Common failure modes

Failure	Consequence	Fix
Trust condition on the whole issuer	Any repo or tenant on a shared issuer can assume the role	Condition on subject and audience; use attribute conditions
Skipping attestation	The workload's self-claim becomes its identity	Use node and workload attestors, rather than trusting what the workload says about itself
Over-privileged federated role	Same blast radius as the old key, as in the JadePuffer service principal attacks	Least privilege per workload
Static key left in place after migration	Attackers use the old path	Revoke and alert on use
Unrestricted IMDS on nodes	Pods borrow the node role	Block pod access to the node IMDS

Guides: Kubernetes identity security, API key rotation automation, certificate lifecycle management. Glossary: workload identity, mTLS, service account, NHI. Vendors: machine identity, HashiCorp Vault.