Seven Deployment-Reality Challenges and Three Operational Gaps No Framework Addressed — and How the Applied Quantum PQC Migration Framework v2.0 Responds
Update to: Post-Quantum Cryptography Migration Frameworks: A Definitive Survey Through March 2026
Update: since this survey update was published, the framework has advanced to v2.1 (June 2026), which adds new positions and sections and brings all six sector extensions onto the same baseline. The v2.0 references below describe that release as published and remain accurate. See What’s New in v2.1.
In March 2026, I published a comprehensive survey of every PQC migration framework published through that date. Three months later, the landscape looks different — not because the framework count has grown dramatically, but because the nature of the problem has shifted. The PQC migration conversation moved from “how do we prepare?” to “how do we deploy?” — and that shift exposed gaps that no existing framework, including my own v1.1, adequately addressed.
This companion survey covers everything published between March and June 2026, assesses whether any new framework addresses the deployment-reality challenges that have emerged, and documents how The Applied Quantum PQC Migration Framework v2.0 responds to them.
Three developments between March and June 2026 altered the PQC migration planning landscape:
Google set a 2029 completion target. On March 25, 2026, Heather Adkins (VP, Security Engineering) and Sophie Schmieg (Senior Staff Cryptography Engineer) announced that Google is targeting 2029 to complete its PQC migration across Chrome, Android, Google Cloud, and internal infrastructure. Not 2035. Not 2030. 2029 — six years ahead of NIST’s disallowance deadline. Microsoft’s Quantum Safe Program targets 2033. When the company that operates the world’s most widely used browser and one of the two dominant mobile operating systems sets an explicit completion target, it becomes a de facto ecosystem constraint for everyone else.
Let’s Encrypt committed to Merkle Tree Certificates. On June 3, 2026, Let’s Encrypt announced that MTCs will be its path to post-quantum Web PKI, targeting a staging environment by late 2026 and production readiness in 2027. Let’s Encrypt issues a dominant share of public TLS certificates (web technology surveys indicate it serves as the certificate authority for over 60% of websites with known CAs). When combined with Google Chrome’s stated preference for MTCs and Cloudflare’s parallel testing, this means public Web PKI is heading toward a fundamentally different architecture for post-quantum authentication. Organizations that planned their PKI migration as a straightforward algorithm swap now need to plan for two parallel architectures.
The FIPS validation gap became a hard constraint. As of June 2026, no FIPS 140-3 validated cryptographic module offers PQC algorithms in approved mode. SafeLogic submitted CryptoComply 140-3 with PQC to CMVP on May 19, 2026, with validation expected before end of 2026. FIPS 140-2 certificates move to the Historical list in September 2026. For regulated organizations — which includes most of my framework’s target audience — this creates a deployment sequencing constraint that no framework had addressed.
These three developments are why v2.0 of the Applied Quantum PQC Migration Framework is a major version, not a point release. The 8-phase architecture is unchanged, but the planning model beneath it has been restructured to address deployment realities that did not exist when v1.1 was published.
Meta, “Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways” (April 16, 2026). Authors: Rafael Misoczki, Isaac Elbaz, Forrest Mertens. The most substantive new publication in the quarter. Meta introduces a five-level “PQC Migration Levels” maturity model (PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled) and a six-step migration strategy (prioritize risks, build inventory, address external dependencies, build PQC components, establish guardrails, deploy). Meta reports reaching PQ-Enabled for portions of its internal traffic using hybrid ML-KEM-768 + X25519.
Meta’s playbook is valuable for two reasons. First, it comes from an organization that has actually deployed PQC at scale — this is not theoretical guidance. Second, the five-level maturity model is clean and actionable: it acknowledges that most organizations will sit at PQ-Hardened (deployed all currently available protections but unable to fully eliminate threats due to missing industry primitives) for an extended period.
Where Meta’s framework differs from a universal enterprise methodology: it is an internal engineering playbook for a hyperscaler with centralized infrastructure. It does not address Phase 0 (executive mandate / budget), PMO governance, vendor supply-chain management as a dedicated function, sector-specific adaptations, board reporting, or multi-year program management for organizations that do not control both endpoints. Meta’s six steps map roughly to Phases 1, 3, 5, and 7 of my framework — with no equivalent to Phase 0, no formal CBOM architecture (Phase 2 — Meta builds an inventory but not the layered CBOM structure), no roadmap governance (Phase 4), or infrastructure modernization as a distinct concern (Phase 6).
Meta’s playbook addresses one of the seven v2.0 challenges: it implicitly separates confidentiality (hybrid key exchange) from authentication (signature migration), noting that “there are important parts of the industry that are not yet available” for signature migration — a partial alignment with the two-track model.
IACR ePrint 2026/790, “Towards a Field-Informed Risk-Based Framework for PQC Migration in Legacy Systems” (April 2026). Authors: Chammas, Hariss, Bassil, Chamoun. A three-layer risk-based framework focused on legacy and constrained environments: diagnostic characterization, risk scoring, and transition guidance. Addresses a genuine gap — PQC migration for systems that cannot be easily upgraded — but is a risk-assessment model for a specific environment class, not a full-lifecycle methodology.
SSRN, “Towards a Defensible Framework for Post-quantum Cryptography Cost Estimation” (May 5, 2026). Author: Tim D. Williams. A 14-basis cost estimation framework organized into four methodological classes (Parametric, Theoretical, Analogical, Judgemental). This is the most directly relevant academic publication to the v2.0 cost estimation methodology. Williams provides a rigorous taxonomy of cost drivers that any organization building a PQC budget case should reference.
Google — 2029 PQC migration completion target (March 25, 2026); ML-DSA integration in Android 17 beta; Chrome Quantum-resistant Root Store planned for Q3 2027.
Let’s Encrypt — Merkle Tree Certificates as the path to post-quantum Web PKI (June 3, 2026); staging environment late 2026, production 2027.
Microsoft — Quantum Safe Program targeting completion by 2033; PQC APIs GA in Windows Server 2025, Windows 11, .NET 10 via SymCrypt.
SafeLogic — CryptoComply 140-3 FIPS Provider with PQC submitted to CMVP (May 19, 2026); the first publicly announced PQC-capable module to enter the FIPS 140-3 validation queue.
NIST — Additional Digital Signatures: nine candidates advanced to the third round (May 13, 2026): FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV. Evaluation expected to take approximately two years. Not for production planning, but direct evidence of why crypto-agility must be a program requirement.
CISA — “Product Categories for Technologies That Use Post-Quantum Cryptography Standards” (January 23, 2026; updated periodically). Notably distinguishes products that are PQC-capable for key establishment versus digital signatures — an implicit acknowledgment of the signature gap.
IETF PLANTS Working Group — Merkle Tree Certificates drafts (draft-ietf-plants-merkle-tree-certs-00 through -04, February–May 2026). Active standardization of the certificate architecture that Google, Cloudflare, and Let’s Encrypt have committed to implementing.
CA/Browser Forum Ballot SC-081v3 — Certificate lifetime reduction trajectory: 200 days (15 March 2026), 100 days (15 March 2027), 47 days (15 March 2029). This is not PQC-specific, but it intersects directly with PQC PKI planning: organizations that invest in certificate lifecycle automation now are simultaneously building the infrastructure they need for both the MTC transition and PQC PKI migration.
Wavestone — “Radar 2026 of Post-quantum Migration Solutions” (March 2026). A vendor-solution market landscape mapping categories (inventory, network analysis, migration management, PQC-compliant HSM/PKI/CLM, libraries/embedded, edge protection). Useful for vendor evaluation; not a migration methodology.
KPMG — “Prepare Now for Quantum Cyber Risk” (Board Leadership Center, circulated May 2026). A board-advisory article on oversight focus areas. Not a methodology.
I did not identify any major consulting firm (McKinsey, BCG, Deloitte, PwC, EY, KPMG, Accenture, IBM Consulting, Booz Allen) that published a structured, multi-phase PQC migration methodology with named phases, PMO governance, and maturity model between March and June 2026. Output in this period was thought-leadership, board-advisory, and vendor-radar content.
The March-to-June 2026 period exposed seven challenges that a PQC migration methodology must now address. I assessed every publication from this period — and every framework cataloged in the original survey — against each challenge.
Key exchange migration (stopping HNDL) and signature/PKI migration (addressing TNFL) have different urgency drivers, different deployment patterns, and different infrastructure dependencies. Treating them as a single prioritized sequence causes organizations to under-invest in whichever track is not their starting point.
Meta’s playbook implicitly acknowledges this by noting that confidentiality protections (hybrid key exchange) can be deployed now while “important parts of the industry are not yet available” for signature migration. CISA’s product category list distinguishes key establishment from digital signatures. But no framework published before v2.0 formalizes a two-track parallel model with distinct urgency drivers, deployment patterns, and Track A/Track B governance.
Addressed in v2.0: Track A (Confidentiality / Key Exchange) and Track B (Integrity and Authentication / Signatures and PKI) are explicitly treated as parallel migration tracks throughout the methodology.
Let’s Encrypt’s June 3 commitment to MTCs, combined with Chrome’s stated preference and Cloudflare’s testing, means public Web PKI is heading toward a fundamentally different trust architecture. Organizations must now classify their PKI deployments and plan for two parallel architectures: MTC-based for public web, X.509 with PQC algorithms for internal enterprise PKI (mTLS, VPN certificates, Wi-Fi/802.1X, smart card authentication, code signing).
The IETF PLANTS working group drafts define the technical standard. Let’s Encrypt and Google have committed to implementation. But no migration framework translates this architectural fork into organizational PKI planning guidance. The Dutch Handbook, ETSI TR 103 619, GSMA PQ.03, NIST SP 1800-38, and Meta’s playbook do not address MTCs or the dual-architecture planning problem.
Addressed in v2.0: Phase 6 includes a PKI Architecture Evolution section that takes a definitive position on MTCs as the path forward for public Web PKI and provides classification guidance for mapping PKI deployments to the appropriate architecture (MTC vs. X.509 PQC).
No FIPS 140-3 validated cryptographic module with PQC algorithms in approved mode exists as of June 2026 (though some validated modules list PQC operations as non-approved services). SafeLogic’s May 19 CMVP submission is the first known entry in the queue. FIPS 140-2 certificates move to the Historical list in September 2026. For regulated environments, this creates a deployment sequencing constraint: organizations cannot put PQC into production on FIPS-required systems until validated modules exist.
The gap is well-documented in trade press and vendor communications. But no migration methodology systematically classifies deployment environments against the validation constraint and provides sequencing guidance based on environment class.
Addressed in v2.0: A four-tier deployment environment classification (Unrestricted, FIPS-Aware, FIPS-Required, CNSA 2.0) feeds directly into Phase 4 roadmap construction, with “earliest production deployment” dates constrained by environment class.
The SSRN Williams paper (May 2026) provides a rigorous 14-basis cost framework. OMB’s July 2024 report estimated $7.1 billion for federal civilian systems (2025–2035). GSMA’s telecom cost models exist. But no migration methodology integrates cost estimation into the program planning process with specific cost driver categories that a CISO can use to build a budget request.
My own v1.1 did not adequately address this. That was a gap.
Addressed in v2.0: An eight-category cost driver taxonomy (discovery tooling, cryptographic engineering labor, infrastructure modernization, vendor upgrade costs, testing and validation, training, program management, opportunity cost of deferred modernization) integrated into Phase 0 business case construction.
BSI recommends hybrid deployment where feasible. ANSSI promotes hybridized migration but does not mandate hybrid for all deployments. NCSC-UK treats hybrid as an acceptable interim step but prefers pure PQC for new systems. CNSA 2.0 treats hybrid as transitional. ASD does not recommend hybrid but does not prohibit it. An organization operating across these jurisdictions faces contradictory guidance. This is not a new problem, but no framework provides structured navigation guidance.
Addressed in v2.0: A “highest common denominator” strategy — deploy hybrid as default, document a pure-PQC transition plan, evaluate pure PQC for new deployments — with jurisdiction-specific tracking integrated into the Phase 4 roadmap.
“We’ll wait for vendors.” “This is just an IT problem.” “Nobody in our sector has started.” “We did an inventory — we’re done.” These objections kill PQC migration programs. No published framework provides structured responses to the most common organizational resistance patterns.
Addressed in v2.0: Appendix F provides evidence-based responses to eight common objections, each grounded in specific data points (e.g., “Nobody in our sector has started” is countered with the fact that roughly 44% of the top 100 websites already supported hybrid PQC key exchange by mid-2025, according to F5’s analysis of PQC deployment on the web).
Which libraries ship with PQC defaults? Which browsers support hybrid key exchange? Which HSM firmware versions enable PQC? Which cloud KMS platforms offer PQC key types? This information changes monthly and is scattered across vendor blogs, release notes, and conference presentations.
Meta’s playbook and Wavestone’s Radar each provide snapshots. But no migration methodology integrates ecosystem status as a maintained component that feeds into roadmap construction.
Addressed in v2.0: Deployment ecosystem status data integrated into Phases 5 and 6, covering library readiness (OpenSSL, BoringSSL, AWS-LC, Go, Node.js), browser support, HSM firmware status, and cloud platform capabilities.
Version 2.0 also addresses a gap that the seven deployment-reality challenges above do not fully capture: the operational security and governance infrastructure that a PQC migration program requires to function.
No published PQC migration framework before v2.0 includes integrated SOC detection specifications (with illustrative rules and thresholds for hybrid downgrade, cryptographic drift, certificate lifecycle anomalies, TNFL monitoring, and HNDL-indicator detection), quantum-specific incident response playbooks, tabletop exercise scenarios, or a three-horizon CTI model for quantum threats.
No published framework provides a cascading KRI framework for PQC migration (17 indicators across board, CISO, and operational levels with illustrative thresholds), a quantum risk appetite statement template with operational tolerances, a regulatory intelligence process specification, or documentation of the GRC-SOC handoff that makes detection capabilities function.
And no published framework treats crypto-agility as a five-dimensional operational discipline (architecture, operations, governance, skills, supply chain) with a phased implementation roadmap integrated into the migration lifecycle — as opposed to a set of architectural principles.
These additions reflect a consistent pattern: the PQC migration field has focused on what to migrate and when. The question of how to govern, operate, and sustain the migration program has been left largely to individual organizations to figure out on their own.
| v2.0 Challenge | Meta playbook (Apr 2026) | IACR 2026/790 (Apr 2026) | SSRN Williams (May 2026) | PQCC Roadmap (May 2025) | Dutch Handbook (Dec 2024) | Applied Quantum v2.0 (Jun 2026) |
|---|---|---|---|---|---|---|
| Two-track model (key exchange vs. signatures) | Implicit | — | — | — | — | ✓ (explicit Track A / Track B) |
| PKI architecture fork (MTC guidance) | — | — | — | — | — | ✓ (definitive position + classification) |
| FIPS 140-3 gap / environment classification | External dependency noted | — | — | — | — | ✓ (4-tier classification) |
| Cost estimation methodology | — | — | ✓ (14-basis framework) | — | — | ✓ (8-category taxonomy) |
| Multinational hybrid navigation | — | — | — | — | — | ✓ (highest common denominator) |
| Objection-handling | — | — | — | — | — | ✓ (Appendix F, 8 objections) |
| Deployment ecosystem status | Snapshot (Meta internal) | — | — | — | — | ✓ (maintained component) |
The March 2026 survey concluded that the gap between strategic roadmaps and execution methodologies was the defining challenge of PQC migration guidance. Three months later, a second gap has opened: the gap between preparation-phase methodologies and deployment-phase realities.
Most frameworks published before June 2026 were designed for the preparation phase: inventories, risk assessments, roadmaps, pilots. While my own v1.1 provided an execution methodology covering the full lifecycle, its deployment-stage guidance assumed a smoother ecosystem than what organizations are now encountering: secure the mandate, build the inventory, assess the risk, plan the roadmap, design the pilots. That guidance remains necessary. But organizations that are now entering Phases 5 and 6 (pilots and infrastructure modernization) are encountering deployment constraints that preparation-phase frameworks did not anticipate: the FIPS validation gap, the PKI architecture fork, contradictory jurisdictional guidance on hybrid deployment, and the need to run key exchange and signature migration as parallel tracks with different timelines.
Version 2.0 of the Applied Quantum PQC Migration Framework retains the 8-phase architecture that has been validated through real programs since 2023. What has changed is the planning model within Phases 4, 5, and 6 — updated to address a deployment environment that is more complex than any framework anticipated.
The framework remains free, open, and available at PQCFramework.com under CC BY 4.0.
| Date | Publication | Publisher | URL |
|---|---|---|---|
| Mar 25, 2026 | PQC migration timeline: 2029 target | Google (Adkins, Schmieg) | blog.google |
| Mar 2026 | Radar 2026 of Post-quantum Migration Solutions | Wavestone | riskinsight-wavestone.com |
| Apr 16, 2026 | Post-Quantum Cryptography Migration at Meta | Meta (Misoczki, Elbaz, Mertens) | engineering.fb.com |
| Apr 2026 | Risk-Based Framework for PQC Migration in Legacy Systems | Chammas, Hariss, Bassil, Chamoun (IACR) | eprint.iacr.org/2026/790 |
| May 5, 2026 | Defensible Framework for PQC Cost Estimation | Williams (SSRN) | ssrn.com |
| May 14, 2026 | Additional Digital Signatures — 9 candidates advanced | NIST | csrc.nist.gov |
| May 19, 2026 | CryptoComply 140-3 with PQC enters CMVP queue | SafeLogic | safelogic.com |
| Jun 3, 2026 | A Post-Quantum Future for Let’s Encrypt (MTC commitment) | Let’s Encrypt / ISRG | letsencrypt.org |
| Jun 2026 | Applied Quantum PQC Migration Framework v2.0 | Marin Ivezic / Applied Quantum | pqcframework.com |
| Jun 2026 | Applied Quantum PQC Migration Framework v2.1 | Marin Ivezic / Applied Quantum | pqcframework.com |
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。