SVIDs & rotation

X.509 for mTLS, JWT for requests, short lifetimes.

Advanced30 min · lesson 6 of 15

SVIDs are where SPIFFE identity meets the wire. Choosing between the X.509 and JWT forms, and understanding their short lifetimes, is what lets you apply identity correctly to mTLS and to request-level authentication.

X.509 for mTLS, JWT for requests

An X.509-SVID is a certificate carrying the SPIFFE ID in a URI SAN; it is what services present to each other for mutual TLS, so each side cryptographically proves its identity as the connection is established. A JWT-SVID is a signed token carrying the SPIFFE ID as its subject; it suits request-level authentication where a certificate cannot travel — across an L7 gateway, through a proxy that terminates TLS, or when authenticating a specific call rather than a connection. Both are short-lived and verified against the trust bundle; you choose the form based on whether you are securing a connection (X.509) or a request (JWT).

the two SVID forms in use
# X.509-SVID — mutual TLS between services:
# client presents cert (SAN: spiffe://acme.internal/ns/prod/sa/frontend)
# server presents cert (SAN: spiffe://acme.internal/ns/prod/sa/api)
# each verifies the other's cert against the trust bundle → mTLS established
# JWT-SVID — request-level auth across an L7 hop:
# Authorization: Bearer <jwt: sub=spiffe://acme.internal/ns/prod/sa/frontend>
# the receiver validates the signature + subject against the trust bundle

Short lifetimes are the point

SVIDs are deliberately short-lived — often minutes to an hour — and continuously rotated by the SPIRE Agent or mesh, and this is a security feature, not an inconvenience. A leaked SVID is useful only until it expires, which makes revocation largely automatic: you rarely need a certificate revocation list because a compromised identity simply stops working when its credential lapses. This continuous rotation is the concrete mechanism behind zero trust’s "continuously verify" principle at the workload layer — trust is re-established constantly rather than granted once. Because the runtime handles issuance and rotation, applications get this for free without managing any keys.

Choosing and rotating SVIDs
which form
X.509-SVID
securing a connection → mTLS
JWT-SVID
securing a request → L7/proxy
short-lived
minutes-to-hour lifetime
leak expires fast
auto-rotated
revocation via expiry, no CRL
Match the SVID form to connection vs request, and lean on short lifetimes + rotation as the revocation mechanism.
Long-lived SVIDs undermine the whole model
Configuring SVIDs with long lifetimes to "reduce rotation churn" recreates the leaked-long-lived-credential problem SPIFFE exists to solve. Keep SVID TTLs short and let the agent/mesh rotate them automatically — expiry is your primary, and cheapest, revocation control.