NIST standards give post-quantum migration a practical starting point

NIST's first three final standards gave companies specifications they could implement. Key establishment, digital signatures and integration with existing systems still posed different migration problems.

Cybersecurity4 min read

Yubico YubiKey authentication token, 2019.Tony Webster · CC BY 2.0

On 13 August 2024, the US National Institute of Standards and Technology released the first three finalized standards from its post-quantum cryptography project. The agency described the results of eight years of work as ready for immediate use and urged organizations to begin integrating them. The specifications supported a transition whose difficulty extended well beyond choosing an algorithm.

The underlying concern was the ability of a sufficiently capable quantum computer to break widely used public-key cryptography. NIST did not announce that such a machine had arrived or establish a universal deadline for private businesses. It did give security teams a firmer basis for testing replacements. For startups selling cryptographic infrastructure, the commercial task became helping customers change working systems without losing compatibility, performance or control.

Three standards addressed two different jobs

FIPS 203 specifies the Module-Lattice-Based Key-Encapsulation Mechanism, or ML-KEM, derived from CRYSTALS-Kyber. A key encapsulation mechanism lets parties establish a shared secret over a public channel. That secret can then support symmetric encryption and authentication. Describing ML-KEM simply as a replacement that encrypts all application data would miss its place within a larger protocol.

Key establishment and signatures solve different problems

Scroll to view all columns

Comparison	Key establishment	Digital signatures
NIST standards	FIPS 203: ML-KEM	FIPS 204: ML-DSA; FIPS 205: SLH-DSA
Primary function	Establish a shared secret over a public channel.	Authenticate a signatory and detect unauthorized changes to signed information.
Integration question	How does a protocol establish keys before protecting a session?	How does a system sign information and verify that signature?

Functions defined in FIPS 203–205. The integration questions illustrate where each function fits within a system.

FIPS 204 specifies ML-DSA, derived from CRYSTALS-Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, derived from SPHINCS+, using a different mathematical approach. Signatures help establish who signed information and detect unauthorized changes. They do not themselves make the information confidential. NIST described ML-DSA as the principal signature choice and the hash-based standard as a backup should the lattice-based approach prove vulnerable.

These distinctions shaped the product work. A vendor securing connections had to understand where session secrets were established. A software distributor had to examine how releases were signed and how devices verified them. Both could describe their work as post-quantum migration while dealing with different interfaces, keys and failure modes. Procurement needed that specificity before comparing two suppliers’ claims.

Migration starts with finding the dependency

An application rarely owns every cryptographic decision on which it depends. A library, network appliance, identity service or endpoint controlled by a customer may determine the protocol and available algorithms. Replacing one implementation is therefore different from completing a connection between systems managed by different organizations. NIST’s warning that integration would take time was commercially significant: publication could remove uncertainty about specifications without removing dependency on other vendors.

A practical migration product could help a customer identify where public-key cryptography was used, which supplier controlled it and how a change would be verified. An inventory becomes more useful when it links a finding to an owner and a replacement path. Merely counting certificates or discovering algorithm names would leave unanswered whether a business process could continue operating after the change.

Three DE-CIX equipment cabinets with Brocade networking hardware and yellow cables visible through their mesh doors. — DE-CIX network equipment, 2011.Stefan Funke (opens in a new tab) · CC BY-SA 2.0 (opens in a new tab)

For a young company, this suggested a way to narrow the initial market. A tool that helped a specific class of enterprise software upgrade and test its connections could demonstrate a clearer result than a broad promise of protection against quantum attacks. The limitation was that some changes would remain tied to established vendors’ product cycles and customers’ ability to update their own environments.

Performance claims need a system around the algorithm

FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. Its description places them in increasing order of security strength and decreasing order of performance. That is a tradeoff within the standard, not a benchmark for every application. The impact of a deployment also depends on the implementation, hardware, protocol and surrounding workload.

Parameter choice changes ciphertext size

Period or category	bytes per ML-KEM ciphertext
ML-KEM-512	768
ML-KEM-768	1,088
ML-KEM-1024	1,568

Ciphertext sizes specified in FIPS 203, Table 3. Each parameter set produces a shared secret of 32 bytes, but its ciphertext size differs. These payload sizes are specified by the standard; they do not measure network latency, total handshake traffic or application performance.

Source5

A startup supplying an implementation could demonstrate how it behaved in the customer’s environment: whether peers interoperated, what happened on an unsupported connection and how operational staff diagnosed a failed exchange. Claims about latency or throughput needed a stated configuration and comparable measurements. A technically impressive algorithm demonstration would not by itself establish that a product was ready for routine enterprise use.

The security language also required care. NIST described the standardized approaches in terms of their believed resistance to quantum adversaries. That was not a guarantee against every future discovery or every implementation error. The complete product still depended on correct integration and secure operation. Claiming complete protection against quantum attacks would promise more than the standards provided.

Build for another change after this one

NIST was also evaluating additional algorithms. Its announcement described future standards as backups and told administrators they did not need to wait for them. The parallel work supported a practical architectural principle: systems should be able to change algorithms and parameters again. Hardwiring one choice deeply into a product could make a future transition unnecessarily expensive.

Investors could assess progress through a real migration: dependencies identified, an integration completed and a customer able to operate it. The publication of standards did not establish a market size, a buying deadline or guaranteed demand for a new vendor. It gave companies specifications around which to organise the engineering work. Businesses that could turn that task into a repeatable implementation, with clear limits and measured results, had a more credible proposition than those selling a distant threat alone.