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

The Quantum Computing Cybersecurity Preparedness Act asked OMB for a funding estimate. Most of the cost sat in products agencies did not build, so the honest answer depended on vendor roadmaps, contract terms and refresh cycles.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

On December 21, 2022, President Biden signed the Quantum Computing Cybersecurity Preparedness Act. It required OMB to issue guidance within 180 days telling agencies to maintain an inventory of information technology vulnerable to decryption by quantum computers. It required OMB, within one year after NIST issued post-quantum standards, to direct agencies to prioritize systems for migration and write migration plans. And it required OMB to report to Congress within 15 months with a strategy and an estimate of the funding agencies would need, followed by annual progress reports. National security systems were excluded. The law built on National Security Memorandum 10 from May 2022 and OMB memorandum M-23-02 from November 2022, which had already started annual cryptographic inventories. NIST had selected candidate algorithms in July 2022 but had not finalized standards.

Earlier in this series we argued that NSM-10’s 2035 goal hid a nearer deadline set by how long each system’s data must stay secret. The law signed this week added something the memo had not: a demand for money estimates and annual progress reports to Congress. 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.

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.

That distinction matters because the remedy differs. Agency-built code needs engineering time and a library upgrade. 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.

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. 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, 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.

Which costs an agency controls

The estimate breaks into three kinds of cost. 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.

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.

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.

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. Four contract practices make the difference. First, ask every supplier of a product that uses public-key cryptography for a dated post-quantum roadmap and keep it on file. Second, require that new purchases support algorithm updates by configuration or software release, without hardware replacement, once standards are final. Third, require the vendor to disclose the cryptographic components and libraries in the product, so the agency inventory can be kept current without guesswork. Fourth, tie renewal terms to delivery: a product that misses its stated roadmap should not renew on the same terms.

None of this requires new law. It requires 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.

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.

With hindsight

NIST published its first three post-quantum standards, FIPS 203, 204 and 205, on August 13, 2024, which started the law’s one-year clock for OMB migration guidance. In July 2024 OMB sent Congress the required report, estimating about $7.1 billion between 2025 and 2035 to migrate prioritized civilian systems. It called the figure highly uncertain and said it was driven largely by replacing technology that cannot support the new algorithms, which is the cost category this article argues depends most on vendors and refresh timing. In November 2024 NIST released draft guidance proposing that widely used quantum-vulnerable algorithms be deprecated after 2030 and disallowed after 2035. Browsers, operating systems and large cloud providers rolled out hybrid post-quantum key exchange in 2024 and 2025, so much web traffic gained protection through vendor updates at little direct cost to agencies, while older appliances and custom systems remained the expensive part.

  • post-quantum cryptography
  • OMB
  • federal IT
  • procurement
  • crypto-agility