I watched NIST close a long chapter on 13 August 2024 when it issued FIPS 203, 204 and 205, the first post-quantum cryptography standards to come out of the competition it opened in 2016 and settled in 2022. FIPS 203 standardises ML-KEM for key encapsulation, FIPS 204 standardises ML-DSA for signatures, and FIPS 205 standardises SLH-DSA as a hash-based signature alternative. Those three documents turn candidate algorithms and draft text into standards that software teams can build against.
For years we treated Kyber, Dilithium and SPHINCS+ as research choices. They are now named, parameterised standards. The question is no longer whether post-quantum cryptography will arrive in ordinary software. The question is how we put it into products without breaking interoperability, performance budgets or existing certificate and protocol machinery.
The threat is already on the calendar
I treat harvest-now-decrypt-later as an operational risk we already live with, not a science-fiction subplot. An adversary does not need a working quantum computer today; they only need patience and storage. They can copy TLS sessions, VPN tunnels, archived backups and any long-lived ciphertext protected through vulnerable public-key mechanisms, then warehouse that material until a cryptographically relevant machine can attack the key establishment.
That puts every record we encrypt today on a clock we do not control. Customer records, source trees, board minutes and other information may need to stay confidential for years. It is not enough to say the data is encrypted. If the ciphertext leaves our perimeter, or if an insider can snapshot it, the harvest can happen now and the decryption can happen later.
That is why migration cannot wait for a headline announcing a cryptographically relevant quantum computer. By then, old traffic may already have been collected. Migration itself takes years: inventorying certificates, libraries, hardware security modules, vendor interfaces and embedded devices; proving interoperability; changing protocols; and rotating keys without breaking production. The migration deadline is before the computer exists, not after.
FIPS 203: the new default for establishing keys
FIPS 203 is NIST's standard for ML-KEM, the module-lattice key-encapsulation mechanism derived from CRYSTALS-Kyber. This is the default post-quantum tool for key establishment. In practical terms, one side has a public and private key pair. The sender encapsulates to the public key, producing a ciphertext and a shared secret. The receiver decapsulates the ciphertext with the private key and obtains the same shared secret.
Treat it as a KEM, not as public-key encryption for application data. Its job is to establish shared key material. The application then uses that material with its normal symmetric encryption. That distinction affects interfaces, error handling and protocol design. A clean KEM abstraction is easier to replace and test than cryptographic assumptions scattered through application code.
ML-KEM comes in three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The number is part of the standard name, not a symmetric-key size. Each set makes a different trade-off between security level and the size and cost of keys and ciphertexts. ML-KEM-768 is the sensible general-purpose starting point, while the lower and higher sets exist for systems with different constraints and assurance requirements. The correct choice still belongs in a threat model, not in a developer's guess.
The implementation rule is deliberately boring: use a maintained implementation, follow the standard's encodings and failure behaviour, and keep the selection configurable. Do not invent an optimisation of the module-lattice mathematics. The hard engineering work is usually around the primitive—negotiation, messages, timeouts, telemetry and rollback—not inside it.
FIPS 204: the general-purpose signature
FIPS 204 standardises ML-DSA, derived from CRYSTALS-Dilithium. It is a module-lattice digital-signature scheme and the general-purpose post-quantum default. Where ML-KEM establishes a secret, ML-DSA proves who signed a message. That puts it into the paths we use for software releases, service identity, documents, certificates and firmware updates.
The engineering trade-offs are concrete. Public keys and signatures are larger than the elliptic-curve artefacts many systems use today. That affects handshake size, certificate chains, storage, message limits and constrained links. Existing parsers may have hidden assumptions about maximum lengths. Those are exactly the sort of assumptions that survive unit tests and fail in production.
I would implement ML-DSA first for ordinary signing use cases, but I would not switch it on everywhere at once. Run it through code-signing pipelines, certificate issuance, verification services, offline recovery and disaster-rebuild procedures. A signature algorithm is only useful if every verifier can consume it and if the organisation can still recover and rotate its keys under pressure.
FIPS 205: the conservative alternative
FIPS 205 standardises SLH-DSA, derived from SPHINCS+. It is a stateless hash-based signature scheme. Stateless matters operationally: we do not have to track one-time signing state or worry about that state being cloned, restored from backup or lost. Each signature can be produced without maintaining a fragile counter across systems.
Its attraction is conservative. The security case rests only on the properties of the underlying hash functions, rather than on a lattice problem. That gives architects an independent family of assumptions and makes SLH-DSA a useful fallback when cryptographic diversity matters.
The trade-off is real. Signatures are larger and operations are slower than with ML-DSA. Bandwidth, latency, storage and verification throughput will notice. I would not treat it as the default for every online handshake. It is a strong candidate for long-lived roots, firmware and other cases where a conservative security foundation can justify the extra size and time. FIPS 205 is the alternative, and I would use it deliberately rather than decoratively.
Migration starts with an inventory
I start every post-quantum programme with an inventory, not a shopping list. Until we know every key, certificate, algorithm, protocol, library, device, owner and data lifetime in the estate, “migrate to post-quantum cryptography” is a slogan rather than a plan.
Keys and certificates tell us what is actually in production. Algorithms and protocols tell us which TLS stacks, virtual private networks, signing paths and firmware channels will change. Libraries and devices tell us which components can be upgraded and which are frozen. Owners matter because cryptography changes need budgets and maintenance windows. Data lifetimes tell us where harvest-now-decrypt-later creates the most immediate exposure.
That inventory becomes a sequenced backlog: what must move first, what can wait, what needs isolation or replacement, and what cannot be solved with cryptography alone. It also exposes dependency risk. A service may be ready while a partner's mutual-TLS client, an appliance or an old device is not.
Only after that map exists would I run hybrid TLS pilots. During the transition, a hybrid key exchange combines an established classical mechanism with a post-quantum mechanism so the session does not depend on either one alone. This lets teams introduce ML-KEM while retaining protection from the established mechanism and while ecosystems catch up. It does not remove the need for protocol support at both ends.
I want pilots with realistic traffic, certificate lifecycles and rollback. Measure handshake sizes, CPU, memory and latency. Test load balancers, proxies, inspection tools, mobile clients and unusual networks. Watch for middleboxes that reject messages simply because they are larger or unfamiliar. The cryptographic primitive may be sound while the system around it still fails.
What I would do this year
First, give post-quantum migration a named technical owner with authority to get answers from every product team. Build the inventory and keep it alive. Include TLS and mutual TLS, code signing, firmware and boot chains, secure shell access, public-key infrastructure, hardware security modules, databases, message queues and third-party services that hold keys or terminate sessions.
Second, rank the estate by data lifetime, harvest-now-decrypt-later exposure and blast radius. Long-lived secrets and systems that establish trust for everything else belong near the front. A short-lived internal certificate and a root used to verify devices for many years are not the same risk.
Third, choose maintained libraries that track the NIST standards and make algorithms configurable. Test known-answer vectors, malformed inputs, negotiation failures and version mismatches. Benchmark on the actual devices and traffic shapes you operate. Include backups, key rotation, disaster recovery and rollback, because migrations fail at their edges.
Fourth, pilot hybrid key establishment on an internal service and then on a controlled external edge. Instrument which algorithms negotiate, how often fallbacks occur, what errors clients see and what the performance distribution looks like. Averages hide the devices and networks most likely to break.
Finally, ask every critical supplier for a written roadmap and put algorithm agility into new contracts. The aim is not to predict the exact year quantum hardware crosses a threshold. It is to stop one algorithm choice from requiring a multi-year rewrite. The work is unglamorous and it will not be finished this year. That is precisely why it should start now.