Post-quantum PKI certificate migration is the process of replacing the digital signature algorithms that underpin an organisation’s X.509 certificate infrastructure with quantum-resistant alternatives, standardised by NIST in FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), before cryptographically relevant quantum computers can break the RSA and elliptic-curve schemes currently in use. For regulated organisations in the EU public sector, finance, healthcare and legal sectors, this is not a future-planning exercise: it is an active compliance obligation with deadlines already published.
Why PKI Migration Is Categorically Different from Upgrading Session Encryption
Replacing session-key encryption in TLS is relatively contained: update the library, deploy a new configuration, and every new session automatically uses the new key-encapsulation mechanism. Certificate migration is a different class of problem entirely.
Digital signatures embedded in certificates are long-lived. A root CA certificate issued today may carry a validity period of 20 to 25 years. The signature on that certificate, produced with RSA-4096 or ECDSA P-384, must remain verifiable for its entire lifetime. If a quantum computer capable of breaking those algorithms becomes available in 2035, every document signed, every authentication performed, and every code binary verified under that root between now and then becomes retrospectively untrustworthy. This is the “harvest now, decrypt later” threat applied to identity, not just confidentiality.
Key-encapsulation mechanisms (KEMs) protect data in transit; once the session closes, breaking the session key yields nothing new. A certificate signature, by contrast, binds an identity claim. Forging or invalidating it retroactively undermines audit trails, legal non-repudiation, contract validity and regulatory evidence, precisely the assets that compliance officers in GDPR, DORA and NIS-2-regulated environments are responsible for protecting.
Furthermore, the entire X.509 certificate ecosystem must move together. A single upgraded leaf certificate achieves nothing if the intermediate CA that signed it still uses RSA, because the chain of trust is only as strong as its weakest link. Root CAs, intermediate CAs, OCSP responders, CRL distribution points, and every relying party from browser to IoT device must all be updated in a coordinated sequence.
The Three Certificate Migration Models
There are three recognised approaches to migrating certificates, each with different suitability for long-lived identity credentials in regulated environments.
| Model | How it works | Backward compatibility | Best suited for |
|---|---|---|---|
| Composite certificate | A single X.509 object carries both a classical (RSA/ECDSA) and a PQC signature. Relying parties validate whichever they support. | High: legacy systems fall back to the classical signature | Transitional infrastructure where not all endpoints can be updated simultaneously |
| Dual certificate | Two separate certificates are issued for the same identity: one classical, one PQC. Systems present whichever the relying party accepts. | High: legacy systems use the classical certificate | Environments with heterogeneous relying parties and flexible protocol stacks |
| PQC-only certificate | A single certificate carrying only a post-quantum signature, with no classical fallback. | None: requires all relying parties to support PQC before deployment | New greenfield deployments, or closed environments where all endpoints are under organisational control |
For long-lived identity credentials in regulated environments, the composite model is generally the most appropriate choice during the transition period. It preserves interoperability with legacy systems while ensuring that any relying party capable of validating the PQC signature does so. The IETF PQUIP Working Group is actively developing the protocol specifications that will underpin composite certificate deployment across IETF-based protocols, and organisations should track this work to ensure their implementations align with emerging standards.
Maintaining Chain of Trust During the Transition
The sequence of migration across the certificate hierarchy is critical. Migrating leaf certificates before root and intermediate CAs creates broken chains. The correct order is root CA first, then intermediate CAs, then OCSP responders and CRL infrastructure, and finally leaf certificates.
Root CA migration is the highest-stakes step. A new PQC root CA must be pre-installed in all trust stores (operating systems, browsers, HSMs, application trust anchors) before any certificates it issues can be validated. This distribution process alone can take 12 to 18 months for widely used public roots. For enterprise private PKI, the timeline is shorter but still requires coordinated deployment across all endpoints, including remote and travelling staff.
OCSP responders and CRLs must be updated to sign their responses with PQC algorithms once the issuing CA has migrated. An OCSP response signed with RSA from a CA that has migrated to ML-DSA creates a trust mismatch that breaks revocation checking, one of the less obvious failure modes that organisations frequently overlook during migration planning.
The EU Regulatory Obligation: C(2024) 2393
EU Commission Recommendation C(2024) 2393 on the post-quantum cryptography transition roadmap, published in 2024, sets explicit expectations for public-sector entities and operators of critical infrastructure covered by NIS-2. The recommendation calls for a completed cryptographic inventory by 2025, prioritisation of long-lived and high-value credentials (precisely the PKI assets most at risk), and progressive implementation of quantum-safe algorithms in critical systems through 2027 and beyond.
While C(2024) 2393 is a recommendation rather than a binding regulation, it is the interpretive framework that NIS-2 national competent authorities will apply when assessing whether organisations have taken “appropriate technical measures” under Article 21 of Directive 2022/2555. DORA-regulated financial entities face equivalent pressure through EBA and EIOPA guidance on ICT risk management. The IBM Cost of a Data Breach Report 2023 found that the average time to identify and contain a data breach was 277 days, a figure that underlines how long undetected certificate compromise can persist.
ENISA has stated plainly: “Organisations should not wait for quantum computers to arrive before acting. The time to migrate cryptographic infrastructure is now, while interoperability standards are being finalised.” The NIS-2 Directive, which took effect in October 2024, now applies to an estimated 160,000 entities across the EU, a tenfold increase over the NIS-1 scope, meaning the population of organisations with a formal obligation to address this has expanded dramatically.
ML-DSA vs. SLH-DSA for Long-Lived Certificate Signing
NIST FIPS 204 standardises ML-DSA (formerly CRYSTALS-Dilithium), a module-lattice-based signature scheme. NIST FIPS 205 standardises SLH-DSA (formerly SPHINCS+), a stateless hash-based scheme. Both are approved for use in certificate signing, but their properties make them suitable for different positions in the hierarchy.
ML-DSA produces smaller signatures and verifies faster than SLH-DSA, making it the practical default for intermediate CAs and leaf certificates where performance and certificate size affect operational systems. Its security rests on the hardness of module lattice problems, which are well-studied but structurally different from the hash-function security that SLH-DSA relies upon.
SLH-DSA’s security assumptions reduce entirely to the collision resistance of standard hash functions (SHA-2 or SHA-3). For root CA certificates that may carry validity periods of 20 years or more, and whose compromise would be catastrophic, this conservative security model is a significant advantage. The larger signature size (several kilobytes versus a few hundred bytes for ML-DSA) is irrelevant for a root CA certificate that is distributed once and cached. Dustin Moody, NIST’s PQC project lead, has noted that “the transition to post-quantum cryptography is not a simple algorithm swap: it requires rethinking trust anchors, certificate lifetimes, and the entire chain of custody for digital identities.” For root CAs with the longest lifetimes and highest assurance requirements, SLH-DSA is the more defensible choice.
A CISO’s Concrete First Steps: Cryptographic Inventory and Prioritisation
The practical starting point is a cryptographic bill of materials (CBOM), an inventory of every cryptographic dependency in the organisation mapped to the asset it protects. The NIST NCCoE Migration to PQC Project provides tooling guidance and reference architectures for this discovery phase.
Concretely, the inventory should cover: all certificate stores (Windows Certificate Store, Java keystores, browser trust anchors, application-embedded certificates); every HSM and its firmware version; code-signing pipelines and the certificates used to sign firmware, software packages and container images; VPN gateways and their IKE/IPsec certificate configurations; and TLS endpoints including internal services that are often overlooked in external-facing security programmes.
Each asset should be tagged with: the signing algorithm and key length; the certificate expiry date; whether it is part of a public or private PKI hierarchy; and the sensitivity classification of the data or system it protects. This tagging immediately produces a prioritisation matrix. Long-lived credentials (root CAs, document-signing certificates, code-signing certificates) with high sensitivity ratings move to the front of the migration queue. Short-lived TLS leaf certificates with 90-day lifetimes are the lowest priority because they will be replaced dozens of times before quantum risk materialises.
Once the inventory is complete, the CISO should identify which certificate authorities (internal or external) have published PQC migration roadmaps and align internal timelines accordingly. For private PKI operated in-house, the decision on migration model (composite, dual, or PQC-only) should be documented and aligned with C(2024) 2393 milestones before the end of 2025.
FAQ
Why is PKI migration to post-quantum cryptography harder than upgrading TLS session keys?
TLS session keys are ephemeral and replaced with every session, so a library update is sufficient. PKI certificates carry long-lived digital signatures that bind identities to public keys. Every root CA, intermediate CA, OCSP responder, CRL, and relying party must simultaneously support the new algorithm, requiring a system-wide coordinated update rather than a point fix.
What is a composite certificate and when should an organisation use it?
A composite certificate embeds both a classical (RSA or ECDSA) and a post-quantum signature in a single X.509 object. A relying party that understands both algorithms validates both; a legacy system falls back to the classical signature. This model is best suited to transitional periods where not all endpoints can be updated simultaneously, which describes most regulated organisations today.
What does EU Commission Recommendation C(2024) 2393 require, and for whom?
C(2024) 2393 calls on EU member states and public-sector bodies to complete a cryptographic inventory by 2025, prioritise migration of long-lived and high-value credentials, and implement quantum-safe algorithms in critical infrastructure progressively through 2027 and beyond. It is a recommendation, not binding regulation, but it defines the “appropriate technical measures” standard under NIS-2 and will inform how national competent authorities assess compliance.
Which post-quantum signature algorithm is better for certificates that must stay trusted for ten or more years: ML-DSA or SLH-DSA?
ML-DSA (FIPS 204) offers smaller signatures and faster performance, making it suitable for most certificate use cases. SLH-DSA (FIPS 205) relies only on the security of hash functions, providing a more conservative long-term security assumption at the cost of larger signature sizes. For root CA certificates with very long lifetimes, SLH-DSA’s security model is preferable despite its overhead.
How should a CISO start a cryptographic inventory today?
Use tooling aligned with the NIST NCCoE Migration to PQC Project guidance to discover every certificate store, HSM, code-signing pipeline, VPN gateway, and TLS endpoint. Tag each asset by algorithm, key length, expiry date, and the sensitivity of the data it protects. Prioritise long-lived credentials (root CAs, document signing, code signing) first, then infrastructure certificates, then short-lived TLS leaves. Document the result as a cryptographic bill of materials (CBOM) and align migration sequencing with C(2024) 2393 milestones.