Post-quantum cryptography · NIST standards · Migration

NIST’s First PQC Standards:
A Practitioner’s Guide

In August 2024, the US National Institute of Standards and Technology (NIST) finalised its first three post-quantum cryptography standards. For practitioners, the important step is not simply learning three new acronyms. It is understanding which security function each standard performs—and where it may fit into a controlled migration.

Three Standards, Two Different Jobs

The standards do not form a single interchangeable package. One establishes shared secrets; two create digital signatures.

ML-KEM: Establishing a Shared Secret

ML-KEM, defined in FIPS 203, is a key-encapsulation mechanism. It allows two parties to establish a shared secret over a public channel. That secret can then be used with symmetric cryptography for encryption and authentication.

ML-KEM is derived from CRYSTALS-Kyber and has three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. It should not be described as a universal drop-in replacement for every use of RSA or elliptic-curve cryptography. The surrounding protocol, product, key-management model and compliance requirements determine how it can be used.

ML-DSA: General-Purpose Digital Signatures

ML-DSA, defined in FIPS 204, generates and verifies digital signatures. It is derived from CRYSTALS-Dilithium and supports authenticity and integrity use cases rather than key establishment.

Its three parameter sets produce signatures of 2,420, 3,309 or 4,627 bytes. Those sizes are larger than many widely deployed classical signatures, so certificate chains, network messages, storage, hardware interfaces and constrained devices all need realistic testing.

SLH-DSA: A Hash-Based Signature Alternative

SLH-DSA, defined in FIPS 205, is a stateless hash-based digital-signature scheme. It is based on SPHINCS+ and provides an alternative whose security rests on a different family of mathematical assumptions from ML-DSA.

That diversity comes with a substantial size and performance trade-off. Depending on the parameter set, an SLH-DSA signature is 7,856 to 49,856 bytes. This does not confine it to one fixed use case, but it makes careful evaluation particularly important for high-volume protocols and constrained environments.

“ML-KEM establishes keying material. ML-DSA and SLH-DSA prove who signed data and whether it changed. A migration plan must keep those jobs separate.”

Final Standards Do Not Mean an Immediate Big-Bang Replacement

Final standards give organisations a stable basis for planning, procurement, implementation and testing. They do not mean that every production system should be converted at once.

Readiness still depends on protocol support, interoperable implementations, validated cryptographic modules, certificate and key formats, hardware support, operational tooling and supplier roadmaps. NIST also lists potential updates or errata for FIPS 203 and FIPS 204, so teams should track the current publication pages rather than treat a downloaded copy as permanently frozen.

Hybrid Is a Transition Pattern, Not a Universal Answer

In August 2026, RFC 10024 standardised hybrid key-agreement groups for TLS 1.3 that combine ML-KEM with traditional elliptic-curve Diffie–Hellman mechanisms. The design aims to preserve security as long as at least one component remains secure.

This is useful evidence that standards are moving into deployable protocols. It is not a reason to assume that every application should use the same hybrid construction, or that hybrid key agreement solves signature migration. Each protocol needs its own interoperable design, testing and fallback decisions.

Migration Order Should Follow Risk and Dependency

It is tempting to summarise the transition as “key exchange first, signatures later”. That may describe some parts of the current ecosystem, but it is not a safe universal rule.

• TLS services may encounter hybrid ML-KEM support before post-quantum certificate chains become routine.
• Firmware, code-signing and device-root decisions may need earlier signature planning because deployed assets can remain in service for many years.
• Long-lived confidential data may make key-establishment migration urgent because encrypted material can be collected now and attacked later.
• Legacy hardware, embedded systems and managed services may determine the practical sequence regardless of the preferred architecture.

The right order depends on data lifetime, system lifespan, threat exposure, upgrade difficulty and supplier dependency—not on one industry-wide slogan.

The Operational Challenge Is Discovery

The hard part is rarely finding the names of the algorithms. It is finding where cryptography actually lives: TLS endpoints, virtual private networks, Secure Shell, code signing, secure email, device certificates, application programming interfaces, mobile applications, embedded systems, hardware security modules, key-management platforms and supplier-managed services.

Symmetric algorithms and hash functions should also appear in a complete cryptographic inventory, but they should not automatically be placed in the same migration category as quantum-vulnerable public-key mechanisms. The inventory needs to record purpose as well as algorithm.

One Concrete Step This Week

Take one manageable group of applications and add two fields to its cryptographic inventory:

• Algorithm or mechanism—for example RSA, ECDH, ECDSA, ML-KEM, ML-DSA or SLH-DSA.
• Cryptographic function—for example key establishment, digital signature, encryption, hashing or key derivation.

Then record the implementation and version, protocol, owner, data-retention period, supplier dependency, upgrade path and test status. You cannot prioritise a migration if you cannot distinguish what each mechanism is doing.

Questions Worth Taking Back to the Team

• Which systems protect information that must remain confidential for the longest time?
• Which signing keys protect software or devices with the longest operational life?
• Which protocols and products already support final—not draft—PQC standards?
• Which systems cannot be changed without a supplier, hardware refresh or lengthy recertification?

“Where should your organisation begin: external TLS, internal PKI, code signing, remote access or supplier-managed services?”

Sources

• NIST Post-Quantum Cryptography project and migration overview
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• IETF RFC 10024: Hybrid ML-KEM key agreement for TLS 1.3
• OpenSSL 3.5 documentation: ML-KEM and hybrid TLS groups