Post-Quantum Cryptography in 2026: What ML-KEM and ML-DSA Mean for You

No one has built a quantum computer that can break real cryptography — today's machines are orders of magnitude too small and too noisy. Yet the migration to post-quantum cryptography (PQC) is already well underway in browsers, SSH and messaging apps. This guide explains why, what has been standardized, and what it means if you build or run software.

What quantum computers break — and what they don't

Two quantum algorithms matter for cryptography:

• Shor's algorithm (1994) efficiently factors integers and computes discrete logarithms. Those are exactly the hard problems behind RSA, finite-field Diffie-Hellman and elliptic-curve cryptography. A sufficiently large, error-corrected quantum computer would break them outright, regardless of key size.
• Grover's algorithm (1996) speeds up brute-force search quadratically, which in theory halves the effective security of symmetric keys and hashes. In practice Grover parallelizes poorly and needs an enormously long computation, so the impact is far smaller than "halving" suggests.

So the AES-256 and SHA-256 you use today are fine. The public-key layer — every key exchange and digital signature on the internet — is what needs replacing.

Harvest now, decrypt later

If a quantum computer is years away, why migrate now? Because an adversary can record encrypted traffic today and store it. The session keys in that traffic were agreed using X25519 or RSA; once a quantum computer exists, those exchanges can be broken retroactively and every recorded session decrypted.

This gives a simple test, often called Mosca's inequality: if the number of years your data must stay secret, plus the years your migration will take, exceeds the years until a cryptographically relevant quantum computer exists, you're already late. Medical records, government communications and trade secrets have shelf lives of decades.

Signatures are different. A forged signature only matters if it can be used while the signature is being checked — a quantum computer in 2035 can't retroactively impersonate a server in a 2026 TLS handshake. That's why the industry upgraded key exchange first and is moving more slowly on signatures and certificates.

The NIST standards

After an eight-year public competition, NIST published three post-quantum standards on 13 August 2024:

A fourth, FN-DSA (based on Falcon), is being standardized for applications that need smaller signatures. In March 2025 NIST also selected HQC, a code-based KEM, as a backup to ML-KEM built on different mathematics — insurance in case lattice cryptography suffers an unexpected breakthrough.

The cost: bigger keys and signatures

Post-quantum algorithms are fast — ML-KEM is competitive with X25519 in speed — but their keys and outputs are much larger:

ML-KEM-768 and ML-DSA-65 are NIST security category 3 (comparable to AES-192) — the parameter sets most deployments, including Chrome and OpenSSH, have chosen. SLH-DSA-128s is category 1, with a tiny public key but large, slow-to-generate signatures.

An extra kilobyte per handshake is easily absorbed for key exchange. For certificates the cost multiplies — a TLS chain carries several public keys and signatures — which is one reason PQ certificates are rolling out more slowly, and why proposals like Merkle Tree Certificates are being explored.

Why everyone deploys hybrids

Production systems combine a post-quantum algorithm with a classical one, so a connection stays secure unless both are broken. This caution is justified: SIKE, a post-quantum candidate that reached the fourth round of NIST's process, was broken in 2022 by a classical attack that ran in about an hour on a single laptop core. ML-KEM has withstood far more scrutiny, but a hybrid costs little and removes the risk of betting everything on new mathematics.

Hybrid post-quantum cryptography is already protecting a large share of internet traffic:

• Web browsing — Chrome enabled hybrid post-quantum TLS key exchange by default in 2024, moving from an early Kyber draft to the standardized X25519MLKEM768 later that year. Other browsers and major CDNs such as Cloudflare support it too, so a large fraction of HTTPS connections are already quantum-resistant for key exchange.
• SSH — OpenSSH added a hybrid post-quantum key exchange as the default in version 9.0 (2022) and switched the default to mlkem768x25519-sha256 in version 10.0 (2025). See our SSH key guide.
• Messaging — Signal added post-quantum key agreement (PQXDH) in 2023; Apple's iMessage introduced its PQ3 protocol in 2024.
• Libraries — OpenSSL 3.5 (2025) ships ML-KEM, ML-DSA and SLH-DSA, and Go's standard library offers ML-KEM and uses hybrid key exchange in crypto/tls by default.

The timeline

NIST's draft transition guidance (IR 8547, 2024) proposes deprecating quantum-vulnerable algorithms at the 112-bit security level — including RSA-2048 — after 2030, and disallowing all quantum-vulnerable public-key algorithms after 2035. The NSA's CNSA 2.0 suite sets similar deadlines for U.S. national security systems. Whether or not a quantum computer arrives by then, compliance requirements will force the change.

What should you do now?

1. Inventory your cryptography. Know where you use RSA, ECDH, ECDSA and Ed25519 — TLS termination, SSH, VPNs, code signing, JWT signing, stored encrypted data, hardware tokens.
2. Turn on hybrid key exchange where it's available. Update TLS libraries, load balancers and OpenSSH. This addresses harvest-now-decrypt-later with no protocol redesign.
3. Prioritise long-lived secrets. Data that must stay confidential for 10+ years deserves attention first.
4. Keep symmetric crypto strong. Prefer AES-256 or ChaCha20 and SHA-256 or better — these survive the transition unchanged.
5. Build crypto agility. Avoid hard-coding algorithms and key sizes; make them configurable so the next migration is a config change, not a rewrite.
6. Don't roll your own PQC. Use the standardized algorithms from maintained libraries, in hybrid mode, and wait for protocol standards (TLS, X.509, JOSE) rather than inventing formats.

Try it yourself

With OpenSSL 3.5 or later you can generate post-quantum keys and run an ML-KEM encapsulation locally. We used exactly these commands to measure the sizes in the table above:

openssl genpkey -algorithm ML-KEM-768 -out kem.pem
openssl pkey -in kem.pem -pubout -out kem.pub
openssl pkeyutl -encap -inkey kem.pub -pubin -out ct.bin -secret ss.bin
wc -c ct.bin ss.bin          # 1088-byte ciphertext, 32-byte shared secret

openssl genpkey -algorithm ML-DSA-65 -out dsa.pem
printf 'hello' > msg.txt
openssl pkeyutl -sign -inkey dsa.pem -in msg.txt -out sig.bin
wc -c sig.bin                # 3309-byte signature