BSI TR-02102-1 and post-quantum cryptography: the 2026 recommendations

BSI TR-02102-1 is the technical guideline on cryptographic mechanisms published by the German Federal Office for Information Security (BSI, Bundesamt für Sicherheit in der Informationstechnik). Version 2026-01, dated 23 January 2026, recommends hybrid post-quantum key agreement, treats classical key agreement used alone as recommended only until the end of 2031 (end of 2030 where protection needs are very high), and sets RSA keys of at least 3000 bits. It is a technical guideline, not a law, and this article shows how to turn those three points into a TLS configuration you can test.

What TR-02102-1 is, and what it is not

TR-02102-1 lists the cryptographic mechanisms the BSI considers suitable, with key lengths and a time horizon attached to each. It is guidance. By itself it creates no obligation for a private company. It becomes binding only when something else makes it binding: a contract with a German client, a sector rule, a public procurement requirement, or an internal cryptographic policy that cites it. That last sentence is our reading of how the document is used in practice, not a quotation from the guideline.

Two consequences follow for teams serving German customers. First, always cite the version. Every figure in this article comes from version 2026-01, and you should requote them from the version in force when you are audited. Second, a supplier questionnaire asking whether you are TR-02102-1 compliant is really asking whether your deployed configuration matches the recommended mechanisms and their horizons. The dated milestones are summarised on our BSI TR-02102-1 reference page, and the guideline itself is published by the BSI as a PDF: BSI TR-02102-1.

The 2026-01 position on key agreement

The guideline recommends hybrid post-quantum key agreement. Hybrid means combining a classical key agreement, such as elliptic curve Diffie-Hellman (ECDH), with a post-quantum key encapsulation mechanism (KEM), so that the session key stays secure if either component holds. In TLS 1.3 the post-quantum component in production today is ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), standardised by NIST as FIPS 203 on 13 August 2024.

Two dates matter. Classical key agreement used alone is recommended only until the end of 2031. Where protection needs are very high, that becomes the end of 2030. These are recommendations with a horizon, not a switch-off date imposed by a regulator.

Key agreement comes first for a physical reason, not a regulatory one. Recorded TLS traffic is protected only by the key exchange that produced its session keys. An attacker who stores ciphertext today can decrypt it later if the key exchange becomes breakable, a pattern known as harvest now, decrypt later (HNDL). Signatures and certificates do not have that property: a signature verified today cannot be forged retroactively. This is why the key agreement horizon arrives before any signature migration.

RSA of at least 3000 bits, and what it does not buy you

Version 2026-01 sets a minimum RSA key length of 3000 bits. In practice, certificate authorities, hardware security modules and TLS libraries work with 3072 bit RSA keys, which satisfies the threshold and is widely supported. Checking the key length of a deployed certificate takes one command.

openssl x509 -in server.crt -noout -text | grep -i public-key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
openssl req -new -key server.key -out server.csr

Be precise about what this achieves. A longer RSA key raises the classical security level. It does not make the key quantum resistant: RSA, ECDSA, EdDSA, ECDH, finite-field Diffie-Hellman and DSA are all broken by Shor's algorithm on a sufficiently large quantum computer, whatever the key size. The 3000 bit floor and the hybrid key agreement recommendation answer two different problems, and meeting one does not satisfy the other.

For comparison, NIST IR 8547 proposes deprecating quantum-vulnerable algorithms at the 112 bit security level, which includes RSA-2048, after 2030, and disallowing all quantum-vulnerable public-key algorithms after 2035. That document is an initial public draft published on 12 November 2024 and still a draft: NIST IR 8547 (ipd). A German minimum of 3000 bits and a draft US deprecation of 2048 bit keys point in the same direction, from two different texts with two different statuses.

Mapping the recommendation into a TLS configuration

The guideline recommends a mechanism, hybrid key agreement. Choosing the concrete TLS 1.3 group is an implementation decision, and what follows is our practical mapping rather than a quotation. The hybrid groups registered with IANA are X25519MLKEM768 (codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) and SecP384r1MLKEM1024 (0x11ED, 4589), listed in the IANA TLS parameters registry. Their use in TLS 1.3 is described in RFC 10024 (August 2026). Current Chrome, Edge and Firefox already offer X25519MLKEM768 by default, so enabling it server side changes what real browsers negotiate immediately.

Step 1: confirm the library supports the groups

OpenSSL 3.5 or later is required for the ML-KEM TLS groups in OpenSSL. Check before touching any server configuration.

openssl version
openssl list -tls-groups | grep -i mlkem

Step 2: offer the hybrid group first, keep a classical fallback

Order matters: the hybrid group goes first, classical groups stay behind it so that older clients still connect. Never remove the classical fallback in the same change.

# nginx, built against OpenSSL 3.5 or later
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# Apache httpd with mod_ssl, OpenSSL 3.5 or later
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

Directive names and support differ between distributions and between builds of the same server version, so verify against your own package rather than assuming. Full recipes for nginx, Apache, HAProxy and Caddy are in our guide to enabling ML-KEM on common web servers. Test in staging before production.

Step 3: verify what is actually negotiated

openssl s_client -connect example.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null | grep -i negotiated

A successful handshake prints the negotiated group. Repeat the same test without the hybrid group to confirm that classical clients still connect.

How the German horizon compares with other timelines

German dates do not exist in isolation. If you serve clients in several countries, the earliest applicable horizon drives the plan.

Evidence a German client or auditor will ask for

NIS2, Directive (EU) 2022/2555, Article 21(2)(h), requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. For financial entities, the DORA regulatory technical standards, Commission Delegated Regulation (EU) 2024/1774, Article 6, require an encryption and cryptographic controls policy including provisions for updating or changing cryptographic technology based on developments in cryptanalysis. Neither text names post-quantum algorithms.

Our interpretation, clearly labelled as such: naming TR-02102-1 and its version inside that policy, with the mechanisms you accept and the horizon you apply, is one practical way to show the policy is anchored to a recognised reference and has a review trigger. Keep the artefacts simple and dated: the policy itself, an inventory of TLS endpoints with their negotiated groups and certificate key sizes, and a scan result per endpoint. Our page on NIS2 Article 21(2)(h) sets out what the directive asks for. This article is information, not legal advice.

Next step: check what your servers negotiate today

Before writing any plan, measure the current state. Scan your domain with PQC Status to see which TLS versions, key agreement groups and certificate algorithms your server actually offers, including 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 the result as the first line of your inventory, then enable the hybrid group in staging, keep the classical fallback, and record the before and after for each endpoint.