# Workload identity 101: replacing long-lived secrets

Source: https://startwithidentity.com/guides/machine-identity/workload-identity-101/
Last updated: 2026-01-15
License: content by Start with Identity. Cite the source URL.

---

## The problem

Most production incidents start with a leaked API key. The key was issued years ago, lives in an environment variable, was committed to a git history, and authorizes more than it needed to. Workload identity replaces this pattern.

## What workload identity is

A cryptographic identity issued to a software workload (container, function, service), short-lived, and attested by the underlying platform. Instead of "here's my secret API key," the workload presents "here's a cryptographic credential proving I am the payments-service running in production cluster east-1."

## The standards

- **SPIFFE:** Identity specification. SPIRE is the reference runtime.
- **Cloud-native equivalents:** AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity, Azure Workload Identity, Kubernetes ServiceAccount tokens with OIDC trust.

These coexist. Most multi-cloud deployments end up running SPIFFE for cross-cloud identity and using cloud-native primitives where the trust path is internal.

## Implementation pattern

1. Workload starts. Platform attests it (running in this pod, in this namespace, in this cluster).
2. Workload requests a credential from the identity authority.
3. Identity authority issues a short-lived credential (SVID, JWT, x.509 cert) bound to the workload's identity.
4. Workload uses the credential to call other services. Receivers validate.
5. Credential expires in minutes. Workload renews.

## What this replaces

- Long-lived API keys in environment variables
- Service account passwords in vaults that workloads then read with another long-lived credential
- Mutual TLS with manually managed certificates
- Shared secrets between services

## What it doesn't replace

- Application-level authorization decisions (the workload identity tells you what service is calling, not whether that call is allowed)
- Database row-level security
- End-user identity in requests that originate from humans

## Common pitfalls

- Skipping platform attestation and just trusting whatever the workload claims it is
- Issuing workload identities with permissions that match historical API keys (carrying over over-privilege)
- Not federating SPIFFE with cloud-native identity, requiring workloads to handle multiple credential types
- Treating workload identity as a vault problem when it's an identity problem