The Compounding Costs of Delaying PQC Migration

It is easy to assume the cost of post-quantum cryptography migration begins when an organization starts replacing algorithms. In reality, the eventual cost is already being shaped by decisions made today.

Cryptographic dependencies accumulate. Legacy systems age, applications and devices multiply, vendor relationships expand, and unsupported cryptography embeds itself deeper into business processes. When migration eventually begins, an organization inherits a larger and more interconnected estate than the one it postponed.

Delay carries a genuine benefit: standards and products mature, and some implementation costs decline as vendors deliver PQC through normal upgrades. That has to be weighed against a growing legacy estate, a shorter execution window, and less freedom to align migration with refresh cycles. Government guidance increasingly treats this as a multiyear modernization program rather than a cryptographic upgrade: the UK NCSC expects large organizations to need two to three years for discovery, assessment, and planning alone, with priority migrations by 2031 and completion by 2035.

What Might Migration Actually Cost?

There is no authoritative average for a private enterprise. Few organizations have completed estate-wide migrations, cryptographic infrastructure is rarely tracked as its own cost center, and scope varies enormously by architecture.

The most credible public number is federal. OMB estimated that migrating prioritized federal civilian systems would cost roughly $7.1 billion between 2025 and 2035, a figure GAO called a rough order-of-magnitude estimate and one that excludes private industry entirely. It does not transfer to a bank or a manufacturer, but it shows what makes migration expensive: systems that cannot support PQC or hybrid cryptography need replacement, not reconfiguration.

Private estimates are less established. One practitioner model for a hypothetical large enterprise (10,000+ employees, 200+ applications, $100M IT budget) puts the five-to-seven-year cost at $16.3M optimistic, $35.5M expected, and $69.5M conservative, with $3.5M–$7.5M in year one for governance, training, vendor engagement, and discovery. Its ranges imply $750K–$2.2M of initial planning for a midsized organization. The PQFIF framework offers an illustrative global-bank scenario of 47,000 cryptographic assets at $12M, while noting the scenario is conceptual and requires validation.

These are planning scenarios, not validated averages. The conclusion is not that every enterprise should budget $35 million, but that a complex migration can reasonably become a multiyear, eight-figure program in which discovery and planning alone require seven figures. Smaller organizations differ sharply: the NCSC notes that businesses running mostly commodity IT may receive much of their migration through routine vendor updates, though clients and application dependencies remain the customer's responsibility.

Delay Compresses the Work and Removes Options

What delay does not eliminate is the need to understand the environment. A bank with 10,000 applications will still need to determine which use quantum-vulnerable cryptography, which business services depend on them, and which can be upgraded without disruption. NIST's migration project places cryptographic visibility at the beginning for a simple reason: organizations cannot prioritize or migrate cryptography they have not identified.

Starting early does not reduce every line item. It creates options: folding PQC into a planned cloud migration, adding crypto-agility during an already-funded application rewrite, replacing incompatible hardware during a normal refresh, amending vendor requirements at contract renewal, and training teams incrementally rather than competing for scarce specialists. OMB now explicitly directs agencies to use these mechanisms to minimize cost.

Delay removes them. A system that could have been replaced through normal refresh instead needs a dedicated project, a contract that could have absorbed PQC requirements at renewal has to be reopened, and applications that could have migrated sequentially have to be tested concurrently, all competing for the same people and maintenance windows. No reliable evidence supports a fixed annual cost multiplier for delay, but delay demonstrably increases the risk of schedule compression, unplanned replacement, and reduced negotiating leverage. The scope of work is unchanged; the opportunities to sequence it safely are not.

Vendor Readiness and Cryptographic Debt Set the Cost Base

Third-party readiness may determine how quickly an enterprise can move at all. Financial institutions depend on payment processors, core banking platforms, cloud providers, HSMs, certificate authorities, and hundreds of commercial applications, each with its own roadmap. Some will deliver PQC through a normal upgrade; others will require new licenses, appliances, or full replacement. In shared-responsibility environments, a provider may upgrade its endpoint while the customer remains responsible for clients, policy configuration, and regression testing. Early engagement establishes which products have committed roadmaps, whether contracts include upgrade rights, and which reach end of life mid-migration.

Most enterprises also carry cryptographic debt: certificates without clear ownership, hardcoded cryptographic parameters, legacy libraries, embedded devices with long replacement cycles, and redundant PKI, HSM, and secret-management environments. Cost is therefore not determined by how many RSA or ECC keys an organization holds, but by how deeply they are embedded, what depends on them, who controls those systems, and whether the cryptography can be changed through configuration or requires code and hardware changes.

Testing Is a Real Budget Category

Implementing an algorithm is not the same as proving a production system can operate with it. PQC introduces larger keys, signatures, certificates, and handshake messages; OMB notes that ML-DSA signatures are measured in kilobytes and SLH-DSA signatures can reach tens of kilobytes. Those create processing, bandwidth, certificate-chain, and hardware implications that only appear under realistic volumes; large-scale TLS and IPsec testing routinely surfaces constraints invisible in a lab. Organizations that find them late face emergency capacity purchases or replacement projects that were never budgeted.

Budget the First Year to Narrow the Range

The first year does not need to replace every vulnerable algorithm. It needs to produce the information required to estimate and control the wider program. The June 2026 federal approach follows this logic: inventory, assessment, governance, training, and planning precede broader migration.

A credible first year should answer where quantum-vulnerable cryptography exists, which business services and data depend on it, which systems protect information that must stay confidential for years, which vendors control the migration path, which systems can be upgraded through configuration versus code changes or replacement, and what the low, expected, and high program estimates realistically are. Those answers replace an unsupported point estimate with a range tied to measured facts.

Progress in year one is better measured by visibility and adaptability than by algorithms replaced, which is why crypto-agility belongs in the migration plan rather than a follow-on project. A migration that swaps RSA or ECC without improving the organization's ability to change cryptography solves the immediate transition while preserving the conditions that made it expensive.

Organizations do not need perfect knowledge to begin, only enough visibility to identify what they have, understand what depends on it, and align migration with investments they are already planning. Waiting reduces some technical uncertainty. It also leaves less time, less flexibility, and a more expensive set of choices.