PQC Migration Framework v2.1 is Live
The PQC migration conversation moved from preparation to deployment, and the deployment environment fractured. v2.0 and v2.1 shipped this month to address it. What changed, and what it means for your
If your program spent the last two years on inventory, risk scoring, and roadmaps, you are now arriving at the part where you actually deploy. The environment you are deploying into looks different from the one the planning-phase guidance assumed.
Three developments between March and June changed how a PQC migration program has to be planned, and I have rebuilt the framework’s planning model around all three. Version 2.0 shipped at the start of June. Version 2.1, which completes that cycle, is now live at PQCFramework.com, with the Universal Framework and all six sector extensions on a single baseline for the first time. It stays free under CC BY 4.0, like every release before it.
The three shifts, and what each means for your program.
Google put a 2029 stake in the ground
On March 25, 2026, Google announced that it is targeting 2029 to complete its PQC migration across Chrome, Android, Google Cloud, and internal infrastructure. That is six years ahead of NIST’s 2035 disallowance deadline.
I have made this argument before. The useful planning date is the one your suppliers, regulators, insurers, and largest customers impose on you, and it almost always lands earlier than any honest Q-Day estimate. Google runs the browser on most of your users’ devices and one of the two dominant mobile platforms, so when it fixes a completion date, that date becomes a constraint on everyone whose systems have to interoperate with Chrome and Android, whatever your own internal timeline says.
Bottom line: Plan to the tightest external deadline you are actually bound by, which for most organizations now sits well inside 2035, and treat Q-Day predictions as secondary.
Public Web PKI is forking from your internal PKI
On June 3, 2026, Let’s Encrypt committed to Merkle Tree Certificates (MTCs) as its path to post-quantum Web PKI, targeting a staging environment late this year and production in 2027. Let’s Encrypt issues the certificates for a large share of the public web. Google Chrome has stated a preference for MTCs, Cloudflare is testing them, and the IETF’s PLANTS working group is standardizing the format.
Post-quantum authentication is splitting into two architectures, and you now have to plan for both. Public-facing TLS is heading toward MTCs. Your internal PKI — mTLS, VPN and Wi-Fi/802.1X certificates, smart-card authentication, code signing — stays on X.509 with PQC signature algorithms. If you scoped PKI migration as a single algorithm swap across one certificate type, that scope no longer matches where the public web is going.
Bottom line: Classify every PKI deployment as public-web (MTC) or internal-enterprise (X.509-with-PQC) now, and plan them as two efforts with different timelines, tooling, and owners.
The FIPS 140-3 wall for regulated systems
As of June 2026, no FIPS 140-3 validated cryptographic module offers PQC algorithms in approved mode. SafeLogic’s CryptoComply submission entered the CMVP queue on May 19, 2026, the first publicly announced PQC-capable module to do so, with validation expected before year end. FIPS 140-2 certificates move to the Historical list this September.
For most of the organizations this framework is written for, that gap sets the sequence. An unrestricted web application can deploy hybrid TLS today. A FIPS-required payment or government system cannot put PQC into production until validated modules exist. A roadmap that treats those two as the same deployment problem will be either reckless or paralyzed.
Bottom line: Sort systems into deployment classes by their validation requirement, deploy hybrid wherever you are not blocked, and stage FIPS-required systems against the validation timeline instead of holding the whole program for them.
The biggest planning change: run two tracks in parallel
The thread connecting all three shifts is that key-exchange migration and signature migration are no longer one job. They have different drivers, different readiness, and different blockers, and the framework now runs them as parallel tracks instead of a single prioritized queue.
Track A, confidentiality and key exchange. Driven by Harvest Now, Decrypt Later: traffic captured today can be decrypted once a CRQC exists, so anything with a long confidentiality horizon is exposed right now. Track A is deployable today. Hybrid ML-KEM + X25519 key exchange works in current libraries (OpenSSL 3.5+, BoringSSL, AWS-LC) and shipping browsers. There is little reason to wait on it.
Track B, integrity and authentication. Driven by Trust Now, Forge Later: the risk that a future quantum computer forges the signatures your systems rely on. Track B is gated by the decisions above (the MTC-versus-X.509 fork, FIPS validation of signing modules, certificate lifecycle automation) and by a signature standard that is still moving. NIST advanced nine more signature candidates to a third round in May 2026, FN-DSA (draft FIPS 206) is not final, and HQC’s standard is still pending.
Run these as one sequence and you hit one of two failure modes I see often: teams that declare victory after enabling hybrid TLS and never fund the harder signature work, or teams that stall key-exchange protection while waiting for the PKI picture to settle. Either way, a whole track goes unaddressed.
v2.1 takes positions inside the split. It states where hybrid and composite signatures belong, and it foregrounds the part of Track B you can deploy now: SP 800-208 stateful hash-based signatures, for firmware and code signing. It also adds algorithm-specific vulnerability weighting to Phase 3 risk scoring, which forces an uncomfortable point: an estate heavy in elliptic-curve cryptography is no safer than an RSA-era one. ECC is not a safe harbor.
Because the signature standard keeps moving, the safest assumption is that whatever you deploy on Track B, you will replace. Build for that. Designing so the signature algorithm can be swapped when the standard settles is the job crypto-agility does, which is why the framework treats it as a measured operational capability rather than a diagram of abstraction layers.
Bottom line: Split the program into Track A (key exchange, deploy now) and Track B (signatures and PKI, sequenced against the fork and FIPS), give each an owner and a timeline, and treat the signature algorithm you choose as replaceable.
What’s actually in v2.0 and v2.1
The eight-phase lifecycle has not changed since 2023. What changed is the planning model inside it and the operational scaffolding around it.
v2.0 added the structures: the two-track model, the four-tier deployment environment classification (Unrestricted, FIPS-Aware, FIPS-Required, CNSA 2.0), the PKI architecture position, a cost-estimation taxonomy a CISO can build a budget from, a consolidated map of 14-plus regulatory deadlines converging by 2030, and the operational security layer the field had skipped: SOC detection use cases and quantum-specific incident-response playbooks, plus GRC instruments (risk-appetite statements, a 17-indicator cascading KRI framework, a regulatory-intelligence process, and audit procedures). No published PQC migration framework I am aware of had included integrated SOC detection or GRC governance before this. v2.0 also split Payments into its own extension and added Digital Assets.
v2.1 takes positions inside those structures and closes the program out. The additions that matter most for planning:
The hybrid and composite signature position, with SP 800-208 as the deploy-now piece of Track B
Algorithm-specific risk weighting in Phase 3 (the ECC point above)
Securing the CBOM itself (a new Activity 2.5): your cryptographic inventory is a precise map of where you are weakest, and it deserves the protection you would give any other targeting data
A data-at-rest decision framework: per store, re-encrypt, key-wrap, or delete, driven by confidentiality horizon against asset and media life
An explicit AI-assisted migration position for discovery and code transformation
Migration Verification and Program Closure: how to prove the migration held. A migration you cannot evidence is a claim, not a control, and that evidence dossier is also your litigation defense
v2.1 also brings all six sector extensions onto the same baseline. Financial Services, Payments, and Digital Assets get the v2.1 positions in sector terms; Government & Defense, CNI/OT, and Telecommunications move up directly from v1.1, each with a new sector challenge: the January 1, 2027 CNSA 2.0 acquisition gate for federal agencies, the OT data estate whose confidentiality horizon is set by plant lifetimes rather than record retention, and the 6G standardization window now open in 3GPP. The full change list is on the What’s New page.
Free, and attribution is required
I publish this under CC BY 4.0 because the migration problem is too large and too urgent to sit behind six-figure engagement fees. Use it, adapt it, build a commercial program on it. The license asks one thing in return: credit the source.
I am raising this because several consulting firms have taken the framework, removed my name and Applied Quantum’s attribution, made cosmetic changes, and presented it to clients as proprietary methodology. Some have added their own copyright notices, which CC BY 4.0 specifically prohibits. I wrote about that separately, with the dated survey evidence behind the original concepts.
The part that matters for you as a buyer: if a firm is selling you a PQC migration framework, it is worth 30 minutes to check what you are paying for. The survey I maintain catalogs more than 80 published frameworks and documents which capabilities were absent from the field before they appeared here, including the Two-Track Migration Model, Deployment Environment Classification, the Minimum Viable CBOM, TNFL, and crypto-agility expressed as Y ≈ K / A. A framework that closely tracks these and credits no source is repackaging methodology you can get free, in its current form, from the practitioner maintaining it. Ask the firm one question: which public methodologies does your framework build on? The ones worth hiring answer without hesitating.
Where to start
If your program is still in planning, the highest-value move this month is to redraw the roadmap as two tracks and sort your systems into deployment classes. Both are concrete enough to finish in a working session. If you are further along, look at the v2.1 verification and closure material, because deciding now what evidence will prove the migration held is the step most programs skip until an auditor or a board asks for it.
The framework is at PQCFramework.com, free, with the full v2.1 change list here. I write about the developments that change how you plan, execute, and govern this migration. Next up: the two-track split in more operational detail, the MTC transition as it moves toward staging, and what the FIPS timeline does to regulated-sector sequencing.