Post-quantum cryptography explained: FIPS 203, 204 and 205

Post-quantum cryptography (PQC) is a set of new public-key algorithms that stay secure even against a large quantum computer, and any organization that uses TLS, VPNs, code signing or digital certificates will have to adopt it. The short version: NIST finalized three standards on August 13, 2024 (FIPS 203 for agreeing on keys, FIPS 204 and FIPS 205 for signatures), your browser very likely uses the first one today, and the algorithms they replace are scheduled to be phased out between 2030 and 2035.

What is post-quantum cryptography?

Post-quantum cryptography is regular software cryptography based on math problems that no known algorithm, classical or quantum, solves efficiently. It runs on the computers and phones you already own. Nothing about it requires quantum hardware.

The name trips people up. “Post-quantum” describes the threat it is meant to survive, not the technology inside it. It is also different from quantum key distribution (QKD), which uses single photons and dedicated optical links to share keys. QKD has niche uses in telecom and government networks. Post-quantum cryptography is what almost everyone else will deploy, because it drops into the same protocols (TLS, SSH, IPsec, X.509 certificates) that you run now.

It replaces public-key cryptography in its two jobs. The first is key establishment: two machines that have never met agree on a secret key over an open network. The second is digital signatures: proving that a message, a software update or a certificate came from who it claims.

Why do quantum computers break RSA but not AES?

A large, error-corrected quantum computer running Shor’s algorithm could factor large numbers and compute discrete logarithms efficiently, and those are exactly the problems that RSA, Diffie-Hellman and elliptic-curve cryptography depend on. Symmetric ciphers such as AES and hash functions such as SHA-256 face a much smaller quantum speedup.

NIST’s draft transition report, IR 8547 (November 2024), says that all NIST-approved symmetric primitives with at least 128 bits of classical security are believed to meet at least the lowest of its five post-quantum security categories. AES-256 sits in the top category. So the problem is concentrated in public-key cryptography, the part that sets up keys and proves identity. The bulk encryption of your data with AES can stay.

This distinction matters for budgeting. You do not need to re-encrypt every database. You need to change how keys are exchanged and how things are signed, which touches fewer lines of code but more systems and vendors.

What do FIPS 203, 204 and 205 standardize?

FIPS 203 standardizes ML-KEM for key establishment. FIPS 204 standardizes ML-DSA and FIPS 205 standardizes SLH-DSA, both for signatures. NIST derived them from three algorithms that won its public competition: CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+.

Sizes come from the size tables in each FIPS document. For comparison, an X25519 public key is 32 bytes and an Ed25519 signature is 64 bytes. Post-quantum keys and signatures are tens to hundreds of times larger, and that size jump causes more integration trouble than the math does.

ML-KEM, the one you will use most

A key encapsulation mechanism (KEM) works like this: the server publishes a public key, the client uses it to wrap a fresh random secret, and only the server can unwrap it. Both sides end up with the same 32-byte shared secret, which then keys AES for the rest of the session. ML-KEM comes in three sizes (512, 768 and 1024). ML-KEM-768 is the one browsers and SSH picked.

ML-DSA and SLH-DSA, two kinds of signature

ML-DSA is the general-purpose signature: reasonably fast, with signatures around 2.4 to 4.6 KB depending on the parameter set. SLH-DSA is slower and its signatures are larger, but its security rests only on hash functions, which cryptographers have studied for decades. That makes it a conservative choice for things you sign rarely and verify for years, such as firmware images or a root certificate.

What about Falcon and HQC?

Two more algorithms are on the way, and neither is a reason to wait. FN-DSA, based on Falcon, is a signature scheme with smaller signatures than ML-DSA. NIST’s standardization page lists it as FIPS 206, still in development. HQC, a key-establishment algorithm based on error-correcting codes, was selected on March 11, 2025.

HQC exists as insurance. ML-KEM and ML-DSA both rest on lattice problems. If someone found a weakness in lattices, NIST wants a backup built on different math. When it announced HQC, NIST said it expected a draft standard in about a year and a final standard in 2027. Dustin Moody, who leads NIST’s post-quantum project, was direct about priorities at the time: “Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.”

What is a hybrid key exchange, and are you already using one?

A hybrid key exchange runs a classical algorithm (usually X25519) and ML-KEM side by side and mixes both results into the session key, so the connection stays secure as long as either one holds. You are very likely using one right now.

The main clients already ship it:

• Chrome 131, released in November 2024, switched its default from the pre-standard Kyber to the hybrid ML-KEM768 plus X25519.
• OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 its default key exchange, and OpenSSH 10.1 warns users when a connection falls back to a non-post-quantum scheme.
• Apple’s iOS 26, iPadOS 26, macOS Tahoe 26 and visionOS 26 advertise the hybrid X25519MLKEM768 group in TLS 1.3 connections by default.
• Cloudflare reported on October 28, 2025 that the majority of human-initiated traffic to its network was using post-quantum encryption.

This is real progress, with a catch. It usually covers the hop between a user’s device and the edge of a CDN or cloud provider. Behind that edge sit load balancers, internal APIs, service meshes, VPN concentrators, database links, hardware security modules and connections to partners and banks. Those are yours to upgrade, and most of them still negotiate classical key exchange.

Signatures are further behind. The certificates that websites present are still RSA or ECDSA almost everywhere, because post-quantum certificates are large and the public certificate ecosystem has not settled how to use them. That delay is tolerable for now: a forged signature needs a quantum computer at the moment of the attack, while recorded key exchanges can be broken years later (the threat known as harvest now, decrypt later).

When will RSA and elliptic curves be retired?

NIST’s draft IR 8547 proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing RSA, ECDSA, ECDH and the rest after 2035. The document is still an initial public draft, but governments are already treating its dates as real.

In the United States, Executive Order 14412 (signed June 22, 2026) and OMB memorandum M-26-15 turned those years into obligations for federal systems. The EU and the UK have their own schedules, with milestones between 2028 and 2035. If you sell to governments, banks or multinationals, their deadlines reach you through contracts and vendor questionnaires. We cover the full set in our piece on post-quantum migration deadlines.

Do you need to rewrite your software?

Mostly no. In most systems you upgrade libraries, protocol configurations and vendor products rather than business logic. The pain shows up in specific places:

• Code that hard-codes an algorithm or a key type instead of reading it from configuration.
• Database columns, message formats and protocol fields sized for a 256-byte RSA signature that now have to hold 3,309 bytes.
• Smart cards, payment terminals, meters and other embedded devices with little memory and no update path.
• Hardware security modules whose firmware does not yet support ML-KEM or ML-DSA.
• Partner integrations where the other side has to change at the same time.

The engineering goal is crypto-agility: being able to swap an algorithm by changing configuration and redeploying, not by rewriting code. Teams that build that capability once will handle HQC, FN-DSA and whatever comes after without another multi-year project. The glossary defines crypto-agility and the other terms used here.

Which algorithm should you pick?

For most organizations the defaults are already decided by the protocols: hybrid ML-KEM-768 with X25519 for key exchange in TLS and SSH, and ML-DSA for new signature use cases once your certificate authority and hardware support it. SLH-DSA fits long-lived roots of trust and firmware signing, where signature size matters less than confidence in the math.

Picking algorithms is the easy part. The hard part is knowing where public-key cryptography lives in your estate, which systems protect data that must stay secret for a decade, and which vendors are blocking you. That is why the US, UK and EU transition plans all start with a cryptographic inventory, and why sectors with long-lived data and long equipment lifecycles, such as banking and finance and telecommunications, tend to feel the pressure first.

If you want to know how exposed your systems are before committing to a full program, a quantum readiness assessment gives you that picture in a few weeks. When you are ready to plan and run the change itself, our post-quantum cryptography migration service starts from the inventory and works through your systems in order of risk.