Quantum Unfiltered #9 — PQC Migration: What No One Tells You Until You're In It
A field report from inside programs that grew past 120,000 tasks, and the v2.1 release of the open-source framework that maps the way through.
In this edition: On June 9 I spoke at the inaugural Q-Day Summit in Paris and gave a field report from inside the PQC migration programs I've been leading for governments and large enterprises. One of them grew past 120,000 tasks. This edition is the extended version for the people who weren't in the room: why discovery never finishes and no tool sees everything, how to get budget when nobody knows the cost, why the SHA-1 analogy misleads, and why your vendors' roadmaps are your critical path. Alongside it, I'm announcing the biggest update to the PQC Migration Framework since its release: v2.0 and v2.1 ship together, with the Universal Framework and all six sector extensions now on a single aligned baseline, plus the first SOC and GRC implementation guidance any PQC framework has specified. I also cover what your SOC and GRC functions actually need to do about quantum, Let's Encrypt's commitment to Merkle Tree Certificates, the FIPS validation gap that constrains every regulated deployment, and a Flapdoodle on the five vendors who pitched me "mathematically proven unbreakable" cryptography before I finished my coffee. My book Quantum Ready ships in the next few days.
What No One Tells You Until You’re Already in It
On June 9, I spoke at the inaugural Q-Day Summit in Paris, in a room of CISOs, government officials, defense leaders, and cryptographers. Most of the program covered standards, QKD, and sovereignty. My session covered different ground: a field report from inside the PQC migration programs I’ve been leading for governments and large enterprises. 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 already knew. The gap between PQC advice and PQC execution is enormous, and most organizations preparing to start have no idea what they’re walking into. I wrote up the full field report on PostQuantum.com. Here are the points that landed hardest.
The scale is unlike anything most security teams have attempted. Of those 120,000 tasks, fewer than 30,000 were direct cryptographic remediation. The rest, 60 to 85% of the effort, was the enablement system: discovery, governance, vendor management, training, testing infrastructure, and audit evidence. People reach for the SHA-1 to SHA-2 transition as the analogy, but that was a hash swap inside one mathematical family using the same libraries. PQC changes the mathematics, the key sizes (sometimes by 50x), the signature sizes, and the performance of every protocol touching asymmetric cryptography, multiplied across every server, device, OT controller, and container you run.
Discovery never finishes, and no single tool sees everything. Network scanning misses embedded crypto, agent-based discovery is blind to OT and IoT, and external scanning sees less than 10% of your real cryptographic surface. The inventory drifts the moment you build it. The programs I lead run discovery and migration in parallel and treat the cryptographic inventory like vulnerability management: continuous and fed into the SOC. The ones that try to finish discovery first are still building spreadsheets when the deadlines arrive.
On budget, the argument that works has nothing to do with quantum computers. Discovery finds the broken cryptography you already have: SHA-1 in production, weak TLS, expired certificates, 1024-bit RSA. It pays for itself in immediate risk reduction, and the inventory it produces is compliance evidence that NIS2, DORA, and CNSA 2.0 all require. On governance, the lesson is blunt: programs with shared ownership produce PowerPoints, programs with one accountable executive produce results. And your vendors’ roadmaps are your real critical path. IBM’s readiness survey found 62% of organizations expect vendors to handle PQC migration. Ask your top 20 whether they have it on a shipped roadmap with dates; fewer than a quarter will.
The point I most wanted the room to take home: PQC breaks real infrastructure. It works on a vendor’s bench and then fails in production, where ML-KEM-768 key shares run 38x larger than X25519 and ML-DSA-65 signatures run 51x larger than ECDSA. Firewalls drop oversized ClientHello messages, middleboxes break on larger extension fields, and OT devices on 8- or 16-bit microcontrollers simply cannot run the algorithms. When those devices control power grids or hospital equipment, a failed migration carries physical consequences. You cannot spreadsheet your way through this, and most organizations will discover it for the first time in the next two to three years. I would rather they hear it now.
PQC Migration Framework v2.1 Released — Now With SOC, GRC, and All Six Sector Extensions
Everything I covered in Paris, and considerably more, is in the Applied Quantum PQC Migration Framework, which is open-source and free under CC BY 4.0. I just completed its biggest update since release, shipping v2.0 and then v2.1 within the same month. For the first time, the Universal Framework and all six sector extensions sit on a single aligned baseline.
Three structural changes drove the major version. Migration sequencing is now explicitly two-track: Track A (key exchange, driven by HNDL) can deploy hybrid today, while Track B (signatures and PKI, driven by TNFL) depends on PKI architecture decisions and FIPS validation that remain unresolved. Treating them as one sequence causes organizations to under-invest in whichever track isn’t their starting point. The PKI model has forked, with Merkle Tree Certificates for public Web PKI and X.509-with-PQC for internal enterprise PKI. And a four-tier deployment environment classification (unrestricted, FIPS-aware, FIPS-required, CNSA 2.0) determines when each system can actually enter production.
v2.1 then takes positions inside those structures. It adds explicit guidance on hybrid and composite signatures, algorithm-specific vulnerability weighting in risk scoring (ECC is not a safe harbor: estates heavy in elliptic curve cryptography score differently than RSA-era assumptions suggest), a full SOC and GRC implementation specification, and a program closure methodology covering migration verification and the evidence dossier. A migration you cannot prove is a claim, not a control. The sector extensions for government and defense, critical infrastructure, telecommunications, financial services, payments, and digital assets each gained sector-specific positions. I also updated the Getting Started with Quantum Security guide and the Quantum Security Reference.
The Part No One Specifies: What Your SOC and GRC Actually Do About Quantum
Most CISOs I talk to ask “what should my SOC be doing about quantum?” and get vague answers. No published PQC migration framework specified SOC detection capabilities or quantum-specific incident response before this year, which is exactly why v2.1 adds them. So let me be specific, because this is the operational gap that turns a migration into a liability.
Your SOC needs cryptographic detection capabilities that don’t exist in any standard playbook today. Hybrid downgrade detection: alert when a connection that should be hybrid negotiates classical-only, which is the PQC equivalent of SSL stripping. Cryptographic drift monitoring: flag systems that revert to classical crypto through configuration changes or vendor updates. And it needs four incident response playbooks that no SOC currently has: PQC algorithm vulnerability disclosure, confirmed hybrid downgrade attack, credible CRQC capability announcement, and emergency algorithm rotation. All of this must be operational before your first production PQC deployment. Deploying PQC without the ability to detect attacks against it is flying blind. I detailed the five detection use cases and the three-horizon threat intelligence model separately, because the SOC’s role in this transition has gone almost entirely unexamined.
On the GRC side, your board will ask for quantum readiness metrics your team cannot yet produce. The instrument that works is a three-tier KRI structure: board-level quarterly risk posture, CISO-level monthly migration progress, and operational real-time drift detection. You also need a quantum risk appetite statement with explicit tolerances for HNDL exposure, TNFL exposure, and regulatory compliance buffer, the same discipline you apply to any other material risk. Build audit evidence from day one: retrofitting two years of undocumented decisions into an audit trail takes ten times the work and produces ten times less credible documentation.
Let’s Encrypt Commits to Merkle Tree Certificates
Let’s Encrypt, the nonprofit CA that secures over 700 million websites and issues 54% of all public TLS certificates, committed to Merkle Tree Certificates as its path to post-quantum web authentication. Staging in late 2026, production in 2027.
This is the commitment that makes MTCs viable for the majority of the encrypted web. The reason the architecture exists is the PQC signature size problem from the field report above: ML-DSA-65 signatures run about 3,300 bytes against 64 for ECDSA, and a PQC X.509 certificate chain can exceed 10KB of handshake overhead. MTCs batch certificates into a Merkle tree and amortize a single post-quantum signature across thousands of them, dropping authentication overhead to as little as 736 bytes. Post-quantum HTTPS could end up smaller than today’s classical chains.
The practical guidance: public-facing web PKI is heading toward MTCs, while internal enterprise PKI stays on X.509 with PQC algorithms. Invest in certificate lifecycle automation now. You need it for the CA/Browser Forum’s 47-day certificate lifetimes by March 2029 regardless of PQC, and it’s the same infrastructure that makes MTC adoption manageable.
The FIPS Gap That Constrains Every Regulated Deployment
Here’s a constraint that almost no PQC coverage mentions and that determines the deployment timeline for every regulated organization: as of June 2026, no cryptographic module has achieved FIPS 140-3 validation with PQC algorithm support. Multiple vendors are in the CMVP queue, but the process averages 18+ months. The earliest realistic validated PQC software modules arrive mid-2027. HSM modules will lag further.
This collides with CNSA 2.0‘s January 2027 procurement gate. National security systems must support quantum-resistant algorithms in new acquisitions from that date, using modules that won’t be validated until after it passes. Meanwhile FIPS 140-2 certificates move to the Historical list on September 21, 2026, forcing a parallel transition to FIPS 140-3 even before PQC validation exists. For unrestricted environments, none of this applies and you can deploy hybrid TLS today. For FIPS-required environments, plan pilots and staging now and target production after validation. The gap is the binding constraint, not your technical readiness, which is exactly why the framework’s deployment environment classification exists.
Coming Soon: Quantum Ready
My book Quantum Ready ships in the next few days, and it’s the book-length companion to everything above. Where the framework gives you the 8-phase methodology, the book gives you the reasoning behind each phase, extended case examples, and guidance for leading the program from the first board conversation through closure: executive mandate, budget strategy, discovery, CBOM architecture, hybrid deployment, vendor governance, testing, and building crypto-agility as a permanent capability rather than a one-time project. If the field report in this edition described problems you recognize, the book is the structured way through them. Sign up at quantumready.com to be notified at launch.
Quantum Flapdoodle: “Mathematically Proven Unbreakable Cryptography”
Five PQC companies pitched me partnership deals in a single morning recently. Four of the five promised some version of the same thing: mathematically proven unbreakable cryptography. I’ve spent three decades around cryptography and the phrase still stops me, because no such thing exists.
Every one of these pitches was for a proprietary algorithm with no NIST standardization and no national-agency approval. The history here is a graveyard. Proprietary cryptography that vendors swore was unbreakable has been broken, repeatedly, often within months of someone competent looking at it. The whole point of the NIST process was to subject candidate algorithms to years of public cryptanalysis by the global research community, which is the only thing that earns confidence in a cryptographic primitive. A vendor’s private assurance is worth nothing against that standard.
There’s a one-afternoon verification test. Ask the vendor: is your algorithm NIST-standardized or approved by a national cryptographic authority? Is the specification public? Has it survived independent peer review? If the answers are no, no, and no, you’re looking at the same con that produced every broken proprietary cipher in the historical record, just wearing post-quantum vocabulary. The connection to my field report above is direct: the “comprehensive quantum vulnerability assessment” built on external scanning alone and the “mathematically proven unbreakable” algorithm are the same thing, confidence that hasn’t been earned.
If you found this edition useful, forward it to a colleague who’s about to start a PQC program and doesn’t yet know what they’re walking into. If I got something wrong, hit reply. I read everything and correct publicly. The full PostQuantum.com resource library is at postquantum.com, and the open-source migration framework is at pqcframework.com.
— Marin