Migrating TLS and PKI to Post-Quantum Cryptography

The uncomfortable truth about post-quantum migration is that the deadline already passed for some of your data. A capable quantum computer does not exist yet, but the harvest now, decrypt later threat means an adversary recording your TLS traffic today can decrypt it the moment one does. For any secret with a confidentiality lifetime measured in years — health records, intellectual property, state secrets, long-lived credentials — the clock started the day that traffic crossed the wire.

This is a practitioner's plan for migrating TLS and PKI to post-quantum cryptography. It is grounded in the standards that actually exist as of 2026, the tooling that is actually shipping, and the migration work we have run on real enterprise estates — not in a marketing horizon where everything is "quantum-ready" by next quarter.

TL;DR / Key takeaways

• The driver is harvest now, decrypt later: confidentiality, not authentication, is the urgent risk, so TLS key exchange (ML-KEM) moves first.
• NIST finalised the standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures.
• The pragmatic 2026 deployment is the hybrid TLS handshake — classical X25519 plus ML-KEM — which stays secure if either algorithm holds.
• PKI signature migration (ML-DSA / SLH-DSA) is the long tail: roots and intermediates move last, gated by CA and HSM support that is still maturing.
• A realistic enterprise migration runs 5 to 15 years; cryptographic discovery alone takes 12 to 24 months. The durable goal is crypto-agility, not a one-time swap.

Why TLS and PKI are two different problems

It is tempting to treat "post-quantum migration" as a single project. In practice TLS and PKI fail to quantum computers in different ways and on different timelines, and conflating them is the first mistake teams make.

TLS key exchange is about confidentiality. The classical Diffie-Hellman or ECDH exchange that establishes your session keys is exactly what an attacker captures and stores. This is the harvest-now target, and it is the part you can and should move first — because a fix deployed today protects sessions recorded today.

PKI signatures are about authentication and integrity. A forged certificate signature only helps an attacker who has a quantum computer now; you cannot retroactively forge a handshake that already happened. The risk is real but it is a future-dated risk, which buys you time to do the harder structural work: certificate authorities, hardware security modules, root-of-trust ceremonies, and the entire issuance and revocation machinery.

Dimension	TLS key exchange	PKI signatures
Property at risk	Confidentiality	Authentication / integrity
Quantum threat type	Harvest now, decrypt later (retroactive)	Real-time forgery (future-dated)
Urgency	High — move first	Moderate — sequence after
2026 standard	FIPS 203 (ML-KEM)	FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
Practical first step	Hybrid handshake	Inventory + agility, then leaf-up rollout
Main blocker	Endpoint and library support	CA, HSM, and ecosystem readiness

Reading the table the right way: start with key exchange, sequence signatures behind it. That single decision keeps the urgent risk addressed while you take the time PKI genuinely needs.

The standards you are actually migrating to

NIST finalised three post-quantum standards in August 2024, and these — not draft algorithms — are what you design against:

• FIPS 203 — ML-KEM (derived from CRYSTALS-Kyber): a key encapsulation mechanism. This is the algorithm that replaces or augments classical key exchange in TLS. It is the centre of gravity for the harvest-now problem.
• FIPS 204 — ML-DSA (derived from CRYSTALS-Dilithium): a lattice-based digital signature scheme. The default choice for most quantum-safe PKI signatures.
• FIPS 205 — SLH-DSA (SPHINCS+): a hash-based signature scheme. Slower and larger, but built on conservative, well-understood hash assumptions — valuable for long-lived roots where you want maximum confidence in the security foundation.

Two engineering realities follow. First, these algorithms are bigger. ML-KEM keys and ML-DSA signatures are substantially larger than their elliptic-curve equivalents, which inflates handshake sizes, certificate chains, and packet counts. Test for MTU fragmentation, buffer limits in middleboxes, and latency on constrained links before you celebrate a working handshake. Second, they are young. ML-KEM has had far less cryptanalytic scrutiny than RSA or ECC, which is precisely why the industry consensus — Google, Cloudflare, AWS, Microsoft, all targeting roughly 2029 internally — is hybrid, not pure PQC.

Hybrid TLS: the pragmatic 2026 posture

A hybrid TLS handshake runs a classical key exchange (typically X25519) and a post-quantum KEM (ML-KEM) together, then derives the session secret from both. The session is secure as long as either component holds. If ML-KEM is later broken, you still have X25519; if a quantum computer arrives, you still have ML-KEM. You are not betting the estate on a single young algorithm.

This is not theoretical. Hybrid key exchange is already deployed at scale across major browsers and cloud front doors, and it is the right default for any internet-facing TLS termination point you control today.

Practical guidance from our deployments:

1. Start at the edge. Load balancers, API gateways, and reverse proxies are where you terminate the most internet-facing TLS and where hybrid support has landed first. Enabling it there protects the largest volume of harvest-now traffic with the fewest changes.
2. Measure the handshake. Larger key shares change packet sizes. Validate against your real network path — VPN concentrators, firewalls, and IoT links are where oversized handshakes break first.
3. Negotiate, do not mandate — yet. Offer hybrid groups and let clients negotiate. Hard-failing on classical-only clients before the ecosystem is ready turns a security upgrade into an outage.
4. Log what gets negotiated. You cannot manage what you cannot see. Capturing the agreed key-exchange group per connection is how you measure real coverage instead of assuming it.

On Azure specifically: Microsoft added ML-KEM and ML-DSA to SymCrypt in late 2024, and the primitives are working their way up the stack through 2026. We cover the key-management dimension in depth in our note on Azure Key Vault and post-quantum migration, including where Key Vault and Managed HSM support currently stands.

Migrating the PKI: the long tail

PKI is harder because trust is hierarchical and slow to turn. You do not flip a root CA to ML-DSA on a Tuesday. The migration runs outward from the leaves:

1. Leaf certificates first. End-entity certificates have short lifetimes and high churn, so they are the natural place to introduce PQC or hybrid certificates once your issuing CA and clients support them.
2. Intermediates next. These rotate less often and validating clients must trust the new signature algorithm before you cut over.
3. Roots last. Root keys live in HSMs for a decade or more and are embedded in trust stores you do not control. They move only when the ecosystem — operating systems, browsers, device trust stores — can validate the new algorithm.

Expect to run parallel trust chains for years: classical and post-quantum certificates issued side by side, with clients selecting what they can validate. This is normal and it is why the work is measured in years, not sprints. The two prerequisites are not yet fully in place in 2026 — public CAs are not issuing production PQC certificates at scale, and HSM firmware support is still arriving — which is exactly why the right 2026 investment is structural readiness, not a premature root migration.

Discovery first, or you are guessing

You cannot migrate cryptography you cannot see, and crypto hides everywhere: hard-coded in application libraries, baked into appliance firmware, pinned in mobile apps, embedded in third-party products, and scattered across certificate stores and HSM partitions. This is why cryptographic discovery alone takes 12 to 24 months for a large organisation, and why it is the single most under-budgeted phase.

A usable inventory records, for every cryptographic use: the algorithm and key length, the certificate lifetime, the data's confidentiality lifetime, and external exposure. That last pairing — confidentiality lifetime against exposure — is what lets you prioritise honestly. A public-facing endpoint protecting ten-year secrets is a different problem from an internal service protecting ephemeral session data. We treat this as the foundation of every engagement and have written it up separately in our guide to cryptographic discovery and inventory.

Crypto-agility is the actual deliverable

Here is the strategic point that gets lost in algorithm names: ML-KEM is not the destination. The standards will keep evolving, recommendations will shift, and something in today's PQC lineup may yet be weakened. If your response to that is another multi-year project, you have not solved the problem — you have rescheduled it.

The durable goal is crypto-agility: an estate where the cryptographic algorithm is configuration, not a hard-coded assumption. Concretely, that means abstracting crypto behind interfaces rather than calling primitives directly, centralising certificate and key management so rotation is automated, shortening certificate lifetimes so the system is built to change, and keeping the discovery inventory live so the next migration starts from knowledge rather than archaeology. We develop this into a full programme in our crypto-agility roadmap for the enterprise, and it sits naturally inside a broader Zero Trust posture where no algorithm, key, or certificate is implicitly trusted forever.

For context on external pressure: NSA's CNSA 2.0 requires quantum-safe algorithms for new national-security systems by January 2027, with full migration across 2030 to 2035. Most commercial enterprises are not bound by CNSA 2.0, but it is the clearest signal available of how seriously the most security-conscious buyers are treating the timeline — and supply chains tend to follow.

A pragmatic sequence

The phases below run in order, but the last one feeds back into the first: operationalising algorithm choice as live configuration is what makes the next migration a routine update rather than a fresh project.

Loading diagram...

1. Run cryptographic discovery across TLS, certificates, HSMs, libraries, and third-party products.
2. Prioritise by harvest-now exposure — confidentiality lifetime against external reach.
3. Enable hybrid TLS key exchange at edge termination points and validate interoperability and handshake size.
4. Re-architect PKI for agility: shorter certificate lifetimes, automated rotation, algorithm decoupled from code.
5. Migrate signatures leaf-up to ML-DSA / SLH-DSA as CAs and HSMs add support, running parallel trust chains.
6. Operationalise: monitor negotiated algorithms, treat crypto as managed configuration, keep the inventory live.

Start the discovery now. The migration itself may take a decade, but the harvest-now traffic you fail to protect this year is decrypted on the attacker's schedule, not yours.

FAQ

Do I need to migrate TLS to post-quantum cryptography now if quantum computers cannot break it yet? Yes, because the threat is harvest now, decrypt later. Adversaries can capture today's TLS-protected traffic and store it until a cryptographically relevant quantum computer exists, then decrypt it retroactively. Any data with a confidentiality lifetime longer than your migration window is already at risk, which is why key-establishment migration is the urgent first move.

What are FIPS 203, 204, and 205? They are the post-quantum standards NIST finalised in August 2024. FIPS 203 is ML-KEM for key encapsulation (the TLS key exchange), FIPS 204 is ML-DSA, a lattice-based signature scheme, and FIPS 205 is SLH-DSA, a hash-based signature scheme. ML-KEM addresses the harvest-now risk in TLS; ML-DSA and SLH-DSA are the basis for quantum-safe PKI signatures.

What is a hybrid TLS handshake and why use it? A hybrid handshake combines a classical key exchange such as X25519 with a post-quantum KEM such as ML-KEM in a single negotiation, deriving the session secret from both. It stays secure as long as either algorithm holds, so you get post-quantum protection without betting everything on a young algorithm. Most early deployments, including major cloud and browser rollouts, use hybrid for exactly this reason.

How long does a post-quantum PKI and TLS migration realistically take? For a large enterprise, plan on 5 to 15 years end to end. Cryptographic discovery and inventory alone typically take 12 to 24 months because crypto is embedded in code, appliances, certificates, HSMs, and third-party products. TLS key exchange can move relatively early via hybrid; root and intermediate CA signature migration is the long tail.

Is Azure ready for post-quantum TLS and PKI? Partially, and it is moving. Microsoft added ML-KEM and ML-DSA to SymCrypt in late 2024, and Azure Key Vault and Managed HSM post-quantum support is tracking through 2026. Public certificate authorities have not yet issued production PQC certificates at scale, so the pragmatic 2026 posture is hybrid TLS where supported plus a crypto-agile design that can adopt PQC certificates when CAs and HSMs are ready.

What is crypto-agility and why is it the real goal? Crypto-agility is the ability to change cryptographic algorithms, key sizes, and certificate types quickly and safely without re-architecting systems. Because post-quantum standards and recommendations will keep evolving, the durable objective is not a single swap to ML-KEM but an estate where algorithms are configuration, not hard-coded assumptions. Agility is what lets you respond to the next break in months rather than years.

---

Scoping a post-quantum migration and want a discovery and crypto-agility plan that survives contact with a real estate? Our Zero Trust and cybersecurity practice helps European enterprises inventory their cryptography, deploy hybrid TLS, and design a quantum-safe PKI on Azure. We are practitioners who have done this work — happy to compare notes.