What is workload identity, and why replace static keys with it?

Workload identity is a way for software, such as a container, function or job, to prove who it is and receive short-lived credentials without a stored secret. It replaces static API keys and shared passwords that leak, never expire, and tell you nothing about which service used them.

What problem does it solve?

Services need to call other services. The old way is to create a key, paste it into a config file or secret store, and ship it. That key then lives for months. It gets copied into backups, build logs and laptops. When it leaks, nothing shows which machine it was taken from, and rotating it means touching every system that holds a copy.

MITRE ATT&CK lists use of valid accounts, technique T1078, as a way attackers gain and keep access. A leaked service key is exactly that. It looks like a legitimate caller.

How does it work?

The idea is to base identity on something the platform can verify, not on a secret someone stored.

1. The platform knows what a workload is: this pod, in this namespace, running this service account, or this function with this role.
2. The workload asks an identity service for a credential.
3. The service checks the workload's properties, a step called attestation, and issues a short-lived credential, often valid for minutes.
4. The workload presents that credential to the target service, which verifies it and applies policy.
5. When it expires, a new one is issued automatically. Nothing long-lived is stored.

SPIFFE, an open standard from the Cloud Native Computing Foundation community, defines this pattern. A SPIFFE ID is a URI that names a workload, such as spiffe://example.org/payments/api. It is carried in a short-lived document that can be an X.509 certificate or a signed token. Cloud platforms offer similar features that let a workload exchange its platform token for access to another provider's resources. RFC 8693 defines a standard token exchange mechanism often used for this.

What changes for the engineer?

A constructed example. A nightly report job in a cluster needs to read from a storage bucket. Before: a developer creates an access key for a service user, stores it in a secret, and the key stays valid for two years. After: the job's service account is trusted by the cloud's identity system, which hands the job a credential that lasts one hour and only for that bucket. If the job's logs leak the credential, it is useless by lunchtime. Audit logs say the report job read the data, not "a key".

What are the common mistakes?

Giving the workload identity an overly broad role defeats the benefit, since a short-lived token that can do everything is still dangerous. Another is keeping the old static keys active after migration. Leave them and attackers will use them. A third is identity per team instead of per service, which blurs accountability.

Attestation quality also matters. If any pod in a namespace can claim any identity, the service is no safer. Tie identities to properties that an attacker inside one workload cannot change.

How does this help investigations?

With static keys, a log line says a key id made a call. You then dig for who owns the key and where copies live. With workload identity, each call carries a name for the workload, such as the report job in the finance namespace. That makes anomaly detection practical: a build job that suddenly reads customer data stands out, because its identity has a narrow normal pattern.

It also supports clean offboarding of services. Remove the workload and its trust relationship, and its access ends with it. No hunt for keys is needed. For regulated environments, the audit trail of who accessed what, tied to a named workload rather than a shared secret, is easier to present to an assessor.

How to check or apply this

1. Inventory long-lived credentials used by services: cloud keys, tokens, database passwords. List last used date and owner.
2. Pick one service and replace its key with platform workload identity.
3. Scope its role to the exact resources and actions needed.
4. Delete the old key after confirming the new path works.
5. Set an alert for creation of new long-lived keys.
6. Repeat by risk: internet-facing and production services first.

Quick check

Sources

1. SPIFFE overview
2. RFC 8693, OAuth 2.0 Token Exchange
3. MITRE ATT&CK T1078, Valid Accounts
4. NIST SP 800-207A, Zero Trust Architecture Model for Cloud-Native Applications

Last reviewed: 18 October 2026.