What SPIFFE Answers for Workload Identity and What It Doesn’t

On workload identity, a spec the industry has already started building around, and what the next layer looks like.

---

I don't have a better answer than SPIFFE (Secure Production Identity Framework for Everyone) for workload identity, and that's where I want to start, because what follows is going to sound like I do.

The first time I read the SPIFFE spec, I didn’t think, "this solves workload identity." I thought, "this defines workload identity, and then stops short of tying identity to anything you actually care about." There were two things specifically bothering me:

1. The spec punts on authorization entirely, which is the half of the identity problem that actually determines whether your system is secure. You can have the world's most beautiful cryptographic proof that a workload is who it claims to be, and it still tells you nothing about what that workload is allowed to do.
2. The registration model (how an identity gets associated with a workload in the first place) is left almost entirely to implementations, which means the thing you most want to be airtight is the thing the spec has the least to say about.

Years later, after watching the space evolve, those first two reactions hold up better than I expected. SPIFFE is the default answer to a real problem: how machines prove who they are to each other without shared secrets. And overall, the SPIFFE model is sound and the spec is thoughtful. It just doesn't go far enough, and in the last seven years the problems that matter most have drifted somewhere the spec doesn't reach.

What workload identity looked like before SPIFFE

Here's the world SPIFFE was designed to fix.

User identity has had real primitives for a long time: Kerberos, Active Directory, LDAP, later SAML and OIDC. Machine identity had a model, too, but it was a borrowed one: stand up a service account in the directory, or a row in /etc/passwd, or an IAM user in AWS, hand the credentials to the machine, and call it done. The machine's identity was a re-purposed human identity it was impersonating, which meant the credential was static, copyable, revocable only by hand, and impossible to rotate at the speed modern infrastructure moves. The worst version of this I’ve ever encountered was an AD environment with thousands of machines running services under domain admin credentials, because that was easier than figuring out which permissions each service actually needed. Nobody thought too hard about it because the network was static enough for it to mostly work, and the audit report hadn't caught up yet.

Then the network stopped being static. Cloud, containers, and ephemeral compute collapsed the assumptions the old model rested on. A Kubernetes pod might live for minutes, an EC2 instance for a single batch job, a GitHub Actions runner for the length of a deployment. None of them have a stable location, none of them have a stable identity, and most of them barely have a stable IP address long enough to matter.

So teams fell back on shared secrets, which is a polite way of saying they went back to what they always had: API keys in environment variables, database passwords in config files, service account tokens that someone will rotate eventually. Most teams think they have a handle on their credentials until someone actually audits, at which point the count tends to come back in the thousands. Each static credential becomes a target or a permanent backdoor waiting to be found.

SPIFFE's answer to this problem was the right one, and I want to give it full credit before I spend the rest of the post on what it doesn't do.

The core bet of SPIFFE is that trust should be grounded in platform attestation rather than shared secrets, which means verifying what a workload is based on the cryptographically checkable properties of its environment, issue it a short-lived credential based on that verification, and make the whole thing work the same way regardless of which cloud you're running on.

That bet was correct. CNCF graduated the project. Istio, Linkerd, Envoy, and HashiCorp all support it. For the canonical case of service A calling service B in a known environment, it delivers.

The workload identity questions SPIFFE can’t answer

"How does Service A authenticate to Service B" was the question SPIFFE was created to answer. But this is not the most useful question to ask in 2026. Instead, the useful questions are:

• How does an AI agent prove it's acting on Alice's behalf, with a scoped permission, for thirty minutes?
• How does a CI/CD pipeline deploying to production carry evidence of who triggered the deploy?
• How does a request transiting five microservices carry a chain of custody back to the original caller?
• How does a workload in my cloud present proof to a workload in your cloud, using a token neither of us can replay?
• How do I bind a credential to a specific workload so it can't be stolen and used elsewhere?

However, SPIFFE does not answer any of these questions. It's worth sitting with that for a moment, because the list isn't short and it isn't edge cases. The spec was scoped to bootstrapping and basic mTLS, and that scope was reasonable when it was written. But the hard problems of workload identity moved, and the spec didn't follow them.

There's a tell, if you want one outside my own reasoning. In March 2024 the IETF (Internet Engineering Task Force) chartered a new working group, WIMSE (Workload Identity in Multi-System Environments), to address the gap between what SPIFFE specifies and what the industry actually needs. Its output includes a new token type, the Workload Identity Token (WIT), along with architecture and credential exchange drafts for cross-system identity.

WIMSE is not trying to solve SPIFFE's failures; they're trying to solve the things SPIFFE never set out to address. But they're the things you need to build a modern workload identity system on top of, which is exactly the point.

Then there's the JWT-SVID, which is where the spec does something genuinely remarkable: it ships with a warning about the credential format it just defined. The spec for JWT-SVID acknowledges that JOSE has historically been difficult to implement securely, describes a replay scenario where a token minted for two audiences lets either recipient impersonate the sender to the other, and then concludes that the spec "is unable to solve it completely while retaining validation compatibility with RFC 7515."

That sentence is the whole story. The spec couldn't fix the problem because fixing it would have meant breaking JWT validation compatibility, and the introduction to the spec says explicitly that "compatibility with existing applications and libraries is a core requirement." The authors made a tradeoff: ship a credential format that works with every JWT library in every language, at the cost of shipping known footguns into production.

You can see why they made the call. A bespoke token format would have required every consumer to integrate custom validation code, and adoption would have been dead on arrival. For a nascent CNCF project trying to win an ecosystem, compatibility was the right commercial choice. It just wasn't a security win, and JWT implementation vulnerabilities have been a recurring industry story for a decade to prove it.

The SPIFFE project knows this. A 2023 GitHub issue proposed extending JWT-SVIDs with DPoP to bind tokens to a key held by the workload; it still hasn't merged. Meanwhile, the IETF's WIMSE working group is standardizing the Workload Identity Token, which does essentially the same thing, and the SPIFFE project is now working to support WITs. The project has known about the replay problem since at least 2023, attempted a fix that didn't ship, and is now adopting someone else's fix instead. That's an honorable engineering trajectory and a rough thing to say out loud about your own standard.

So the subversive read isn't that SPIFFE is wrong. It's that SPIFFE is narrower than the version of it most teams have in their heads. It's a well-specified bootstrap and authentication layer with a credential format the authors themselves told you to be careful with. Everything above it (delegation, authorization, proof-of-possession, cross-domain exchange, and identity for autonomous agents) is somebody else's problem.

Except that "somebody else" is you.

Four properties any mature workload identity platform needs

If SPIFFE is the base layer, then the layer above is where real identity engineering happens. There are four properties any mature workload identity platform needs, none of which are specified by SPIFFE.

1. Policy-bound identity issuance

Who gets to issue what identity, under what conditions, and how do you audit it?

Think of this as the passport office problem. You can design the most tamper-resistant passport in the world, but if the decisions about who qualifies for one are being made by a different agency in a different building with a different filing system, the passport is only as trustworthy as the weakest link in that chain. SPIFFE says nothing about who runs the passport office or how they decide who walks away with what. The registration or policy model you add on top becomes the thing your security posture actually depends on.

If that policy lives in a separate database from the rest of your access control, you now have two systems of record that can drift out of sync with each other. If it lives in the same control plane as your human access, you have one source of truth, and your audit story is one story instead of two.

2. Native attestation breadth

A workload identity system is only as good as the platforms it natively understands. If the identity system speaks AWS, GCP, Azure, Kubernetes, and generic TPM, fine.

But in 2026, most deployment-time identity decisions happen in CI/CD. If your system doesn't natively attest GitHub Actions, GitLab CI, CircleCI, Azure DevOps, Terraform Cloud, and BitBucket, then either you're writing custom attestors or you're falling back on long-lived join tokens, which was the exact problem SPIFFE was supposed to solve.

3. Delegation with attribution

SPIFFE can say "this workload is X." It cannot say "this workload is X, acting on behalf of user Y, with a limited scope, for a bounded time, and here is the audit record." That capability has to come from somewhere. Either your identity platform encodes it directly in the credential with attribution baked in, or your application code is left to implement delegation semantics in headers, custom JWT claims, or worse. The first option is auditable by default. The second is how breach postmortems start.

4. Proof-of-possession

A JWT that anyone who intercepts it can replay is a credential problem pretending to be an identity. WIMSE's answer is to bind tokens to a private key held only by the workload. SPIFFE's answer is "keep the audience narrow and hope for the best." Modern platforms need to move toward possession-bound credentials, which is where the standards are heading and where your own implementation should probably be heading, too.

All four of these properties (identity issuance, attestation, delegation, and proof-of-possession) sit outside the SPIFFE spec. If your chosen platform doesn't have them, you're either going to build them or make do without them — only to quickly discover why you shouldn't.

Where SPIRE fits (and where it doesn’t)

SPIRE is an open source implementation of the SPIFFE specification, used primarily in Kubernetes workloads. SPIRE is faithful to SPIFFE, but that fidelity is both its strength and its limit. If you adopt SPIRE, you are adopting a 2017 view of what workload identity is, and you'll end up either writing the layer above yourself or bolting on other projects to get there.

If you adopt SPIRE, you are adopting a 2017 view of what workload identity is, and you'll end up either writing the layer above yourself or bolting on other projects to get there.

The pattern I've watched repeatedly is this: teams don't back away from SPIRE, they pilot it. The pilot usually goes fine: a few services, a handful of registration entries, a Kubernetes cluster someone owns end-to-end. Then they try to roll it out more broadly, and that's where the infrastructure footprint becomes apparent. Nested servers for scale. A datastore to operate. Registration entry lifecycle management across teams that don't know each other. Selectors that have to stay in sync with ephemeral infrastructure.

None of those are implementations of the SPIFFE spec; they're the things you have to build around the spec to make a production deployment survive a year. A lot of SPIRE pilots don't become SPIRE rollouts; not because the pilot failed, but because the rollout work is bigger than the identity problem the team was trying to solve in the first place.

Teleport fills the gaps SPIFFE leaves open

That's the gap Teleport’s workload identity layer was built to fill. Not as a bolt-on to SPIFFE, but as the layer above it.

Teleport builds on SPIFFE using the same IDs, SVIDs, Workload API, and even the same trust bundles. Teleport can also federate with SPIRE-managed trust domains, and standard SPIFFE SDKs work unmodified. What Teleport adds is the layer the spec leaves open.

Policy is governed by Teleport's existing role-based access controls (RBAC): A WorkloadIdentity resource maps directly to roles, managed via tctl or Terraform, with no separate registration database or parallel policy store. Human access and workload access run through the same control plane and land in the same audit log.

Attestation is native and broad: Join methods for AWS, GCP, Azure, Kubernetes, GitHub Actions, GitLab CI, CircleCI, BitBucket, Azure DevOps, Terraform Cloud, and TPM for bare metal. Workload attestors for Unix, Kubernetes, Docker, Podman, Sigstore (for supply chain provenance), and Systemd. If a platform is where your workloads actually live, there's a good chance Teleport already attests it.

Delegation comes from Teleport's role impersonation model: A bot or user holding impersonation rights can generate a credential for a target role, and the impersonator's identity is captured in the certificate and the audit log. Teleport prevents recursive impersonation, and scopes time to live (TTL) to the maximum of the impersonated roles. This gives you, by default, the "X acting on behalf of Y" property the SPIFFE spec doesn't provide.

That "acting on behalf of Y" property is particularly relevant for AI agents. With Teleport, these agents are already first-class actors in Teleport's identity layer, receiving short-lived privileges, controlled with RBAC, and every action attributed in the audit log. For agents that need runtime containment, Teleport announced Beams in March 2026.

The problem Beams solves is this: teams running AI agents in production today are using every bad pattern the industry has ever invented: API keys in environment variables, service principals checked out of a secrets manager, password files mounted into containers, certificates handed out with no meaningful scope, and IAM roles attached to pods and shared across every agent that pod runs. All of it running next to each other, with no consistent audit story tying any of it together. It's the exact credential sprawl problem SPIFFE was written to solve, reintroduced a decade later because nobody had a good answer for giving an autonomous, non-deterministic process identity and access in a hurry.

Each Beam is a Firecracker VM with full filesystem and networking isolation, and is wired into Teleport's identity layer. Agents running in a Beam inherit delegated identity and authenticate to services and inference endpoints without secrets, and every action they take is audited. tsh beams add provisions the VM, injects the cert, opens the tunnel, and you're running in about two seconds.

Why a VM boundary specifically, rather than something lighter weight like a sidecar or a namespace? Because agent autonomy and a trustworthy sandbox need a stronger isolation model than process-level controls can give you. If the agent is going to be allowed to decide what to do, the thing containing the agent has to be containing it for real, not on the honor system.

None of this makes you immune to misconfiguration. If you misconfigure RBAC, you misconfigure identity. If you grant a bot too many impersonation targets, you've recreated the authorization drift problem at a different layer. The difference is that with Teleport, it's one layer to get right instead of three.

Learn more about Teleport Beams at beams.run.

Where I land on the future of SPIFFE

SPIFFE is the best available base layer for workload identity, and I mean that sincerely.

The question it was written to answer (how do we bootstrap identity without shared secrets) was the right question to ask in 2018, and the spec's answer was thoughtful and has held up. What I've been trying to argue in this piece isn't that SPIFFE was wrong, but that the interesting questions moved on. The 2026 version of workload identity is about non-deterministic workloads acting on someone's behalf with a provable chain of custody, across trust domains, without bearer tokens that anyone who touches them can replay. That's the question the IETF is now trying to answer with WIMSE, and it's the question the SPIFFE project itself is now working to catch up with through API extensions.

If you're picking a workload identity platform today, the four properties I've spent this post on are the ones worth evaluating against. Policy-bound issuance. Native attestation breadth. Delegation with attribution. Proof-of-possession semantics. A platform that has them is dealing with the world as it exists today. A platform that doesn't is going to leave you writing that layer yourself, probably under deadline, and probably while something else is on fire.

The deeper thing I've come to believe after sitting with this space for a while, is that the hardest part of workload identity was never going to be the cryptography. That’s a solved problem. Instead, the hardest part is the organizational and operational work of keeping policy and reality in sync across teams, platforms, clouds, and time. SPIFFE got the cryptographic layer right, and it's reasonable that a spec stopped there. However, most of the work of building a trustworthy identity system lives above that layer, and as an industry we haven't yet agreed on what that layer should look like.

But we're getting closer.

---

About the author: Rob Cobbins has nearly two decades of experience as a sales engineer focused on cybersecurity solutions spanning network, identity, cloud and vulnerability management. Before joining Teleport, he spent much of his career at CyberArk working on privileged access and application/workload identity, and he writes from the vantage point of someone who has watched dozens of enterprise security programs succeed and fail up close.