PQC Migration – What No One Tells You Until You’re Already in It

On June 9, I spoke at the inaugural Q-Day Summit in Paris. Laurent Leloup and the team at Qadastra assembled a room of CISOs, government officials, defense leaders, cryptographers, and practitioners, all focused on the operational realities of the quantum transition. The DGA opened the event. The French Defense Innovation Agency participated. The program covered everything from PQC standards to quantum key distribution to sovereignty.

My session covered different ground. I gave a field report from the inside of PQC migration programs I’ve been leading for governments and large enterprises over the past several years. One of those programs grew past 120,000 tasks in its integrated master schedule. It was not the only one.

The response in the room confirmed what I knew: the gap between PQC advice and PQC execution is enormous, and most organizations preparing to start their programs have no idea what they’re walking into. This article is the extended version of that session for the people who were not in the room.

Q-Day Is Irrelevant. The Deadlines Are Already Set.

I opened with a line designed to provoke a room called “Q-Day Summit.” The exact arrival date of a cryptographically relevant quantum computer (CRQC) is, for practical purposes, beside the point. Whether Q-Day lands in 2030 or 2040, your organization’s migration timeline is no longer set by quantum physics. Regulators, vendors, insurers, and clients have taken the decision out of your hands.

I counted 14 hard or semi-hard PQC deadlines across 10 jurisdictions arriving in the next 48 months. CNSA 2.0’s procurement gate hits in January 2027: after that date, any new system acquired for US national security must support quantum-resistant algorithms. The EU is writing PQC requirements into NIS2 law. Australia’s ASD has issued one of the most aggressive timelines anywhere: stop using all classical asymmetric cryptography by end of 2030. India is opening a CII migration window in 2027-2029. A draft US executive order would require federal agencies to migrate key establishment by December 2030 and signatures by December 2031.

The pattern is clear. These deadlines are compressing, not relaxing. And the enterprise estimate for a full PQC migration is 12 to 15+ years. That gap between the time available and the time required is the defining tension of PQC in 2026. Debating when a CRQC will arrive is a distraction from the work that needs to start now.

The Largest IT/OT/Cyber Transformation You Have Attempted

I showed the audience a number: 120,000 tasks in a single program’s integrated master schedule. Fewer than 30,000 of those tasks were direct cryptographic remediation: actually touching keys, certificates, algorithms, and protocols. The rest (roughly 60-85% of the total effort) was the enablement system: cryptographic discovery and inventory, governance and reporting, vendor lifecycle management, workforce training, testing infrastructure, hybrid operations, and the metrics and audit evidence required to prove you’re actually migrating.

The SHA-1 to SHA-2 transition is the closest analogy most people reach for, but it misleads more than it helps. SHA-2 was a hash function swap inside the same mathematical family, using the same libraries, with the same key management infrastructure. PQC changes the fundamental mathematics, the key sizes (sometimes by 50x), the signature sizes, the handshake behavior, and the performance characteristics of every protocol that touches asymmetric cryptography. That means TLS, SSH, IPsec, S/MIME, code signing, certificate authorities, HSMs, IoT device attestation, payments, and dozens more.

Every system in your organization runs cryptography at every layer. From the hardware root of trust (TPM, Secure Enclave, HSM) through firmware signing and secure boot, through the operating system’s TLS libraries and certificate stores, through network protocols, through application-layer encryption and authentication, up to identity infrastructure and data-at-rest protection. Now multiply that stack by every server, workstation, mobile device, IoT sensor, OT controller, cloud instance, and container in your organization. That is the migration surface. That is why one program generated 120,000 tasks and it was not the only one.

Discovery Never Finishes, and No Tool Sees Everything

Three realities confront any organization starting cryptographic discovery.

First, most organizations do not have a comprehensive, current IT asset inventory. The ones that have tried to build one know it costs millions and takes years. Expecting to achieve a complete cryptographic inventory before starting migration means expecting to solve a harder problem than the one you have already failed to solve.

Second, no single discovery tool sees all cryptography. I walked the audience through five modalities and what each one misses. Network scanning catches TLS handshakes but misses embedded crypto and encrypted payloads. Code scanning catches library calls but misses runtime configuration. Agent-based discovery covers managed IT but is blind to OT, IoT, and third-party managed infrastructure. External scanning sees your perimeter, which is less than 10% of your total cryptographic surface. Vendor attestation depends entirely on the vendor’s honesty and completeness.

Services now market “comprehensive quantum vulnerability assessments” based on external scanning alone. They scan your public TLS endpoints, generate a report, and deliver it to your board. That report covers a fraction of your actual exposure. The confidence it produces is unearned.

Third, the inventory drifts the moment you finish building it. A container scales up with pinned cipher suites in seconds. A CI/CD pipeline deploys code with a different crypto library in minutes. A vendor firmware update changes embedded crypto overnight. A new SaaS integration negotiates its own TLS on day one. Point-in-time inventories capture a snapshot that is already decaying.

The practical answer is to treat cryptographic inventory the way you treat vulnerability management: continuous, automated, and fed into the SOC as a detection use case. And run discovery and migration in parallel rather than in sequence. Prioritize before you scan: external-facing systems first, then critical internal infrastructure, then business applications, then OT and IoT, then the long tail. Start mitigating the first tier while you’re still scanning the second. The programs I lead all work this way. Nobody finishes discovery before starting migration. The ones that try are the ones still building spreadsheets when the 2030 deadlines arrive.

How to Get Budget When Nobody Knows the Cost

Every CISO starting a PQC program hits the same wall: the CFO asks “what will this cost?” and nobody can answer. Cryptographic infrastructure has never been a separate budget line in any organization. It sits inside development, infrastructure, and vendor contracts with no line item labeled “cryptography.”

The answer that works: “I can tell you what phase one costs and what it delivers. I need that phase to give you a credible total.” Phase one (governance setup, initial vendor engagement, and cryptographic discovery) has estimable costs, bounded scope, and a defined deliverable. Use the three-scenario model for subsequent phases: low, central, and high estimates, with the range narrowing as discovery produces measured data.

The most powerful budget argument is one that has nothing to do with quantum computers. Discovery finds your existing broken cryptography. Every organization I have worked with has uncovered SHA-1 still in production, weak TLS configurations, expired certificates, and 1024-bit RSA keys during PQC discovery. The discovery phase pays for itself in immediate risk reduction before a single quantum-related change is made. Frame it to the CFO as a security cleanup that should have been done years ago, and simultaneously produces the data needed to plan the quantum migration.

The first cryptographic inventory your organization builds is also an asset with value far beyond PQC. NIS2, DORA, and CNSA 2.0 all require evidence of cryptographic risk management. Every auditor will ask for this inventory. You do not have one. Building it is compliance evidence with immediate value.

80-90% of the total program cost comes in years 4-8, the implementation wave. The early phases are modest investments that de-risk the larger spend. Present the spending profile that way to the CFO.

Governance: One Owner, One Mandate, One Budget

I watched two financial services organizations delay their PQC programs by six months this year. Budget was allocated. Technical readiness was there. What killed them: months of committee discussion that produced nothing except a later start date.

Cryptography sits across security, IT, engineering, procurement, and OT. Every team touches it. No single team is accountable. When you ask “who owns PQC?” and three people look at each other, you have your answer.

The governance model that works has three components, and I’ve seen this pattern hold across every large transformation I’ve led. A single accountable executive (typically the CISO, with board-level mandate, dedicated budget, and cross-functional authority). A steering committee that clears blockers but does not own the program. And a dedicated program office with full-time staff. Programs with shared ownership produce PowerPoints. Programs with a single accountable executive produce results. I’ve written about PQC governance in detail, including the organizational dynamics that delay programs and how to break through them.

Crypto-Agility Is a Program, Not a Feature

Every framework says “build crypto-agility.” Almost nobody explains what that means in practice. Crypto-agility is an architecture problem, but it is more than an architecture problem. It is also processes, skills, tooling, and vendor contracts. It needs its own budget and governance. Treating it as a side-task of the PQC migration guarantees that it dies when the migration “finishes.”

The reason crypto-agility must be treated as a permanent capability is that the PQC migration is not the last migration. NIST is already evaluating additional signature schemes. Daniel Bernstein’s June 2026 paper demonstrated ML-DSA key recovery in under one second, proving that PQC implementation vulnerabilities are real and will require rapid algorithm rotation. Sovereignty fragmentation means different jurisdictions require different algorithm combinations. And hybrid deployment (classical + PQC together) is a transitional state: every organization deploying hybrid today will eventually migrate again from hybrid to PQC-only.

Five pillars make crypto-agility operational. Architecture: abstract cryptographic choices behind configuration rather than code. Processes: documented algorithm rotation procedures, tested before you need them. Skills: a team that can evaluate and deploy new algorithms, hired and trained now, not under emergency conditions. Vendor contracts: crypto-agility as a procurement requirement on every new system and every contract renewal. Tooling: continuous monitoring for cryptographic drift. If you fund crypto-agility as a line item inside the PQC migration and cancel the budget when the migration ends, you have bought yourself one transition. If you fund it as a permanent capability, you have bought every transition after that. Rethinking Crypto-Agility covers the practical implementation in depth.

Hybrid Deployment: The Debate Is Settled, but Budget for the Overhead

Bernstein’s paper settled the hybrid question. His quantitative estimate: the near-term risk from our own PQC implementation software exceeds the near-term risk from quantum computers by three orders of magnitude. Solo ML-DSA deployment produces an order of magnitude more breakable signature keys over the next five years compared to hybrid ECC+ML-DSA. Deploy hybrid. Retain classical cryptography as a safety net. This is non-negotiable.

But hybrid is not free, and this is what most guidance leaves out. Sovereignty fragmentation means Germany mandates hybrid (BSI TR-02102-1), Australia discourages it (ASD ISM specifies pure ML-KEM-1024), and the US allows it transitionally (CNSA 2.0). An engineer writing a TLS configuration in 2026 faces contradictory requirements depending on which government she is configuring for. Your crypto-agility architecture had better support per-jurisdiction configurations, because one global setting will not satisfy Germany and Australia simultaneously.

Your counterparties may not support hybrid yet. Your SOC needs new detection rules for downgrade attacks (forcing a connection back to classical-only, the PQC equivalent of SSL stripping). Your testing matrix triples: classical-only fallback, PQC-only, and hybrid combination. And hybrid is a transitional state: CNSA 2.0 sets exclusive PQC use for networking by 2030 and software by 2033. Declaring victory at hybrid and disbanding the program means reassembling it in three years for the next transition.

Budget hybrid as a permanent operating mode, not a transitional workaround.

PQC Breaks Real Infrastructure. Test Everything.

PQC algorithms work in the lab. Every vendor will demonstrate a clean handshake on a bench. The question is what happens when those much-larger keys and signatures hit your actual production infrastructure.

An ML-KEM-768 key share is 1,216 bytes compared to 32 bytes for X25519 (38x larger). An ML-DSA-65 signature is 3,293 bytes compared to 64 bytes for ECDSA (51x larger). A certificate chain with ML-DSA can exceed 10KB. Firewalls with fixed buffer sizes drop oversized ClientHello messages. Middleboxes that parse TLS headers break on larger extension fields. QUIC initial packets exceed UDP MTU limits. Load balancers, WAFs, and IDS/IPS systems encounter packet structures they were not designed for. Google’s Chrome team and Cloudflare both found extensive breakage during real-world PQC testing.

OT and IoT compound the problem. Equipment on 10-to-20-year lifecycles running 8/16-bit microcontrollers cannot execute the new algorithms. LoRaWAN in the EU allows 51 bytes per uplink payload; ML-KEM-768 ciphertext alone is 1,184 bytes. Some devices physically cannot run PQC. When these devices control power grids, water treatment, or hospital equipment, the consequences of a failed migration are physical, not digital.

You cannot spreadsheet your way through this. You need staging environments that mirror your production network topology, including every middlebox, firewall, and load balancer in the path. You need OT/IoT hardware testbeds with real devices running real protocols. You need performance testing under production-scale load. This testing infrastructure is a distinct, significant budget item that gets missed in every program estimate I’ve reviewed. For critical systems, deploying untested PQC is unacceptable risk.

Your Vendors’ PQC Roadmap Is Your Critical Path

62% of organizations in IBM’s quantum readiness survey expect their vendors to handle PQC migration. That belief will age poorly.

Ask your top 20 vendors whether they have PQC on a shipped product roadmap. Not a blog post about quantum awareness. A product roadmap with dates. In my experience, fewer than a quarter will have one. Your regulatory deadline may be 2027-2030. Your vendor’s product cycle may not align. And over a 7-to-10-year program, vendors will be acquired, merged, or discontinued. The vendor you depend on in year 2 may not exist in year 7.

The fix is engagement, not confrontation. Start the conversation with every critical vendor today. Ask for their PQC roadmap, supported algorithms, hybrid support plans, and estimated timeline. Most vendors have not been asked yet. Being the customer who asks first shapes the relationship. Review every contract at renewal for crypto-agility clauses, PQC support timelines, and escrow or source access provisions. Track vendor readiness formally as a recurring KRI that the steering committee sees quarterly. And for critical systems where a vendor has no PQC plan, no roadmap, and no timeline: start evaluating alternatives now. Vendor replacement for critical systems takes 2-3 years. If you wait until year 5 to discover your vendor cannot deliver, you have added 2-3 years to a program that was already running late.

SOC and GRC Integration Are Not Post-Migration Checkboxes

Most CISOs I talk to ask “what should my SOC be doing about quantum?” and get vague answers. Let me be specific.

Your SOC needs hybrid downgrade detection rules: alert when a connection that should be hybrid negotiates classical-only. It needs cryptographic drift monitoring: flag systems that revert to classical crypto through configuration changes or updates. It needs four incident response playbooks: algorithm vulnerability disclosure, confirmed hybrid downgrade attack, credible CRQC capability announcement, and emergency algorithm rotation. And it needs SOC analyst training on PQC protocol behavior and new alert patterns. All of this must be operational before your first production PQC deployment, not after. Deploying PQC into production without the ability to detect attacks against it is flying blind.

On the GRC side, your board will ask for quantum readiness metrics and your team cannot produce them yet. Build three-tier KRIs: board-level quarterly risk posture, CISO-level monthly migration progress, and operational real-time drift detection. Stand up regulatory intelligence as a dedicated function tracking PQC developments across every jurisdiction you operate in. Add PQC to your vendor risk assessments as a recurring item. And build audit evidence from day one. NIS2, DORA, and CNSA 2.0 all require proof of quantum preparedness. Retrofitting two years of undocumented decisions into an audit trail takes ten times the work and produces ten times less credible documentation.

Sector-Specific Challenges

The universal challenges I’ve described are compounded by sector-specific constraints. In the talk, I covered a selection of these drawn from the sector extensions of the PQC Migration Framework.

In OT and critical infrastructure: industrial protocols like Modbus and DNP3 have minimal or no cryptographic capability to upgrade. Safety Instrumented Systems certified under IEC 61511 require 12-18 months of re-certification for any cryptographic change. Offshore platforms, underground mines, and nuclear facilities may be physically inaccessible for hardware upgrades. For defense: classified system re-accreditation under the Risk Management Framework can take 12-24 months per system, and the accreditation pipeline becomes a bottleneck when hundreds of systems need re-authorization simultaneously. Coalition allies operating under NATO interoperability requirements may adopt different PQC algorithms on different timelines. Satellite and space systems cannot be physically updated after launch.

In financial services: a single cross-border payment triggers over 30,000 cryptographic function calls across 9+ independent parties. No single entity controls the chain. Payment HSMs under FIPS/PCI PIN certification operate on 10-15-year lifecycles with re-certification windows of 6-18 months. Post-trade infrastructure (custodians, CCPs, CSDs) depends on independently authenticated messaging chains where no single institution can migrate alone. Insurance carriers face policy terms of 20-30+ years, making actuarial data and long-tail claims records prime HNDL targets. And in digital assets, every blockchain transaction that spends from an address exposes the public key permanently on-chain, making existing addresses retroactively vulnerable.

Start Now. The Framework Is Open-Source.

I closed the talk with a line from the session abstract: most organizations will encounter these challenges for the first time in the next two to three years. I would rather they hear about them now.

Everything I covered in Paris, and considerably more, is detailed in the Applied Quantum PQC Migration Framework, which is open-source and free under CC BY 4.0. The framework covers the full 8-phase migration lifecycle with sector-specific extensions for financial services, payments, telecommunications, OT and critical national infrastructure, government and defense, and digital assets. Version 2.0 was released in June 2026.

For practitioners and organizational leaders who want a structured, book-length treatment of the methodology, Quantum Ready covers the full playbook: from executive mandate and budget strategy through cryptographic discovery, CBOM architecture, hybrid deployment, vendor governance, testing, and building crypto-agility as a permanent capability.

The organizations doing this work now are the ones who will not be doing it under emergency conditions when the 2030 deadlines arrive. Start while it is a program, before it becomes a crisis.