The Hybrid Question: Why the World Can’t Agree on How to Deploy PQC

Somewhere in your organization, an engineer is writing a TLS configuration file. She needs to specify which key exchange algorithms the server will offer. In a pre-PQC world the answer was simple: ECDHE with P-256 or X25519, full stop. In 2026 the answer depends on which country she’s configuring for.

If the server faces German government clients, BSI’s TR-02102-1 recommends hybrid mode: ML-KEM combined with a classical key exchange, both running at once. From the end of 2031, BSI no longer recommends classical key agreement used on its own. If it faces Australian government clients, ASD’s guidance says it does not recommend hybrid schemes, does not prohibit them, and expects organizations to move to purely post-quantum algorithms, with traditional asymmetric cryptography retired by the end of 2030. If it faces US National Security Systems, CNSA 2.0 calls for ML-KEM-1024; the NSA will not require hybrid and keeps it out of the solutions NSS will eventually run. Three governments, three answers to the same configuration question.

It is the central implementation question in PQC migration, and the world’s major cybersecurity authorities answer it differently. The sharpest differences concern the end state: ASD and the NSA want purely post-quantum cryptography, while the EU certification guidance says lattice-based schemes should not be used on their own. As I discussed in The Global PQC Migration Clock, timeline divergence gets most of the attention. The hybrid question is harder to manage, because timelines can be sequenced (do the earliest one first), while conflicting end states have to be designed for at the same time.

The Positions

The nuances get lost in summary, so here is who says what.

Hybrid Recommended in Most of Europe

Germany. BSI’s TR-02102-1 version 2026-01 recommends hybrid and sets the first fixed end dates for classical public-key cryptography used on its own: the end of 2030 for the most sensitive applications, the end of 2031 for key agreement generally, and a planned end for classical signatures by 2035. TR-02102 is formally a recommendation, although many German organizations treat it as binding and it is binding for products that handle classified information. In my May version I described it as a mandate. That overstated its legal force.

France. ANSSI “strongly recommends” hybrid for products that protect data beyond 2030, and it extends the recommendation to signatures as well as key establishment. ANSSI’s June 2026 announcement of PQC requirements for qualification from 2027, which press reports described as a certification cutoff, did not change that position.

EU certification. The ECCG’s Agreed Cryptographic Mechanisms v2, the cryptographic reference for evaluations under the EU’s EUCC scheme, say lattice-based schemes such as ML-KEM and ML-DSA should not be used in a standalone way. Hash-based signatures may be. EUCC evaluation guidance therefore strongly favors hybrid for lattice-based PQC; the protection profile and security target of a given product decide what that product must implement.

Other European authorities. The October 2024 date I gave for the joint statement of 18 Member States was wrong; it was signed on 27 November 2024 and endorses hybrid as the transition approach. The Czech NÚKIB recommends hybrid without mandating it and also accepts standalone ML-KEM-1024 and ML-DSA-87. Switzerland’s FINMA, in its July 2026 guidance, notes that various organizations recommend hybrid schemes, citing the European joint statement, and suggests institutions consider hybrid for critical data while flagging the added complexity and cost. Europol’s framework for financial services calls hybrid TLS a no-regret first step. The ETSI TS 103 744 specification defines hybrid key establishment. In practice, most European authorities lean toward hybrid.

Hybrid as an Interim Step in the US, UK and Australia

United States, national security. The NSA’s CNSA 2.0 FAQ says the NSA “will not require NSS developers to use hybrid certified products for security purposes,” accepts that “product availability and interoperability requirements may lead to adopting hybrid solutions,” and states that “hybrid solutions will not be integrated into eventual deployable solutions.” CNSA 2.0 sets exclusive-use dates: software and firmware signing and traditional networking by 2030; web, cloud, operating systems, niche equipment and legacy systems by 2033. My May version said CNSA 2.0 allows hybrid during the transition. It is closer to say that the NSA tolerates hybrid where interoperability forces it.

United States, civilian agencies. OMB M-26-15 describes hybrid approaches as “an intricate and resource-intensive stopgap” and leaves the choice to agency risk assessments. Neither EO 14412 nor M-26-15 prohibits hybrid.

United Kingdom. The NCSC says that if a PQ/T hybrid scheme is chosen, it should be used as an interim measure within a framework that allows a straightforward migration to PQC-only. The NCSC also points out that hybrids cost more and mean migrating twice. It has not set a date for ending hybrid use.

Australia. ASD “does not recommend, but does not prohibit, the use of post-quantum/traditional (PQ/T) hybrid schemes” and expects all organizations to transition to purely post-quantum algorithms. The ISM prefers ML-KEM-1024 and ML-DSA-87 and approves ML-KEM-768 and ML-DSA-65 only until the end of 2030.

Hybrid as a Transitional Option in Asia

Japan’s National Cyber Command Office recommends crypto-agility and hybrid PQ/T schemes as transitional strategies without mandating them. Malaysia’s NACSA roadmap encourages early hybrid adoption in public-sector pilots. Brunei’s July 2026 PQC Migration Framework recommends hybrid, such as ML-KEM with ECDH, where appropriate. Singapore’s CSA, in its Quantum-Safe Migration Handbook, treats hybrid deployment as a useful interim strategy, to be chosen on a risk basis rather than mandated. India’s roadmap builds PQC and hybrid pilots into the foundations phase for critical infrastructure.

No Stated Position

Canada expects PQC to run alongside legacy algorithms at first and the legacy algorithms to be disabled, isolated or tunnelled once everything works, but takes no position on hybrid as such. South Korea, the UAE, SAMA, the HKMA, the Bank of Israel and the Dutch national quantum strategy say nothing on the question. NATO’s public quantum roadmap states no hybrid policy, although its members’ national agencies take both sides of the split.

The Case for Hybrid

The European position rests on a specific technical concern: what if the PQC algorithms, or their implementations, turn out to be weaker than expected?

ML-KEM is based on the Module Learning with Errors problem. Lattice cryptography goes back to the mid-1990s. Regev introduced Learning with Errors in 2005, and the module variant ML-KEM relies on was formalized around 2012. RSA (1977) and elliptic curve cryptography (proposed in 1985) have longer records against classical cryptanalysis: Shor’s algorithm showed in 1994 that a quantum computer would break both, and classical attacks have still not broken them at recommended key sizes. ML-KEM’s predecessor, CRYSTALS-Kyber, went through every round of NIST’s 2016–2024 process and extensive academic scrutiny, but standardized ML-KEM deployments have a short operational track record.

Hybrid mode provides insurance. If a novel classical attack breaks ML-KEM (or any PQC algorithm), the classical component still protects the connection. If a quantum computer breaks the classical component, the PQC component protects it. A correctly designed hybrid keeps the session key secret as long as one component and the way the two are combined stay secure. It does not protect against failures the two halves share, such as a broken random number generator, memory corruption or a downgrade, and a hybrid key exchange does nothing for authentication. BSI’s position is that this belt-and-suspenders approach is warranted while PQC algorithms accumulate a track record.

The evidence from 2026 is mostly about implementations, and it strengthens the case. In June, Daniel J. Bernstein demonstrated key recovery against buggy ML-DSA implementations in under a second and argued that deploying ML-DSA on its own damages security compared with hybrid Ed25519+ML-DSA; I made the engineering version of that argument in The PQC Migration’s Biggest Risk Isn’t Quantum Computers. In late July, a researcher described key recovery against wolfSSL’s ML-KEM-1024, with an IACR preprint following in August: an incomplete check in hand-written assembly let the attacker recover about 98% of a reused private key’s coefficients from shipped binaries, using a few hundred chosen ciphertexts sent to a decapsulation oracle. wolfSSL fixed the flaw in version 5.9.2. The attack needs a reused key and an observable decapsulation response, so ephemeral TLS key shares are not exposed to it in the same way. The algorithm was fine and the code was not; in a hybrid deployment with a reused key, the classical half would have stayed intact.

The mathematical questions are more speculative but still open. A peer-reviewed CRYPTO 2026 paper linked Module-LWE to a structured dihedral problem that several research groups are attacking with quantum algorithms, and Daniel Simon posted a preliminary claim of a polynomial-time quantum algorithm for the dihedral coset problem. The claim is disputed: Gupte, Ragavan and Zhandry posted a rebuttal in August arguing that the algorithm cannot solve the problem, and Simon revised his paper with a response in October. Neither result breaks ML-KEM. Both are the kind of result the hybrid camp has in mind, although a quantum attack that broke both the lattice and the elliptic-curve component would defeat a hybrid as well.

ANSSI’s position is the most conservative. Its follow-up position paper extends the hybrid recommendation to digital signatures. Most hybrid discussions focus on KEMs, because the HNDL threat drives the urgency around confidentiality. ANSSI argues that signature algorithms deserve the same caution: if ML-DSA is broken, a hybrid signature that includes a classical signature still provides authentication and integrity. Hybrid signatures cost more in size and verification time, and ANSSI considers the security margin worth it.

Conservative algorithm choices need revisiting too. BSI has long listed FrodoKEM and Classic McEliece as conservative alternatives to ML-KEM. On 1 October 2026 it advised against using Classic McEliece in new developments after researchers estimated key recovery below the scheme’s claimed security levels, and it plans to revise the guideline in early 2027. BSI notes that no practical attack on the recommended parameter sets has been shown. Hybrid protects against a broken PQC algorithm; it does not remove the need to change algorithms when the evidence changes.

The Case Against Hybrid

Australia’s decision not to recommend hybrid is an engineering judgment about complexity, and the US and UK positions now follow the same judgment.

Hybrid key exchange runs two key-establishment components in every handshake, and their outputs are combined into one secret. Two algorithm implementations must be maintained, patched and tested, and both are attack surfaces. ML-KEM accounts for most of the size. In RFC 10024’s X25519MLKEM768, the client’s key share is 1,216 bytes, 1,184 of them ML-KEM-768 and 32 X25519; the server’s share is 1,120 bytes. Against pure ML-KEM, hybrid adds 32 bytes in each direction, so the argument against hybrid is about complexity.

ASD’s position appears to be that this complexity creates more operational risk during the transition than it removes in cryptanalytic risk. If you deploy PQC, deploy it with the strongest parameter set and spend your engineering effort on getting one implementation right rather than on managing the interaction between two cryptographic stacks. OMB’s “intricate and resource-intensive stopgap” is the same argument in federal language, and the NCSC’s point about migrating twice is the cost version of it: an organization that goes hybrid now has to remove the classical half later.

There is also a timeline argument. Hybrid mode assumes you will eventually drop the classical component, and organizational inertia is powerful. A system running hybrid PQC in 2027 may still be running hybrid in 2035 because nobody prioritized the switchover. Australia’s guidance aims at pure PQC from the start, so there is no second switchover to forget.

What the IETF Standardized

The internet’s standards body has now written down both answers, with a clear default. RFC 10024, published in August 2026, standardizes hybrid ML-KEM key exchange for TLS 1.3 and marks X25519MLKEM768 as “Recommended: Y.” SecP256r1MLKEM768 and SecP384r1MLKEM1024 are registered with “Recommended: N,” which under RFC 9847 means the IETF has not designated them as recommended; entries it discourages get a separate “D”. RFC 9954, published in July, describes the general hybrid construction. Pure ML-KEM for TLS, which had a contested path through the working group, was approved by the IESG on 3 September 2026 as an Informational document with its code points marked “Recommended: N.” ML-DSA in TLS was approved as Informational in July, held during an appeal and released to the RFC Editor in September.

Outside TLS, RFC 9980 brought post-quantum OpenPGP in June 2026, with composite ML-KEM encryption and ML-DSA signatures plus standalone SLH-DSA signatures. The LAMPS composite-signature draft for X.509 was still a draft in mid-2026.

The practical effect is that hybrid X25519MLKEM768 is the most widely deployed PQC key exchange on the public internet, and pure ML-KEM is available for the environments, such as NSS, that require it.

Why I Expect the Disagreement to Last

Both positions are defensible on their own terms. The European agencies are optimizing for cryptographic and implementation risk. The US, UK and Australian agencies are optimizing for operational simplicity and a single migration. They weight different risks differently, based on different institutional cultures and different assessments of where the greater danger lies.

Since May the gap has widened. The US federal government put its stopgap language into an OMB memo that binds every civilian agency, while BSI wrote its preference into dated end points for classical-only cryptography and the EUCC guidance says lattice-based schemes should not stand alone. These are published policies that agencies have invested institutional credibility in, and NATO’s public roadmap states no hybrid policy of its own.

I expect the divergence to persist at least into the early 2030s, and organizations should plan on that assumption. I’ve argued this in the PQC standards fragmentation analysis and in the broader context of sovereignty in the PQC era. Countries make different PQC implementation choices for the same reasons they make different choices about encryption backdoors, QKD investment and domestic algorithm development: cryptographic policy is national security policy, and national security priorities differ.

What to Actually Implement

If you operate in a single jurisdiction, follow that jurisdiction’s guidance.

If you operate across borders, you need a strategy that satisfies the strictest applicable requirement without creating an unmanageable patchwork. Here’s my recommendation, based on working with organizations facing exactly this problem:

Deploy hybrid key exchange now for commercial and European-facing services. X25519MLKEM768 is the default in OpenSSL 3.5, enabled by default in Chrome and Firefox, and the recommended hybrid group in RFC 10024. For compatible general-purpose TLS it fits BSI’s and ANSSI’s hybrid recommendations, the EUCC guidance on lattice-based schemes, the NCSC’s interim guidance and M-26-15’s agency discretion. ASD does not prohibit hybrid; its ISM prefers ML-KEM-1024 and approves ML-KEM-768 only until the end of 2030. Regulated deployments still need their own check of the required assurance level, algorithm profile and validation, and a hybrid key exchange does not make authentication post-quantum.

Follow CNSA 2.0 for National Security Systems. If you supply into NSS, build to ML-KEM-1024 for key establishment and ML-DSA-87 for general-purpose signatures, and use LMS or XMSS for software and firmware signing as CNSA 2.0 specifies. Use hybrid only where NSA guidance or interoperability requires it, and plan for the classical component to be gone by 2030 for software and firmware signing and traditional networking and by 2033 for everything else. Test pure PQC operation well before those dates.

Architect for per-deployment configuration. Your TLS configuration, VPN policy and PKI hierarchy should be able to switch between hybrid and pure PQC per deployment, configured for the contract, security domain and technical profile each one serves. An Australian government gateway might run ML-KEM-1024 on its own; a German government gateway runs hybrid. The internal PKI issues certificates that can carry classical and PQC signature chains. Crypto-agility is the prerequisite for making this work without parallel infrastructure.

For signatures, use hybrid where ANSSI applies, and weigh it everywhere else. Hybrid signatures cost more in performance and bandwidth than hybrid KEMs, and most jurisdictions have not taken a position on them. If your products need ANSSI qualification or serve French government clients, hybrid signatures are the safer choice. Elsewhere, pure ML-DSA is acceptable, but the 2026 implementation bugs are a reason to keep a classical signature alongside it in systems you cannot patch quickly.

Track the IETF work. RFC 9954 and RFC 10024 settled hybrid TLS key exchange; pure ML-KEM and ML-DSA in TLS are approved as Informational; composite X.509 signatures are still in draft. Implementation details will keep changing, which is one more reason not to hardcode a hybrid construction that a later RFC supersedes.

The Practical Takeaway

The hybrid question looks like a technical debate about TLS configurations, but it is a governance and architecture question. The technical implementation of hybrid mode is straightforward: OpenSSL 3.5 does it by default. The hard part is deciding which mode applies to which deployment, documenting that decision in a way that auditors and regulators in several jurisdictions will accept, and keeping the flexibility to change the answer when requirements change.

The organizations I’ve seen handle this well separated the algorithm decision from the architecture decision early in their migration programs. They built infrastructure that could run hybrid or pure, then configured each environment for its regulatory context. The organizations that struggle picked one mode globally, usually whatever their home jurisdiction recommended, and then discovered they needed the other mode for a different market.

Build for both. Configure per environment. And don’t assume the current disagreement will resolve before you need to ship.

From the author