SVIDs

What Is an SVID?

SVIDs are the credential format at the heart of SPIFFE, a Cloud Native Computing Foundation (CNCF) standard for workload identity.

Every SVID carries three components:

1. A SPIFFE ID
2. A valid cryptographic signature
3. An optional public key

The SPIFFE ID itself follows a URI format: spiffe://trust-domain/path (for example, spiffe://acme.com/billing/payments). The trust domain identifies the administrative boundary (usually an organization, environment or team), and the path identifies the specific workload.

An SVID is only valid if it was signed by a certificate authority within that trust domain.

This model separates workload identity from network location, IP address or hostname. A pod in Kubernetes, a Lambda function in AWS and a virtual machine in Azure can all hold SVIDs and authenticate to each other without sharing a secret or relying on network topology.

SPIFFE SVID Formats: X.509-SVID vs. JWT-SVID

The SPIFFE spec defines two SVID formats, each suited to a different communication pattern.

X.509-SVIDs are X.509 certificates in which the SPIFFE ID is embedded as a URI-type Subject Alternative Name (SAN). The key usage extension is marked critical, and leaf certificates must set digitalSignature.

X.509-SVIDs integrate directly with mutual TLS (mTLS), making them the preferred format for synchronous service-to-service calls.

The SPIFFE spec recommends using X.509-SVIDs over JWT-SVIDs wherever possible, because JWT tokens are susceptible to replay attacks if intercepted.

JWT-SVIDs are JSON Web Tokens signed by the issuing authority. They work better in HTTP/REST contexts where identity needs to travel in an Authorization header, or where certificate-based mTLS is impractical.

The table below compares the two SVID formats defined by the SPIFFE specification.

How Are SVIDs Issued and Rotated?

SVIDs are delivered to workloads through the SPIFFE Workload API, a local gRPC API exposed by a SPIRE agent running on the same node.

The Workload API does not require the workload to authenticate itself first; the SPIRE agent performs attestation on behalf of the workload using kernel-level and platform-level signals like process ID, service account, pod labels, cloud instance metadata and similar indicators.

Once attested, the SPIRE agent issues an SVID and caches it locally.

Before the credential expires, the agent proactively fetches a fresh SVID and signals any dependent processes. Certificates are typically short-lived, valid for minutes or hours rather than months.

This automated rotation cycle means workloads never store a long-lived secret. If an SVID is somehow captured, it expires quickly and cannot be reused.

How Do SVIDs Control Access?

The SVID doesn’t directly control access, but the credential provides cryptographic proof of a workload/service/AI agent’s identity that downstream systems can use to make access decisions.

The publication Careful Adoption of Agentic AI Services, released by the Cybersecurity and Infrastructure Security Agency (CISA) along with other regulatory bodies, recommended that each agent have a distinct, cryptographically anchored identity with its own unique keys or certificates, such as SVIDs, as part of cybersecurity best practices.

When the workload wants to access resources or communicate with another service, it presents its SVID. The receiving service validates the SVID by checking its credential signature against the trusted SPIFFE authority and confirming the credential is valid and not expired.

Once the SVID is validated, access or denial to resources is granted based on the policy engine or authorization service.

Policies are typically written against the SPIFFE ID. An MCP server can control access to information or services based on these policies.

In environments that combine workload identity with device security, policies can also require proof of the health of the machine running the workload.

This is accomplished by incorporating signals from MDM and EDR platforms, which can then automatically deny or revoke access in the event a valid agent is running on a compromised machine.

The IETF recommends SVIDs for agents because SVIDs are a much stronger form of identifying agents, facilitating communication, and controlling how much access or authorization a specific agent or workload should get when compared to OAuth tokens by themselves.

• Micah Spady, Director of Product Marketing at SecureW2

How Do SVIDs Eliminate Static Credentials?

Traditional service authentication often relies on hardcoded API keys, long-lived service account tokens or shared passwords embedded in configuration files.

This pattern gives rise to what’s known as “secret zero” — the challenge of protecting the first credential before any secure channel exists to protect it.

SVIDs sidestep secret zero entirely. There is no pre-shared secret to protect because the SPIRE agent derives identity through attestation, not configuration.

The only material a workload receives is a short-lived credential it cannot reasonably leak or hoard for re-use.

Non-human identities already outnumber human identities by 25 to 50 times in modern enterprises, according to research from the Non-Human Identity Management Group, which makes manual credential hygiene unscalable.

For AI agents and microservices, short credential lifespans matter. A misconfigured container that leaks its SVID exposes a credential valid for minutes, not years.

Related Terms

Frequently Asked Questions