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.

India finalized a national roadmap with binding timelines for critical infrastructure. Canada passed enabling legislation that gives regulators the power to mandate quantum-safe cybersecurity. A reported draft U.S. executive order would set hard dates for federal agencies and their contractors. CNSA 2.0’s procurement gate for national security systems is now eight months away. NIST advanced nine additional signature candidates, reinforcing that the algorithm landscape will keep evolving. The G7 central banks published their first collective acknowledgment of the quantum threat to finance. And Google’s ECC-breaking quantum circuits were independently reproduced, removing the last uncertainty margin around the cryptanalytic resource estimates.

None of these alone rewrites a migration plan. Together, they confirm that organizations still planning to a 2035 horizon are planning to a deadline the rest of the world is abandoning. For the full picture of PQC regulatory and industry deadlines across jurisdictions, I maintain a comprehensive global PQC deadlines tracker on PostQuantum.com. What follows is my analysis of the developments that matter most for practitioners right now.

CNSA 2.0: Eight Months to the Procurement Gate

The nearest hard deadline is also the least discussed. On January 1, 2027, every new acquisition for a U.S. National Security System must support CNSA 2.0 algorithms. A system delivered the day after without ML-KEM-1024 key establishment and ML-DSA-87 digital signatures is non-compliant on arrival. No waiver queue. No grandfather clause. No transition period.

That gate does not arrive alone. On September 21, 2026, NIST moves all remaining FIPS 140-2 certificates to Historical status. On November 10, 2026, CMMC 2.0 Phase 2 begins mandatory third-party assessments for most Level 2 defense contractors. Three cryptographic compliance deadlines in five months, each assuming the previous one has been addressed.

The binding constraint is CMVP validation. Post-quantum algorithm implementations need FIPS 140-3 validation to be acceptable for federal use. The current CMVP process averages over 500 days from submission to active certificate. Organizations that entered the pipeline by late 2024 or early 2025 will have validated modules. Those that did not face a gap that no amount of urgency can compress. As I covered in The 2027 Procurement Gate, the defense industrial base is about to discover which vendors were paying attention and which were not.

India Finalizes Its Roadmap

India’s Department of Science and Technology published the final version of its national quantum-safe migration report under the National Quantum Mission. The core timelines from the draft are unchanged: Critical Information Infrastructure (defense, power, telecom, transport, BFSI) follows a 2027/2028/2029 accelerated track. Regular enterprises follow a 2028/2030/2033 schedule.

What changed in the final version is significant in three areas. First, Preferential Market Access provisions now direct both public and private organizations to prefer indigenously developed quantum-safe products. Second, the testing and certification framework specifies four assurance levels with granular test cases, including side-channel resistance with specific TVLA pass criteria. Third, CBOM submissions become mandatory starting FY 2027-28.

For multinationals operating in India, the Preferential Market Access provisions add a new variable to vendor strategy. For everyone, the mandatory CBOM requirement validates the Minimum Viable CBOM approach I have advocated: regulators are moving from “you should know your cryptography” to “prove that you do.”

U.S. Signals Hard Dates — but Hasn’t Set Them Yet

Nextgov/FCW reported on May 20 that the White House is circulating a draft executive order requiring federal agencies to migrate key establishment to PQC by December 31, 2030 and digital signatures by December 31, 2031. Covered contractors would face a 2030 deadline.

This has not been signed. It is a draft sourced to a single report, and the specific dates could shift or disappear entirely. But the signal matters because previous executive actions had been pulling in different directions. EO 14306 stripped some of the harder provisions from Biden-era guidance. Trump’s March 2026 cyber strategy named PQC as a modernization pillar but set no dates. If signed, the draft EO would fill that gap and extend hard deadlines to the federal contracting base, which is the single largest lever the U.S. government has over private-sector technology adoption.

I include it here not as a done deal but as a leading indicator of where U.S. federal policy is heading. Organizations that depend on federal contracts should be planning to the rumored 2030 timeline regardless, because by the time a signed order makes it official, the implementation window will already be too short for programs that haven’t started.

Canada Passes Enabling Legislation — Without Mentioning Quantum

Canada’s Bill C-8 passed the Senate on June 4, nearly identical to the Bill C-26 introduced in June 2022. Senator Mohamed-Iqbal Ravalia asked the only quantum-related question in the entire Senate debate. Senator McNair’s response: “There was no direct discussion at the committee level, but the bill is robust enough that the regulatory process can deal with issues around quantum computing.”

Bill C-8 does not set a PQC deadline. What it does is hand regulators the tools to set one later: mandatory cybersecurity programs, incident reporting, ministerial power to compel operators to harden systems, and penalties of up to $15 million per day. Enforceable PQC-specific regulations are 12 to 24 months away from Royal Assent, putting them at late 2027 to mid-2028 at the earliest. Canada’s Treasury Board SPIN procurement guidance, which went live April 1, 2026, is currently the sharpest PQC-adjacent lever in Canadian federal policy.

The gap between the legislative framework’s potential and its quantum-specific execution is striking. The full analysis is on PostQuantum.com.

Google’s ECC Circuits: Reproduced in Two Months

In March, Google Quantum AI published resource estimates showing ECC-256 could be broken with roughly 1,175 logical qubits and about 2.6 million Toffoli gates. The team hid the circuit designs behind zero-knowledge proofs, citing responsible disclosure.

In June, André Schrottenloher at Inria published independently constructed circuits that match Google’s results on qubits and beat them on gate count. Craig Gidney, the Google researcher who designed the original circuits, confirmed the match and conceded the ZKP approach failed.

The CRQC timeline is unchanged — breaking ECC with 1,175 logical qubits still requires hardware nobody has built. But the uncertainty margin around the resource estimates is gone. The circuits are now published and independently verified. Any future quantum hardware advance can be immediately assessed against a known, concrete cryptanalytic target. For migration programs, this tightens the connection between quantum hardware announcements and actual cryptanalytic risk: the goalposts are now fixed and visible.

NIST Advances Nine Additional Signature Candidates

NIST released NIST IR 8610, announcing that nine candidate algorithms advanced to the third round of its Additional Digital Signatures process. Five were eliminated. The survivors span four mathematical families, with only one (HAWK) lattice-based, and even HAWK rests on different assumptions than ML-DSA and FN-DSA.

NIST is building cryptographic insurance. If a breakthrough compromises the standard lattice problems underlying its primary signature standards, most of these candidates provide alternatives on entirely different foundations. For migration programs, the practical implication is that crypto-agility is not optional. Your architecture needs to accommodate algorithm changes that could come from either a lattice cryptanalysis surprise or a standards-body decision to deprecate or modify an existing standard.

The nine survivors include SQIsign (148-byte signatures, the most compact PQC scheme), UOV, MAYO, FAEST, and HAWK. Several of these produce signatures smaller than ML-DSA, which matters for constrained environments (IoT, DNSSEC, embedded OT systems) where ML-DSA’s 2,420-byte signatures are prohibitive. Organizations with significant OT/CNI deployments should track the compact signature candidates closely.

G7 Central Banks Acknowledge the Quantum Threat

The G7 central banks’ Quantum Technologies Working Group published its first report in May, with all eight G7 central banks collectively acknowledging the quantum threat to the financial system. The report follows the G7 Cyber Expert Group’s PQC migration roadmap (January 2026, targeting 2030 to 2035) but takes a wider lens, covering quantum computing applications and quantum sensing alongside cryptographic security.

For financial services CISOs, the G7 CEG roadmap’s 2030-2032 migration window for high-priority systems is the current benchmark. Combined with CNSA 2.0 (for firms with NSS-adjacent contracts), the EU’s NIS2/DORA timeline, and MAS/HKMA guidance in Asia-Pacific, financial institutions operating across jurisdictions face converging compliance expectations from multiple regulators simultaneously.

Migration Impact

If you are planning to a 2035 completion horizon, revisit that assumption. NIST’s draft guidance deprecates classical algorithms after 2030. Australia’s ASD recommends ceasing all traditional asymmetric cryptography by end of 2030. India targets CII migration by 2029. The rumored U.S. EO would set 2030/2031 for agencies. Even where hard deadlines have not yet been enacted, the direction and clustering of dates around 2028 to 2030 tells you where the finish line is moving. For the full current picture, see the global PQC deadlines tracker.

For defense contractors and NSS vendors, the January 2027 procurement gate is the immediate action item. Verify that your products support ML-KEM-1024 and ML-DSA-87. Confirm your CMVP validation status. If your cryptographic modules are not in the FIPS 140-3 validation pipeline, the January gate will close before your certificates arrive.

For multinationals, PQC standards fragmentation is now an operational planning variable. NIST selections dominate the Western world, but China’s ICCS process is actively evaluating submissions, South Korea’s KpqC winners are announced, and India’s Preferential Market Access provisions may shape vendor selection in the subcontinent. A migration plan that assumes a single global algorithm family is planning for a world that will not exist.

Bottom line: I have been arguing for years that debating Q-Day arrival dates is beside the point because regulators, vendors, and counterparties set their own deadlines. What I am seeing now is the next phase: guidance is becoming law, voluntary is becoming mandatory, and the dates are converging on 2028 to 2030. If your program timeline does not survive contact with that calendar, escalate now.

For the full and continuously updated landscape of PQC regulatory and industry deadlines, see the Global PQC Deadlines Tracker on PostQuantum.com.

The Applied Quantum PQC Migration Framework provides structured guidance for program planning, governance, and regulatory alignment across jurisdictions in Phase 0 (Executive Mandate) and Phase 4 (Roadmap & Governance).

Four months ago, when Google and Cloudflare published the MTC proposal, the biggest open question was whether the rest of the CA industry would follow or resist what looked like browser vendors dictating PKI architecture. Let’s Encrypt’s commitment answers that question. With Chrome, Cloudflare, DigiCert, and the world’s largest CA aligned, MTCs have crossed from proposal to industry consensus in record time.

This has concrete implications for how organizations should plan the PKI component of their PQC migration. The Web PKI is heading toward a two-track architecture that will persist for years: MTCs for browser-to-server authentication, standard X.509 certificates with ML-DSA signatures for everything else. If your migration plan assumes a single PKI path, it needs revision.

Why MTCs Exist

The engineering constraint is clear. A typical TLS handshake today transmits about 1,248 bytes of authentication data across five signatures and two public keys. If you replace those with ML-DSA-44 (FIPS 204), that figure pushes past 14,700 bytes, well beyond TCP’s initial congestion window. Cloudflare’s engineers found that at that payload size, a meaningful share of TLS connections fail outright. Google’s threshold analysis calls anything above ~7 KB “implausible unless a CRQC is tangibly imminent.”

MTCs solve this by batching. Instead of each certificate carrying its own post-quantum signature, the CA signs a single Merkle tree head representing potentially millions of certificates. Browsers receive tree head updates out-of-band (through browser updates, analogous to how root certificates are distributed today), and the TLS handshake carries only a compact inclusion proof: a chain of hash values that grows logarithmically with tree size. For a batch of roughly 4.4 million certificates, the proof is 736 bytes. No signature travels over the wire.

The CA’s post-quantum signature exists only once, on the tree head checkpoint, and Google and Cloudflare have indicated this will use a hybrid approach combining ECDSA and ML-DSA. Because batched signing means the CA’s HSM signs infrequently, the computational cost of expensive PQ signing operations becomes negligible.

MTCs do not replace or bypass NIST-standardized algorithms. ML-DSA still signs the tree head checkpoints. What changes is architectural. Google is redesigning the plumbing that delivers standardized cryptography to billions of browsers without choking the pipes.

Certificate Validity Reductions Add Urgency

The MTC timeline coincides with a separate pressure that compounds any per-certificate overhead. The CA/Browser Forum’s Ballot SC-081v3 shrinks maximum TLS certificate validity from 398 days to 200 days (March 2026), then 100 days (March 2027), and ultimately 47 days (March 2029). Let’s Encrypt has already announced it will reduce certificate lifetimes to 64 days by February 2027 and 45 days by February 2028.

Shorter lifetimes mean more frequent issuance. An architecture that amortizes one post-quantum signature across millions of certificates fits this trajectory far more naturally than one that signs each certificate individually. For organizations still managing certificates manually, the validity reductions alone are a forcing function. Combined with the PQC size problem, fully automated certificate management has moved from best practice to prerequisite.

The Non-Browser Gap

The concern I raised in my analysis of Google’s MTC proposal persists: MTCs are optimized for a world where browsers mediate trust, receive frequent updates, and maintain background connections to transparency services. This works for Chrome, Firefox, and Safari users. It does not work for curl, Python’s requests library, IoT devices, embedded systems, or the vast population of non-browser TLS consumers.

Let’s Encrypt acknowledges this implicitly by tracking ML-DSA in X.509 as a parallel path. The organization is watching RFC 9881 and the draft-ietf-tls-mldsa TLS extension, which would allow traditional X.509 certificates to carry post-quantum signatures. The non-browser ecosystem will likely need standard X.509 certificates with ML-DSA or FN-DSA (FIPS 206) signatures, performance overhead and all, until operating systems can distribute tree heads at the system level.

The result: a split certificate infrastructure that persists for years. Your migration plan needs to account for both tracks.

What Let’s Encrypt Got Right on TNFL

Let’s Encrypt’s framing of urgency is worth noting. For years, the conventional wisdom treated authentication as less urgent than encryption because signature forgery requires a CRQC operating in real time, not retroactively. Let’s Encrypt’s post explicitly acknowledges this framing and then moves past it, noting that long-lived keys, particularly root CA keys and code-signing keys, are high-value targets.

That is the right instinct, and it aligns with the Trust Now, Forge Later thesis I have been developing since 2018. The deeper TNFL concern, the one that drives the urgency in my framework’s treatment of signature migration, is about the trust infrastructure itself: root CA private keys, code-signing hierarchies, and software supply chains where a single forged signature can cascade through millions of systems. MTCs address the handshake authentication piece. The supply-chain and code-signing pieces remain open.

The IETF PLANTS Working Group

The standardization vehicle for MTCs is the IETF PLANTS (PKI, Logs, And Tree Signatures) working group, established after a successful Birds-of-a-Feather session at IETF 124. Google, Cloudflare, Let’s Encrypt, and Filippo Valsorda are participating. The ACME protocol that Let’s Encrypt subscribers use to obtain certificates will need extensions to support MTC issuance. Organizations running ACME clients or operating certificate infrastructure should start monitoring the PLANTS working group and the mtcs@chromium.org mailing list.

Migration Impact

For organizations running PQC migration programs, Let’s Encrypt’s announcement changes the planning assumptions for PKI modernization:

If you operate public-facing web services, start tracking MTC developments and ensure your ACME clients will be ready. Nothing changes in your certificate issuance today, but the production timeline (2027 for Let’s Encrypt) is close enough that infrastructure planning should begin. Browser-facing TLS will migrate via MTCs, not via ML-DSA X.509 certificates.

If you maintain internal PKI for microservices, VPNs, mTLS, and device authentication, plan for the standard X.509 path. Your internal CAs will need to issue certificates with ML-DSA or composite signatures. This is the harder migration: you own the CA, you own the clients, and you bear the full performance cost of larger signatures and certificate chains. Phase 6 of the PQC Migration Framework covers PKI modernization, including dual-stack CA deployment for this scenario.

Enable hybrid post-quantum key exchange now (X25519MLKEM768). This addresses the more urgent HNDL encryption threat immediately, requires no certificate changes, and is supported by all major browsers and edge providers today.

Automate your certificate management completely. The CA/Browser Forum’s validity reductions are coming regardless of post-quantum considerations. Organizations that can rotate certificates at high frequency will be in the best position to migrate when MTC issuance goes live. Organizations still managing certificates manually will struggle with both the validity reductions and the eventual cryptographic transition.

Bottom line: The Web PKI’s post-quantum architecture is now decided. MTCs for browser-facing authentication, standard X.509 with PQC signatures for everything else. Organizations should update their Phase 6 PKI modernization plans to reflect this two-track reality. If you are waiting for the industry to converge on a single approach, it already has: two approaches, for two different trust models.

For the full analysis of the MTC architecture and its implications, see Google’s Merkle Tree (MTC) Gambit to Quantum-Proof HTTPS, Cloudflare Joins Google: Two Internet Giants Now Say 2029, and Let’s Encrypt Commits to Merkle Tree Certificates on PostQuantum.com.

The Applied Quantum PQC Migration Framework addresses PKI modernization and dual-stack CA deployment in Phase 6 (Infrastructure & Performance).

That alone would be significant. What makes the paper consequential for PQC migration programs is its quantitative analysis: Bernstein estimates that 25% of ML-DSA libraries will ship with severe vulnerabilities at initial release, and projects that solo ML-DSA deployment would produce roughly an order of magnitude more breakable signature keys than hybrid Ed25519+ML-DSA over the next five years.

The timing is pointed. In April 2026, cryptography engineer Filippo Valsorda argued that hybrid ECC+ML-DSA signatures are unnecessary and would slow urgent PQC deployment. Sophie Schmieg, Google’s senior cryptography engineer, argued on the IETF TLS list that hybrid signatures are less necessary than hybrid key exchange because signature forgery damage is bounded by key revocation. Bernstein’s paper dismantles both positions with working code and historical data.

The Attacks

The first attack targets what Bernstein calls the “AABBCC” bug, where coefficients in the secret polynomial end up repeating in pairs. This is an ML-DSA-specific version of a vulnerability announced in 2018 by Dilithium co-designer Vadim Lyubashevsky, who said the bug “can easily be exploited to recover the secret key.” Lyubashevsky never published a working demo. Bernstein does.

The second attack targets nonce repetition, the ML-DSA analog of the Sony PlayStation 3 ECDSA disaster from 2010. If ML-DSA signature software accidentally reuses the secret nonce, the attacker recovers the secret key by simple polynomial division. Both attacks produce universal forgeries.

But these bugs pass all standard functionality tests. A signature generated with the AABBCC bug is a valid ML-DSA signature. It interoperates with correct verifiers. It passes known-answer tests if those tests were generated by code with the same bug (which is exactly what happened with both official Dilithium 1.0 implementations in 2017).

Three Independent Papers, One Conclusion

Bernstein’s paper arrives alongside two corroborating findings. Nadim Kobeissi’s “Verification Theatre” paper reported 13 vulnerabilities in Cryspen’s libcrux, a library used by Firefox and OpenSSH that advertised formal verification. Four bugs were inside the formal verification boundary, including a wrong multiplication constant in ML-DSA. If the leading formally verified PQC library ships with bugs its verification framework cannot catch, the unverified majority will fare worse.

Separately, Lee, Lim, and Yoon found that production ML-DSA implementations have shipped with arithmetic overflow bugs from aggressive removal of Montgomery reductions. Whether the resulting non-conformant signatures leak information about the secret key remains an open question that Bernstein frames as likely.

These are not coincidences. They are the statistical baseline for cryptographic software. Blessing, Specter, and Weitzner’s study of eight major cryptographic libraries found 0.45 to 1.19 CVEs per 1,000 lines of code added, with an average exploitable lifetime of 5.13 years. ML-DSA’s signing procedure is unusually complex compared to classical alternatives, and the ecosystem is adding an estimated 100,000 to 200,000 lines of new, algorithm-specific code across roughly 50 libraries. The CVE data predicts what happens next.

Why the “Skip Hybrid” Argument Fails

Valsorda’s case rested on two claims: that ML-DSA is easier to implement securely than classical alternatives, and that the Wycheproof test suite represents improved testing infrastructure. Bernstein addresses both. Wycheproof does not include ML-DSA key-generation tests. Its signature-generation tests use a nonstandard interface that many implementations will skip. Standard interoperability tests, which are what most deployments actually run, cannot catch the classes of bugs Bernstein demonstrates.

The comparison with Ed25519 makes the gap concrete. Bernstein’s CVE review found 1 to 2 severe vulnerabilities across roughly 100 Ed25519 libraries over more than a decade, yielding a severe-vulnerability rate of about 2%. ML-DSA libraries in 2027, by his model, face an 18% rate. That gap narrows over time as ML-DSA implementations mature, but it persists for years.

Schmieg’s argument that signature forgery damage is bounded by revocation does not survive contact with how forgeries actually propagate. DigiNotar compromised hundreds of thousands of users before revocation. Forged code-signing keys enable persistent access that survives key rotation entirely. Revocation bounds the visibility of forgery, not the consequence.

Context the Reader Needs

Bernstein has advocated for hybrid ECC+PQ deployment for a decade and has been among the most vocal critics of NIST’s PQC process. The paper is technically sound, but it is an advocacy document for a position he has held since 2016. That does not weaken the core argument. It does mean the quantitative estimates in Figure 9.1.1 should be treated as order-of-magnitude reasoning rather than precise predictions. The directional conclusion (more breakable ML-DSA keys than Ed25519+ML-DSA keys) holds across wide variations in the underlying assumptions. The specific numbers do not.

The paper also deliberately excludes the risk of a mathematical break of the ML-DSA specification itself. If Dilithium’s underlying lattice assumptions turned out to be weaker than expected, the breakable-key estimates would be vastly higher. This conservative scope means the paper may actually understate the case for hybrid.

Migration Impact

For anyone managing a PQC migration program, three actions follow directly:

Do not deploy solo ML-DSA for new signature applications if hybrid Ed25519+ML-DSA is available. The IETF composite ML-DSA specification for TLS is at revision 10. The LAMPS composite signatures draft for X.509 is at revision 19. The code required for Ed25519+ML-DSA is almost entirely the same code required for solo ML-DSA. The signature size increase from adding Ed25519 (64 bytes) to an ML-DSA-44 signature (2,420 bytes) is 2.6%. For applications already absorbing the order-of-magnitude jump from ECDSA to ML-DSA, the marginal cost is in the noise.

Invest in ML-DSA testing infrastructure that goes beyond standard functionality tests. Cross-library checksum comparisons using derandomized RNGs catch the classes of bugs Bernstein demonstrates. Standard interoperability tests do not. If your organization is evaluating or deploying ML-DSA libraries, require your vendors to demonstrate this level of testing. Organizations in Phase 5 of the PQC Migration Framework should add cross-implementation checksum testing to their pilot acceptance criteria.

Budget for software maturation as a scheduled phase, not a surprise. An ML-DSA library that ships today and receives its first serious security audit in two years is carrying two years of undetected vulnerabilities. The CVE data predicts this with statistical regularity. A credible PQC migration plan treats bug discovery and patching as a scheduled activity, not a crisis.

The irony should not be lost: we are migrating to new signature algorithms because the old ones may eventually be broken by quantum computers, and in the process, we risk deploying the new algorithms in ways that make them immediately breakable by classical computers. Hybrid cryptography eliminates that tradeoff. It should be the default.

Bottom line: Organizations currently planning or executing PQC signature deployment should adopt hybrid Ed25519+ML-DSA as the default configuration. The cost difference is negligible; the security difference, by Bernstein’s quantified analysis, is an order of magnitude in breakable keys for the next five years. Any steering committee still debating whether hybrid signatures are “worth the complexity” can now be shown the numbers.

For the full technical analysis, see my detailed coverage of the Bernstein paper on PostQuantum.com and the broader implications for migration strategy in The PQC Migration’s Biggest Risk Isn’t Quantum Computers.

The Applied Quantum PQC Migration Framework provides structured guidance for hybrid deployment across TLS, IPsec, SSH, and code-signing in Phase 5 (Pilots & Migration Patterns).

And I keep running into two problems that compound each other.

The first is that the knowledge base for running a PQC migration barely exists. There are no established methodologies beyond what I and a handful of others are building now. There are no shelves of books on the subject. Most consultants advising organizations on PQC migration have never run one. I watch programs stall because teams drew the wrong analogy — treating this like a Y2K remediation, or a standard infrastructure refresh, or a compliance checkbox exercise — and built plans that collapse when they encounter the actual complexity of cryptographic dependencies across an enterprise. PQC migration is the largest, most complex IT/OT overhaul most organizations will ever attempt, and the people responsible for executing it are largely working without a map.

That is why I published the framework. But a framework alone is not enough, because the second problem is that the ground keeps shifting. A CISO who built her roadmap around NIST’s 2035 deprecation horizon in January discovered by May that regulators are clustering their deadlines around 2028 to 2030. An architect who planned solo ML-DSA signature deployment in March now has a 59-page paper quantifying why that decision carries an order of magnitude more risk than hybrid. A PKI team that assumed post-quantum certificates would be larger versions of today’s X.509 chains just learned that the world’s largest certificate authority chose an entirely different architecture.

No established playbook, and the few reference points that exist keep moving. That is why I am launching The PQC Migration Brief.

What This Newsletter Does

Every issue applies a single editorial filter: does this development affect how organizations plan, execute, or govern their PQC migration?

If yes, I cover it. If no, I skip it, no matter how interesting the quantum computing news might be. You will not find quantum hardware milestones here unless they change CRQC timeline estimates enough to affect migration urgency. You will not find quantum sensing or quantum AI coverage. You will not find general industry funding news. For that broader coverage, PostQuantum.com and Quantum Observer are the right places.

What you will find: algorithm guidance updates that affect your selection decisions. Regulatory developments that change your timelines. Vendor readiness changes that alter your procurement assumptions. Infrastructure findings that affect your deployment planning. Lessons from real programs, including my own, about what works and what fails in practice. And, where the established knowledge simply does not exist yet, the practitioner judgment calls and methodology decisions that I am building into the framework as I go.

Every analyzed item ends with a concrete practical takeaway. Something specific enough that you could forward it to your program manager or steering committee and they would know what to do with it.

Why Now

Three things converged in 2026 that made a dedicated migration-focused channel necessary rather than optional.

First, the compliance calendar compressed. A year ago, most migration roadmaps assumed a comfortable glide path to 2035. Today, CNSA 2.0’s procurement gate hits January 2027. A draft U.S. executive order targets 2030 for agencies and contractors. The EU is writing PQC obligations into NIS2 implementing law. India finalized a 2029 deadline for critical infrastructure. Google and Cloudflare both committed to 2029 for full post-quantum migration. Organizations planning to a 2035 horizon are planning to a deadline their regulators, vendors, and counterparties have already abandoned.

Second, the implementation questions got harder and there is almost nowhere to turn for answers. Early PQC guidance was “do an inventory, prioritize, migrate.” That advice is correct in the way that “buy low, sell high” is correct. The practitioners I work with are past that stage. They need answers to questions like: should I deploy solo ML-DSA or hybrid Ed25519+ML-DSA for signatures? How do I plan PKI modernization when the Web PKI is forking between Merkle Tree Certificates and traditional X.509? What do I do when my HSM vendor’s FIPS 140-3 validation is 18 months away and my compliance deadline is 8 months away? No textbook covers this. Most advisors have not faced it. The answers are being discovered in real programs right now, and this newsletter is where I share what I am learning.

Third, the noise level increased. Vendor marketing, Q-FUD (quantum fear, uncertainty, and doubt), and breathless media coverage make it harder to identify which developments actually matter for migration planning. A practitioner who reads every quantum news item spends hours filtering signal from noise. This newsletter does that filtering for you.

How This Connects to the Framework

The Applied Quantum PQC Migration Framework is the reference methodology: an 8-phase, end-to-end guide covering everything from executive mandate and business case through discovery, CBOM, risk scoring, roadmap, pilots, infrastructure, and vendor governance. It is free, completely open, and published under CC BY 4.0. No email gate, no signup required. Use it, adapt it, build on it.

This newsletter is the ongoing companion. The framework tells you how to migrate. The newsletter keeps you current on what changed since you last looked. When a development affects a specific framework phase, I will say so and link to it. When a development requires the framework itself to be updated, I will note that too.

I also write about quantum security more broadly on PostQuantum.com, and my book Quantum Ready covers organizational quantum readiness for practitioners who want the full argument in one place. Applied Quantum is my firm, where we help financial services, government, telecoms, and critical infrastructure organizations execute what the framework describes.

What’s Coming

The first substantive issues are already drafted. Here is what to expect over the next two weeks:

The ML-DSA hybrid debate is settled. Daniel Bernstein’s June 2026 paper provides open-source attacks that recover ML-DSA secret keys in under a second, backed by a statistical model showing solo ML-DSA deployment produces roughly ten times more breakable keys than hybrid Ed25519+ML-DSA. I will walk through what the paper says, where its estimates are strong, where they require nuance, and what it means for your Phase 5 deployment decisions.

The Web PKI is forking. Let’s Encrypt, Google, and Cloudflare have aligned on Merkle Tree Certificates as the post-quantum authentication path for browsers. Your internal PKI (microservices, VPNs, mTLS, device authentication) will take a different path. I will cover what this two-track reality means for PKI modernization planning and what you should be doing now.

Every deadline moved forward. Five countries tightened their PQC timelines between March and June. NIST advanced nine additional signature candidates to the third round. The G7 central banks published their first quantum risk report for financial services. Google’s secret ECC-breaking circuits were independently reproduced in two months. I will map the pattern and explain what it means for program timelines.

Subscribe if you want the analysis filtered, grounded, and actionable. Unsubscribe whenever it stops being useful. The framework is yours regardless.

Welcome to The PQC Migration Brief.

— Marin