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 requires hybrid mode: ML-KEM combined with a classical key exchange, both running simultaneously. If it faces Australian government clients, ASD’s ISM guidance says deploy ML-KEM-1024 without hybrid, and stop offering classical asymmetric algorithms entirely by 2030. If it faces US National Security Systems, CNSA 2.0 allows hybrid during the transition but requires exclusive PQC use for networking equipment by 2030. Three governments, three answers to the same configuration question.

This is not a theoretical compliance exercise. It is the central implementation question in PQC migration, and the world’s major cybersecurity authorities have taken positions that cannot be reconciled into a single global configuration. As I discussed in The Global PQC Migration Clock, timeline divergence gets most of the attention. But the hybrid question is harder to manage, because timelines can be sequenced (do the earliest one first), while contradictory mode requirements must be satisfied simultaneously.

The Positions

Let me be precise about who requires what, because the nuances matter and get lost in summary.

Hybrid mandatory. Germany’s BSI mandates hybrid for all production PQC deployments in TR-02102-1 (January 2025 update). France’s ANSSI “strongly recommends” hybrid for all products protecting data beyond 2030. The ETSI TS 103 744 standard specifies hybrid key exchange. The October 2024 joint statement from 18 EU member state cybersecurity authorities endorsed hybrid as the transition strategy. The EU’s ECCG ACM v2 recommends PQ/T hybrid schemes. In practice, the European consensus is hybrid.

Hybrid discouraged. Australia’s ASD explicitly does not recommend hybrid. The ISM specifies ML-KEM-1024 as the required parameter set and ML-KEM-768 as acceptable only until 2030. The target is pure PQC from the outset.

Hybrid as transition, pure PQC as endpoint. The US under CNSA 2.0 allows hybrid during migration but sets explicit dates for exclusive PQC use: networking equipment by 2030, web/cloud/OS/legacy by 2033, all NSS by 2035. Hybrid is a waystation, not a destination. The UK’s NCSC recommends hybrid “where possible” but doesn’t mandate it, and hasn’t published a date for ending it.

No definitive position. Japan recommends hybrid as a transitional strategy without mandating it. Canada, India, Singapore, South Korea, and the UAE have not taken a public position on hybrid vs. pure.

The Case for Hybrid

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

ML-KEM is based on the Module Learning with Errors problem, a lattice construction that is roughly 20 years old. Compare that to RSA (published 1977) or elliptic curve cryptography (standardized in the 1990s), both of which have survived over 25 years of intensive cryptanalytic attack before quantum algorithms threatened them. ML-KEM has been through eight years of NIST evaluation and extensive academic scrutiny, but it has not been through three decades of adversarial pressure from the world’s best mathematicians and intelligence agencies.

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. You need both to fail simultaneously for the connection to be compromised. BSI’s position is that this belt-and-suspenders approach is warranted during the period when PQC algorithms are still accumulating their track record.

ANSSI’s position is even more conservative. Its follow-up position paper extends the hybrid recommendation to digital signatures, not just key exchange. Most hybrid discussions focus on KEMs, because the HNDL threat model drives urgency around confidentiality. But ANSSI argues that signature algorithms deserve the same caution: if ML-DSA is broken, a hybrid signature scheme that includes a classical signature still provides authentication and integrity. The performance cost is higher for hybrid signatures (larger signature sizes, longer verification times), but ANSSI considers the security margin worth it.

BSI goes further on algorithm selection, including FrodoKEM (whose security reduction to worst-case lattice problems is tighter than ML-KEM’s) and Classic McEliece (code-based, with a security argument dating to 1978) as acceptable alternatives. This reflects a philosophy I’d characterize as “trust the mathematics you can prove, not the mathematics that is merely believed hard.”

The Case Against Hybrid

Australia’s rejection of hybrid is not crypto-skepticism. It’s an engineering judgment about complexity.

Hybrid mode doubles the cryptographic machinery in every connection. Two key exchanges run in parallel. Two sets of keys are derived and combined. Two algorithm implementations must be maintained, patched, and tested. Two attack surfaces exist. In a TLS handshake, hybrid increases the ClientHello size substantially (ML-KEM-768 adds ~1,200 bytes to the key share; a hybrid combining that with X25519 adds the classical share on top). For constrained devices, bandwidth-limited networks, or latency-sensitive applications, the overhead is not trivial.

ASD’s position appears to be that this complexity creates more operational risk during the transition than it mitigates in theoretical cryptanalytic risk. If you’re going to deploy PQC, deploy it properly and cleanly, with the strongest parameter set (ML-KEM-1024), and spend your engineering effort on getting one thing right rather than on managing the interaction between two parallel cryptographic stacks.

There is also a timeline argument. Hybrid mode creates an implicit assumption that you’ll eventually drop the classical component. But 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 approach forces the clean break upfront: you’re either on classical or on PQC, with no comfortable middle ground that becomes permanent.

Why This Disagreement Won’t Resolve

Both positions are defensible on their own terms. The European agencies are optimizing for cryptographic risk. The Australian agency is optimizing for operational simplicity. Neither is wrong. They’re weighting different risks differently, based on different institutional cultures and different assessments of where the greater danger lies.

The prospects for international harmonization on this question are poor. The 18-member-state joint statement hardened European consensus around hybrid. ASD’s ISM guidance has been consistently anti-hybrid across multiple updates. CNSA 2.0 has locked in its hybrid-to-pure transition schedule with specific dates. These are not draft positions awaiting feedback. They’re published policy that agencies have invested institutional credibility in defending.

The divergence will persist at least through the 2030s, and organizations should plan accordingly. I’ve argued this in the PQC standards fragmentation analysis and in the broader context of sovereignty in the PQC era. Countries are making different PQC implementation choices for the same reasons they make different choices about encryption backdoors, QKD investment, and domestic algorithm development: because 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. Problem solved.

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. X25519MLKEM768 is already the default in OpenSSL 3.5 and in Chrome and Firefox’s TLS stacks. This configuration satisfies BSI, ANSSI, CNSA 2.0 (during transition), the UK NCSC, and every jurisdiction that hasn’t taken a position. It also satisfies Australia’s requirement in the near term, since ASD discourages hybrid but does not prohibit it, and ML-KEM is still present in the negotiation.

Architect for per-jurisdiction configuration. Your TLS configuration, VPN policy, or PKI hierarchy should support switching between hybrid and pure PQC modes at the deployment level. This is not per-connection overhead; it’s per-deployment-environment configuration. The Australian-facing VPN gateway runs ML-KEM-1024 pure. The German-facing gateway runs hybrid. The internal PKI issues hybrid certificates with classical and PQC signature chains. Crypto-agility is the prerequisite for making this work without maintaining parallel infrastructure.

Plan the hybrid exit for CNSA 2.0 environments. If you supply into US National Security Systems, mark 2030 (networking) and 2033 (everything else) as the dates when the classical component drops. Your test environments should validate pure PQC operation well before those dates. Don’t discover that your stack can’t function without the classical fallback six months before the exclusive-use deadline.

For signatures, follow ANSSI if you serve the French market. Hybrid signatures are more costly (performance and bandwidth) than hybrid KEMs, and most jurisdictions haven’t taken a position on them. But if your products require ANSSI certification or serve French government clients, hybrid signatures are the safer choice. If you don’t serve the French market, pure PQC signatures with ML-DSA are acceptable everywhere and avoid the performance penalty.

Track the IETF standards. The hybrid key exchange specification (draft-ietf-tls-hybrid-design, building on what’s deployed in browsers as X25519MLKEM768) and composite signature specifications (draft-ietf-lamps-pq-composite-sigs) are still evolving. Implementation details will change. This is another reason crypto-agility matters: you don’t want to hardcode a hybrid construction that gets superseded by a revised IETF RFC.

The Practical Takeaway

The hybrid question feels like a technical debate about TLS configurations, but it’s actually 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 multiple jurisdictions will accept, and maintaining the architectural flexibility to change the answer when requirements evolve.

The organizations I’ve seen handle this well share one trait: they separated the algorithm decision from the architecture decision early in their migration program. They built infrastructure that could run hybrid or pure, then configured each environment based on its regulatory context. The organizations that struggle are the ones that 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.