Understanding NIST FIPS 203, 204 and 205

In August 2024, after an eight-year public competition involving cryptographers worldwide, NIST finalized the first three post-quantum cryptography standards. If your organization runs on RSA or elliptic-curve cryptography today — and it does — these three documents describe what you will be running instead.

FIPS 203 — ML-KEM, for key establishment

ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism, formerly CRYSTALS-Kyber) solves the problem RSA key exchange and ECDH solve today: two parties agreeing on a shared secret over an untrusted network. It is the workhorse standard — every TLS handshake in a post-quantum world involves an ML-KEM operation.

The practical trade-off is size. An RSA-2048 public key is 256 bytes; ML-KEM-768, the commonly recommended parameter set, uses a 1,184-byte public key. That roughly 4.6× growth flows through handshake sizes, certificate chains, and constrained-device budgets — measurable, manageable, but not free.

FIPS 204 — ML-DSA, for digital signatures

ML-DSA (Module-Lattice-based Digital Signature Algorithm, formerly CRYSTALS-Dilithium) is the general-purpose successor to ECDSA and RSA signatures: code signing, JWTs, certificates, document signing. It is fast and well-balanced, and it is the default signature recommendation for most enterprise use cases.

Again, size is the migration cost to plan for: an ECDSA-P256 signature is 64 bytes; ML-DSA-65 signatures are 3,309 bytes. Protocols and storage formats that assumed small signatures deserve early attention in any migration sequence.

FIPS 205 — SLH-DSA, the conservative option

SLH-DSA (Stateless Hash-based Digital Signature Algorithm, formerly SPHINCS+) takes a different mathematical route: its security rests only on hash functions, the most conservative and best-understood assumption in cryptography. The price is bulk — SLH-DSA-128s signatures run 7,856 bytes with slower signing.

It shines where trust must outlive everything else: root certificate authorities, firmware signing keys, long-lived legal archives. Think of it as the anchor of the fleet — heavy, slow, and the last thing you want to fail.

And FALCON

FALCON, a compact lattice-based signature scheme selected by NIST alongside the others (its standard, expected as FIPS 206 under the name FN-DSA, is still being finalized), fills the gap ML-DSA leaves: signatures of just 666 bytes for FALCON-512. Where bandwidth or storage is tight — embedded devices, high-volume protocols — FALCON is frequently the right mapping.

The real problem is choosing per asset

The standards are not interchangeable. The correct target depends on each asset's cryptographic role — key establishment versus signature — and its operational constraints: latency budgets, size budgets, trust lifetime. Multiply that decision by every key, certificate, and library call in an enterprise estate, and “which algorithm?” becomes a mapping problem measured in the tens of thousands.

That is precisely the job of AutoPQC's Migration Mapping Engine: classify every discovered asset by role, then map it deterministically to the correct NIST-standardized replacement, with the reasoning attached.