BSI TR-02102-1 und Post-Quanten-Kryptografie: die Empfehlungen für 2026

BSI TR-02102-1 ist die Technische Richtlinie zu kryptografischen Verfahren, herausgegeben vom Bundesamt für Sicherheit in der Informationstechnik (BSI). Version 2026-01 vom 23. Januar 2026 empfiehlt eine hybride Post-Quanten-Schlüsseleinigung, stuft eine allein eingesetzte klassische Schlüsseleinigung nur noch bis Ende 2031 als empfohlen ein (bis Ende 2030 bei sehr hohem Schutzbedarf) und legt RSA-Schlüssel mit mindestens 3000 Bit fest. Es handelt sich um eine Technische Richtlinie, nicht um ein Gesetz. Dieser Artikel zeigt, wie Sie diese drei Punkte in eine testbare TLS-Konfiguration umsetzen.

Was TR-02102-1 ist und was nicht

TR-02102-1 listet die kryptografischen Verfahren auf, die das BSI für geeignet hält, jeweils mit Schlüssellängen und einem Zeithorizont. Sie ist eine Orientierungshilfe. Für sich allein begründet sie keine Pflicht für ein privates Unternehmen. Verbindlich wird sie erst, wenn etwas anderes sie verbindlich macht: ein Vertrag mit einem deutschen Kunden, eine Branchenregelung, eine Anforderung in einer öffentlichen Ausschreibung oder eine interne Kryptografierichtlinie, die sie zitiert. Der letzte Satz gibt unsere Lesart der praktischen Verwendung des Dokuments wieder, kein Zitat aus der Richtlinie.

Für Teams mit deutschen Kunden ergeben sich daraus zwei Konsequenzen. Erstens: Nennen Sie immer die Version. Alle Angaben in diesem Artikel stammen aus Version 2026-01, und Sie sollten sie bei einem Audit aus der dann gültigen Version erneut zitieren. Zweitens: Ein Lieferantenfragebogen, der wissen will, ob Sie TR-02102-1-konform sind, fragt eigentlich, ob Ihre eingesetzte Konfiguration den empfohlenen Verfahren und deren Horizonten entspricht. Die datierten Meilensteine sind auf unserer Referenzseite zu BSI TR-02102-1 zusammengefasst, und die Richtlinie selbst veröffentlicht das BSI als PDF: BSI TR-02102-1.

Die Position von 2026-01 zur Schlüsseleinigung

Die Richtlinie empfiehlt eine hybride Post-Quanten-Schlüsseleinigung. Hybrid bedeutet, eine klassische Schlüsseleinigung wie Elliptic Curve Diffie-Hellman (ECDH) mit einem Post-Quanten-Schlüsselkapselungsverfahren (Key Encapsulation Mechanism, KEM) zu kombinieren, sodass der Sitzungsschlüssel sicher bleibt, solange eine der beiden Komponenten standhält. In TLS 1.3 ist die heute produktiv eingesetzte Post-Quanten-Komponente ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), von NIST am 13. August 2024 als FIPS 203 standardisiert.

Zwei Daten sind entscheidend. Eine allein eingesetzte klassische Schlüsseleinigung wird nur noch bis Ende 2031 empfohlen. Bei sehr hohem Schutzbedarf gilt stattdessen Ende 2030. Es handelt sich um Empfehlungen mit einem Horizont, nicht um ein von einer Aufsichtsbehörde verordnetes Abschaltdatum.

Die Schlüsseleinigung steht aus einem technischen, nicht aus einem regulatorischen Grund an erster Stelle. Aufgezeichneter TLS-Verkehr ist nur durch den Schlüsselaustausch geschützt, aus dem seine Sitzungsschlüssel hervorgegangen sind. Ein Angreifer, der heute Chiffretext speichert, kann ihn später entschlüsseln, falls der Schlüsselaustausch brechbar wird. Dieses Muster ist als Harvest now, decrypt later (HNDL) bekannt. Signaturen und Zertifikate haben diese Eigenschaft nicht: Eine heute verifizierte Signatur lässt sich nicht nachträglich fälschen. Deshalb kommt der Horizont für die Schlüsseleinigung vor jeder Migration der Signaturen.

RSA mit mindestens 3000 Bit und was es Ihnen nicht bringt

Version 2026-01 legt eine Mindestlänge für RSA-Schlüssel von 3000 Bit fest. In der Praxis arbeiten Zertifizierungsstellen, Hardware-Sicherheitsmodule und TLS-Bibliotheken mit 3072-Bit-RSA-Schlüsseln, die den Schwellenwert erfüllen und breit unterstützt werden. Die Schlüssellänge eines eingesetzten Zertifikats prüfen Sie mit einem einzigen Befehl.

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

Seien Sie präzise darin, was damit erreicht wird. Ein längerer RSA-Schlüssel erhöht das klassische Sicherheitsniveau. Er macht den Schlüssel nicht quantenresistent: RSA, ECDSA, EdDSA, ECDH, Diffie-Hellman über endlichen Körpern und DSA werden alle durch den Shor-Algorithmus auf einem ausreichend großen Quantencomputer gebrochen, unabhängig von der Schlüssellänge. Die Untergrenze von 3000 Bit und die Empfehlung zur hybriden Schlüsseleinigung beantworten zwei unterschiedliche Probleme, und die Erfüllung des einen genügt nicht für das andere.

Zum Vergleich: NIST IR 8547 schlägt vor, quantenanfällige Algorithmen auf dem Sicherheitsniveau von 112 Bit, darunter RSA-2048, nach 2030 als veraltet einzustufen und alle quantenanfälligen Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen. Dieses Dokument ist ein am 12. November 2024 veröffentlichter erster öffentlicher Entwurf und weiterhin ein Entwurf: NIST IR 8547 (ipd). Ein deutsches Minimum von 3000 Bit und eine im Entwurf befindliche US-Abkündigung von 2048-Bit-Schlüsseln weisen in dieselbe Richtung, aus zwei verschiedenen Texten mit zwei verschiedenen Status.

Die Empfehlung in eine TLS-Konfiguration übertragen

Die Richtlinie empfiehlt ein Verfahren, die hybride Schlüsseleinigung. Die Wahl der konkreten TLS-1.3-Gruppe ist eine Implementierungsentscheidung, und das Folgende ist unsere praktische Zuordnung, kein Zitat. Die bei der IANA registrierten hybriden Gruppen sind X25519MLKEM768 (Codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) und SecP384r1MLKEM1024 (0x11ED, 4589), aufgeführt im IANA-Register der TLS-Parameter. Ihre Verwendung in TLS 1.3 beschreibt RFC 10024 (August 2026). Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 bereits standardmäßig an. Eine serverseitige Aktivierung verändert also sofort, was echte Browser aushandeln.

Schritt 1: Prüfen, ob die Bibliothek die Gruppen unterstützt

Für die ML-KEM-TLS-Gruppen in OpenSSL ist OpenSSL 3.5 oder neuer erforderlich. Prüfen Sie dies, bevor Sie eine Serverkonfiguration anfassen.

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

Schritt 2: Die hybride Gruppe zuerst anbieten, einen klassischen Fallback beibehalten

Die Reihenfolge ist wichtig: Die hybride Gruppe steht an erster Stelle, klassische Gruppen folgen dahinter, damit ältere Clients weiterhin eine Verbindung aufbauen. Entfernen Sie den klassischen Fallback niemals in derselben Änderung.

# 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

Namen und Unterstützung der Direktiven unterscheiden sich zwischen Distributionen und zwischen Builds derselben Serverversion. Prüfen Sie daher anhand Ihres eigenen Pakets, statt Annahmen zu treffen. Vollständige Anleitungen für nginx, Apache, HAProxy und Caddy finden Sie in unserem Leitfaden zur Aktivierung von ML-KEM auf gängigen Webservern. Testen Sie in Staging, bevor Sie in Produktion gehen.

Schritt 3: Prüfen, was tatsächlich ausgehandelt wird

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

Ein erfolgreicher Handshake gibt die ausgehandelte Gruppe aus. Wiederholen Sie denselben Test ohne die hybride Gruppe, um zu bestätigen, dass klassische Clients weiterhin eine Verbindung aufbauen.

Wie sich der deutsche Horizont zu anderen Zeitplänen verhält

Die deutschen Daten stehen nicht für sich allein. Wenn Sie Kunden in mehreren Ländern bedienen, bestimmt der früheste anwendbare Horizont die Planung.

Nachweise, die ein deutscher Kunde oder Auditor verlangen wird

NIS2, Richtlinie (EU) 2022/2555, Artikel 21(2)(h), verlangt Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. Für Finanzunternehmen verlangen die technischen Regulierungsstandards zu DORA, Delegierte Verordnung (EU) 2024/1774 der Kommission, Artikel 6, eine Richtlinie für Verschlüsselung und kryptografische Kontrollen, einschließlich Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse. Keiner der beiden Texte nennt Post-Quanten-Algorithmen.

Unsere Interpretation, ausdrücklich als solche gekennzeichnet: TR-02102-1 samt Version in dieser Richtlinie zu nennen, zusammen mit den von Ihnen akzeptierten Verfahren und dem angewandten Horizont, ist ein praktischer Weg, um zu zeigen, dass die Richtlinie an einer anerkannten Referenz verankert ist und einen Auslöser für Überprüfungen hat. Halten Sie die Nachweise einfach und datiert: die Richtlinie selbst, ein Inventar der TLS-Endpunkte mit ihren ausgehandelten Gruppen und Zertifikatsschlüssellängen sowie ein Scan-Ergebnis pro Endpunkt. Unsere Seite zu NIS2 Artikel 21(2)(h) erläutert, was die Richtlinie verlangt. Dieser Artikel dient der Information und stellt keine Rechtsberatung dar.

Nächster Schritt: Prüfen Sie, was Ihre Server heute aushandeln

Bevor Sie einen Plan schreiben, messen Sie den aktuellen Stand. Scannen Sie Ihre Domain mit PQC Status, um zu sehen, welche TLS-Versionen, Schlüsseleinigungsgruppen und Zertifikatsalgorithmen Ihr Server tatsächlich anbietet, einschließlich der Frage, ob eine hybride ML-KEM-Gruppe ausgehandelt wird. Ein Scan beschreibt nur die extern sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Konformitätsbescheinigung. Verwenden Sie das Ergebnis als erste Zeile Ihres Inventars, aktivieren Sie dann die hybride Gruppe in Staging, behalten Sie den klassischen Fallback bei und dokumentieren Sie den Zustand vorher und nachher für jeden Endpunkt.