PQC Migration Frameworks: What Changed Between March and June 2026

Seven Deployment-Reality Challenges 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

---

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.

The Quarter That Changed the Conversation

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 a hard deadline, 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 over 54% of all public TLS certificates. 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 with PQC support exists. 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.

New Publications: March–June 2026

Structured Frameworks and Methodologies

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 Phases 0, 2 (CBOM), 4 (roadmap governance), or 6 (infrastructure modernization as a distinct concern).

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.

Vendor and Hyperscaler Announcements

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 PQC-capable module known to enter the FIPS 140-3 validation queue.

Government and Standards Body Activity

NIST — Additional Digital Signatures: nine candidates advanced to the third round (May 13, 2026): FAEST, HAWK, MAYO, MQOM, MQR-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 (March 2026), 100 days (March 2027), 47 days (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.

Consulting Firms

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.

No major consulting firm (McKinsey, BCG, Deloitte, PwC, EY, KPMG, Accenture, IBM Consulting, Booz Allen) 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.

Seven Deployment-Reality Challenges — and Who Addresses Them

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.

Challenge 1: Two-Track Migration Model

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.

Challenge 2: PKI Architecture Fork (Merkle Tree Certificates)

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).

Challenge 3: FIPS 140-3 Validation Gap

No FIPS 140-3 validated cryptographic module with PQC support exists as of June 2026. 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.

Challenge 4: Cost Estimation Methodology

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.

Challenge 5: Multinational Regulatory Navigation

BSI and ANSSI mandate hybrid cryptography. NCSC-UK prefers pure PQC. CNSA 2.0 treats hybrid as interim. ASD discourages hybrid. 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.

Challenge 6: Objection-Handling

“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 42% of the top 100 websites support hybrid PQC key exchange as of mid-2026).

Challenge 7: Deployment Ecosystem Status

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.

Updated Coverage Table: March–June 2026 Publications

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)

What This Means for the Landscape

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.

Every framework published before June 2026 — including my own v1.1 — was designed for the preparation phase: 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.

---

Publications Cited in This Update (Chronological, March–June 2026)

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 13, 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

---