Soatok published a clear-eyed piece today on hybrid post-quantum constructions—the practice of combining a classical algorithm (X25519, ECDSA) with a post-quantum one (ML-KEM, ML-DSA) so that the system remains secure even if one of the two is broken. The post argues that hybrid KEMs are a reasonable safety blanket while hybrid signatures have a weaker justification, and that the industry should stop letting the perfect be the enemy of the deployed. We broadly agree, and this post explains why.
The Asymmetry Between KEMs and Signatures
Soatok’s central observation is one that deserves wider uptake: the harvest-now-decrypt-later (HNDL) threat that motivates hybrid KEMs has no analogue for signatures.
When an adversary captures ciphertext today, they can store it indefinitely and decrypt it once a cryptographically relevant quantum computer (CRQC) arrives. The data that was confidential in 2026 is still confidential in 2036. A hybrid KEM like X-Wing—which combines ML-KEM-768 with X25519—hedges against this threat by ensuring that an attacker must break both the lattice problem and the elliptic curve discrete logarithm to recover the plaintext. If ML-KEM turns out to be flawed, X25519 is still there. If X25519 falls to a quantum adversary, ML-KEM is still there. The cost is modest: a slightly larger key exchange, a second KDF call, and some additional bandwidth. The insurance is real.
Signatures are different. A signature is verified at the time it is received. A quantum adversary who arrives in 2036 cannot retroactively forge a signature that was verified and acted upon in 2026. There is no stockpile of signatures waiting to be broken. The threat model that justifies hybrid KEMs—store now, exploit later—does not apply in the same way.
That said, hybrid signatures are not without merit. Long-lived signatures on software packages, certificates, or firmware could in principle be forged by a future quantum adversary, and there is a reasonable belt-and-suspenders argument for hedging against a lattice break even in the authentication context. The case is simply less urgent than for KEMs, where the consequences of a wrong bet are retroactive and irrecoverable.
We have been recommending post-quantum native design for all new systems since April 2, with hybrid constructions where backward compatibility requires them. That recommendation was deliberately agnostic about signatures versus KEMs. We are now refining it: hybrid KEMs are a compelling transitional measure; hybrid signatures are far less necessary, and should be evaluated against the specific threat model rather than adopted as a default.
Lattice Confidence Is Earned, Not Assumed
A recurring objection to pure post-quantum deployment is that lattice-based cryptography is “too new” to trust without a classical fallback. Soatok addresses this directly, and the numbers bear repeating: NTRU was patented in 1997. The learning-with-errors problem was introduced by Regev in 2005—the same year Curve25519 was published. ML-KEM and ML-DSA survived nearly a decade of the most intensive public cryptanalysis effort the field has ever organized, the NIST Post-Quantum Cryptography Standardization Process, in which hundreds of researchers from dozens of countries actively tried to break every candidate.
The process worked. SIKE, the supersingular isogeny-based scheme, was broken during the competition—a catastrophic attack that the evaluation process was designed to surface. The lattice candidates survived. This is not absence of scrutiny; it is scrutiny that produced a result.
We have additional evidence from our own work. When we built Crucible and tested 15 ML-KEM and ML-DSA implementations across five languages, we found two minor conformance gaps and zero security vulnerabilities. The implementations that ship inside AWS-LC, Cloudflare CIRCL, the Go standard library, and wolfSSL’s FIPS module all passed every test. The post-quantum ecosystem is not speculative anymore. It is production-grade software that has been tested, audited, and deployed at scale.
The Real Risk Is Complexity
Here is what our audit practice has taught us: the most common source of cryptographic failure is not a broken primitive. It is the complexity surrounding the primitive—the state machine that manages keys, the serialization layer that encodes messages, the fallback logic that negotiates which algorithm to use.
Every hybrid construction doubles the number of moving parts in exactly these layers. A hybrid KEM requires two key generations, two encapsulations, two decapsulations, and a combiner that must be correctly implemented to preserve the security properties of both components. A hybrid signature requires two signing operations, two verification operations, and a composition that must not introduce verification oracle attacks. Each additional algorithm is additional attack surface—not because the algorithm itself is weak, but because the integration is where bugs live.
We have spent the past two months documenting what happens when cryptographic implementation complexity outpaces engineering discipline. The bugs we found were not in the cryptographic primitives. They were in the wrappers, the serialization, the specification-to-code translation, the build system defaults. Adding a second algorithm to every cryptographic operation in a system multiplies exactly these surfaces.
For KEMs, the HNDL threat clearly justifies this cost. The insurance against a catastrophic retroactive loss of confidentiality is worth the additional integration complexity. For signatures, the calculus is less clear-cut. Hybrid signatures carry the same complexity costs, but the threat they hedge against—a lattice break that enables forgery—is one where the damage is prospective rather than retroactive. That does not make hybrid signatures pointless; it makes them a less urgent priority than hybrid KEMs, and one where the complexity tradeoff deserves more scrutiny.
Migration Friction Kills
Soatok makes a pragmatic point that resonates with everything we see in practice: the biggest risk to the post-quantum transition is not that the algorithms are wrong. It is that the transition takes too long because the industry overcomplicates it.
Every additional requirement—hybrid signatures on top of hybrid KEMs, dual certificate chains, negotiation for four algorithms instead of two—adds friction to migration. Friction means slower adoption. Slower adoption means more years of classical-only systems exposed to the HNDL threat that the entire transition is supposed to address. The irony is acute: treating hybrid signatures as a prerequisite for deployment may extend the window during which systems are vulnerable to exactly the quantum threat they are trying to mitigate.
Our recommendation stands: design new systems as post-quantum native. Use ML-KEM for key encapsulation. Use ML-DSA for digital signatures. Use hybrid KEMs (X-Wing or equivalent) where backward compatibility with classical systems is required during transition. Hybrid signatures may be appropriate for specific use cases—long-lived code signing, certificate authorities, scenarios where signature validity must span decades—but they should not be the default, and they should not gate the broader migration.
Conclusion
Soatok’s post captures something the applied cryptography community has been circling around without stating plainly: hybrid constructions are a safety blanket, and for KEMs, that blanket is clearly worth the cost. For signatures, the case is real but less compelling. The distinction is not about confidence in lattices—it is about whether the urgency of the threat model justifies the additional complexity.
We are a team that has audited more post-quantum implementations than most. We built the conformance testing framework that the ecosystem uses to validate them. We documented what happens when verification complexity outpaces engineering reality. From that vantage point: the lattice primitives are sound, the implementations are maturing, and the greatest risk to the transition is making it harder than it needs to be.
Deploy post-quantum cryptography. Use hybrid KEMs where they make sense. Consider hybrid signatures where the use case warrants them, but do not treat them as a prerequisite. And above all, do not let the pursuit of a theoretically perfect transition delay the practically necessary one.
The full version of this argument, alongside the rest of our migration recommendations, lives in our Post-Quantum Migration Playbook — a free practitioner guide covering primitives, hybrid constructions, TLS migration, libraries, conformance testing, rollout strategy, and the bug classes we keep finding in audits. Companion to our live PQ Migration Readiness scorecard and scanner.