The NIST Post-Quantum Standards: What They Are and What They Require of You

In August 2024, after an eight-year evaluation, NIST published its first three finalised post-quantum cryptographic standards. That event ended a long period in which the sensible answer to “which algorithm should we use?” was “wait.” The waiting is over, and a migration timeline now exists with dates attached.

This is a practical guide to what was standardised, what each standard is for, and what the deadlines actually oblige you to do.

The three standards

FIPS 203 — ML-KEM

ML-KEM, derived from the algorithm previously known as CRYSTALS-Kyber, is a key encapsulation mechanism. It is the replacement for the key exchange in TLS and anywhere else two parties need to agree on a shared secret. Its security rests on the Module Learning With Errors problem.

This is the one that matters most urgently, because key exchange is what harvesting attacks target. Public keys run roughly 800 to 1,568 bytes and ciphertexts 768 to 1,568 bytes depending on parameter set — larger than elliptic curve equivalents, but small enough that most protocols absorb the difference without redesign.

FIPS 204 — ML-DSA

ML-DSA, from CRYSTALS-Dilithium, is the primary standard for digital signatures. It handles authentication, code signing, certificates, and anywhere you need to prove something came from a particular party and was not altered.

Signatures range from about 2,420 to 4,595 bytes. For comparison, an ECDSA P-256 signature is 64 bytes. That is a meaningful jump, and it is where most of the engineering pain in this migration lives.

FIPS 205 — SLH-DSA

SLH-DSA, from SPHINCS+, is also a signature scheme, but it is built on a deliberately different mathematical foundation: nothing but the security of hash functions. It exists as insurance. If a structural weakness is ever found in lattice-based cryptography, ML-DSA and ML-KEM would both be in trouble at once, and SLH-DSA would not.

The cost of that insurance is size. SLH-DSA signatures run from roughly 7,856 to 49,856 bytes. Nobody deploys this by default. You deploy it where the consequence of a break is catastrophic and the signature is infrequent — firmware signing and root certificates being the obvious cases.

The timeline that has teeth

Standards alone do not force anyone to move. Deadlines do. NIST’s draft IR 8547, published for public comment in late 2024, sets out the transition schedule for United States federal systems, and it is far more consequential than most organisations have registered.

• After 2030: RSA, ECDH, ECDSA, DSA and finite-field Diffie-Hellman at roughly 112-bit security become deprecated. Continued use requires the data owner to document a risk justification.
• After 2035: those same algorithms become disallowed, including at higher strengths and including legacy deployments. At that point accepting the risk is no longer an available option.

The distinction between deprecated and disallowed is where organisations get caught. Deprecated sounds soft, and it is — for four or five years. Then it is not. If your hardware refresh cycle is seven years, the equipment you buy in 2028 needs to still be compliant in 2035, which means the purchasing decision is already constrained.

These are federal requirements, but they will not stay confined to federal systems. Standards of this kind propagate through procurement, through compliance frameworks, and through vendors who would rather ship one product than two.

What is still missing

A fourth signature standard, based on the FALCON algorithm and expected as FIPS 206, has been announced but not finalised. It matters because its signatures are considerably more compact than ML-DSA’s, which makes it attractive for constrained environments and for certificate chains where every byte is multiplied.

NIST has also continued evaluating additional signature schemes to broaden the mathematical diversity of the portfolio. The practical implication is that the algorithm set is not frozen, which is an argument for building systems that can change algorithms rather than betting on one.

What the size increases actually break

The abstract statement “post-quantum signatures are larger” becomes concrete in a few specific places, and these are worth checking early:

• Certificate chains. A TLS handshake may carry several signatures and several public keys. Replacing 64-byte signatures with 3,000-byte ones multiplies through the chain and can push handshakes past the initial congestion window, adding a full round trip.
• Embedded and IoT devices. Constrained memory and small MTUs make multi-kilobyte signatures genuinely difficult, not merely inconvenient.
• Blockchain and distributed ledgers. Every transaction carries a signature and every node stores it forever. The storage and bandwidth implications are structural rather than incidental.
• Protocols with fixed-size fields. Anything that assumed a signature would fit in a particular number of bytes needs revisiting, and this category is always larger than expected.

What to do in the next twelve months

Three things, in order.

Inventory your cryptography. Find every place RSA and ECC appear across applications, appliances, firmware, and third-party dependencies. This is tedious and it is the prerequisite for everything else. Organisations consistently underestimate how long it takes and consistently find things they did not know existed.

Turn on hybrid key exchange where it is already available. Combining ML-KEM with an existing elliptic curve exchange gives you post-quantum protection without betting entirely on a young algorithm, and it defeats harvesting attacks immediately. For a lot of web traffic this is a configuration change at the CDN or load balancer rather than an engineering project.

Put post-quantum readiness into procurement. Ask vendors, in writing, for their migration roadmap and their support for FIPS 203, 204 and 205. Anything you buy today with a multi-year life needs to survive 2035, and the cheapest time to establish that is before the purchase order.

Signatures can generally wait longer than key exchange, because forging a signature requires a quantum computer that exists now rather than one that might exist later. Key exchange cannot wait, because that attack is already running.