The PQC Migration’s Biggest Risk Isn’t Quantum Computers

Every previous major cryptographic transition replaced mature code with mature code. When organizations moved from DES to AES, the replacement algorithm had been studied for years and implementations were well-understood. When SHA-1 gave way to SHA-256, the new hash function slotted into existing codebases without requiring fundamental rearchitecting. Even the RSA key-length upgrades from 1024 to 2048 to 4096 bits involved the same underlying mathematics, the same libraries, the same implementation patterns.

The post-quantum migration is different in a way that the community has not fully internalized. We are replacing battle-tested cryptographic implementations, some with a decade or more of deployment and security scrutiny, with entirely new code based on entirely new mathematical structures. We are doing this across hundreds of libraries, in dozens of languages, under deadline pressure created by the realistic possibility that a cryptographically relevant quantum computer (CRQC) could arrive within a few years. And the community is now debating whether to do this without retaining the existing cryptography as a safety net.

That debate is producing a concrete, measurable cost. Daniel J. Bernstein’s June 2026 paper “Exploiting ML-DSA bugs,” which I covered in a recent analysis, provides the first quantified estimate of what we lose by stripping out ECC: roughly an order of magnitude more breakable signature keys over the next five years. The near-term risk from our own migration software, by his analysis, exceeds the near-term risk from quantum computers by three orders of magnitude.

This is a story about ML-DSA specifically, but the principle it illustrates applies to every algorithm in the PQC transition. New cryptographic code ships with bugs. That is not a prediction; it is a statistical regularity observed across decades of CVE data. Hybrid cryptography — deploying PQC as an additional layer alongside classical ECC rather than as a replacement — is the defense-in-depth response to this reality. The question is whether the community will adopt it as the default, or whether urgency will override engineering prudence.

Defense in Depth Is Not a New Idea

The principle behind hybrid cryptographic deployment is older than post-quantum cryptography itself. Engineers managing safety-critical systems have always preferred layered defenses over single points of failure. Redundant braking systems in aircraft. Backup generators in hospitals. Defense-in-depth architectures in network security. The logic is identical: when you cannot guarantee the reliability of any single component, you combine independent components so that a failure in one does not compromise the system.

Applied to the PQC transition, the principle is straightforward. A hybrid signature pairs a classical algorithm (say, Ed25519) with a post-quantum algorithm (say, ML-DSA, FIPS 204). The verifier checks both signatures. An attacker must break both to forge a message. If the PQ implementation has a bug, ECC stops the forgery. If a quantum computer breaks ECC, PQ stops the forgery. The system fails only when both layers fail simultaneously.

For key exchange, this approach is already the norm. Hybrid ML-KEM (combining X25519 with ML-KEM) is deployed in Chrome, Firefox, and Cloudflare’s edge network. The IETF hybrid key exchange specification is progressing toward adoption. Nobody in the key exchange debate is seriously arguing for dropping X25519 and shipping solo ML-KEM. The Harvest Now, Decrypt Later threat justifies urgency, and hybrid deployment is the accepted way to manage that urgency without assuming the new code is bug-free.

For signatures, the same principle should apply. The Trust Now, Forge Later (TNFL) threat is the signature analog of HNDL: an attacker who can forge signatures today can compromise software supply chains, certificate authorities, and authentication systems with consequences that persist long after the forged key is revoked. The IETF has a composite ML-DSA specification for TLS (now at revision 10) and an X.509 composite signatures draft at revision 19. The engineering groundwork is done.

And yet, a vocal segment of the community is arguing for skipping hybrid signatures entirely.

The Case for Skipping Hybrid

The strongest version of this argument came in April 2026, when Filippo Valsorda published a widely cited post responding to Google’s 2029 PQC migration deadline. Valsorda argued that hybrid ECC+PQ authentication “makes no sense” anymore and that the community should “go straight to pure ML-DSA-44.” His reasoning: the CRQC timeline has shortened, hybrid signatures introduce complexity (composite key types, wire formats, interoperability), and that complexity will slow deployment at the worst possible moment.

Valsorda offered two supporting claims. First, that ML-DSA is “a lot easier to implement securely” than classical alternatives. Second, that the Wycheproof test suite represents improved testing infrastructure that will catch implementation bugs.

Sophie Schmieg, Google’s senior cryptography engineer and co-author of the 2029 deadline announcement, has 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.

Nadim Kobeissi, writing from a different position on the hybrid spectrum, has called hybrid signatures “a safety blanket” while acknowledging that safety blankets serve a purpose. His framing is more nuanced, but his work on ML-DSA implementation quality is central to the counter-argument.

These are serious people making serious arguments under real time pressure. The urgency is not manufactured. I have been arguing for years that organizations should prepare based on ecosystem deadlines, not Q-Day predictions. Google’s 2029 target validates that position. The question has never been whether to act.

The question is whether the proposed action makes the problem worse.

Why It Does: The Evidence

Three independent findings in the first half of 2026 converge on the same conclusion: ML-DSA software is fragile, undertested, and shipping with exactly the kinds of bugs that hybrid deployment would contain.

New Code Ships with Bugs

This is not an ML-DSA-specific observation. It is a statistical regularity documented across decades of cryptographic library development.

Blessing, Specter, and Weitzner’s 2021 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. Alexopoulos et al.’s study of 11,959 CVEs across 11 open-source projects found a similar average lifetime and confirmed the fit to an exponential distribution. This data has been accumulating for over a decade, and the pattern has not changed: new code ships with vulnerabilities, those vulnerabilities take years to find, and some fraction of them are severe enough to allow attackers to compromise the system’s core security guarantees.

The PQC migration is adding an estimated 100,000–200,000 lines of new, algorithm-specific code across roughly 50 ML-DSA libraries alone. At published vulnerability rates, Bernstein estimates approximately 100 vulnerabilities across this new code, with about 25% of libraries shipping with at least one severe vulnerability at initial release. These are not worst-case projections; they are the statistical baseline for cryptographic software.

ML-DSA Specifically Is Implementation-Dense and Undertested

ML-DSA’s signing procedure is unusually complex compared to classical alternatives. It requires expanding 32 bytes of randomness into 1,024 polynomial coefficients through a chain of hashing, bit-unpacking, and modular arithmetic, then performing polynomial multiplication in a quotient ring, with rejection sampling that sometimes restarts the entire process. Every one of those steps involves dense, performance-sensitive code where a single index error, bit-shift mistake, or input-length miscalculation produces signatures that are valid, interoperable, and exploitable.

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.

A separate audit published as “When Removing Reductions Goes Wrong” by Lee, Lim, and Yoon found that production ML-DSA implementations have shipped with arithmetic overflow bugs from aggressive Montgomery reduction removal. Whether the resulting non-conformant signatures leak secret key material is an open question.

Bernstein’s paper walks through ML-DSA coefficient-unpacking code in three production libraries (the official Dilithium implementation, mldsa-native, and OpenSSL) and shows how a single character change in any of them creates an exploitable vulnerability invisible to standard tests. His two open-source attack demos each recover equivalent secret keys and forge arbitrary signatures in under one second on a single laptop core.

The Wycheproof test suite, cited as evidence of improved testing, does not include ML-DSA key-generation tests. Its signature-generation tests use a nonstandard interface that many implementations will not expose. Standard interoperability tests — which are what most ML-DSA deployments actually run — cannot catch the classes of bugs Bernstein demonstrates, because buggy signatures pass verification.

Compare this to Ed25519, which has been deployed across 700+ applications for over a decade. Bernstein’s CVE review found 1–2 severe vulnerabilities across roughly 100 Ed25519 libraries, yielding an estimated severe-vulnerability rate of about 2%. The ML-DSA ecosystem has not yet had time to accumulate comparable scrutiny. That is not a criticism of ML-DSA’s design; it is an observation about software maturity that applies to any new cryptographic implementation.

The Cost of Hybrid Is Minimal

The argument that hybrid signatures will “slow us down” assumes a deployment bottleneck that the existing standards work does not support.

IETF working groups have already produced the necessary specifications. The composite ML-DSA specification for TLS is at revision 10, the LAMPS composite signatures draft for X.509 is at revision 19, and JOSE/COSE composite signature serializations are progressing. The code required for Ed25519+ML-DSA is almost entirely the same code required for solo ML-DSA; the additional Ed25519 component uses stable, mature libraries already present in every deployment environment.

The signature size increase from adding Ed25519 (64 bytes) to an ML-DSA-44 signature (2,420 bytes) is roughly 2.6%. The public key increase from adding a 32-byte Ed25519 key to a 1,312-byte ML-DSA-44 key is roughly 2.4%. For applications already absorbing the order-of-magnitude size increase from ECDSA to ML-DSA, the marginal cost of Ed25519 is in the noise.

Multiple regulators already endorse hybrid deployment. The BSI recommends it. ANSSI recommends it. The compliance picture for organizations operating across jurisdictions makes hybrid the path of least regulatory friction, not the most.

But Hybrid Is Not Free

I advocate for hybrid deployment because the security outcomes are better. I should be equally clear about what it costs.

Hybrid means two cryptographic implementations to maintain, patch, and rotate keys for. When a vulnerability is discovered in either the ECC or the PQ component, your team must assess, test, and deploy the patch. That is twice the surface area for security operations, and organizations already struggling to inventory their cryptographic dependencies will feel it. The composite key and certificate formats, while standardized, are new to most toolchains; certificate chain validation, hardware security module support, and automated issuance pipelines will all require updates.

Hybrid also creates a downgrade attack surface that solo deployment does not. If an attacker can strip the PQ signature from a hybrid message and present only the ECC signature (or vice versa), the security guarantee collapses to the weaker component. Protocols and applications must be designed to reject single-algorithm signatures when a hybrid was expected. This requires binding the two signatures together cryptographically (as the IETF composite specifications do) and monitoring for malicious downgrade attempts in production. Organizations deploying hybrid should plan for downgrade detection from day one, not as an afterthought.

None of this changes the security calculus. The operational costs of maintaining two algorithms are real but manageable; the cost of a forgeable signature key is not. The point is that hybrid deployment is a deliberate engineering decision with its own operational requirements, not a checkbox that makes PQC migration simpler. It makes migration safer. Those are different things, and organizations should plan for both.

The Quantified Cost of Skipping Hybrid

Bernstein’s paper puts numbers to what was previously a qualitative argument. His Figure 9.1.1 estimates the number of breakable keys per year for three scenarios: solo Ed25519, solo ML-DSA, and Ed25519+ML-DSA.

The result: solo ML-DSA deployment produces roughly 10 times more breakable signature keys than hybrid Ed25519+ML-DSA, sustained for at least five years. This gap persists even after quantum attacks begin, because the first quantum computers will be expensive enough that per-key attack costs limit the number of ECC keys an attacker can break. A billion-dollar quantum computer in 2029, by Bernstein’s estimate, would break about 2^15 (roughly 32,000) ECC keys per year. In the same year, ML-DSA software vulnerabilities would leave approximately 2^27.5 (roughly 190 million) ML-DSA keys breakable by classical attackers.

I covered the methodology and assumptions behind these estimates in my detailed analysis. The specific numbers should be treated as order-of-magnitude reasoning, not precise predictions. But the directional conclusion holds across wide variations in the underlying assumptions: hybrid deployment is safer than solo PQ deployment, and will remain so for years after the first quantum attacks.

The Principle Extends Beyond ML-DSA

The ML-DSA signature debate is the sharpest current test case, but the principle applies across the PQC transition.

ML-KEM (FIPS 203) has its own implementation complexity, its own history of bugs (the KyberSlash timing vulnerabilities, for example), and its own deployment panic. The community got the answer right for key exchange: hybrid X25519+ML-KEM is the default. That decision implicitly validates the defense-in-depth argument. The question is why the same community would reach a different conclusion for signatures.

The answer, when you strip away the technical details, is that signatures carry less perceived urgency than key exchange because of the HNDL asymmetry. Data encrypted today with vulnerable key exchange can be decrypted years later by a quantum attacker. Signatures forged today cause immediate damage, but that damage is (in theory) bounded by key revocation. This reasoning leads Schmieg and others to conclude that hybrid signatures are “far less necessary.”

Bernstein’s paper dismantles this reasoning quantitatively. Forgery damage is not neatly bounded by revocation when the attacker uses forged signatures to compromise software supply chains, install persistent access, or undermine certificate authorities. The DigiNotar attack compromised hundreds of thousands of users before revocation. NSA’s QUANTUMINSERT attacks were undetected for eight years. Key rotation accomplishes nothing if the replacement keys use the same vulnerable software.

The same principle will apply to whatever comes after ML-DSA and ML-KEM. If NIST standardizes additional signature schemes (FN-DSA is in progress; NIST has called for additional signatures), those too will go through a period of implementation immaturity. If lattice-based assumptions weaken and the community needs to migrate again, the new replacement algorithms will carry the same new-code risk. Hybrid deployment is not a one-time hedge against ML-DSA specifically; it is a structural principle for managing cryptographic transitions safely.

What Organizations Should Do

I have spent a decade helping organizations prepare for the quantum transition. The message has always been the same: the deadlines are set, the migration is long, start now. I stand by every word of that. What I will not endorse is a deployment strategy that trades a long-term quantum risk for an immediate, quantifiable, classical risk.

Deploy hybrid ECC+PQ for both key exchange and signatures. For key exchange, this is already consensus. For signatures, the specs exist, the overhead is negligible, and the security benefit is now quantified. If your ML-DSA library turns out to be one of the estimated 25% with a severe vulnerability at release, the Ed25519 layer catches the forgery. If a quantum computer arrives and breaks Ed25519, the ML-DSA layer catches the attack. This is what defense in depth means.

Invest in ML-DSA testing that goes beyond interoperability checks. Cross-library checksum comparisons using derandomized RNGs catch the classes of bugs Bernstein demonstrates. Standard functionality tests do not. Require your library vendors to demonstrate this level of testing.

Build crypto-agility into your migration architecture. The PQC field is not settled. Algorithms may be deprecated, parameters may change, new schemes may be standardized. A migration plan that hardcodes solo ML-DSA-44 is fragile in exactly the way that cryptographic infrastructure should not be. Hybrid deployment, by retaining a classical layer, provides a natural fallback path if the PQ layer needs to be swapped.

Budget for software maturation as an expected phase of deployment. 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 Question We Should Be Asking

The question driving the PQC migration is no longer just “when will a CRQC arrive?” It is “what damage will we do to ourselves in the rush to prepare for one?”

We are migrating to new signature algorithms because the old ones may eventually be broken by quantum computers. In the process, we risk deploying the new algorithms in ways that make them immediately breakable by classical computers. Bernstein’s estimate of ML-DSA keys breakable through software bugs in 2027 exceeds his estimate of Ed25519 keys breakable through quantum attack in 2029 by three orders of magnitude. The near-term threat from our own migration may be larger than the near-term threat we are migrating to prevent.

Hybrid cryptography eliminates this tradeoff. It should be the default.