FIPS 203, 204, 205: the standards every security team needs to understand

In August 2024, NIST published three documents that effectively set the global baseline for post-quantum cryptography. FIPS 203, FIPS 204, and FIPS 205. If you work in security, these are the standards your organisation will be migrating to, and understanding what they actually define, and why, is the starting point for any serious migration plan.

The process that produced these standards took eight years. In 2016, NIST invited the global cryptographic community to submit candidate post-quantum algorithms. 69 submissions arrived. They were then subjected to four rounds of analysis, attack attempts, and public scrutiny by researchers around the world. Three algorithms emerged as primary standards. A fourth, FALCON (now FIPS 206), followed shortly after.

The reason the process was so deliberate is that cryptographic standards last for decades. RSA has been in use since 1977. Getting this wrong has long-term consequences that are very hard to undo.

FIPS 203: replacing key exchange

FIPS 203 defines ML-KEM, the Module Lattice-Based Key Encapsulation Mechanism. It is based on a candidate called CRYSTALS-Kyber and is the algorithm that replaces Diffie-Hellman and ECDH wherever those are used. In practice, that means TLS, SSH, IPsec, and any other protocol that needs to establish a shared secret between two parties.

ML-KEM comes in three parameter sets. ML-KEM-512 offers NIST Level 1 security, roughly equivalent to AES-128. ML-KEM-768 offers Level 3, equivalent to AES-192, and is the recommended choice for most enterprise deployments. ML-KEM-1024 offers Level 5, equivalent to AES-256, for the highest-sensitivity applications.

The practical trade-off compared to classical key exchange is size. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1184 bytes and the ciphertext is 1088 bytes. That is a meaningful size increase, but well within what modern protocols can handle. TLS has already been updated to accommodate it.

FIPS 204: replacing digital signatures

FIPS 204 defines ML-DSA, the Module Lattice-Based Digital Signature Algorithm. Based on CRYSTALS-Dilithium, it replaces RSA and ECDSA wherever those are used for signing. That includes certificate authorities, code signing, authentication tokens, and anything else that relies on a digital signature to prove authenticity.

The size increase here is more significant. An ECDSA P-256 signature is about 64 bytes. An ML-DSA-65 signature, the Level 3 parameter set, is 3309 bytes. For most applications this is manageable, but for bandwidth-constrained environments like embedded systems or IoT devices, it matters. That is part of the reason FIPS 206, which defines FALCON with much smaller signatures, was standardised alongside it.

FIPS 205: the conservative option

FIPS 205 defines SLH-DSA, based on SPHINCS+. It is the backup signature algorithm, the one you use when you want maximum conservatism. Unlike ML-DSA, whose security rests on lattice problems, SLH-DSA’s security depends only on hash functions. Hash functions are among the oldest and best-understood primitives in cryptography. There is no exotic mathematics involved.

The trade-off is performance and size. SLH-DSA signatures are large, anywhere from 7856 bytes to over 35000 bytes depending on the parameter set. Signing is also significantly slower than ML-DSA. For root certificate authorities, long-lived document signatures, and other contexts where you sign infrequently and want maximum confidence in the algorithm’s long-term security, SLH-DSA is the right choice. For everything else, ML-DSA is more practical.

What to deploy first

The most urgent deployment is ML-KEM in TLS. Key exchange is where harvest now, decrypt later attacks are most directly relevant. Adversaries are collecting TLS traffic today. Replacing ECDH with hybrid X25519 + ML-KEM-768 stops new traffic from being vulnerable, even if a quantum computer eventually arrives.

Signature migration is important but slightly less time-sensitive for most organisations. Certificate lifetimes are typically one to two years, which gives more time to plan the PKI transition. Root CAs are different. A root CA certificate issued today might still be in use in 2040. Those are exactly the cases where SLH-DSA should be the signature algorithm of choice.

The practical sequence for most organisations is hybrid TLS first, then SSH and VPN, then PKI and code signing, and finally hardware and embedded systems, which have the longest replacement cycles and need the most planning.