Migrating PKI and certificates to PQC signatures
Certificate authorities, chains, and the signatures that anchor trust all have to move to post-quantum algorithms. Why PKI is a dependency for everything else, and how to sequence it.
PKI is a prerequisite, so plan it early even if it executes later
Certificates authenticate almost everything, and their signatures (RSA/ECDSA) are quantum-vulnerable. Migrating PKI means CAs that can issue PQC-signed certificates — using ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) — plus endpoints that can validate them. Because endpoints depend on the CA being ready first, PKI belongs early in planning even where the harvest-now-decrypt-later clock puts key exchange first for execution.
Public-key infrastructure is the trust backbone: TLS certificates, code-signing certificates, device identity, and internal service authentication all chain to a certificate signed by a CA. Those signatures use RSA or ECDSA, which Shor's algorithm breaks. Unlike key exchange, a signature is not harvestable — you cannot forge one retroactively — so the confidentiality clock is less urgent. But the dependency clock is: nothing downstream can present a PQC certificate until the issuing CA can sign one.
The PQC signature choices
- **ML-DSA (FIPS 204)** — the lattice-based general-purpose signature, the default first choice for most certificate use.
- **SLH-DSA (FIPS 205)** — a stateless hash-based signature with very conservative security assumptions and larger signatures; favored for roots of trust and long-lived firmware where maximum assurance matters more than size.
- **FN-DSA (FALCON)** — a lattice signature with small signatures, standardization ongoing at NIST; worth tracking where signature size is the binding constraint.
Sequencing the PKI migration
PKI migrates from the root of trust outward, but rolls out from the leaves inward — a tension you resolve with careful sequencing:
- **Make validators PQC-aware first.** Clients, servers, and verifiers must be able to accept PQC signatures before you start issuing them, or you break trust chains.
- **Stand up PQC-capable issuance.** Ensure the CA software and any HSMs that hold CA keys support the chosen PQC signature algorithm.
- **Introduce new roots/intermediates** rather than resigning existing ones in place; run classical and PQC hierarchies in parallel during transition.
- **Migrate leaf certificates** through normal renewal cycles, shortening lifetimes where you need to accelerate turnover.
- **Retire classical trust anchors** only once validation coverage is complete and confirmed.
Larger signatures and chains break size assumptions
PQC signatures and public keys are much larger than ECDSA — SLH-DSA signatures especially. Certificate chains grow, which can exceed buffer sizes in embedded validators, blow past protocol field limits, or slow handshakes. Test the full chain against your smallest, oldest validators, not just modern servers, and account for the size increase in any system that stores or transmits certificates.
HSMs and key ceremonies
CA private keys usually live in hardware security modules, and not every HSM firmware supports PQC signature algorithms yet. Confirm HSM support early — it is a common long-lead dependency — and plan the key-generation ceremonies for new PQC roots with the same rigor as classical ones. Where HSM support lags, that gap becomes an explicit roadmap blocker, not an assumption to discover mid-migration.
Because so much depends on PKI, treat it as shared infrastructure with its own owner and its own validation gates. Getting it PQC-ready unblocks TLS authentication, code signing, and device identity — several downstream waves at once.