The Post-Quantum Invoice: Why the Real AI-Era Infrastructure Story Is a Cryptography Migration
Five documented standards milestones expose a harder problem than building the quantum computer: replacing the encryption that protects data with a twenty-year shelf life.
Replacing the encryption under a running enterprise is less like swapping an engine and more like replacing the plumbing in an occupied building, floor by floor, while the tenants keep showering. The pipe specification was settled years ago. The bill comes from the walls nobody opened. While capital markets price quantum computing as a race to a working machine, the constraint that will actually move procurement budgets is the inventory of systems that cannot be patched, the vendors who will not commit to a date, and the data already sitting in an adversary's storage array.
Five Signals, Not Five Headlines
- 13 Aug 2024 — NIST finalizes FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), converting post-quantum key establishment and signatures from research candidates into federal procurement requirements.
- Sep 2024 — NIST IR 8547 warns that migration may run 10–20 years and names "harvest now, decrypt later" as a present-tense exposure.
- 11 Mar 2025 — NIST selects HQC as a fourth standardized key-establishment algorithm, explicitly targeting memory-constrained hardware where lattice-based ML-KEM is a poor fit.
- CNSA 2.0 — NSA's schedule puts vendors on a 2030 clock, national security systems on 2033, and full transition on 2035, making cryptographic provenance a contract term rather than a research roadmap.
- Production deployment — Cloudflare shipped hybrid X25519MLKEM768 key agreement, proving that migration can begin before the threat arrives by retaining a classical fallback.
The Deadline Has Moved Inside the Enterprise
Post-quantum cryptography has crossed from standards drafting into enforced procurement, with federal timelines now binding vendor roadmaps and hybrid handshakes already carrying production traffic. The resulting exposure is not a broken algorithm; it is an uninventoryed estate of embedded controllers, long-lived certificates and sealed firmware that cannot absorb a new key format.
The Asset Inventory Is the Attack Surface
Three consequences sit outside the coverage loop. First, migration cost is dominated by discovery, not mathematics. Evidence point one: NIST IR 8547 places the transition window at 10–20 years, explicitly because organizations must locate and replace cryptographic dependencies embedded in life-support, industrial control and payment hardware with decades-long service lives. A hospital's infusion controller and a utility's substation relay do not receive a TLS library upgrade on a quarterly cadence. The durable competitive advantage therefore belongs to whoever maintains a cryptographic bill of materials, not whoever can demo ML-KEM on a development board.
Second, the physics of the handshake has commercial consequences. ML-KEM-768 carries a 1,184-byte encapsulation key against 32 bytes for X25519; ML-DSA-65 signatures run into kilobytes. On a fiber backbone that is noise. On a satellite backhaul, a low-power mesh link or a TLS session renegotiating inside a mobile application, it is a measurable latency and battery tax. Teams that benchmark hybrid key agreement only inside a region will ship a system that works in staging and degrades in the field. Certificate transparency logs, hardware security modules with fixed key-slot sizes and legacy VPN appliances all inherit the same constraint.
Third, confidentiality horizons now determine migration order. Evidence point two: the same NIST guidance frames retrospective decryption as an active collection strategy. Genomic records, defense procurement files and litigation discovery retain sensitivity for thirty years; a marketing cache does not. Capital allocated uniformly across an estate is capital wasted. The defensible sequence is to rank data by residual confidentiality life, then work backward to the systems that hold it, rather than upgrading the perimeter because it is easy to see.
The Case Against Panic Buying
The alarmist reading — that every RSA and elliptic-curve key must be replaced this quarter — does not survive scrutiny. Cryptanalytically relevant quantum computers remain undemonstrated at the scale and error rates required for factoring or discrete logarithms at 2,048 bits, and estimates of their arrival span a decade or more. Short-lived, low-sensitivity traffic can tolerate a measured transition. Premature wholesale replacement burns engineering capacity that would be better spent on inventory and key agility, and a hastily deployed, poorly validated implementation can introduce exploitable failure modes that the classical system did not have. The rational response is risk-ordered migration, not a fire sale of quantum-safe appliances.
What Y2K and SHA-1 Actually Teach
The closest precedent is the Y2K remediation program, followed by the SHA-1 to SHA-256 TLS migration. In both cases the cryptographic or logical fix was comparatively small; the cost sat in discovering embedded instances, negotiating with third parties and coordinating cutover across an ecosystem no single actor controlled. Y2K succeeded because governments imposed a dated deadline and funded inventory work. SHA-1 took years because browsers, certificate authorities and server vendors had to move in sequence. Evidence point three: NSA's CNSA 2.0 schedule — 2030 for vendor support, 2033 for national security systems, 2035 for completion — is an explicit attempt to reproduce the Y2K coordination mechanism. Deadlines work. Algorithms alone do not.
Agility Is Not a Firmware Patch
The equally seductive counter-position is that algorithm agility makes this a configuration exercise: abstract the crypto layer, swap the primitive, ship. In practice, agility has to be designed into key storage layouts, certificate chains, attestation roots and secure elements before it can be exercised. A sealed device with a fixed ROM bootloader and a hardcoded root of trust is not agile, regardless of the abstraction in the application. Some estates will require replacement, and some vendors will sell "PQC-ready" labels against software they have not validated. Procurement must demand evidence of a tested second algorithm, not a marketing claim of flexibility.
What to Do Before the Next Budget Cycle
- Build the cryptographic inventory. Enumerate TLS endpoints, signed firmware, VPN tunnels, code-signing roots and long-term archives. Assign each a confidentiality horizon and an owner.
- Write the obligation into the contract. Require FIPS 203 support dates, a second-algorithm fallback, SBOMs and a firmware update commitment with a named end-of-life. Reject open-ended "future-proof" language.
- Test the constrained path. Benchmark hybrid handshakes on your worst link, not your best one. Validate HSM capacity, certificate sizes and session-resumption behavior.
- Protect the long-lived payload first. Re-encrypt archives and classified or clinical records under a hybrid or post-quantum scheme; accept slower migration for ephemeral traffic.
- Citizens: keep browsers and operating systems current so hybrid key agreement is negotiated, and assume that anything uploaded today may be decrypted a decade from now.
Six Months Out: A Procurement Split
By April 2027, expect Request for Proposal language to name FIPS 203 explicitly, a first wave of latency complaints from satellite and IoT deployments running hybrid handshakes, and consolidation among key-management vendors that can actually demonstrate agility. Expect also the first widely acknowledged embedded fleet that cannot make the 2033 date and must be physically replaced. The winners will not be the firms with the loudest quantum announcements. They will be the ones that knew, in advance, where every key lived.