The Root Is Easy. Getting It Everywhere Isn't

Every AI agent deployed has to answer one question before it does anything useful: can I trust the thing I'm talking to? We know the answer lives in a trust store. Most organisations can't tell you how many trust stores they have, where they are, or who is responsible for updating them.

That gap has probably always been there. AI Agents, and the up coming post-quantum migration are about to make that gap very expensive.

When I say trust anchors, I mean the root CA certificates (and, where needed, the intermediates) that relying parties need in order to build and validate a certificate chain.

The talk is about issuance, not trust

Most crypto agility conversations are around the issuance side: new hierarchies (including PQC ones), automated certificate management, and ever-shorter certificate lifetimes. All of that matters...

... but a certificate is only as good as the relying party's ability to validate it. Issuance agility without trust agility gets you a shiny new certificate that half the estate rejects.

Anyone who has rotated a private root knows the pattern. The key ceremony takes days or weeks. Getting the new root's trust anchor everywhere takes months (or longer), and the outage comes from a corner of the estate nobody thought about.

Trust anchors are assets

Your root CA certificates, and any intermediates you deliberately pre-distribute, deserve the same treatment as any other critical asset. For each, you should be able to answer three questions:

1. Where? Every OS store, runtime, image, cluster, cloud service and appliance that has to trust it.
2. Who? A named team that owns it, not a vague department ("IT").
3. How? The mechanism used to add, remove, and roll back trust anchors.

The shift is that the unit of management isn't the certificate. It's the distribution channel. You don't have ten thousand trust stores to manage; you have a dozen or so channels that feed them. Get the channels right and the stores follow.

The channel map

In any given enterprise, trust anchors could reach relying parties through several mechanisms:

• Windows endpoints and servers: GPO or Intune. Usually the best-run channel, which is exactly why it's easy to assume the job is done.
• Linux: an internal ca-certificates package (rpm/deb) from your internal repo, running update-ca-trust (RHEL family) or update-ca-certificates (Debian/Ubuntu) on install. Versioned, auditable, rollback-able.
• Container images: baked into golden base images. Trust is frozen at build time, so every image built before the change carries the old trust anchors.
• Kubernetes: bundles projected into pods (cert-manager's trust-manager, ClusterTrustBundle), with env vars like SSL_CERT_FILE, REQUESTS_CA_BUNDLE or NODE_EXTRA_CA_CERTS pointing at them.
• Language runtimes: Java's cacerts (often reset by a vendor JDK upgrade), Python's certifi, Node's bundled store. Each, by default, capable of quietly ignoring the OS trust store.
• Infrastructure as code: Terraform and Ansible are excellent channels, and also where root PEMs can be pasted into modules as literals, creating unowned copies.
• Cloud managed services: load balancer and API gateway mTLS trust stores (validating inbound client certificates), reachable only through IaC or the console. In the other direction, managed services calling your internal endpoints often can't take a custom trust anchor at all.
• The long tail: appliances, network kit, OT, partner integrations. Often manual, often undocumented.

Every bullet is a channel. Every channel needs an owner.

Making the channels slick

The goal isn't a new tool or yet another agent to deploy and manage. It's making the channels you already have run fast and consistent so that they're boring/run of the mill.

• One source of truth. A single signed, versioned trust anchor bundle that every channel pulls from. Channels reference it; they never keep their own copy.
• A named owner per channel. If the Linux repo, base image pipeline and Terraform modules all belong to different teams, record that.
• Add before you remove. The overlap window where relying parties trust old and new anchors together. It seems obvious, but most rotation outages come from forgetting this. Cross-certifying the new root with the old one can bridge the stragglers, but path building differs between CryptoAPI, OpenSSL, Java and Go, so test it per runtime.
• Rehearse the playbook. Add a test anchor, remove it, emergency de-trust and roll back. Practise them before you need them.
• Measure the time-to-trust. For each channel: how long from "approved" to its relying parties provably trusting the new anchor? Your slowest channel is the limit of your crypto agility.

Attest before you roll

Distribution is only half the job. If you can't attest that the new trust anchor is in place and valid (this includes the revocation services: CRL distribution points and OCSP responders, plus AIA if clients fetch intermediates, published and reachable from the relying parties) you shouldn't roll to it. By attest I mean verifiable evidence from the relying party itself, not a deployment log, and not the node/workload attestation SPIFFE uses.

A GPO that applied, a package that installed or a pipeline that went green tells you the channel ran. It doesn't tell you the relying party now trusts the anchor. On top of that, images get rebuilt from old bases, pods don't restart, Java apps point at their own keystore, appliances silently reject the import. These issues can't happen in the dark.

Monitoring has to sit on the relying parties, not the channels:

• Report what's actually in each store. Fingerprints of the anchors present (ideally SPKI hashes, which stay stable when a root is re-issued or cross-signed with the same key), per host, image, cluster and service, compared against the approved bundle version.
• Test the path, not just the file. A handshake, run from the relying party's own runtime, against an endpoint presenting a certificate from the new hierarchy proves the trust, not just that a PEM landed on disk. For mTLS, remember the server is a relying party too.
• Gate the cutover on evidence. Only start issuing from the new hierarchy once each channel reports coverage above an agreed threshold, with the stragglers named and owned.
• Gate the removal too. Only retire the old anchor once you can prove nothing still depends on it, and no unexpired certificates still chain only to it.
• Watch for drift. Anchors that shouldn't be there matter as much as ones that are missing. A trust store nobody watches is one an attacker can quietly add to.

Without good quality monitoring, "we've rolled the new anchor" is a belief, not a fact.

SPIFFE proves the model works

If all this sounds abstract, look at SPIFFE / SPIRE. SPIRE treats the trust bundle as a managed, versioned object and pushes it to workloads automatically. Within a trust domain, trust rotation becomes almost a non-event. That's what good looks like.

But don't forget its edges:

• The upstream anchor. In most enterprises SPIRE chains to your private PKI via an UpstreamAuthority. That root is still an asset that needs an owner and a rotation plan.
• Relying parties that don't speak SPIFFE. Gateways, databases, legacy apps and appliances still need the bundle, and they get it through the other channels.
• Federation. Every federated trust domain is a trust grant. It deserves an owner, a review cycle and a way to revoke it.

SPIFFE doesn't solve the problem. It shows how the rest of the estate should be.

Why now: agents and PQC

Agent identity is converging on workload identity. The IETF's emerging WIMSE work treats agents as workloads, and reference architectures are already giving agents SPIFFE identities for mTLS.

This means every agent runtime, tool server, MCP server or gateway is a new relying party. Many are spun up from notebooks and ad-hoc images that sit outside current estate management. Agent sprawl can become trust store sprawl, and it can happen fast.

Next comes PQC. New roots, parallel hierarchies or composite certificates, and a long overlap where relying parties have to trust both old and new anchors. Having the PQC anchor in the store isn't enough on its own either: the relying party's crypto library also has to be able to verify the new signature algorithm (e.g. ML-DSA), which is exactly what the path test catches. You can't migrate trust anchors that you can't enumerate, and you can't enumerate an anchor nobody owns.

So here's a simple thought experiment. If you had to get a new private root onto every system that needs it by the end of the month, and prove it was there (and working), which channel would let you down?

That's where to start.

Your slowest channel is the limit of your crypto agility.