Start free trial

By Yair Knijn · March 3, 2026

The post-quantum migration starts with an inventory you were supposed to already have

Every post-quantum briefing points the same way: a cryptographically relevant quantum computer is years out, the NSA's CNSA 2.0 timeline doesn't force full migration until 2035, and there are louder fires this quarter. So PQC gets filed as research, something to revisit when the hardware threat is closer. That filing confuses the easy part of the problem with the hard part.

The hard part is not picking ML-KEM over ML-DSA. It's knowing what certificates and keys you actually have, where they live, and how fast you can re-issue them. That work is needed now, it takes years, and almost nobody has it done. Defer the algorithm choice all you like. Defer the inventory and you arrive at the deadline blind.

Regulators ask for an inventory first, not a purchase

NIST published the first post-quantum standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The algorithms have stopped being the open question. From NIST's own migration project to the NSA's CNSA 2.0 framing, the instruction that keeps surfacing is the same: step one is a cryptographic inventory, not a vendor purchase. CNSA 2.0 wants quantum-safe algorithms in new national security systems by 2027 and broad migration by 2030. None of those dates are reachable until you can answer where your crypto is.

You can't migrate algorithms you can't enumerate

Algorithm migration is find-and-replace, and that doesn't work on a corpus you never indexed. The certificates you know about are the public-facing ones with monitoring. The ones that wreck a migration are everything else: an internal CA chain signed with a key nobody can locate, a hardcoded cert in a firmware image, a service mesh doing mutual TLS whose issuance path lives in a Helm chart three teams removed from yours, a load balancer terminating TLS off a config last touched by someone who left.

A real inventory is not a spreadsheet of expiry dates. Per certificate it records the signature and key algorithm, the key size, the issuing CA, where the private key sits, and which system depends on it. That last field turns a flat count of thousands of certs into a short list of the handful you cannot re-issue without a change window and a vendor ticket. That short list is your actual PQC project, and you find it by enumerating now, not under deadline pressure.

Crypto-agility is a pipeline property, not a one-time swap

Crypto-agility gets sold as a feature you buy. It's closer to a property your issuance pipeline either has or doesn't. The test is mechanical: can you change the algorithm or key parameters for a class of certificates and have them re-issued, deployed, and verified across the fleet without hand-editing each endpoint? If rotating a curve today means a quarter of coordinated manual work, then moving to a post-quantum algorithm tomorrow isn't a swap, it's a program. The standards will keep moving, so the team that can re-issue its estate on demand treats each change as a routine rollout while the team that re-issues by hand treats each as a crisis.

The near-term payoff lands immediately, quantum or not: an accurate inventory kills the surprise outages from forgotten expiries, and automated renewal takes the late-night re-issue off your on-call. Concretely, that means:

This is the work Automate Certificates is built to absorb. Each customer Environment gets a live inventory of every certificate it can see, with algorithm and key data attached, plus an automated issuance pipeline that turns a parameter change into a rollout instead of a project. That's the real down payment on post-quantum: not the algorithm, the agility to change it. To see what you'd have to re-issue tomorrow, start with what you have today on the features page.