Post-Quantum Cryptography in 2026: Kyber, Dilithium, and the Migration That Already Started

The migration nobody wanted to do has quietly started without you. If you are using a recent Chrome, Firefox, or Edge to read this on a Cloudflare-fronted site, your TLS handshake is already running X25519MLKEM768: a hybrid that combines a classical Curve25519 key exchange with the lattice-based ML-KEM-768 that NIST standardized as FIPS 203 in August 2024. If you SSH into a host running OpenSSH 10 or newer, your KEX has been mlkem768x25519-sha256 by default since April 2025. The post-quantum transition stopped being a slide in a CISO deck about 18 months ago. It is now the operational reality that lives in your tls_handshake_duration_seconds p95 graph, in middlebox failure tickets, and in the size of your ClientHello messages.

This is not “post-quantum 101” — the earlier post on this blog covered the basics, the algorithm zoo, and the threat model in some detail. This post is for the engineer who has to make the migration land: what changed in 2026, what the lattice math actually says, where it bites in production, and what the honest hybrid-deployment story looks like in TLS, SSH, code signing, and the Vault PKI you operate. The threat is not that you will wake up to a CRQC tomorrow. The threat is the harvest-now-decrypt-later traffic that is already being captured today against the keys you are still using, and the long-lived signatures (firmware, code-signing roots, software supply chain artifacts) that will outlive RSA-2048 by an embarrassing margin.

What a quantum computer would actually break

Skip this if you are clear on the threat model — it is the only honest place to start, because most of the urgency in the field is calibrated against a machine that does not yet exist. The fear is a cryptographically relevant quantum computer (CRQC): one large enough, coherent enough, and error-corrected enough to run Shor’s algorithm at scale. Shor’s algorithm reduces integer factorization and the discrete logarithm problem to polynomial time on a quantum machine. That breaks RSA, classical Diffie-Hellman, and elliptic-curve discrete log all at once — i.e., everything in the asymmetric column of your openssl ciphers output.

It does not break symmetric cryptography or hashes in the same way. Grover’s algorithm gives a quadratic speedup against generic search: AES-128 effectively becomes “AES-64-against-Grover” — uncomfortable but not catastrophic, and AES-256 keeps a 128-bit post-quantum security margin. SHA-256 collisions get a Grover-style speedup but the practical impact is to push hash-based signatures to bigger output sizes, not to abandon them. The migration is therefore overwhelmingly about asymmetric algorithms: KEMs (key encapsulation, the thing that used to be ECDHE) and signatures (the thing that used to be RSA-PSS or ECDSA).

The mainstream estimate as of mid-2026 puts a CRQC capable of breaking RSA-2048 somewhere between 2030 and 2040, with wide error bars on both sides. The current record for a fully error-corrected logical qubit count is far short of the millions needed for Shor against 2048-bit RSA, but the field has been ahead of public-facing expectations for the last two years and nobody competent will tell you a date with confidence. What matters operationally is the harvest-now-decrypt-later timeline:

Traffic captured today  ──────────────► Quantum computer exists
   2026                                       ~2030 - 2040

           ╔════════════════════╗
           ║  Data with a       ║
           ║  10+ year sensitivity   ─────► already at risk
           ║  window            ║
           ╚════════════════════╝

           ╔════════════════════╗
           ║  Signatures on     ║
           ║  artifacts that    ─────► already at risk
           ║  ship for years    ║
           ╚════════════════════╝

           ╔════════════════════╗
           ║  Ephemeral chatter ║
           ║  with <5y value    ─────► probably fine
           ╚════════════════════╝

The “probably fine” category is shrinking faster than people realised. The “already at risk” category is what NSA’s CNSA 2.0 timeline assumes when it tells national security systems they need to be migrated by 2030 for new deployments and 2035 across the board. Federal civilian agencies inherit a 2035 deadline from National Security Memorandum 10. Your enterprise compliance team inherits whichever of those leaks into your auditor’s checklist first.

What NIST actually shipped

Eight years of standardization compressed into the suite below. NIST published the first three Federal Information Processing Standards on August 13, 2024. By mid-2026 they are the bedrock everyone is building on, and a fourth is on the way.

A few things are not obvious from the table. First, the family resemblance: ML-KEM and ML-DSA both come from the CRYSTALS suite and both lean on Module-LWE, which means a single algorithmic break against the underlying problem would affect both. That is exactly why NIST is standardizing alternatives — SLH-DSA (hash-based, completely different assumption) and HQC (code-based, a different lattice-free hard problem). Diversity is the cryptographic equivalent of not running everything on the same hypervisor.

Second, “Kyber” and “Dilithium” are the algorithm names you will read in papers and the names baked into a thousand library identifiers (crypto_kem_kyber768_keypair, crypto_sign_dilithium3_sign). “ML-KEM” and “ML-DSA” are the FIPS-blessed names. They are mostly the same algorithm with some parameter and encoding choices nailed down. The hybrid TLS code point in your packet capture says MLKEM768, not Kyber768. Read both names as synonyms unless you are reading round-3 NIST submissions.

Third, FN-DSA (Falcon) is the one nobody knows what to do with operationally. The math is gorgeous — NTRU lattice signatures with the smallest signature size of any post-quantum scheme — but the floating-point Gaussian sampling in the keygen and signing routines is brutally hard to implement without side channels and constant-time bugs. It is going to show up where the 666-byte signature size (vs. 2420 bytes for ML-DSA at the equivalent security level) is worth the implementation pain: very small leaf certificates, IoT firmware signing, anything that fits inside a 1500-byte MTU.

The Module-LWE math, at a level you can defend in code review

You can use ML-KEM without understanding the lattice math. You should not deploy it as a migration owner without understanding it. The version here is intentionally just deep enough to explain why the parameter sets look the way they do and why this particular hard problem is what your traffic now depends on.

The fundamental object is the Learning With Errors (LWE) problem. Pick a secret vector s over a finite field Z_q. Pick a random matrix A. Compute b = A·s + e, where e is a small error vector drawn from a tight distribution. The hard problem is: given (A, b), recover s. The errors are what makes it hard — without them this is straight linear algebra. With them, you cannot Gaussian-eliminate your way out because every row is slightly wrong in an unknown way. The best known algorithms reduce LWE to lattice problems (closest-vector, shortest-vector) where the best classical and quantum attacks are exponential in the lattice dimension.

Ring-LWE specialises this: instead of A being a matrix of integers, it is structured as multiplication in a polynomial ring Z_q[X] / (X^n + 1). That gives huge efficiency gains (polynomial multiplication via NTT instead of matrix-vector products) but introduces algebraic structure that some researchers worry might give attackers more to work with.

Module-LWE is the middle ground that Kyber uses. Instead of working over a single big polynomial ring, you work over a small matrix of polynomial rings. The A is now a k × k matrix whose entries are polynomials in Z_q[X] / (X^256 + 1), with q = 3329. For ML-KEM-768, k = 3. For ML-KEM-1024, k = 4. The same code path supports all three parameter sets just by changing k, which is one of the reasons the library implementations are small and the formal verification work has been tractable.

In one diagram:

                    LWE                Ring-LWE              Module-LWE
                  -------             -----------            -----------
   secret s:     vector of            single polynomial      vector of polynomials
                 integers             in Z_q[X]/(X^n+1)      in (Z_q[X]/(X^256+1))^k
   matrix A:     n x n matrix         single polynomial      k x k matrix of polynomials
                 of integers

   structure:    none                 maximum                some (tuneable via k)
   speed:        slow                 fast                   fast
   confidence:   highest              lowest                 middle  <-- Kyber sits here

The k parameter is the dial: bigger k means bigger keys, bigger ciphertexts, more security margin, and harder-to-break instances. ML-KEM-512 (k=2) targets NIST security level 1 (roughly equivalent to AES-128 against the best quantum attack). ML-KEM-768 (k=3) targets level 3 (≈ AES-192). ML-KEM-1024 (k=4) targets level 5 (≈ AES-256). The current default everywhere — TLS, SSH, the IETF hybrid draft — is 768. That choice is not arbitrary: it sits at a point where the byte sizes are tolerable for a TCP handshake and the security margin is comfortable for the harvest-now-decrypt-later timeline.

ML-DSA (Dilithium) uses the same Module-LWE foundation with the same Z_q[X]/(X^256+1) ring but a different q = 8380417 and a Fiat-Shamir-with-aborts construction for signatures. The rejection sampling in the signing routine is why ML-DSA signing is variable-time in a way that is fine but the implementation has to be careful. ML-DSA-44 (NIST level 2), ML-DSA-65 (level 3), and ML-DSA-87 (level 5) are the published parameter sets.

The thing to take away: every TLS handshake you are now doing rests on the assumption that Module-LWE is hard. We have around 25 years of academic attack research on the underlying lattice problems with no catastrophic break, but the parameter sets in FIPS 203 have only been under wide implementation scrutiny since 2022. If something is going to go wrong, the most likely failure modes are side-channel leaks in implementations (timing on the modular reduction, on the NTT, on rejection sampling), not a break of the underlying problem.

The byte and millisecond cost: what migration actually weighs

Anyone telling you the migration is free has not measured. The numbers below are the ones you can defend in a capacity review.

A few honest notes. The CPU numbers are for a modern x86-64 with AVX2; Cortex-M0+ embedded numbers are 100-1000x worse on the cycles-per-op axis and that is where IoT post-quantum is genuinely painful. The size numbers are what dominate the handshake cost in practice. A classical TLS 1.3 handshake’s ClientHello is around 200-500 bytes; the hybrid one with X25519MLKEM768 is closer to 1500-1700 bytes because the key_share extension carries both an X25519 public key and an ML-KEM-768 encapsulation key. That pushes the ClientHello past the 1500-byte Ethernet MTU and triggers IP fragmentation on networks that don’t handle TCP segmentation properly, which is the single biggest source of “hybrid TLS doesn’t work for some of our customers” tickets in 2026.

Cloudflare’s published measurements from March 2025 found roughly 38% of HTTPS traffic on their network using a hybrid PQC handshake, with a measured added latency of 10-20 ms median over classical X25519. That number is dominated by the larger ClientHello on the network, not by CPU. The CPU cost of ML-KEM is genuinely small.

Where the migration shows up in your stack

This is the part the abstract reports tend to skip: what actually changes in the systems you run.

TLS 1.3 — already largely done if you let it

If your TLS terminator is a recent OpenSSL (3.5+), BoringSSL, Rustls, or Cloudflare’s gateway, and your clients are recent Chrome/Edge/Firefox/Safari, the hybrid handshake is already the negotiated default for many connections. The relevant code point is 0x11EC for X25519MLKEM768, registered by the IETF in early 2025. The IETF draft pinning the construction (draft-ietf-tls-hybrid-design) is in late stages of standardization. There is also SecP256r1MLKEM768 (0x11EB) for FIPS-mandated NIST curve environments.

For a quick check on a host, you can probe with OpenSSL 3.5:

1
2
3
4
5

# Confirm your OpenSSL has the PQ groups compiled in
openssl list -kem-algorithms | grep -i kem
# Hit a server and see what was negotiated; -msg dumps the handshake records
openssl s_client -connect cloudflare.com:443 \
  -groups X25519MLKEM768:X25519 -msg 2>&1 | grep -E 'group|key_share|MLKEM'

The server picks one group. If both sides offered X25519MLKEM768 and they don’t show a downgrade, you are in. On Nginx 1.27+ you do not need a separate configuration line — if the underlying OpenSSL supports the group it is enabled by default. The legacy story is the same as every other TLS migration: the server has to advertise the group, the client has to support it, and middleboxes that thought ClientHello was always a single packet have to be updated or replaced.

The certificate on the server is still classical for now. PQ certificates (ML-DSA roots and leaf certs) are a much harder rollout because every CA, every browser trust store, and every revocation infrastructure has to be updated. The current hybrid TLS deployment buys you confidentiality against harvest-now-decrypt-later — an attacker who captures today’s encrypted traffic cannot decrypt it in 2035 even if RSA falls, because the key exchange used a quantum-resistant component. Server authentication via classical RSA/ECDSA certs is still vulnerable to a real-time CRQC attack, but that is a “the attacker exists and is online during the handshake” attack, which is much further out than HNDL.

SSH — done by default

OpenSSH 9.0 (April 2022) introduced sntrup761x25519-sha512 as a non-default hybrid PQ KEX. OpenSSH 9.9 (September 2024) added mlkem768x25519-sha256. OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 the new default. By mid-2026 the bulk of Linux distribution-shipped OpenSSH installations are doing post-quantum hybrid key exchange without anyone touching a config file.

You can check what your local client and a remote server agree on:

1
2
3
4
5
6
7
8

# What does your client offer, in priority order?
ssh -Q kex | head -5

# What does the server propose? -vv shows the KEX algorithm list
ssh -vv user@host 2>&1 | grep -E 'kex: algorithm|kex_alg|host key'

# Pin to MLKEM to fail loudly if the server doesn't support it
ssh -oKexAlgorithms=mlkem768x25519-sha256 user@host

The thing to add to your SSH hardening checklist in 2026 is to fail closed on KEX. An attacker who can MITM your SSH handshake and force a downgrade to plain curve25519-sha256 removes the post-quantum protection. The KexAlgorithms directive in sshd_config and ssh_config can be set to PQ-only (mlkem768x25519-sha256,sntrup761x25519-sha512) on hosts where you control both ends, but be aware this will fail against older clients.

SSH host keys and user keys are still classical. The SSH equivalent of the TLS certificate problem applies: until OpenSSH supports ML-DSA host and user keys (work in progress, not yet shipped as of June 2026), the SSH server is identified by an Ed25519 or RSA key that a CRQC would be able to forge.

Code signing, JWTs, and the long-lived signature problem

Where TLS handshakes are ephemeral, signatures persist. A firmware image signed today with RSA-3072 will still be on the device — and still expected to verify — in 2035. A CA root certificate signed today is in trust stores for a decade. The Linux kernel’s module signing keys, your Sigstore Fulcio root, your container image signing key, your Vault PKI intermediate (see the deep dive on Vault PKI): all of those are signatures that an attacker with a future CRQC could forge to backdate a signed artifact.

This is the migration that is harder than TLS. The tooling story for ML-DSA in code signing is fragmented in mid-2026. cosign has experimental ML-DSA support behind a feature flag. The Linux kernel accepts ML-DSA-65 in CONFIG_MODULE_SIG_ALL since 6.10, but distribution defaults are still RSA. PKCS#11 modules on HSMs vary wildly — Thales, Entrust, and Utimaco shipped firmware updates with ML-DSA and SLH-DSA support during 2024–2025, AWS CloudHSM and Azure Managed HSM added ML-DSA in late 2025, GCP Cloud HSM in early 2026. If your signing root lives in an HSM, the question to ask the vendor is “what’s the ML-DSA key generation latency, signing throughput, and what does the key-attestation chain look like?” not “do you support it on the slide deck.”

For long-lived roots (CA roots, code signing roots, firmware update roots), SLH-DSA (FIPS 205) is the conservative choice. The signatures are huge (7-50 KB depending on parameter set) but the algorithm rests on nothing but the collision resistance of SHA-2/SHA-3, which is the assumption you trust most. The pattern that is emerging is: SLH-DSA at the root, ML-DSA for intermediates and leaves. SLH-DSA’s size is tolerable if you only verify it once on boot and then trust an intermediate.

The full migration matrix

A practical sanity check: testing what you have

If your job in this migration is to verify that production actually got the upgrade and to catch the parts that did not, the testing toolkit is more useful than another spec read. A few representative commands you can run from any modern Linux box:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Build openssl with PQ support if your distro's is too old
# (most distros have shipped 3.5+ by mid-2026; check first)
openssl version  # Want >= 3.5.0

# What groups does your local openssl support?
openssl list -kem-algorithms

# Test a hybrid handshake against a target. -groups forces the client preference.
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768 -msg 2>&1 | \
  awk '/key_share|MLKEM|group/'

# Same with curl, which uses libcurl + openssl/boringssl
curl -v --curves X25519MLKEM768 https://example.com 2>&1 | grep -i kem

# SSH negotiation trace
ssh -vv -oKexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | \
  grep -E 'kex:|kex_alg'

On the operator side, the Prometheus metric you want on your TLS terminator is the fraction of handshakes negotiating each KEM group. Nginx with ssl_log_format and a custom field, Envoy with listener.ssl.curves, and HAProxy with txn.ssl_fc_curve all let you log this in 2026 builds. The reason you want the metric: when a CDN customer reports “our app stopped working on some networks,” the answer is overwhelmingly “the hybrid ClientHello is being fragmented by a middlebox that strips IPv4 fragments.” The fix is server-side (advertise the classical group as a fallback) or network-side (raise the MTU, fix the middlebox), and the metric tells you which one is happening.

A quick custom log line for Nginx 1.27 to capture the negotiated group looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

log_format ssl_observability '$remote_addr $ssl_protocol '
                             '$ssl_curve $ssl_curves '
                             '$ssl_cipher $ssl_session_reused';

server {
    listen 443 ssl;
    ssl_protocols TLSv1.3;
    # Default group list in OpenSSL 3.5+ already includes X25519MLKEM768
    # but pin explicitly for clarity:
    ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
    access_log /var/log/nginx/ssl.log ssl_observability;
}

Run that for a week and you will know exactly what fraction of your traffic is post-quantum.

The honest list of things that suck

The migration is real, but the marketing is a few notches ahead of the reality. The list below is the set of papercuts and footguns I would brief an exec on before promising a date.

Handshake fragmentation breaks things you did not know existed. The 1700-byte ClientHello with X25519MLKEM768 exceeds the 1500-byte Ethernet MTU. TCP segmentation handles this for well-behaved networks. Middleboxes that strip IP fragments, satellite links with low MTU, and aging captive portals do not handle it. Cloudflare’s writeups have repeatedly named this as the dominant operational issue.

IoT is not ready. A LoRaWAN device with a 51-byte payload limit cannot run an ML-KEM handshake without 60+ packets, which destroys the duty-cycle budget. There is no good post-quantum story for low-power constrained links in 2026. The pragmatic answer is to keep classical crypto for sensors but ensure the gateway-to-backend leg is post-quantum.

Certificate chains balloon. A classical TLS chain is 3-5 KB. A pure ML-DSA chain is 10-15 KB. A chain with an SLH-DSA root is 20-50 KB. This blows past the size where you can fit the whole handshake in initcwnd, which adds an RTT. Mitigation is chain compression (draft IETF spec, partial deployment), intermediate caching, and ruthlessly avoiding chain bloat. Some CAs are issuing “trimmed” PQ chains that drop the root from the wire and rely on the trust store.

HSM keygen time matters. ML-KEM-768 keygen on a high-end HSM is fast (sub-millisecond). ML-DSA keygen is slower. SLH-DSA keygen is very slow because of the underlying Merkle tree structure — single-digit seconds is common. If your CA issues a lot of certificates with fresh roots, this changes your sizing.

Side-channel implementation bugs are the realistic threat. The Module-LWE problem itself has 25 years of academic scrutiny. The constant-time, side-channel-resistant implementation of ML-KEM has had 18 months of scrutiny. Several timing leaks in early implementations have already been published and patched. If you are not pulling from a maintained library (liboqs, OpenSSL 3.5+, BoringSSL, Bouncy Castle 1.78+), do not roll your own.

Tooling lags spec. Cosign, Sigstore, the kernel module signing flow, OpenSSH host keys, IKEv2 — every one of these is somewhere on the “experimental flag → tech preview → default” path in mid-2026. The spec is done. The ecosystem is mid-migration.

The hybrid is doing real work. The temptation in a year or two will be to drop the classical half of the hybrid because “Module-LWE is fine.” The hybrid exists precisely because Module-LWE has less attack history than X25519. The classical half is the seatbelt for the case where a lattice break appears. Drop the hybrid when classical crypto is the less trusted side of the equation, which is not now.

A concrete migration playbook

If you are the person who has to actually do this in 2026 at an organization with a real production footprint, the order of operations that actually works:

1. Inventory first, deploy second. Find every TLS terminator, every SSH bastion, every signing key, every JWT issuer, every HSM, every embedded device with a TLS stack. If you do not know what is on your network, you cannot migrate it. CISA’s pqc-tools and the open-source cryptocensus scanner are useful starting points; Steampipe-based cloud asset inventory (covered in the cloud security posture management post) is the cloud-side half of the same job.

2. Bucket by data sensitivity window. Encrypted traffic with a 10+ year sensitivity window is the urgent migration. Ephemeral session keys for short-lived web traffic are the patient migration. Signature roots that ship to devices for a decade are the most urgent migration because you cannot rotate them after deployment.

3. Migrate TLS first — it is the easy one. Browsers and Cloudflare-class fronts already do hybrid. Your job is to make sure your fronting layer is on a recent enough TLS terminator and that internal service-to-service TLS (Envoy, Linkerd, Istio) is upgraded. Internal mTLS, covered in the mTLS deep dive, is a place where you control both ends and can move to hybrid earlier than the public internet.

4. Migrate SSH by upgrading OpenSSH and pinning KEX. This is the lowest-risk, highest-leverage win.

5. Plan code signing. This is the hard one because of long-lived artifacts. Pick SLH-DSA for new long-lived roots even though the signatures are big. Plan dual-signing (classical + PQ) for transition artifacts so old verifiers don’t break.

6. Run hybrid for at least 5 years. Do not drop the classical half of the hybrid until the post-quantum half has earned more trust than it has today. The cost of running hybrid is low; the cost of a Module-LWE break with no fallback is catastrophic.

7. Measure. The Prometheus metric on negotiated group is the only honest signal that you actually shipped the migration. Audit slides and policy memos are not.

Verdict

If you do nothing, your TLS handshakes are quietly becoming post-quantum anyway as browsers and CDNs do the work for you. That is enough to defeat harvest-now-decrypt-later for most of your public traffic, and it is the single biggest threat the field has been organising against. If you are running internal infrastructure with long-lived secrets, internal mTLS, code signing, or firmware that ships for years, you have actual work to do this year, and waiting until 2030 is the wrong call. Migrate SSH today (upgrade OpenSSH, pin KEX), make sure your TLS terminators are 3.5+ OpenSSL or modern BoringSSL, inventory your signing keys, and start the long planning cycle on code signing and CA roots with SLH-DSA at the top and ML-DSA at the leaves. Run hybrid for at least the next five years — the classical half is the cheapest insurance policy you will ever buy against a lattice break. Do not roll your own; do not skip the testing; and put a metric on your dashboard so you know whether the migration actually shipped.

Sources

• NIST Releases First 3 Finalized Post-Quantum Encryption Standards (NIST, Aug 2024)
• CRYSTALS-Kyber: A CCA-Secure Module-Lattice-Based KEM (Bos et al., 2018)
• CRYSTALS-Kyber Round 3 Specification (pq-crystals.org)
• OpenSSH: Post-Quantum Cryptography
• OpenSSH 10.0 Introduces Default Post-Quantum Key Exchange (Quantum Computing Report)
• Advancing post-quantum capabilities of SSH in Red Hat Enterprise Linux
• PQ/T Hybrid Key Exchange with ML-KEM in SSH (IETF draft-ietf-sshm-mlkem-hybrid-kex)
• From X25519 to X25519+MLKEM768: How Hybrid TLS Is Becoming Real (PostQuantumSecurity.org)
• Harvest Now, Decrypt Later (Wikipedia)
• Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST (DigiCert)
• Evaluating Post-Quantum Cryptography in IoT Networks (MDPI Future Internet)
• Infrastructure Challenges of Dropping In Post-Quantum Cryptography (postquantum.com)
• Post-Quantum Kyber Benchmarks (wolfSSL)
• Performance and Storage Analysis of CRYSTALS Kyber as a Post Quantum Replacement for RSA and ECC (arXiv)
• NIST’s PQC standards are here — What you need to know (Utimaco)