Marin Ivezic
An engineer setting up a TLS server used to have one sensible answer for key exchange: ECDHE over X25519 or P-256. Now the answer depends on which government’s clients sit at the other end of the connection. Germany’s BSI wants a post-quantum algorithm run alongside a classical one. Australia’s ASD wants ML-KEM-1024 on its own. The US CNSA 2.0 suite permits either during the transition, then sets 2030 as the date networking equipment goes post-quantum only. Three authorities, three answers, one configuration file.
This is the hardest coordination problem in post-quantum migration, and it draws less attention than the deadlines do. Timelines can be sequenced. Work the earliest one first and the rest fall into place behind it. Deployment modes can’t be sequenced. A product shipping into Frankfurt and Canberra in the same quarter has to satisfy both positions at once.
Who requires what
Hybrid expected. Germany’s BSI, the Federal Office for Information Security, treats hybrid as the normal production configuration in its TR-02102-1 technical guideline: a post-quantum key encapsulation mechanism (KEM), the algorithm two parties use to agree a shared secret, combined with a classical key exchange, with both contributing to the final key. France’s ANSSI, the national cybersecurity agency, strongly recommends hybrid for anything protecting data past 2030. ETSI TS 103 744 specifies a hybrid key exchange construction.
Hybrid discouraged. Australia’s ASD, the Australian Signals Directorate, does not recommend it. Its Information Security Manual names ML-KEM-1024 as the target parameter set, and treats ML-KEM-768 as acceptable only until 2030.
Hybrid as a waypoint. The Commercial National Security Algorithm Suite 2.0, CNSA 2.0, allows hybrid during migration without requiring it. The dates for exclusive post-quantum use are published: 2030 for networking equipment, 2033 for web and cloud services and operating systems, 2035 for all national security systems. The UK’s NCSC, the National Cyber Security Centre, recommends hybrid where practical and has set no date for ending it.
No published position. Japan treats hybrid as one transitional option among several. Canada, India, Singapore, South Korea and the UAE have not committed publicly.
The case for hybrid
The European position rests on age. ML-KEM (formerly Kyber) gets its security from the Module Learning With Errors problem, a lattice construction from around 2012 built on Regev’s LWE work of 2005. RSA was published in 1977. Elliptic curve cryptography was proposed in 1985. Both absorbed decades of attack from academia and from intelligence agencies before quantum algorithms became the reason to retire them. ML-KEM came through an eight-year NIST competition and heavy public scrutiny, and it was standardized as FIPS 203 in August 2024. It has not had thirty years, and we do not yet know how the lattice problems will age.
Hybrid buys insurance against exactly that gap. A classical break of ML-KEM still leaves the elliptic curve half protecting the session. A quantum break of the elliptic curve half still leaves ML-KEM protecting it. Both have to fail together before the traffic does.
ANSSI extends the same logic to signatures. Most hybrid discussion is about KEMs, because harvest-now-decrypt-later, the practice of recording encrypted traffic today to decrypt it once a quantum computer exists, puts confidentiality on a clock that authentication does not share. ANSSI’s answer is that a broken ML-DSA (formerly Dilithium) is still a broken signature scheme, and a composite that carries a classical signature alongside it still authenticates. Hybrid signatures cost more than hybrid KEMs in bytes and in verification time. ANSSI takes the trade.
BSI goes further on algorithm choice, naming FrodoKEM and Classic McEliece as acceptable alongside ML-KEM. Both are slower and larger. Both rest on security arguments that are older or more conservative.
The case against hybrid
Australia’s position is an engineering judgment, not skepticism about lattices.
Hybrid doubles the cryptographic machinery in every connection. Two key exchanges run. Two implementations get maintained, patched and tested. Two sets of code carry two sets of bugs. An ML-KEM-768 encapsulation key is 1,184 bytes; the X25519 share adds another 32 on top. On constrained devices, metered links and latency-sensitive paths, that is a real cost rather than a rounding error.
ASD’s reading is that the added complexity creates more operational risk during the transition than it removes cryptographic risk. Deploy one algorithm, deploy the strongest parameter set, and spend the engineering budget on getting that one thing right.
There is a second argument, about time. Hybrid assumes a later removal step that nobody schedules. A system running hybrid in 2027 will still be running hybrid in 2037 unless someone owns the switchover and funds it. Australia forces the clean break at the start instead.
Why the disagreement will hold
Both positions defend well on their own terms. The European agencies are pricing cryptanalytic risk. ASD is pricing operational risk. The weightings differ because the institutions differ.
The prospects for harmonization are poor. The European guidance hardened a consensus rather than opened a negotiation, and BSI and ANSSI have both restated their positions rather than softened them. ASD has held its line across successive ISM updates. CNSA 2.0 has dates attached and a compliance regime behind them. These are published policies with institutional credibility invested in them, not drafts awaiting comment. Cryptographic policy is national security policy, and national security priorities are not converging. Plan for the split to persist into the 2030s.
What to build
For organizations shipping across borders, we recommend four moves.
Deploy hybrid key exchange as the default. Hybrid key exchange combining X25519 with ML-KEM-768 is available in mainstream TLS stacks. It satisfies BSI, ANSSI, the UK NCSC, CNSA 2.0 during the transition, and every jurisdiction with no published position. It also satisfies Australia in the near term, since ASD discourages hybrid rather than prohibiting it and ML-KEM is present either way.
Make the mode a deployment setting. TLS profiles, VPN policy and PKI hierarchies should switch between hybrid and pure post-quantum per environment, not per connection. The Canberra-facing gateway runs ML-KEM-1024 alone. The Frankfurt-facing gateway runs hybrid. That flexibility is what crypto-agility means in practice: changing the algorithm and the mode without re-architecting the system around either.
Schedule the hybrid exit where one is required. In CNSA 2.0 environments, 2030 and 2033 are the dates the classical half comes out. Test environments should run pure post-quantum long before then. Discovering that a stack cannot complete a handshake without the classical fallback is a problem you want in 2028, not in the last quarter before a deadline.
Treat signatures separately from key exchange. Composite signatures are the safer choice for products entering ANSSI evaluation or serving French government clients. Elsewhere, ML-DSA on its own is accepted and avoids the size penalty. Hybrid specifications for both key exchange and signatures are still moving through the IETF, so hardcoding one construction is a good way to turn a compliant deployment into a non-compliant one.
What this asks of a team
Selecting a hybrid group in a TLS stack is a configuration change, not new code. Deciding which mode applies where, recording that decision so auditors in three jurisdictions accept it, and keeping the architecture loose enough to change the answer in 2029 is the actual work.
That’s a skills question before it’s a product question. It needs people who can read BSI, ASD and CNSA guidance side by side, turn the differences into configuration profiles, and defend the mapping to a regulator who only cares about one of the three. Our post-quantum cryptography training at Quantum Academy works through the algorithms, the standards and the deployment decisions that follow from both. For migration methodology and governance structure, see pqcframework.org. For the deeper technical treatment of this divergence, see the original analysis on PostQuantum.com.
Build for both modes. Configure per environment. And do not plan around the disagreement resolving before you ship.