Post-Quantum Cryptography in PKI: Migration Planning for Certificate Authorities and Enterprise PKI Teams

Every PQC migration programme eventually arrives at PKI and slows down. A cipher suite update on a web server takes an afternoon. A root CA migration takes years, requires trust store distribution across thousands of relying parties, and cannot be undone without a trust crisis. That asymmetry is not widely understood at the start of a migration programme, and it produces schedule failures when it is discovered mid-programme.

This article is written for the PKI engineer, security architect, or CISO responsible for certificate infrastructure who already understands the migration case and needs a planning framework. If you need the foundational context on what PKI is and why quantum computers threaten it, see the PKI and quantum computing explainer first. This article picks up where that one leaves off.

Why PKI Migration Is Different from Updating a Cipher Suite

PKI is the trust backbone for TLS, code signing, S/MIME email, document signing, and device authentication. Most of these use cases depend directly on RSA or ECDSA public-key certificates. Identity federation (SAML, OAuth/OIDC) can also involve JOSE/JWKS asymmetric signing keys, metadata signing, and TLS trust anchors, not only X.509 certificates; the migration scope for those systems should be assessed on that basis. NIST IR 8547 (November 2024 initial public draft) sets out the expected transition approach, with quantum-vulnerable algorithms deprecated in new deployments and high-risk contexts targeted for earlier action; the document should be cited with its draft status, and the full disallowance timeline runs to 2035. When those algorithms retire, the entire certificate hierarchy must migrate, not just a configuration setting on a server.

The scale of a typical enterprise PKI is larger than it appears from the outside. An enterprise deployment may include one or more offline root CAs with 20-year validity periods, subordinate CAs with five to ten year validity, issuing CAs, automated certificate management infrastructure (ACME protocol, EJBCA, Venafi, Keyfactor), HSMs at each trust anchor level, and thousands of issued end-entity certificates on annual renewal cycles. Each layer has its own migration dependencies and sequencing constraints.

The sequencing constraint that most planning exercises miss relates to trust chains. RFC 9794 defines several chain types: traditional, PQ/T hybrid, and PQ/T mixed. A traditional root can, in principle, certify a subordinate certificate that contains a post-quantum public key if the certificate profiles and relying-party software support the relevant OIDs and validation rules. What that arrangement does not produce is a fully post-quantum trust chain. A full PQ or hybrid-authentication chain requires post-quantum or hybrid signatures through the chain, or a parallel hybrid PKI design. A cross-signed bridge certificate or a parallel new root hierarchy is required to establish that chain; the sequencing logic is what makes PKI the longest-lead item in most enterprise PQC programmes.

Algorithm Selection: ML-DSA, SLH-DSA, and FN-DSA

Three NIST signature algorithms are relevant to PKI, and they are not interchangeable.

ML-DSA (NIST FIPS 204) is the primary recommended algorithm for PKI certificate signatures. It supports three parameter sets: ML-DSA-44 at NIST security category 2 (benchmarked against SHA-256/SHA3-256 collision search difficulty), ML-DSA-65 at category 3 (AES-192 key search equivalent), and ML-DSA-87 at category 5 (AES-256 key search equivalent). For enterprise PKI root and intermediate CA certificates, which carry long validity periods and sign large numbers of subordinate certificates, ML-DSA-65 or ML-DSA-87 are the appropriate choices. ML-DSA-44 is acceptable for short-lived end-entity certificates in lower-sensitivity contexts.

SLH-DSA (NIST FIPS 205) is a hash-based signature scheme and the conservative choice for offline root CA certificates and other long-lived, low-frequency signing contexts. Its security rests on hash function properties rather than lattice assumptions, which means it provides cryptographic diversity against a scenario in which lattice cryptanalysis advances unexpectedly. A root CA signing ceremony happens perhaps once a decade; the larger signatures and slower verification of SLH-DSA are acceptable at that frequency. For an offline root with a 20-year validity period, the algorithm diversity argument for SLH-DSA is meaningful. Relevant parameter sets for PKI: SLH-DSA-SHA2-128s for security level 1 contexts, SLH-DSA-SHA2-256s for level 5. SHA3 variants (SLH-DSA-SHAKE-128s, SLH-DSA-SHAKE-256s) exist at the same security levels and are available where SHA3 is the organisational preference; the security level is equivalent and the choice is implementation-driven rather than security-driven.

FN-DSA (Falcon) is under NIST standardisation and may become FIPS 206; it is not yet a final FIPS standard. A draft was submitted for approval in August 2025, with a final standard expected no earlier than late 2026. FN-DSA produces compact signatures and is computationally efficient, but its implementation complexity creates practical barriers for enterprise HSM integration. FN-DSA requires floating-point arithmetic for key generation in a way that creates side-channel attack surface, and HSM vendors have been prioritising ML-DSA for their FIPS 140-3 validated modules. For constrained environments with strict size requirements, FN-DSA is relevant to track. For enterprise PKI running on standard HSM hardware, ML-DSA is the default choice while FN-DSA standardisation is completed.

Hybrid certificates, under active development in the IETF LAMPS working group (draft-ietf-lamps-pq-composite-sigs), contain two or more component public keys: at minimum one classical and one post-quantum. They may support migration and interoperability, but whether they deliver hybrid authentication depends on certificate-chain design, the validation policy applied by relying parties, and the presence of downgrade protection. Using a hybrid certificate does not automatically achieve a hybrid-security posture; the chain of trust and protocol-level protection must be designed to prevent a classical-only downgrade. Production availability depends on individual CA platform vendor timelines, and the draft is still active; enterprise PKI teams planning Phase 2 should monitor its progression.

Root CA Migration: The Highest-Stakes Step

An offline root CA migration is the most consequential step in PKI migration, and the one with the longest lead time.

For public trust contexts, TLS on the public internet, the picture varies significantly by browser. Mozilla, Apple, and Microsoft operate traditional X.509 root inclusion programmes; a new root CA (including an ML-DSA root) must be submitted and approved before the relevant browser or operating system will trust it, a process that has historically taken 12 to 24 months. Chrome is on a different trajectory. Google is developing Merkle Tree Certificates (MTC) as the mechanism for quantum-resistant HTTPS in Chrome, supported by a dedicated Chrome Quantum-resistant Root Store (CQRS). A key policy position for CQRS is that it will not accept traditional X.509 certificates with post-quantum signatures; quantum-resistant certificates in Chrome will initially be supported only in MTC format. Organisations planning for WebPKI should therefore distinguish between the Mozilla/Apple/Microsoft inclusion path for ML-DSA X.509 roots and Chrome's MTC/CQRS direction; these are not the same programme. As of the knowledge cutoff for this article, MTC is in feasibility testing with public rollout targeted from 2027. Private enterprise PKI is not affected by this distinction: internal trust stores can be provisioned through MDM and Group Policy regardless of browser root policy.

For private enterprise PKI, the root migration is more tractable. A new ML-DSA root needs to be pushed to enterprise trust stores via Group Policy, MDM profiles, or configuration management tooling, a solved distribution problem for most enterprises. The gate is HSM readiness: an offline root CA signing ceremony requires HSM firmware with validated ML-DSA support at FIPS 140-3 Level 3. Thales Luna Network HSM and Entrust nShield have publicly stated ML-DSA roadmap commitments; the current FIPS 140-3 validation status of specific modules should be confirmed against the NIST Cryptographic Module Validation Program (CMVP) database before scheduling any root ceremony. A vendor roadmap commitment is not the same as a validation certificate.

End-Entity Certificates: Lifecycle Management

End-entity certificates operate on shorter cycles than CA certificates, which makes their migration more tractable. The CA/Browser Forum Ballot SC-081v3 (passed April 2025) established a staged reduction in the maximum validity period for publicly trusted TLS certificates: 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The previous hard maximum was 398 days. Short-lived certificates mean that once the issuing infrastructure supports ML-DSA, new certificates are issued on ML-DSA within one or two renewal cycles; migration happens automatically at the next renewal rather than requiring manual action on every certificate. The 47-day maximum from 2029 accelerates this: the window between a quantum-safe issuing CA going live and full end-entity coverage shrinks considerably.

ACME protocol infrastructure (RFC 8555) must be audited for ML-DSA compatibility before high-volume rotation begins. ACME clients (Certbot, acme.sh, cert-manager in Kubernetes) and ACME servers (Boulder running Let's Encrypt, Step-CA) are at different stages of ML-DSA support. Teams running ACME-based automation should not assume their stack is ML-DSA ready because one component is, the compatibility question applies to each component individually.

Code signing certificates used for long-lived artefacts are the highest-risk end-entity category. A firmware binary signed in 2024 with an ECDSA certificate will have its signature verified by devices receiving firmware updates in 2030, 2035, and beyond. If ECDSA is disallowed by that point and the device's verification toolchain enforces it, the firmware verification chain breaks unless the binary is re-signed. The re-signing programme for long-lived code artefacts is an independent workstream from certificate renewal. It needs to start now, not when the 2030 deprecation date arrives with a backlog of firmware binaries that have never been re-signed under a post-quantum key. SLH-DSA (FIPS 205) is a candidate algorithm worth evaluating for long-lived archive signing. Its security rests on hash function properties rather than lattice assumptions, providing algorithmic diversity and a conservative security basis. FIPS 205 does not present SLH-DSA as an archive-signing standard; whether it is appropriate for a given archive depends on the applicable AdES, timestamp, and long-term validation regime in use.

Revocation Infrastructure: The Overlooked Migration Item

OCSP responders and CRL distribution points sign their responses. If those signatures use RSA and the date is 2031, the revocation infrastructure is running a deprecated algorithm even if the certificates it is vouching for are ML-DSA. Revocation services are frequently overlooked in migration planning precisely because they sit downstream of the CA and are less visible. The planning team that migrates the issuing CAs without touching the OCSP responders creates a compliance finding they will discover under audit.

OCSP stapling (RFC 6066) provides a deployment efficiency that is worth understanding in a migration context. With OCSP stapling, the TLS server retrieves and caches an OCSP response from the CA and includes it in the TLS handshake, removing the need for every client to make a separate OCSP request at connection time. What stapling does not change is where cryptographic verification happens: the relying party client must still verify the signature on the stapled OCSP response (RFC 6960). An ML-DSA-signed OCSP response still requires relying-party support for ML-DSA. Stapling shifts retrieval and caching to the server; it does not transfer signature verification. The implication for migration planning is that OCSP responder algorithm migration and client-side algorithm readiness must be assessed together.

Key Escrow, Archival, and Long-Lived Document Signatures

Regulated sectors that require encrypted data and its decryption keys to be archived for audit or legal hold have a compounded migration problem. Where RSA or ECDSA key pairs are escrowed alongside encrypted data, the escrow itself creates a Harvest Now, Decrypt Later (HNDL) exposure. A cryptographically relevant quantum computer running Shor's algorithm can derive the private key from the escrowed public key, allowing retrospective decryption of anything protected under that key pair.

Re-keying escrowed data requires two distinct migration tracks, which are separate from the certificate infrastructure work and must run in parallel. The first track is encrypted archive migration: the data encryption keys protecting archived data must be rewrapped under a post-quantum key establishment mechanism. ML-KEM (FIPS 203) establishes a shared secret, which is then used with symmetric encryption to protect bulk data; ML-KEM does not encrypt bulk data directly. The second track is signature and archive validation migration: certificates, timestamps, and long-term validation evidence covering archived documents must move to post-quantum signature algorithms (ML-DSA, FIPS 204, or SLH-DSA, FIPS 205) under the applicable AdES or timestamp framework. Conflating these two tracks, treating ML-DSA or ML-KEM as interchangeable, produces a plan that addresses one exposure while leaving the other open.

Long-lived digital signatures on documents present a related problem. ECDSA or RSA signatures on contracts, regulatory filings, and court submissions will eventually become unverifiable if those algorithms are disallowed and the verification toolchain is updated to reject them. RFC 3161 timestamps, trusted timestamp tokens that record the existence and signing status of a document at a specific point in time, provide a partial mitigation. A timestamp applied before the disallowed date is evidence the document existed and was signed before algorithm retirement, providing a legal continuity argument. ETSI EN 319 102-1 (AdES signature formats) provides the framework for long-term signature preservation in regulated document contexts. Planning for long-lived document signature migration should run alongside the certificate infrastructure programme, not after it.

A Four-Phase Migration Plan for PKI Teams

Phase 1: Now, 2026, PKI inventory. Map the complete certificate hierarchy: offline roots, subordinate CAs, issuing CAs, OCSP and CRL infrastructure, HSM platforms and firmware versions, and the certificate management automation stack. Identify which components support ML-DSA today and which require vendor roadmap commitments before migration can begin. The components requiring the longest vendor lead times should drive the Phase 2 start date. NIST NCCoE SP 1800-38B is a useful preliminary reference for cryptographic discovery tooling (covering test plans, threat modelling, and high-level architecture), but it is a preliminary draft, not a complete PKI migration methodology. Teams should use it as a starting point for discovery tooling decisions rather than as a comprehensive migration guide.

Phase 2: 2026 to 2028, Parallel root establishment. Stand up a new ML-DSA root CA alongside the existing RSA/ECDSA root. Begin issuing ML-DSA intermediate and issuing CA certificates under the new root. Push the new root into enterprise trust stores. For public PKI: initiate root inclusion programme applications. Test ACME automation for ML-DSA compatibility. Begin the long-lived code artefact re-signing programme. For algorithm selection decisions in this phase, see the FIPS implementation decision map.

Phase 3: 2028 to 2030, End-entity rotation. Cease issuing new RSA and ECDSA end-entity certificates under the existing hierarchy. Route all new certificate requests to ML-DSA issuing CAs. Rotate short-lived TLS certificates, typically two annual cycles, to ML-DSA. Address OCSP and CRL infrastructure. Complete the Phase 2 long-lived artefact re-signing backlog before the 2030 deprecation date. For the broader migration calendar and cross-programme dependencies, see the PQC migration timeline.

Phase 4: 2030 to 2035, Legacy retirement. Retire the original RSA and ECDSA root and intermediate CAs as their validity periods expire or as all dependent systems have migrated. Complete the re-signing backlog for long-lived artefacts, including any items that emerged after Phase 3. Migrate key escrow and archival systems to ML-KEM. Confirm CMVP validation status of all HSMs in operation.

Crypto agility, the architectural principle of separating algorithm selection from application logic, determines how easily the Phase 2 to Phase 3 transitions happen. Organisations that have already abstracted cryptographic operations through PKCS#11 interfaces, JCE/JCA providers, or OpenSSL engine abstraction can change algorithm selection at the middleware layer. Where applications hardcode RSA key operations or certificate parsing, each one requires application-layer changes. Document crypto agility gaps during Phase 1 to plan remediation in Phase 2, finding hardcoded algorithm dependencies in Phase 3 adds scope and schedule risk when it is least welcome. NIST CSWP 04282021, "Getting Ready for Post-Quantum Cryptography," covers the crypto agility principle in full.