The quantum law asked for a price tag agencies could only get from their vendors

The week

On December 21, 2022, President Biden signed the Quantum Computing Cybersecurity Preparedness Act. Most laws about technology respond to something that has already happened, such as a breach, an outage or a scandal. This one was about a threat that did not yet exist, and a bill that had not yet arrived.

The bill, H.R. 7535, had passed the House in July 2022. The Senate passed an amended version on December 8, and the House agreed to the Senate’s changes on December 12 and 13, which cleared it for signature. It became Public Law 117-260. It carried no appropriation. Its only money provision was a requirement to estimate what the work would cost.

Its concern was simple to state. Much of the encryption that protects government data today, the mathematical scrambling that keeps information secret as it travels and while it is stored, could in principle be broken by a sufficiently powerful quantum computer. Quantum computers work on different physical principles from ordinary ones, and for certain mathematical problems they could be dramatically faster. The problems that guard much of today’s encryption are among them.

The law’s findings named the risk directly. Adversaries could steal encrypted data now and decrypt it later, once quantum machines were capable enough. Its sense-of-Congress section added a preference that carries through this article: the government and industry should favor software, hardware and applications that can be readily updated, a property it called cryptographic agility.

The law set out a sequence of duties for OMB, the Office of Management and Budget, the White House office that oversees how federal agencies spend money and manage technology.

• Within 180 days, OMB had to issue guidance telling agencies to maintain an inventory of information technology vulnerable to decryption by quantum computers.
• Within one year of enactment, and on an ongoing basis after that, each agency had to give its inventory to OMB, CISA, the federal cybersecurity agency, and the National Cyber Director.
• Within one year after NIST, the National Institute of Standards and Technology, issued post-quantum standards, OMB had to direct agencies to prioritize systems for migration and write migration plans. Post-quantum cryptography means new encryption methods designed to resist quantum attack.
• Within 15 months, OMB had to report to Congress with a strategy and an estimate of the funding agencies would need, followed by progress reports once migration guidance was in place.

National security systems, which follow their own separate rules, were excluded.

The law did not start from zero. It built on National Security Memorandum 10 from May 2022, which set the goal of mitigating as much quantum risk as feasible by 2035. It also built on OMB memorandum M-23-02 from November 2022, which had already started annual cryptographic inventories.

M-23-02 was specific. Each agency had 30 days to name a cryptographic inventory and migration lead. By May 4, 2023, and every year after that until 2035, agencies had to submit an inventory focused on high-value assets, high-impact systems and data expected to stay sensitive until 2035. For each system they had to record the vulnerable algorithm, its purpose and key length, and whether it came from a commercial vendor, from another agency or from custom code. They also had to say where it was hosted and how long the data needed protection. Within 30 days of each inventory, agencies had to submit an estimate of the funding needed to migrate those systems.

NIST had selected candidate algorithms in July 2022, the new mathematical recipes intended to replace today’s vulnerable ones, but had not finalized standards. Within weeks of that announcement, researchers showed that one of the algorithms still under study in a later round could be broken with an ordinary computer. The episode did not affect the algorithms NIST had picked. It did show why the law’s authors wanted systems that could change algorithms without being rebuilt.

National security systems were already on a separate track. In September 2022 the NSA had published its own updated algorithm suite for those systems, with transition timelines running to 2035.

So the law arrived at an awkward moment. Agencies were being asked to plan, and to put a price on, a migration to standards that did not formally exist yet. The practical question was how to produce a credible number under that kind of uncertainty.

The law signed that week added a statutory duty to give Congress a government-wide funding estimate and recurring progress reports. M-23-02 had already asked agencies for funding assessments, but for the administration’s internal use.

That changed the question from “what first?” to “what will it cost, and who decides?” Three things determine the answer: where the cryptography actually lives, which costs an agency controls, and how contracts turn a vendor’s roadmap into an agency’s commitment.

Those three parts are the core of this article. Before them comes a short section on the threat itself, because the shape of the cost follows from the mechanics. After them come the people who have to produce the estimate, the same arithmetic in banks and hospitals, and the annual cycle that can make the number better each year.

Why quantum computers threaten today’s padlocks

Almost every secure thing you do online relies on a kind of encryption called public-key cryptography. It solves a basic puzzle: how two parties who have never met can agree on a secret over a public network. Each party has two keys. A public key can be shared with anyone, like a padlock left open on a table. A private key is kept secret, like the only key that opens that padlock. Anyone can lock a message with your padlock, but only you can open it.

Public-key cryptography also underpins digital signatures, the way a website proves it really is your bank, or a software update proves it really came from its maker. The certificates behind these signatures form chains of trust, each one vouching for the next.

The most widely used public-key methods carry names such as RSA and elliptic-curve cryptography. Their security rests on mathematical problems that ordinary computers would take an impractically long time to solve. A large enough quantum computer, running a known algorithm, could solve those particular problems far faster. If that happens, the padlocks stop working.

Nobody knows exactly when such a machine will exist, and expert estimates vary widely. But there is a reason governments did not wait. An adversary can copy encrypted data today and store it, betting on decrypting it later. This is often called “harvest now, decrypt later.” For information that must stay secret for decades, such as intelligence sources, health records or personnel files, the risk begins the moment the data is copied, not the day the quantum computer is switched on.

The fix is to switch to new post-quantum algorithms, which are built on different mathematical problems believed to resist quantum attack. That sounds like a software update. In practice it reaches every system an organization runs, including the ones inside equipment it bought from others and cannot open.

Two kinds of exposure on two clocks

The threat does not hit all cryptography equally, and that matters for the budget. Symmetric encryption, where both sides share the same secret key, is the workhorse that actually scrambles bulk data. Known quantum attacks weaken it only modestly, and longer keys are generally considered enough. Hash functions, used to fingerprint data, are in a similar position. The expensive problem is concentrated in public-key cryptography.

Within public-key cryptography there are two exposures on different clocks. Key exchange, the step where two systems agree on a shared secret, is exposed to harvesting today. Anything protected by a key exchange recorded now could be read later. That makes key exchange the first priority for data with a long life.

Signatures are different. A forged signature only works once a quantum computer exists, so recorded traffic gives an attacker nothing to forge in advance. But some signature keys last a very long time. A root certificate may be trusted for decades. A firmware signing key may be burned into a device’s hardware when it is made. If those cannot be replaced before a capable quantum computer appears, the device or the trust chain cannot be fixed later. That turns some signature problems into hardware problems, and hardware problems into replacement costs.

Why the new algorithms are not drop-in replacements

The post-quantum algorithms NIST was evaluating are larger than the ones they replace. Their public keys, ciphertexts and signatures run to hundreds or thousands of bytes, where today’s elliptic-curve equivalents use a few dozen. On a modern server that difference barely registers. On a smart card, a sensor, an older network appliance or a protocol with fixed message sizes, it can be the difference between working and failing.

Federal use adds a second hurdle. Agencies generally must use cryptographic modules validated under NIST’s FIPS 140 program. A vendor that implements a new algorithm still has to put the module through validation before agencies can rely on it for protected data. So for federal buyers, “the vendor supports it” and “we can use it” can be a year or more apart. Any schedule built on vendor announcements alone will be too optimistic.

Agility as a design property

A useful concept here is crypto-agility: the ability of a system to swap one encryption method for another through configuration or a routine update, without being rebuilt.

Agility has three layers. The protocol has to allow new algorithms to be negotiated. The software has to call a cryptographic library rather than hard-coding the mathematics. And the hardware has to have the memory and processing headroom to run larger algorithms. A product that fails any of the three layers is not agile, whatever its marketing says. The law’s preference for agility was, in effect, a preference for products that pass all three.

Where the cryptography lives

An agency inventory built for M-23-02 tends to list systems. The cost estimate needs something finer: every place a quantum-vulnerable algorithm is used, and who can change it.

In a typical civilian agency only a small share of that sits in code the agency writes. Most is inside commercial software, managed services, network appliances, hardware security modules, smart cards and the certificate chains that tie them together. A network appliance is a dedicated box, such as a firewall or load balancer, that directs and protects traffic. A hardware security module is a tamper-resistant device that stores and uses an organization’s most sensitive keys. Smart cards are the identity badges with embedded chips that federal employees use to sign in.

That distinction matters because the remedy differs:

• Agency-built code needs engineering time and a library upgrade. A library is a ready-made package of code that programs share, and most software uses a cryptographic library rather than writing its own.
• A cloud service may be migrated by its provider with no agency action at all.
• An appliance may need a firmware release that the vendor has not promised, or a replacement because the hardware cannot run the new algorithms fast enough.
• Identity cards and the readers that accept them may need to be reissued across a whole workforce.

An inventory that records only “uses RSA” cannot be priced. One that records “uses RSA in a vendor-managed load balancer, end of support 2027, no stated roadmap” can. The second tells the agency who can change each use, and when.

What the federal inventory asked for, and what it left out

M-23-02 went further than a list of system names. For each in-scope system it asked for the vulnerable algorithm, the service it provided and its key length. It asked whether the cryptography came from a commercial product, another agency or custom code, and who the vendor was. It asked where the system was hosted and how long its data needed protection.

Those fields are close to what a cost estimate needs, with two gaps. The memo did not ask for the contract behind each product, its renewal date or the vendor’s stated plans. Nor did it ask for the equipment’s planned replacement date. Those are the facts that decide whether a fix costs nothing extra or costs a whole replacement. An agency that adds them to its own working copy of the inventory turns a compliance submission into a budgeting tool.

The memo also limited the first inventories to the most sensitive systems: high-value assets, high-impact systems, systems holding data that would still be sensitive in 2035, and identity systems built on public-key infrastructure. That was a sensible start. It also meant the first cost estimates covered only part of the estate, and later inventories would add systems and cost.

Finding the uses

Finding those uses takes several sources, because no single tool sees them all. Certificate inventories and certificate authority logs show where public-key certificates are issued and used. Network scanning shows which protocols and key exchanges systems actually negotiate. Software bills of materials, where vendors provide them, show which cryptographic libraries a product contains; a bill of materials lists the components inside a product. Configuration reviews of hardware security modules and identity systems fill the remaining gaps.

Each source misses something on its own: scanning cannot see data at rest, the information sitting in storage, and bills of materials are only as complete as the vendor makes them. Combining them, and recording the owner of each finding, is what turns a list of systems into something a budget office can use.

The places inventories tend to miss

Some uses of public-key cryptography hide well. Firmware signing keys inside devices rarely show up in network scans. Building access systems that read employee badges are often run by facilities teams, outside the IT inventory. Encrypted backups may wrap their keys with a public-key algorithm that nobody has looked at since the backup product was installed. Virtual private network tunnels to state partners, contractors and other agencies depend on both ends changing together.

Operational technology, the equipment that runs buildings, laboratories and field sites, is a special case. It often has long service lives, limited processing power and vendors with no public roadmap. It is also where premature replacement costs are most likely to cluster.

Shared services and the count-once problem

Many agencies use the same commercial products and the same cloud services. If each agency inventories and prices the same product separately, the government-wide estimate counts the same work many times. M-23-02 anticipated this. It called for a process to identify common cryptographic systems used across agencies, so each agency need not inventory them separately. It also pointed agencies to the FedRAMP program office for inventories of authorized cloud services.

For an agency, the practical point is to know which entries in its inventory are shared and which are unique. Shared entries are usually best priced and negotiated once, centrally. Unique entries, such as custom applications and specialized equipment, are where an agency’s own estimate does most of its work.

Which costs an agency controls

The estimate breaks into three kinds of cost.

Changing what the agency owns

The first is labor to change what the agency owns: its applications, scripts, integrations and internal certificate authorities. This is the most predictable part, and it scales with how disciplined the agency’s software practices already are. An agency that knows which libraries its applications use, and updates them routinely, can plan this work like any other upgrade. One with decades of undocumented custom code faces a longer, costlier search before the work can even start.

The labor is more than code changes. Each change needs testing, including performance testing for the larger algorithms, and interoperability testing with every system on the other end. During the transition many connections will run in hybrid mode, combining a traditional algorithm with a post-quantum one. Hybrid operation is safer but adds complexity, and someone has to decide when to retire the traditional half.

Costs inside existing contracts

The second is cost carried inside existing contracts and subscriptions. If a vendor delivers post-quantum support as a routine update, the agency pays nothing extra beyond testing. If the vendor treats it as a new edition, the cost arrives at renewal. The agency does not control which, but it can find out early and negotiate.

Cloud services fall mostly in this category. A large provider that upgrades its own infrastructure spreads the cost across all its customers. An agency’s share may be invisible in the price. The agency still bears the cost of confirming the change, adjusting any connections it controls, and checking that its own data at rest is protected in the way it expects.

Premature replacement

The third, and usually the largest, is premature replacement: equipment and software that cannot be upgraded and must be retired before its planned end of life.

That cost is driven by timing. Equipment due for refresh anyway costs little extra if the new purchase is post-quantum ready; equipment refreshed early to meet a migration date costs its full remaining value. Aligning migration with refresh cycles is therefore the main lever on the total, and it only works if the next purchases are specified correctly.

Take a federal agency with a fleet of network appliances. Some are due for replacement in two years, some in five, some in eight. If every new appliance bought from now on is required to support post-quantum algorithms through software updates, then most of the fleet will turn over naturally before the migration deadline, at roughly the cost the agency would have paid anyway. Only the appliances with the longest remaining lives, and no upgrade path, need early replacement. Now suppose the same agency keeps buying appliances without that requirement for another three years. Each of those purchases becomes a future premature replacement, and the bill grows with every order.

The difference between those two paths is not a technology decision. It is a purchasing decision, made one order at a time by people who may never have heard the word “quantum” in a meeting. That is why the most valuable early step for many agencies was not a new tool or a new team, but a short paragraph added to the standard language used when buying anything that encrypts data.

How the budget cycle shapes the number

Federal budgets are built well ahead of the money arriving. An agency preparing its request in 2023 was mostly shaping spending for fiscal year 2025. A migration cost identified late may have to be absorbed within existing budgets for a year or two, competing with everything else.

That lag favors the purchasing approach. Changing contract language costs almost nothing and needs no new appropriation. It moves cost out of the premature-replacement category and into ordinary refresh budgets the agency already has. The funding estimate then has to cover only the residue that cannot be absorbed that way.

Ranges, not points

A single number for a migration of this kind will be wrong. A more honest estimate gives a range for each cost category and states the assumptions behind it. Those include how many products the agency expects vendors to upgrade, how many it expects to replace early, and what share of custom code it has examined. As vendors commit to dates and inventories improve, the assumptions firm up and the ranges narrow. That narrowing, year over year, is a better measure of progress than the size of the number itself.

How contracts turn roadmaps into commitments

Most of the second and third kinds of cost depend on vendors, so the procurement record becomes the place where the estimate is either grounded or guessed. A roadmap is a vendor’s stated plan for future features. On its own it is a hope. Written into a contract, it becomes something closer to a commitment.

Four contract practices make the difference:

1. Get the roadmap in writing. Ask every supplier of a product that uses public-key cryptography for a dated post-quantum roadmap and keep it on file.
2. Buy agility. Require that new purchases support algorithm updates by configuration or software release, without hardware replacement, once standards are final.
3. Require disclosure. Require the vendor to disclose the cryptographic components and libraries in the product, so the agency inventory can be kept current without guesswork.
4. Tie renewal to delivery. A product that misses its stated roadmap should not renew on the same terms.

What the language should say

In December 2022 there were no final standards to name, so contract language had to point forward. A workable clause referred to NIST-approved post-quantum algorithms “once standardized,” rather than to any candidate by name. It asked for support within a stated period after standards were final and validated modules were available. It also asked for notice of end-of-support dates, so the agency could see replacement costs coming.

The disclosure clause can be specific without being burdensome. It asks which cryptographic libraries the product uses and which algorithms it supports, in a form the agency can load into its inventory. Some bill-of-materials formats later added fields for exactly this kind of cryptographic detail, which made the request easier for vendors to meet.

Where the clause goes

Agencies buy much of their technology through government-wide contract vehicles and enterprise agreements negotiated once and used many times. Language added at that level reaches every order placed through it. Language added only to an individual agency’s orders reaches that agency alone. The most efficient path is to get the requirement into the large vehicles, and to add it locally where an agency buys directly.

Trade-offs and vendor pushback

The clauses have costs. Some vendors, especially small ones selling specialized equipment, may not be able to commit to a roadmap for standards that do not yet exist. A strict requirement could narrow competition or raise prices. A roadmap written into a contract is also not a warranty. It may be hard to enforce if the vendor simply misses a date.

The sensible balance is to require disclosure and a dated roadmap from everyone, require agility for long-lived equipment, and treat a missed roadmap as a factor at renewal. That keeps small vendors in the market while still giving the agency the facts it needs. It also signals demand. Vendors that see the same clause across many agencies have a reason to build the capability once.

The fix requires no new law, only that the people who write statements of work, the people who run the cryptographic inventory and the people who prepare budget estimates use the same list.

Agencies that kept those three apart produced estimates that were either inflated by worst-case replacement assumptions or understated because vendor-dependent costs were left out. Neither kind of error helps Congress, and both make the next year’s estimate harder to defend.

How the work unfolds inside an organization

The cost estimate is only as good as the cooperation between groups that rarely sit in the same meetings, so it matters who actually does this work.

The security team usually owns the cryptographic inventory. It runs the scans, reads the certificate logs and asks vendors for bills of materials. It knows where vulnerable algorithms are used, but often not what each system cost, when it is due for replacement, or what its contract says.

The infrastructure and application teams know the systems themselves. They know which appliance is fragile, which application was written fifteen years ago by a contractor who has since left, and which cloud service the agency could switch off tomorrow. They can say how hard a change would be, but rarely what it would cost in dollars.

The procurement office holds the contracts. It knows renewal dates, what the vendor has promised and what the agency can still ask for before signing. But it seldom sees the inventory, and it may not know which products contain vulnerable cryptography at all.

The budget office builds the estimate that goes to OMB and, through OMB, to Congress. It needs numbers it can defend: what, when, how much and why. Without the other three groups, it can only guess.

One list, four contributors

The practical answer is a single working list, one row per use of vulnerable cryptography, that all four groups can read and add to. Security records where it is and which algorithm it uses. Infrastructure and application owners record how it can be changed. Procurement records the contract, the vendor roadmap and the renewal date. Budget records the expected cost and the year it falls. Once a year, ahead of the report, the four groups sit down together and walk the list.

That sounds modest, and it is. But in many organizations it would be the first time those four groups had looked at the same document about the same problem. The quality of the estimate improves not because anyone has learned more about quantum computing, but because the people who already know the answers are finally talking to each other.

Who is accountable

M-23-02 required each agency to name a cryptographic inventory and migration lead. That person is the natural owner of the list. The lead needs authority that reaches beyond security, because most of the decisions on the list belong to other people.

Federal law already gives agency chief information officers a role in IT budgeting and acquisition through FITARA, the 2014 IT acquisition reform law. That role is the obvious channel for getting migration requirements into purchases. The chief financial officer and the senior procurement executive complete the picture. When the migration lead reports into the CISO alone, the list tends to stay a security document. When the CIO and CFO sponsor it, it is more likely to shape spending.

Measures that show progress

A handful of simple measures tell an agency whether the work is moving. The first is the share of inventory entries with a known owner and a known path to change. The second is the share of relevant new purchases that included the agility and disclosure clauses. The third is the share of vendor-dependent entries with a dated roadmap on file. The fourth is the width of the cost range in each category. Each should improve every year. If one stalls, the list shows which group needs help.

Smaller and non-federal governments

State and local governments were outside the law, which covered federal agencies only. Their exposure is the same, and many buy the same products, sometimes through the same contract vehicles. A county without a dedicated cryptography team can still do the two cheapest things: add agility and disclosure language to its purchases, and ask vendors for dated roadmaps. Federal demand gave vendors reasons to build the capability. Smaller governments benefit most when they ask for it in the same terms.

Banks, hospitals and insurers face the same arithmetic

The law applied to federal agencies, but the structure of the problem applies to any organization that keeps long-lived secrets: banks holding customer records, hospitals holding patient histories, insurers holding claims files. Every one of them runs on public-key cryptography, and most of it sits inside products they bought.

For a business, the financial logic is the same as for an agency. The cost of migrating is driven less by the cryptography than by the timing of purchases. Every piece of equipment bought today without a path to new algorithms is a cost deferred, not avoided. And the organizations that negotiate early, while they still have choices and a renewal to bargain with, will pay less than those that negotiate late, under a deadline.

Where the long-lived exposure is

In banking, much of the cryptography runs through payment networks, card systems and hardware security modules. Changes there depend on industry standards bodies and networks as much as on the bank. Cards and phones turn over every few years. Hardware security modules, core systems and connections to payment networks change more slowly and more expensively. Records that a bank must retain for years, and the data of customers whose relationships last decades, are the harvest-now exposure.

Hospitals and health systems face a different mix. Many medical devices stay in service far longer than ordinary IT, and their vendors control the software. Patient records must stay confidential for the patient’s lifetime and beyond. A health system’s exposure is therefore weighted toward vendor-dependent costs and premature replacement, the two categories it controls least.

Insurers sit between the two. Their claims and underwriting files are long-lived, but more of their technology runs on mainstream software and cloud services that vendors will upgrade. Their largest effort is likely to be in custom applications and connections with partners.

The regulatory signal

Regulators in many sectors watch federal standards closely. In December 2022 no US financial or health regulator had set binding post-quantum deadlines for the firms it supervised. The federal timeline still mattered to them, because the products those firms buy are largely the same products agencies buy. Federal requirements shape vendor roadmaps, and vendor roadmaps shape everyone’s costs.

There are reputational dimensions too. A board that asks today what its exposure is, and gets a clear answer, is in a much better position than one that hears about the issue first from an examiner or a customer.

An annual review that narrows the estimate

The law’s reporting cycle is what makes this practical. Annual reports to Congress create a recurring moment to reconcile the inventory, the vendor roadmaps and the budget. An agency that treats the report as a compliance exercise will repeat the same uncertainty each year. One that treats it as a procurement review will see its estimate narrow as vendors commit to dates and refresh cycles absorb more of the work.

The agencies that get there keep four things. The first is an inventory that records who can change each use of vulnerable cryptography, and when, as well as where it is used. The second is procurement language that requires agility and disclosure in every relevant purchase. The third is a set of dated vendor roadmaps kept with the contracts. The fourth is a single annual review where security, procurement and budget staff work from one list.

What the review covers

A useful review has a fixed agenda. It starts with what changed in the inventory: new systems found, systems retired, entries reclassified. It then walks the vendor-dependent entries, checking which roadmaps were met, which slipped and which vendors still have not answered. It looks ahead at the next two years of renewals and refreshes, marking each as an opportunity to require agility. And it ends by updating the cost ranges and the assumptions behind them.

The output is short: an updated estimate, a list of contracts to renegotiate, and a list of products to retire on schedule rather than early. Those three items are what OMB, a board or an audit committee can use.

The case for waiting

The strongest argument against all of this effort in 2022 was uncertainty. Nobody could say when a capable quantum computer would exist, and the standards were not final. Spending money on a migration that might not be needed for decades looked premature to some, especially with other security priorities competing for the same budget.

The argument has force for expensive, early replacement. It is much weaker for the cheap steps. Adding contract language, asking for roadmaps and extending the inventory cost little and keep options open. They also address the harvest-now risk for long-lived data, which does not depend on when the quantum computer arrives. The approach in this article spends least where uncertainty is highest, and most where it is lowest.

Estimates go wrong in predictable ways:

• Listing systems instead of the specific places cryptography is used.
• Assuming every vulnerable product must be replaced, which inflates the estimate.
• Leaving vendor-dependent costs out entirely, which understates it.
• Continuing to buy equipment without upgrade paths while the migration plan is being written.
• Treating the report to Congress, or to a board, as paperwork rather than a chance to bring the numbers closer to reality.

Pricing the migration

The questions below turn the article into a short review for any CIO, CISO or budget officer, in government or outside it. Each can be answered from records.

• Do we have an inventory of where public-key cryptography is used, down to the product and component, rather than only the system name?
• For each entry, who can change it: our own staff, a cloud provider, or a vendor through an update or a replacement?
• Do our new purchase contracts require that products can adopt new encryption methods through a software update, without new hardware?
• Which of our devices and systems could not be upgraded and would need early replacement, and when are they due for refresh anyway?
• Do the people who buy technology, the people who track our cryptography and the people who build our budget work from the same list?

An organization that can answer all five has a number it can defend, even if the number is a range. One that cannot has a guess, and the guess will be expensive in whichever direction it turns out to be wrong.

With hindsight

NIST published its first three post-quantum standards, FIPS 203, 204 and 205, on August 13, 2024. FIPS stands for Federal Information Processing Standards, the formal technical rules federal agencies must follow. Their publication started the law’s one-year clock for OMB migration guidance, and turned the candidate algorithms of 2022 into requirements agencies could write into contracts.

The standards gave the 2022 candidates new names. FIPS 203 defined ML-KEM, for key exchange. FIPS 204 and 205 defined ML-DSA and SLH-DSA, two signature methods built on different mathematics. NIST kept working beyond them. In March 2025 it selected a further key-exchange algorithm, HQC, as a backup to ML-KEM built on a different mathematical approach, with a final standard expected in 2027. It also said a standard based on a fourth candidate, FALCON, would follow. The work never really stopped, which is the practical case for agility in one sentence.

In July 2024 OMB sent Congress the required report. It projected about $7.1 billion in 2024 dollars between 2025 and 2035 to migrate prioritized civilian systems. It said the estimate carried a high level of uncertainty, and that replacing systems unable to support the new algorithms made up a significant portion of it. That is the cost category that depends most on vendors and refresh timing.

The report arrived months after the law’s 15-month deadline, and its estimate covered the prioritized systems the inventories had captured, not the whole federal estate. Both points fit the argument made here. Producing a defensible number took longer than the statute assumed, and the number grew from the most sensitive systems outward.

In November 2024 NIST released draft guidance proposing that widely used quantum-vulnerable algorithms be deprecated after 2030 and disallowed after 2035. Deprecated means discouraged and on the way out; disallowed means no longer permitted. For anyone buying long-lived equipment, those two dates turned an abstract concern into a practical purchasing deadline.

Federal policy held its course through a change of administration. An executive order signed in January 2025 included post-quantum provisions. A June 2025 order, Executive Order 14306, amended it but kept two purchasing-related duties. CISA was to publish, by December 1, 2025, and keep updated a list of product categories in which products supporting post-quantum cryptography are widely available. Agencies were to support TLS 1.3, the current version of the protocol that secures web connections, or a successor, by January 2, 2030. A list of product categories is, in effect, a purchasing tool: it tells buyers where they can reasonably demand the capability now.

Other governments set similar dates. In March 2025 the UK’s National Cyber Security Centre published migration timelines asking organizations to finish discovery and an initial plan by 2028, complete their highest-priority migrations by 2031 and finish by 2035. Its guidance explicitly asked organizations to tell their suppliers what they need, the same move this article argued for.

Meanwhile the market moved. Browsers, operating systems and large cloud providers rolled out hybrid post-quantum key exchange in 2024 and 2025. Hybrid means combining a traditional method with a post-quantum one, so a connection stays protected even if either proves weaker than expected. Much web traffic gained protection through vendor updates at little direct cost to agencies, while older appliances and custom systems remained the expensive part.

That split is the clearest confirmation of the argument made in December 2022. Where vendors built agility into their products and shipped it as a routine update, the migration was nearly invisible to the customer. Where equipment could not be updated, or software had been built in-house without agility in mind, the bill remained.

What did not hold up as neatly was the idea that a single report could settle the cost. By 2026 the more useful way to read the estimate was as a moving range, refined each year as inventories widened and vendors delivered or slipped. An agency that had built the working list described here could update it. One that had treated the first report as a one-time submission would have had to start again.

In any sector, the practical message is about purchasing rather than physics. The cheapest migration is the one built into the next product you were going to buy anyway. That only happens if someone asks the right question before the contract is signed.