Post-Quantum Migration on the US Timeline: Aligning to NIST FIPS 203/204/205 and CNSA 2.0

The post-quantum standards are no longer a research topic. NIST finalised them in August 2024, the federal deadlines are dated, and the only open question left for a US firm is whether it starts the inventory now or explains later why it didn’t.

For years the honest answer to “what should we do about quantum” was: nothing yet, the algorithms aren’t standardised. That answer expired on 13 August 2024, when NIST published FIPS 203, 204 and 205. The standards exist, the National Security Agency has attached dates to them through CNSA 2.0, and the federal migration goal is fixed at 2035. This is a playbook, not a survey of the threat. The threat has been written about to death. What most firms lack is an ordered way to spend limited effort against a real timeline.

What the US timeline actually commits you to

Three finalised standards matter. FIPS 203 specifies ML-KEM, the module-lattice key-encapsulation mechanism derived from Kyber, for general key establishment. FIPS 204 specifies ML-DSA, the module-lattice signature algorithm derived from Dilithium, as the primary signature scheme. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme derived from SPHINCS+, held as a backup should the lattice assumptions weaken. Those are the algorithms your vendors and your own engineers will be naming for the next decade.

CNSA 2.0 puts dates against them, and it is worth being precise about who it binds. CNSA 2.0 is the National Security Agency’s suite for National Security Systems. Its deadlines apply directly to NSS owners and operators and, in practice, to any vendor that wants to keep selling into that market. The published sequence is phased: software and firmware signing should prefer the new algorithms from 2025 and use them exclusively by 2030; web browsers, servers and cloud services move on a similar early curve; networking equipment is expected to support and prefer CNSA 2.0 by 2026; operating systems by 2027; and the broad exclusive-use line for cloud, operating systems and traditional networking sits at 2033, with the whole NSS estate transitioned by 2035.

If you are not an NSS operator, do not read those dates as inapplicable. Read them as the schedule your supply chain is already being measured against. The general federal picture reinforces it: National Security Memorandum 10 and OMB memorandum M-23-02, issued in November 2022, told agencies to inventory their active cryptographic systems and prioritise migration, with a government-wide target of 2035. The Quantum Computing Cybersecurity Preparedness Act put the same obligation into statute. A private US firm inherits this indirectly but unavoidably, through the products it buys and the counterparties that will start asking for post-quantum roadmaps.

Start with the inventory, not the algorithm

The single most common mistake is to jump straight to “which library gives us ML-KEM” before anyone can say where the firm uses cryptography at all. You cannot migrate what you have not located. The first deliverable is a cryptographic inventory: a catalogue of every place your estate relies on public-key cryptography — TLS termination, code and firmware signing, VPNs, database and disk encryption key exchange, secrets managers, hardware security modules, certificate authorities, and the long tail of embedded and third-party components that quietly ship their own crypto.

This is exactly the layer the federal memoranda put first, and for good reason: it is the artefact that turns a vague intention into a plan. A structured inventory — increasingly captured as a cryptographic bill of materials, the way software dependencies are captured in an SBOM — lets you see quantum-vulnerable algorithms in context and rank them. We have written separately about generating a CBOM from your estate rather than assembling one by hand; at any real scale, hand-assembly is where the inventory dies. The point of the exercise is not completeness for its own sake. It is that every later decision — what to migrate, in what order, and which supplier to lean on — depends on this map existing.

Prioritise by data lifetime and exposure

With the inventory in hand, the ordering principle is not “most systems first” or “easiest first”. It is data lifetime crossed with exposure. The threat that makes quantum urgent before a cryptographically relevant machine exists is harvest-now-decrypt-later: an adversary records encrypted traffic today and decrypts it once the hardware arrives. The systems that matter most are therefore the ones carrying data that must stay confidential for years and that traverses a network an adversary can capture.

So rank ruthlessly. Long-lived secrets crossing public or shared networks — health records, financial positions, intellectual property, anything with a decade-plus confidentiality requirement — go to the top, because for those the clock has effectively already started. Ephemeral session data that is worthless in five years can wait. Signing keys are a separate axis: a forged signature is a present-tense problem the day a quantum adversary can produce one, which is why firmware and software signing sit early in every published timeline. The output of this step is a ranked list, not a wish. It is what makes limited engineering time defensible.

Sequence the transitions, and buy agility not a one-off swap

Key establishment and signatures migrate differently and should be sequenced accordingly. For key establishment, the near-term consensus is hybrid: pair a classical exchange with ML-KEM so that a break in either one alone does not expose the session. For signatures, ML-DSA is the general workhorse, while firmware and software signing can also use the stateful hash-based schemes LMS and XMSS that CNSA 2.0 already permits. These are not interchangeable, and the sequencing follows the exposure ranking rather than engineering convenience.

The deeper design decision is to migrate through an abstraction layer rather than hard-wire the new algorithms in place. Cryptography will change again; SLH-DSA exists precisely because NIST expects to need a fallback. Building crypto-agility — the ability to swap algorithms without re-architecting the systems that call them — turns this migration from a one-off scramble into a capability, and, as we have argued on crypto-agility as a CRA and PQC twofer, the same abstraction earns its keep against more than one regulatory driver.

Make your vendors move

Most of your quantum-vulnerable cryptography is not yours. It sits inside products — the HSM, the database, the load balancer, the CA software, the operating system, the embedded controller. You cannot migrate those yourself; you can only make the supplier do it and hold them to a date. The leverage is the timeline itself. Put a specific question into every renewal and every RFP: when will this product support FIPS 203/204/205, is there a documented post-quantum roadmap, and does it align to CNSA 2.0 for the components that will be measured against it. Vendors that cannot answer are telling you something. The inventory tells you which of them to chase first, because it tells you which of their products carry your highest-ranked data. That is the point of doing this in order rather than at random.

The board-level framing of all of this — what to fund, when, and how to explain it upward — we have set out in the post-quantum board reading. The engineering point is narrower and harder to argue with: the standards are final, the dates are printed, and the firm that has an inventory can act on any of them. The firm that does not still has to build the inventory first — only later, under more pressure, and with a supplier that has stopped waiting to be asked.