The threat is already active. Adversaries are harvesting encrypted traffic right now — TLS sessions, API calls, database backups — sitting on it until a cryptographically relevant quantum computer exists and they can decrypt it. That is the harvest-now-decrypt-later (HNDL) threat, and it makes this an urgent architecture decision. Not a future problem. Now.
PQC migration actually has two tracks, and they have very different timelines. Key agreement — hybrid TLS using X25519MLKEM768 — is deployable today. It already protects over 52% of TLS traffic at Cloudflare and is enabled by default in iOS 26, Chrome, Firefox, and Edge. Signatures, authentication, and PKI are a different story: a multi-year undertaking with significantly more moving parts.
This article explains the mechanics of the first track, then looks at why the second is so much harder. For the business risk context, see why post-quantum cryptography is an immediate business risk.
Why Is Hybrid Cryptography Architecturally Safer Than Pure Post-Quantum During the Transition?
Hybrid post-quantum cryptography combines a classical algorithm with a post-quantum algorithm in a single protocol run. The security guarantee is precise: the shared secret remains secure if either component is unbroken. An attacker has to break both simultaneously. That is a much harder problem than breaking one.
That disjunctive property is what makes hybrid stronger than either algorithm alone. ML-KEM has gone through rigorous NIST evaluation, but it has accumulated less real-world cryptanalytic scrutiny than RSA and elliptic-curve cryptography. Confidence is high — not absolute. Hybrid acknowledges that asymmetry honestly. If a cryptanalytic breakthrough weakens ML-KEM, X25519 holds. If a quantum computer breaks X25519, ML-KEM holds.
The X25519 component is not there for backwards compatibility. It is genuine defence-in-depth. Cloudflare keeps it for three explicit reasons: cryptanalytic insurance against a lattice-based breakthrough; defence against implementation vulnerabilities in newer post-quantum code; and the extensive deployment history of X25519 as a proven baseline.
The appropriate time to consider pure ML-KEM is when the algorithm has accumulated sufficient cryptanalytic scrutiny from broad deployment — likely several years from now. For greenfield systems with no interoperability requirements, pure PQC is worth evaluating today. For everything else, hybrid mode is the right default. NIST and IETF agree.
How Does ML-KEM Key Encapsulation Differ From Diffie-Hellman — and Why Does This Matter?
Both establish a shared secret between two parties. The mechanisms are completely different.
Diffie-Hellman: co-derivation. Both parties generate a private value, exchange public values, and independently compute the same result. Security depends on the discrete logarithm problem — which Shor’s algorithm breaks on a sufficiently powerful quantum computer.
ML-KEM: one-sided encapsulation. FIPS 203 defines three operations:
- KeyGen — one party (the server in TLS) generates a public/private keypair
- Encaps — the other party (the client) uses the public key to generate a shared secret and a ciphertext; only the ciphertext is transmitted
- Decaps — the server uses its private key to recover the same shared secret from the ciphertext
Neither party negotiates. One generates and the other recovers.
ML-KEM’s quantum resistance comes from the Module Learning With Errors (MLWE) problem — a lattice problem that is hard for both classical and quantum computers. There is no quantum algorithm analogous to Shor’s discrete-log attack for MLWE.
ML-KEM-768 in practice. This is the enterprise default, operating at NIST Security Level 3. Key sizes are larger than X25519: encapsulation key 1,184 bytes, ciphertext 1,088 bytes. ML-KEM computation is actually faster than X25519 on modern hardware. The overhead is entirely in wire bytes — approximately 2,272 bytes added to the TLS handshake. Once the handshake completes, there is no per-packet overhead.
What Is X25519MLKEM768 and How Do Two Secrets Become One Session Key?
X25519MLKEM768 is an IETF-proposed hybrid key agreement (TLS codepoint 0x11ec) combining X25519 with ML-KEM-768. It is not an ad-hoc Cloudflare invention — the earlier X25519Kyber768Draft00 (codepoint 0x6399) is now obsolete.
Here is how it works in a TLS 1.3 handshake. The client advertises X25519MLKEM768 in the supported_groups extension. Both sides independently run the X25519 key exchange and the ML-KEM encapsulation/decapsulation, each producing a shared secret. Those two secrets are concatenated and passed through HKDF (as specified in NIST SP 800-56C) to produce a single TLS session key. Neither secret alone determines the result. Recovering the session key requires breaking both components.
The wire overhead is approximately 2,272 bytes at connection establishment — a one-time handshake cost, not per-request overhead.
This is not a draft proposal. By late 2025, over 52% of TLS 1.3 traffic at Cloudflare used X25519MLKEM768. iOS 26 enables it by default. Chrome enabled it on desktop in March 2024. Approximately 39% of the top 100,000 domains supported it by September 2025. This is the production architecture.
How Does ML-DSA Change the Architecture of PKI, Certificates, and Code Signing?
ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) replaces ECDSA in certificate chains and code signing. The algorithm change carries a structural consequence: every certificate in the system grows substantially.
ECDSA P-256 produces a 64-byte public key and a 72-byte signature. ML-DSA-65 produces a 1.95KB public key and a 3.3KB signature. A single TLS handshake involves five signatures and two public keys across the certificate chain. Cloudflare has measured that deploying even ML-DSA-44 — the smallest parameter set — would add approximately 15KB to typical TLS handshakes. Certificate chains larger than 10KB cause compatibility issues with current infrastructure.
That size expansion cascades through every system that processes certificates: OCSP responders, CT logs, load balancers, and TLS record handling in proxies.
Composite certificates. The backward-compatible transition pattern uses X.509 certificates carrying both a classical key/signature and an ML-DSA key/signature. A client that supports ML-DSA validates the PQ signature; a legacy client validates the classical signature. The composite certificate draft is approaching RFC status; EJBCA (Keyfactor) has proof-of-concept deployments running on Bouncy Castle’s composite implementation.
Device-bound request signing. ML-DSA-65 also appears in mobile authentication. Microsoft’s reference implementation combines ML-DSA-65 with ECDSA P-256, with keys generated in iOS Secure Enclave or Android Keystore — hardware-backed, non-exportable. This is the emerging post-quantum authentication pattern for mobile endpoints.
Why Is PKI Migration the Real Bottleneck — and What Makes It So Hard?
TLS key agreement migration requires a configuration change. PKI migration requires coordinating an entire ecosystem. Those are not the same kind of problem.
The fundamental difference is dependency structure. TLS key agreement is a two-party negotiation at connection time. PKI is a trust chain: root CA, intermediate CAs, leaf certificates, OCSP responders, CT log operators, HSMs, relying-party trust stores — every entity must support the same algorithms for the chain to validate. You cannot partially migrate. If leaf certificates move to ML-DSA while intermediate CAs still sign with ECDSA, the chain breaks for any client validating the ML-DSA path.
Enterprise certificates have lifetimes of one to three years, so the migration window is constrained by rotation cycles, not just algorithm availability. Enterprise PQC migration timelines of five to fifteen years are realistic under normal conditions. For the broader business risk context for this architectural decision — including why the harvest-now-decrypt-later threat makes even a five-year timeline feel tight — see the pillar article.
Then there are the HSMs. Many HSMs in current enterprise deployments were designed for RSA and ECDSA. ML-DSA key sizes may exceed HSM storage limits; ML-DSA signing operations may not be supported in firmware. HSM replacement or firmware upgrade is often a prerequisite for CA migration. You have to sort out your hardware before you can touch your PKI.
For Windows-centric enterprises, Active Directory Certificate Services (ADCS) is the PKI foundation. Microsoft has indicated that ADCS PQC integration is targeted for early 2026. That is a roadmap commitment, not a released feature — but it gives you a planning horizon for when enterprise PKI migration guidance will start to emerge.
PKI migration is underreported as the bottleneck because most coverage focuses on algorithm availability or TLS deployment. The interdependency problem is less visible but is the multi-year constraint. See how these architectural patterns map to migration phases for the organisational timeline.
What Is Cipher Translation and How Does It Make Legacy Systems Quantum-Safe Without Rewriting Them?
PKI migration is a multi-year dependency chain. Cipher translation solves a different problem: what do you do right now with legacy systems that cannot wait?
Cipher translation is a network-layer proxy pattern where a next-generation firewall (NGFW) or SASE platform intercepts classical-encrypted traffic from a legacy endpoint and re-establishes a post-quantum TLS session to the destination. The legacy application changes nothing.
Compare it to a VPN. A VPN wraps existing sessions in a new encrypted tunnel. Cipher translation upgrades the algorithm protecting the existing session at the network boundary — the network architecture does not change. The NGFW terminates the inbound classical TLS session, establishes a new outbound TLS session using X25519MLKEM768 to the destination, and relays the payload. From the destination’s perspective, the connection is quantum-safe.
Application-level migration modifies the TLS library configuration and requires code changes and redeployment. Cipher translation requires no application change. It is the right pattern for EOL software, vendor-locked platforms, and firmware that cannot be updated. Cloudflare One’s SASE implementation demonstrates this at enterprise scale; Zscaler and Palo Alto Networks’ Prisma SASE provide equivalent capability.
There is a scope limitation worth being clear about. Cipher translation protects only the segment between the NGFW and the destination. The legacy-client-to-NGFW segment remains classically encrypted. For architectures where the NGFW is the perimeter, that is an acceptable trade-off — but it is not end-to-end post-quantum security.
Use cipher translation for systems you cannot update. Use application-level migration for systems you control and maintain long-term. Both are valid patterns in a crypto-agile architecture.
What Is Cryptographic Agility and How Do You Build Systems That Outlast Any Single Algorithm?
Cipher translation handles systems you cannot update. Cryptographic agility is the design property that ensures systems you do control can be updated without drama when the time comes.
NIST CSWP 39 defines crypto agility as building systems so cryptographic algorithms can be replaced without redesigning the broader system. The PQC migration is the immediate motivation, but this is useful every time an algorithm is deprecated — and that will happen again.
The core pattern is simple. Application code calls “sign this payload with the current signing algorithm” through an abstract interface. The algorithm is specified in configuration, not hardcoded. When the algorithm changes — ECDSA to ML-DSA, SHA-256 to a future replacement — the configuration changes, not the application code.
Systems that hardcoded SHA-1 or MD5 required application-level changes at every callsite to migrate. At PQC scale, hardcoded algorithm references are the primary source of timeline extension and cost overrun. Do not repeat that mistake.
Before you can design for agility, you need to know what you have. A Cryptographic Bill of Materials (CBOM) is the inventory of every algorithm reference, library version, key type, and protocol configuration across your codebase, dependencies, and infrastructure. Without it, PQC migration routinely discovers unexpected systems and hardcoded references mid-migration. The CBOM comes first.
Practical checklist:
- Abstract algorithm references — resolve at configuration time, not compile time
- Hardware-backed key storage — HSMs and TPMs that support algorithm updates via firmware
- Automated certificate rotation — rotation pipelines that can handle new key types
- Data format discipline — avoid embedding algorithm identifiers in formats with long retention requirements
One more thing worth flagging. Hybrid key agreement protects the tunnel. Securing the authentication phase — login flows, certificate-based identity, API authentication — uses ML-DSA signatures, not ML-KEM encapsulation. These are distinct migration tracks with different infrastructure dependencies. A crypto-agile architecture needs to accommodate both. See the underlying NIST algorithm specifications for ML-DSA detail and how these architectural patterns map to migration phases for the migration roadmap.
Frequently Asked Questions
What is hybrid post-quantum cryptography and why does it use two algorithms at once?
Hybrid PQC combines a classical algorithm (X25519) with a post-quantum algorithm (ML-KEM) in a single protocol run. The shared secret remains secure if either algorithm is unbroken — an attacker must break both simultaneously. During the transition period, when ML-KEM has less accumulated cryptanalytic scrutiny than classical algorithms, that disjunctive property provides a stronger overall guarantee than either algorithm alone.
If hybrid PQC uses both X25519 and ML-KEM, does it use more bandwidth?
Yes, but only in the TLS handshake. ML-KEM-768 adds approximately 2,272 bytes to the ClientHello/ServerHello exchange. ML-KEM computation is actually faster than X25519 on modern hardware; the overhead is in wire bytes, not CPU cycles, and it does not recur after the handshake completes.
Should we skip hybrid mode and go straight to pure post-quantum cryptography?
Not recommended for most production systems today. Pure PQC removes the classical safety net during a period when ML-KEM has high confidence but less accumulated scrutiny than RSA or ECDSA. For greenfield systems with no legacy clients, pure PQC is a valid choice. For everything else, hybrid mode provides the stronger guarantee during the transition.
How does a KEM produce a shared secret without both parties contributing to it?
A KEM is one-sided: the encapsulating party uses the recipient’s public key to generate a shared secret and a ciphertext. Only the ciphertext is transmitted. The recipient recovers the shared secret from the ciphertext using their private key. There is no interactive negotiation. Diffie-Hellman requires both parties to contribute secret values and independently compute the same result.
How does our Certificate Authority need to change to support post-quantum certificates?
The CA must support ML-DSA key generation and signing (FIPS 204). All intermediate CAs in the chain must also be migrated — a partial migration breaks the trust chain. HSMs must support ML-DSA operations. OCSP responders must issue ML-DSA-signed responses. CT log operators must support larger certificate payloads. The composite certificate pattern supports backward compatibility during the transition by allowing legacy clients to validate the classical portion of the certificate while ML-DSA support is rolled out.
What is the difference between cipher translation and a VPN?
A VPN wraps all traffic in a new encrypted tunnel layer. Cipher translation upgrades the algorithm protecting the existing session at the network boundary without creating a new tunnel. Cipher translation is a post-quantum upgrade pattern for legacy endpoints; a VPN is a general-purpose network security pattern that is orthogonal to algorithm selection.
What are BSI, ANSSI, and UK NCSC’s algorithm recommendations?
All three accept X25519MLKEM768 for TLS hybrid key agreement. UK NCSC recommends ML-KEM-768 and ML-DSA-65 as the enterprise parameter defaults. Germany’s BSI endorses hybrid with a conservative posture, also accepting FrodoKEM as an alternative for defence-critical applications. France’s ANSSI supports hybrid for both KEM and signatures, offering the widest architectural flexibility.
