ANSSI and hybrid post-quantum cryptography: what France expects

ANSSI, the French national cybersecurity agency (Agence nationale de la sécurité des systèmes d'information), does not ask organizations to replace classical cryptography with post-quantum cryptography. It asks for both at the same time. Hybridization, meaning a key establishment whose session key depends on a classical algorithm and on a post-quantum key encapsulation mechanism (KEM), is mandatory inside the scope ANSSI regulates. Outside that scope ANSSI publishes recommendations, and it states that these recommendations are not yet regulatory obligations.

What ANSSI means by hybridization

A hybrid handshake performs two key establishments and combines both shared secrets into the session key. An attacker has to break both to recover the traffic. That design answers two separate worries at once. The classical half preserves the guarantees of two decades of analysis and of well audited implementations such as X25519 or ECDH on NIST curves. The post-quantum half, in practice ML-KEM as standardized by NIST in FIPS 203 on 2024-08-13 (csrc.nist.gov), removes the exposure to harvest now, decrypt later (HNDL), where an attacker records encrypted traffic today and decrypts it years later. Recorded traffic is protected only by the key exchange, which is why key exchange migrates first and signatures or certificates can follow.

On the wire, hybridization is simply a named group. IANA has registered X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED) for TLS 1.3 (IANA TLS parameters), and RFC 10024 (August 2026) specifies post-quantum traditional hybrid key agreement mechanisms for TLS 1.3 (rfc-editor.org). Current Chrome, Edge and Firefox offer X25519MLKEM768 by default, so turning it on server side is normally invisible to users. For SSH, OpenSSH added mlkem768x25519-sha256 in 9.9 (2024-09-19) and made it the default key agreement in 10.0 (2025-04-09), with 10.1 (2025-10-06) warning when a connection negotiates a non post-quantum key agreement (OpenSSH release notes).

Where hybridization is mandatory, and where it is advice

ANSSI's requirement is binding in the perimeter it administers, as described in its post-quantum FAQ (cyber.gouv.fr):

• Product qualification: security products that carry, or seek, an ANSSI qualification.
• Diffusion Restreinte (DR): French restricted level information systems and the products protecting them.
• SAIV and SIIV: the sectors of vital importance and their vitally important information systems.

Everywhere else, the position is a recommendation. A French company that does not sell qualified products, does not process Diffusion Restreinte information and is not an operator of vital importance is not bound today by ANSSI's post-quantum doctrine, and ANSSI says so itself. That hedge matters when you write a roadmap: do not present ANSSI guidance to your board as a legal deadline when it is not one. You may still be bound by other texts that say nothing about quantum computing but everything about changing algorithms: DORA Article 6 of Commission Delegated Regulation (EU) 2024/1774 requires an encryption and cryptographic controls policy including provisions for updating or changing cryptographic technology based on developments in cryptanalysis (EUR-Lex), and NIS2 Article 21(2)(h) requires policies and procedures on the use of cryptography (EUR-Lex). Our reading, labelled as interpretation and not as a requirement of either text, is that a hybrid key exchange plan is one credible way to show such a policy is alive rather than decorative. This article is information about published guidance, not legal advice.

The dates ANSSI gives

Two signals drive procurement in France. ANSSI aims to require post-quantum cryptography for products entering qualification from 2027, and it considers that after 2030 it will no longer be reasonable to buy products without post-quantum cryptography. The second is a recommendation, not a prohibition, but it is a strong hint for any multi-year contract signed now. The full dated record is kept on our ANSSI doctrine page.

These dates sit close to the European timeline: the EU Coordinated Implementation Roadmap v1.1, published 2025-06-23, calls for a cryptographic inventory and national roadmaps by the end of 2026, high-risk use cases migrated by the end of 2030 and medium-risk by the end of 2035 (European Commission). That roadmap is coordinated guidance for Member States, not a regulation binding companies, and our roadmap page keeps the milestones with their status. Germany's BSI TR-02102-1, a technical guideline, points the same way: version 2026-01 recommends hybrid post-quantum key agreement and recommends classical key agreement alone only until the end of 2031, or the end of 2030 for very high protection needs.

Higher security levels where possible

ML-KEM has three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. ANSSI expresses a preference for the higher security levels when performance and interoperability allow it. In practice, for public web services, that means X25519MLKEM768 as the interoperable baseline, because browsers offer it today, with SecP384r1MLKEM1024 reserved for links where both ends are under your control and the extra handshake bytes are acceptable. The NSA takes a comparable direction in a different regime: CNSA 2.0, which applies to US National Security Systems only, specifies ML-KEM-1024, ML-DSA-87 and AES-256.

Two cautions. Raising the parameter set is never a reason to drop the classical half: a pure ML-KEM group such as MLKEM768 satisfies nobody's hybridization requirement. And pre-standard Kyber groups, in particular X25519Kyber768Draft00 (codepoint 0x6399), are obsolete and must be replaced by the ML-KEM groups rather than kept as a fallback.

What to deploy, and how to check it

Check what you negotiate today

Start read-only. ML-KEM groups in OpenSSL require OpenSSL 3.5 or later, so check the version first, then ask a server for a specific group.

openssl version

openssl s_client -connect example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

If the group line comes back empty or falls back to X25519, the server has no hybrid group enabled. Server side, keep the hybrid group first and a classical group after it, so that an old client still connects, and test in staging before production. On nginx built against OpenSSL 3.5 or later the directive is:

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Syntax differs between web servers and between versions, so follow the per-server detail in our guide to enabling ML-KEM on nginx, Apache, HAProxy and Caddy rather than copying one directive everywhere.

Evidence to keep

Whether ANSSI's rules bind you or not, the artefacts an auditor or a public-sector client will ask for are the same:

For the second row, record the group name, not a pass or fail: a negotiated X25519MLKEM768 is a fact an auditor can re-verify.

Next step: measure before you plan

ANSSI's doctrine is readable in one afternoon. Knowing which of your own services already offer a hybrid group takes a measurement. You can scan your domain with PQC Status for free to see the TLS versions, cipher suites, certificate chain and whether a hybrid ML-KEM group is negotiated. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation. Use it as the first line of the inventory, then enable X25519MLKEM768 on your public endpoints with a classical fallback, and add a hybrid key exchange requirement to the next contract you renew ahead of the after-2030 purchasing signal.