Post-Quantum Migration Means Making New Keys. Their Randomness Matters.

On October 27, NIST published the final version of NIST IR 8547 , its plan for moving off quantum-vulnerable cryptography. A draft had been circulating since late 2024, so most of the content isn’t a surprise. What’s new is that the dates are no longer proposals. RSA, elliptic-curve cryptography and the rest of today’s public-key algorithms will be deprecated after 2030 and disallowed under NIST standards after 2035.

Federal systems get less time. Under Executive Order 14412  and OMB Memorandum M-26-15 , high value assets and high impact systems must switch to post-quantum key establishment by December 31, 2030, and to post-quantum signatures a year after that. Separately, Executive Order 14306  directed OMB to require agencies to support TLS 1.3 by January 2, 2030, and M-26-15 carries that out. Banks, hospitals and utilities usually end up following federal practice, if sometimes a little later.

What the Report Settles

Most of IR 8547 is a map from old algorithms to new ones. These are the parts worth knowing:

• Key size no longer buys time. The 2024 draft treated RSA-2048 and other 112-bit keys more harshly than larger ones. The final version puts every quantum-vulnerable parameter set on the same schedule, since a large enough quantum computer breaks the underlying math whatever the key length.
• ML-KEM replaces key exchange. FIPS 203  defines ML-KEM, and NIST recommends ML-KEM-768 as the default parameter set. HQC, which rests on different math, has been chosen as a backup .
• ML-DSA and SLH-DSA replace signatures. They come from FIPS 204 and FIPS 205. Stateful hash-based schemes such as LMS and XMSS are also approved, but NIST says they aren’t meant for general use and fit narrower jobs like firmware signing.
• Hybrids are allowed. You can pair a classical algorithm with a post-quantum one during the transition. NIST will still validate the result as long as one part is approved and the parts are combined using an approved method.
• Symmetric crypto stays. AES-128, AES-192 and AES-256 all remain approved, along with NIST’s standard random bit generators. Quantum computers threaten public-key math far more than these, though NIST will disallow a few symmetric options at the 112-bit security level in 2030.

What the Report Can’t Cover

NIST picked the algorithms. It can’t vouch for the randomness you feed them.

Every ML-KEM key pair starts from a random seed, and so does every ML-DSA signing key. If an attacker can predict that seed, they can rebuild your keys, and the strength of the lattice math won’t help you. This has happened before with classical crypto. In 2008, researchers found that a 2006 packaging change in a widely used Linux distribution had stripped nearly all the randomness from its OpenSSL key generation . So few keys were possible that lists of every key for common key types were published within days . In 2012, researchers scanning the internet were able to factor the RSA keys of more than 64,000 TLS hosts , mostly headless and embedded devices that made their keys automatically at first boot, before they had gathered enough entropy.

Post-quantum keys share that weakness. The devices most likely to be short on entropy, like sensors, controllers and edge appliances, are often the same ones that will create a post-quantum key once and keep it for a decade.

In a properly built system, a physical entropy source seeds an approved random bit generator, and that generator supplies the bytes for key generation. NIST validates entropy sources against SP 800-90B , and can certify them separately from the cryptographic module around them. A good source, whether it’s a ring oscillator, a noise diode or a quantum random number generator, doesn’t make anything quantum-safe on its own. It just makes sure ML-KEM and ML-DSA get the unpredictable input their security proofs assume.

A Migration Made of New Keys

People tend to picture this migration as swapping one algorithm for another. A lot of it is really about making new keys. Every TLS certificate, VPN credential, device identity and code-signing key in your organization will be replaced over the next few years, many of them on a federal or contractual deadline. Hybrid key exchange adds to the load, generating both classical and post-quantum key material for every connection. That’s a lot of keys made in a hurry, often on hardware nobody has examined closely in years.

You have to find them first. Public-key crypto turns up in places few organizations have mapped well, including hardware security modules, IoT firmware, key-management systems and products whose internals you can’t see. Most large organizations don’t have a complete cryptographic inventory yet, and building one takes longer than people expect.

Meanwhile, the clock is already running for some data. Well-funded attackers, many of them state-backed, are recording encrypted traffic now in the hope of decrypting it once quantum computers improve, a tactic known as “harvest now, decrypt later.” IR 8547 cites this as one of the main reasons the transition is urgent. If your data has to stay private for ten years, the practical deadline for protecting it may already be behind you. That’s why finance, healthcare, energy, defense and government can’t treat 2035 as their real date.

Where to Start

None of this needs a big reorganization to get going. A sensible first year might look like this:

• Build the inventory. List everywhere public-key crypto is used, including embedded and vendor-managed systems. You can’t plan around what you haven’t found.
• Rank systems by how long their data must stay secret. Anything holding data that must stay confidential past 2035, or traffic exposed to harvest-now-decrypt-later collection, goes first.
• Check how keys are made. For each system on the list, find out where its randomness comes from. Devices that generate keys at first boot deserve the closest look, because upgrading the algorithm without checking its input only does half the job.
• Ask vendors specific questions. Which NIST algorithms and parameter sets do they use? Is the cryptographic module FIPS 140-3 validated, and has its entropy source actually received SP 800-90B validation, rather than just been submitted? Can they change algorithms with a software update, or will it take new hardware? Write the answers down, and keep an eye on vendors who can’t give them.
• Run a hybrid pilot. Try hybrid ML-KEM somewhere the stakes are lower. Larger handshakes, protocol quirks and higher key volume are much easier to learn about now than under a deadline.

Watch for the follow-up documents, too. NIST plans to revise SP 800-131A and its application-specific guidance, including the TLS guidelines in SP 800-52, and says those updates may set earlier transition dates for particular protocols. It expects to prioritize quantum-resistant key exchange, particularly in TLS and IKE. ■