Cryptographic Posture Management — discover, grade & remediate your whole cryptographic estate
Sovereign Certificate Authority for enterprise-grade certificate issuance & management
Certificate Lifecycle Management, discovery, governance & automation
DNS-agnostic Domain Control Validation, ready for 47-day TLS certificates
AI agents and cloud workloads mint identities faster than any human process can follow. SPIFFE and SPIRE were built for that speed — but out of the box, a SPIRE Server signs from a self-signed CA that is invisible to your PKI team. This guide explains the gap SPIRE leaves open and how anchoring its signing CA to a governed, sovereign enterprise root turns an island of trust into part of your estate.
Agentic identity is the problem of giving non-human actors — AI agents, workloads and services — identities they can prove, at a speed and volume no ticket-based process can match. SPIFFE defines the identity format (the SPIFFE ID, carried in a short-lived credential called an SVID) and SPIRE is its reference implementation, attesting each workload and issuing its X.509-SVID at machine speed.
SPIRE is excellent at high-volume, short-lived issuance. What it does not solve is governance: by default its signing CA is a self-signed file on disk, outside every policy, audit and lifecycle control an organisation has built. This guide covers the gap that leaves, and the pattern that closes it — anchoring the SPIRE Server's signing CA to a governed, sovereign enterprise root through an UpstreamAuthority plugin, so SPIRE keeps its speed while the trust domain becomes part of the managed estate.
The newest users of most enterprise systems are not people. Every AI agent, workload and service needs its own identity to authenticate, encrypt and be held accountable, and a single application can spawn thousands of them — identities that live minutes, not years. Issuing those by ticket, spreadsheet or portal is not slow; it is impossible. The question is no longer whether to automate workload identity, but who anchors and governs the system that does.
SPIFFE and SPIRE answer the issuance half of that question extremely well. This guide is about the other half — governance — and the specific gap a stock SPIRE deployment leaves at the top of its trust chain.
The open standard for workload identity is deliberately small. It defines an identity format and a way to deliver it, and leaves the hard operational questions — attestation, CA operation, revocation — to the implementation.
Defines a universal identity format for workloads: the SPIFFE ID, carried in a short-lived, automatically rotated credential called an SVID.
The reference implementation, running inside your infrastructure. It attests each workload — is this really the billing service on this node? — and issues its X.509-SVID on the spot, at machine speed, with no human in the loop.
SPIRE is excellent at high-volume, short-lived issuance. That is exactly the work a CLM should not try to do certificate by certificate: hundreds of thousands of ephemeral certificates belong in the mesh, not in a management console.
SPIRE issues SVIDs beautifully. The question it does not answer on its own is what those SVIDs ultimately chain up to.
Every SVID chains to the SPIRE Server's signing CA. Out of the box, that CA is a flat file on disk: self-signed, invisible to the PKI team, outside every policy, audit and lifecycle control the organisation has built. An ungoverned signing CA means an ungoverned trust domain — no enterprise root, no revocation policy, no compliance evidence, and an island of trust disconnected from the rest of the estate. The answer is not to slow SPIRE down; it is to anchor it properly.
The pattern uses SPIRE's own extension point. An UpstreamAuthority plugin lets the SPIRE Server obtain its signing CA from an external authority instead of generating one itself, so the trust domain anchors to a root the organisation owns.
The division of labour is the whole point: SPIRE handles the hundred thousand certificates that live for an hour; the CLM governs the one that makes them all trustworthy.
One binary next to the SPIRE Server, one configuration block: the CLM endpoint, an API key or mTLS credential, and the issuance profile to use. The SPIRE config block is literally an `UpstreamAuthority "horizon"` entry.
SPIRE requests its signing CA through the plugin; the CLM issues it from a dedicated profile, chained to the enterprise CA, on premises. The whole SPIFFE trust domain now anchors to a root the organisation owns, with a sovereign CA behind it.
The SPIRE intermediates appear in the CLM tagged with their trust domain and role — profile-driven issuance rules, lifecycle policies, audit trail, rotation and revocation — alongside every other certificate in the estate. Guardrails include trust-domain allowlisting and optional revocation of the previous intermediate on each rotation.
Anchoring is not just tidier architecture — it is what makes an agentic-identity deployment defensible to an auditor and durable over time.
The plugin covers X.509-SVIDs — the certificate side of SPIFFE — and connects with an API key or mTLS client certificate, with secrets referenced by path or vault rather than inlined. It is a drop-in for an existing SPIRE deployment: SPIRE keeps minting SVIDs at machine speed, and its root of trust stops being an island.
The trust domain chains to an enterprise CA stack you control, on your premises, not to a file on a pod.
Profile rules, audit events and lifecycle history give NIS2 and DORA auditors the paper trail SPIRE alone cannot produce.
Workload intermediates live next to your TLS, code-signing and user certificates: same inventory, same grading, same dashboards.
Anchor the SPIFFE deployment to a CA hierarchy that can migrate to hybrid and post-quantum algorithms without re-architecting the mesh.
