Workload identity has become a foundational primitive in modern infrastructure. Static credentials do not scale, degrade over time, and rarely explain why access should be allowed. The SPIFFE specification addresses this by defining a standard way to issue short-lived, cryptographically verifiable identities to workloads.
From the beginning, SPIFFE was designed with multiple administrative boundaries in mind. Real systems span clusters, cloud accounts, regions, organizations, and partners. Identity must cross those boundaries without collapsing everything into a single control plane.
SPIFFE identity federation exists to solve exactly this problem.
Trust domains as the foundation
SPIFFE organizes identity around trust domains.
A trust domain represents an administrative boundary with authority over:
- its SPIFFE ID namespace
- its trust anchors
- the issuance of workload identities within that namespace
A workload identity is expressed as a SPIFFE ID, for example:
spiffe://prod.acme.corp/frontendThat identity is meaningful only because the verifier trusts the authority that governs the prod.acme.corp trust domain.
Within a single trust domain:
- workloads receive SVIDs
- SVIDs chain to the domain’s trust anchors
- peers verify identities using those anchors
Federation begins when workloads must authenticate across trust domains.
Why federation is necessary
Consider two independent trust domains:
spiffe://payments.acme.corp
spiffe://inventory.acme.corpEach domain:
- operates its own control plane
- issues and rotates its own identities
- enforces its own policies
- maintains its own trust anchors
If a workload in payments.acme.corp needs to communicate with a workload in inventory.acme.corp, identity must cross an administrative boundary.
Without federation, teams typically fall back to:
- sharing trust anchors globally
- terminating identity at gateways and re-issuing credentials
- abandoning identity and relying on networks or secrets
All of these approaches erase workload identity at the boundary.
SPIFFE federation exists to avoid that outcome.
Federation as defined by the SPIFFE specification
Federation is a first-class concept in the SPIFFE specification.
The spec defines federation as the ability for a trust domain to verify identities issued by another trust domain without:
- sharing private keys
- merging control planes
- centralizing identity issuance
To support this, the specification defines:
- trust domain relationships
- trust bundles
- bundle endpoints
- verification semantics
At the same time, the spec deliberately limits its scope to identity verification.
Trust bundles as the unit of trust
The core object used in federation is the SPIFFE trust bundle.
A trust bundle contains:
- one or more trust anchors for a trust domain
- optional metadata
- no private key material
Trust bundles are the only artifacts exchanged during federation. No identities are delegated, and no keys are shared.
Standardized bundle endpoints
The SPIFFE federation specification defines standardized bundle exchange using SPIFFE bundle endpoints.
Bundle endpoints are HTTPS endpoints that serve trust bundles. Two authentication profiles are defined:
- https_web, authenticated using Web PKI TLS
- https_spiffe, authenticated using SPIFFE X.509-SVIDs
The specification requires that:
- bundle endpoint clients MUST support both profiles
- bundle endpoint servers MUST support at least one profile
- TLS configurations meet defined security requirements
This ensures interoperability while allowing deployment flexibility.
How to establish federation
Assume the following trust domains:
spiffe://payments.acme.corp
spiffe://inventory.acme.corpTo federate:
- payments.acme.corp is federated with:
- the trust domain name inventory.acme.corp
- the bundle endpoint URL for that domain
- the expected endpoint authentication profile
- it periodically fetches the trust bundle from that endpoint
- it validates the bundle according to the specification
Federation can be symmetric or asymmetric depending on configuration.
How verification works with federation
Federation does not change how workloads authenticate.
At runtime:
- a workload presents its SVID
- the verifier extracts the SPIFFE ID
- the trust domain portion of the ID is identified
- the corresponding trust bundle is selected
- certificate chain verification proceeds normally
Federated identities are verified using the same cryptographic process as local identities.
Explicit and scoped trust
SPIFFE federation is explicit and opt-in.
Trust domains do not implicitly trust each other. Each federation relationship must be configured intentionally, including:
- which trust domain is federated
- where its bundle endpoint is located
- how its bundle is authenticated
- how often it is refreshed
The spec enables federation but does not force trust expansion.
What federation does not define
Even with standardized bundle exchange, the SPIFFE federation spec intentionally does not define:
- authorization semantics
- policy models
- enforcement location
- federation topology
- governance or lifecycle rules
Federation answers one question only:
Can this workload identity be cryptographically verified as originating from the stated trust domain?
What that identity is allowed to do remains a separate concern.
Common misconceptions
Federation is often misunderstood.
It is not:
- a global root CA
- transitive by default
- workload-level delegation
- dynamic trust based on behavior
Federation operates strictly at the trust domain level and only affects identity verification.
Why federation alone is often insufficient
In theory, SPIFFE federation is clean and well-defined.
In practice, teams encounter issues when:
- trust relationships grow faster than policy
- bundles become stale or poorly governed
- verification is decoupled from enforcement
- identity context disappears after the handshake
These are not flaws in the specification. They are consequences of how identity is applied in real systems.
Federation is most effective when verification and enforcement remain tightly coupled.
Looking ahead
The SPIFFE federation specification provides a precise, interoperable foundation for extending workload identity across administrative boundaries.
What it intentionally leaves open is how federation is enforced, constrained, and observed at runtime.
In a follow up post, we will explore how Riptides approaches federation, enforces it below the application layer, and how runtime context changes the security properties of federated workload identity.
If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.