Post-Quanten-Migration 2026: Plan für Entwicklungsteams

Kurz gesagt. 2026 erledigt sich ein großer Teil der Post-Quanten-Arbeit für die Transportverschlüsselung durch Updates. Chrome, Firefox, Apples Betriebssysteme der Version 26, OpenSSL 3.5, Go 1.24+, JDK 27 und OpenSSH 10 handeln standardmäßig einen hybriden Schlüsselaustausch mit ML-KEM aus. Deine Aufgabe ist es, die Verbindungen zu finden, bei denen das noch nicht passiert: alte Bibliotheken, fest konfigurierte Gruppenlisten, Middleboxes, TLS 1.2, VPNs, interne Dienste. Signaturen und Zertifikate sind der langsame Teil. Öffentliche CAs können noch keine ML-DSA-Zertifikate für Browser ausstellen. Erstelle deshalb jetzt dein Inventar, erprobe ML-DSA in der privaten PKI und entwirf deine Systeme mit Blick auf Algorithmenagilität. Für die Planung gelten die Termine aus dem NIST-Entwurf IR 8547: 112-Bit-Schlüssel wie RSA-2048 sind nach 2030 veraltet, alle quantenanfälligen Public-Key-Algorithmen sind nach 2035 verboten. Die CNSA 2.0 der NSA setzt für nationale Sicherheitssysteme der USA frühere Termine.

Zwei Probleme, zwei Zeitpläne

Ein kryptografisch relevanter Quantencomputer würde mit dem Shor-Algorithmus RSA, Diffie-Hellman über endlichen Körpern und Kryptografie mit elliptischen Kurven (ECDH, ECDSA, EdDSA) brechen. Symmetrische Kryptografie und Hashfunktionen überstehen das mit den heutigen Schlüssellängen: AES-256 und SHA-256 oder größer. Niemand kann dir sagen, wann es eine solche Maschine geben wird. Laut der Projektseite von OpenSSH liegen die veröffentlichten Schätzungen bei „5–20 Jahren, wobei viele Beobachter damit rechnen, dass sie Mitte der 2030er-Jahre kommen“. Die Migration zerfällt in zwei Probleme mit sehr unterschiedlicher Dringlichkeit:

• Vertraulichkeit: dringend. Verschlüsselter Datenverkehr, der heute aufgezeichnet wird, lässt sich entschlüsseln, sobald es den Quantencomputer gibt. Das ist harvest now, decrypt later (jetzt speichern, später entschlüsseln). Alles, was länger als ein paar Jahre geheim bleiben muss, ist schon heute gefährdet, wenn sein Schlüsselaustausch klassisch ist. Die Abhilfe ist ein Post-Quanten-Schlüsselaustausch, und den kannst du heute schon einsetzen.
• Authentifizierung: mit Frist. Eine gefälschte Signatur zählt erst, wenn sich jemand auf sie verlässt; der Quantencomputer muss also genau in diesem Moment existieren. Signaturschlüssel und Vertrauensanker leben aber lange. Root-Zertifikaten, Firmware-Schlüsseln, Codesignaturschlüsseln und archivierten signierten Dokumenten wird jahrzehntelang vertraut, und ihr Austausch dauert Jahre.

Plane die Arbeit in dieser Reihenfolge: zuerst den Schlüsselaustausch, dann die Signaturen.

Die Fristen, die es tatsächlich gibt

Drei Punkte zu dieser Tabelle:

1. IR 8547 ist noch ein Entwurf. Behörden und Hersteller planen mit den Terminen 2030 und 2035, aber sie sind noch keine endgültige NIST-Richtlinie. Im Entwurf bedeutet „deprecated“ (veraltet), dass du den Algorithmus noch nutzen darfst, wenn du das Risiko akzeptierst, und „disallowed“ (verboten), dass du ihn überhaupt nicht nutzen darfst.
2. Die Stufe 2030 trifft 112-Bit-Schlüssel, vor allem RSA-2048. RSA-2048 steckt noch in vielen Zertifikaten und in vielen Diensten, die Tokens signieren (zwei der sechs Endpunkte im Scan weiter unten nutzen es). P-256 und RSA-3072 bieten 128 Bit und bleiben bis 2035 zulässig, doch ein Umstieg auf sie verschafft höchstens fünf Jahre, weil der Entwurf nach 2035 alles Quantenanfällige verbietet.
3. Die Fußnote der CNSA 2.0 ist für hybride Verfahren wichtig. Hybride Modi sind erlaubt, aber die Algorithmen der CNSA 2.0 „müssen ab dem angegebenen Datum zwingend ausgewählt werden“. Eine rein klassische Konfiguration ist dann also nicht mehr akzeptabel.

Was schon standardmäßig Post-Quanten-Verfahren nutzt

Diese Komponenten handeln ohne jede Konfiguration einen hybriden Schlüsselaustausch mit ML-KEM aus, sofern beide Seiten aktuell genug sind:

Auch auf der Serverseite hat sich etwas bewegt. Ein Scan mit OpenSSL 3.5.7 am 20. Oktober 2026 mit dem Skript aus dem Abschnitt zum Inventar ergab Folgendes:

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

Zwei Spalten sagen alles. Beim Schlüsselaustausch ist das Bild gemischt: Manche Dienste nutzen das Hybridverfahren, manche nicht. Die Zertifikatsspalten sind durchweg klassisch, ECDSA P-256 oder RSA-2048. Bei SSH sieht es genauso aus; dort wählt GitHub für einen Client mit OpenSSH 10 bereits das Hybridverfahren:

debug1: kex: algorithm: mlkem768x25519-sha256

Schritt 1: Inventar

Was du nicht auflisten kannst, kannst du nicht migrieren. Ein brauchbares kryptografisches Inventar beantwortet für jeden Einsatz von Public-Key-Kryptografie: welcher Algorithmus und welche Schlüssellänge, welche Bibliothek in welcher Version, wer über die Konfiguration bestimmt, wie lange die geschützten Daten vertraulich bleiben müssen und wie lange dem Schlüssel oder der Signatur vertraut werden muss.

Beginne mit dem, was sich von außen messen lässt, also mit deinen TLS-Endpunkten:

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

Das Skript muss mit einem Client aus OpenSSL 3.5 laufen: Ältere Clients bieten das Hybridverfahren nie an, und für sie sieht jeder Server klassisch aus. Für viele Domains auf einmal meldet der Bulk-Domain-Checker pro Host Schlüsselaustausch, Zertifikatsalgorithmen und Ablaufdatum.

Danach geht es nach innen, wo die meiste Arbeit liegt:

• Bibliotheken und Laufzeitumgebungen. Erfasse die Versionen von OpenSSL, BoringSSL, Go, JDK, .NET, Node.js und Python in jedem Image und auf jedem Host. OpenSSL 3.0 wird upstream nicht mehr unterstützt und hat kein ML-KEM, und Ubuntu 24.04 liefert es weiterhin aus. Allein diese Tatsache erklärt viele Ergebnisse.
• Explizite Konfiguration. Suche nach Gruppen- und Cipher-Listen wie ssl_ecdh_curve, SSLOpenSSLConfCmd Groups, CurvePreferences, jdk.tls.namedGroups und KexAlgorithms. Jede davon ist eine Stelle, die ein Update der Standardwerte nicht erreicht.
• Code. Suche nach direkten Aufrufen von RSA-, ECDSA-, ECDH- und Ed25519-APIs, nach Schlüssellängen, nach Werten für alg in JWTs und nach öffentlichen Schlüsseln, die in Datenbanken gespeichert sind. Signaturen, die in Datenformaten gespeichert sind, lassen sich später am schwersten ändern.
• Langlebige Schlüssel und Zertifikate. Root-Zertifikate privater CAs, Codesignatur- und Firmware-Schlüssel, Signaturschlüssel für Dokumente, SSH-CAs, Schlüssel in HSMs. Notiere jeweils das Ablaufdatum und die Algorithmen, die das HSM unterstützt.
• Anbieter. Load Balancer, WAFs, Proxys mit TLS-Inspektion, VPN-Konzentratoren, verwaltete Datenbanken, SaaS-APIs. Lass dir von jedem Anbieter die Roadmap für ML-KEM und ML-DSA schriftlich geben.

Halte das Ergebnis maschinenlesbar fest. CycloneDX hat genau dafür eine Cryptography Bill of Materials (CBOM) eingeführt. Die CBOM beschreibt Algorithmen, Schlüssel, Zertifikate und Protokolle als Komponenten deines Softwareinventars, neben der Paket-SBOM, die du vielleicht schon erzeugst.

Schritt 2: Schlüsselaustausch abschließen

Für jeden Punkt, an dem du selbst TLS terminierst:

1. Aktualisiere die TLS-Bibliothek. OpenSSL 3.5, Go 1.24 oder neuer, JDK 27 oder ein aktueller Build von BoringSSL oder AWS-LC.
2. Entferne fest konfigurierte Gruppenlisten oder setze X25519MLKEM768 darin an die erste Stelle. Eine Härtungszeile, die aus einer alten Anleitung kopiert wurde, ist der häufigste Grund, warum ein moderner Server nur reines X25519 aushandelt. Die Mechanik beschreibt X25519MLKEM768 erklärt.
3. Teste über den echten Netzwerkpfad. Das hybride ClientHello ist etwa 1,5 KB groß. Manche Firewalls, Load Balancer und Proxys mit TLS-Inspektion scheitern an ClientHellos, die sich über zwei Pakete erstrecken. Vergleiche einen hybriden und einen rein klassischen Handshake über denselben Pfad, bevor du dem Server die Schuld gibst.
4. Prüfe beide Teilstrecken. Hinter einem CDN oder Load Balancer ist die Verbindung vom Edge zum Origin eine eigene TLS-Sitzung. Datenverkehr, der auf dieser Strecke aufgezeichnet wird, lässt sich genauso speichern und später entschlüsseln.
5. Schalte TLS 1.2 ab, wo du kannst. Hybride Gruppen sind nur für TLS 1.3 definiert.

Dann die Kanäle außerhalb des Webs:

• SSH. OpenSSH ab Version 9.0 handelt bereits ein hybrides Post-Quanten-Verfahren aus, wenn beide Seiten es unterstützen. Alte Server, Netzwerk-Appliances und eingebettete SSH-Stacks tun das oft nicht. Clients ab OpenSSH 10.1 geben eine Warnung aus, die das Risiko benennt: „This session may be vulnerable to 'store now, decrypt later' attacks.“
• VPNs und IPsec. IKEv2 unterstützt zusätzliche Schlüsselaustausche (RFC 9370), über die Hersteller ML-KEM ergänzen. Sieh in den Versionshinweisen zur Firmware deines Gateways nach.
• Verschlüsselung auf Anwendungsebene. Alles, was Datenschlüssel mit RSA oder ECDH umhüllt, etwa Envelope-Verschlüsselung, verschlüsselte Backups oder Ende-zu-Ende-verschlüsseltes Messaging, braucht einen Weg über ML-KEM oder ein hybrides KEM. HPKE (RFC 9180) mit einem hybriden KEM ist der übliche Baustein. Der HPKE-Playground zeigt, wie die Teile zusammenpassen.

Schritt 3: Signaturen und Zertifikate

Hier ist das Ökosystem noch nicht so weit, dir die Arbeit abzunehmen. 2026 geht es deshalb um Vorbereitung:

• Öffentliche Webzertifikate: abwarten, aber vorbereiten. Kein Browser akzeptiert ML-DSA-Zertifikate von öffentlichen CAs. Chrome hat im Februar 2026 erklärt, dass vorerst nicht geplant ist, X.509-Zertifikate mit Post-Quanten-Schlüsseln in den eigenen Root Store aufzunehmen. Chrome baut einen separaten quantenresistenten Root Store rund um Merkle Tree Certificates auf, die in der IETF-Arbeitsgruppe PLANTS standardisiert werden. Bis dahin besteht die sinnvolle Arbeit in Automatisierung. Ein Team, das jedes Zertifikat innerhalb von Minuten austauschen kann, wechselt auch die Algorithmen problemlos, und die kürzeren Zertifikatslaufzeiten drängen in dieselbe Richtung.
• Private PKI: ML-DSA jetzt erproben. Bei internem mTLS, Service Meshes, Geräteidentitäten und VPN-Zertifikaten liegen beide Enden in deiner Hand. OpenSSL 3.5, Go 1.27, Java 24+, .NET 10 und BouncyCastle können alle mit ML-DSA-Schlüsseln und -Zertifikaten umgehen. Rechne bei ML-DSA-65 mit einem Leaf-Zertifikat von etwa 5,5 KB und teste, was dabei kaputtgeht: Puffergrößen, Header-Limits, HSM-Unterstützung. ML-DSA für Entwickler enthält funktionierenden Code und die Fallstricke bei Schlüsselformaten.
• Langlebige Vertrauensanker zuerst. Einem Root- oder Firmware-Schlüssel, der 2026 erzeugt wird, wird auch nach 2035 noch vertraut. Für das Signieren von Firmware und Software-Updates verlangt die CNSA 2.0 die zustandsbehafteten hashbasierten Verfahren LMS oder XMSS (SP 800-208) und erwartet bis 2030 deren ausschließliche Nutzung. Das zustandslose SLH-DSA (FIPS 205) ist die konservative Alternative, wenn du den Signaturzustand nicht verwalten kannst.
• Signierte Artefakte, die prüfbar bleiben müssen. Dokumente, Archive und Logs, die heute mit ECDSA signiert werden, müssen neu geschützt werden, bevor ihre Signaturen nicht mehr vertrauenswürdig sind. Plane die Erneuerung von Zeitstempeln und das erneute Signieren von Archiven ein, so wie es die Langzeitvalidierung von PDF-Signaturen schon heute für ablaufende Zertifikate tut.
• Tokens und APIs. JOSE und COSE haben Codepoints für ML-DSA (RFC 9964). Eine Signatur von 3,3 KB macht ein JWT in base64url etwa 4,5 KB groß, was für Cookies und Header relevant ist. Miss nach, bevor du umstellst.

Schritt 4: den nächsten Wechsel günstig machen

Die Migration wird kein einmaliger Wechsel sein. Der hybride Schlüsselaustausch könnte später reinem ML-KEM weichen. Zu ML-DSA könnte FN-DSA hinzukommen, das das NIST als FIPS 206 plant. Composite- und hybride Signaturen werden noch ausgearbeitet. Kryptoagilität sorgt dafür, dass nicht jede dieser Änderungen wieder zu einem mehrjährigen Projekt wird:

• Algorithmuskennungen werden mit den Daten mitgeführt (eine OID, der Parameter alg in JOSE, ein Versionsbyte), und Verifizierer wählen anhand dieser Kennungen den Algorithmus, statt ihn vorauszusetzen.
• Schlüssel- und Signaturgrößen sind nicht fest einprogrammiert. Spalten, Puffer und Protokollfelder bieten Platz für Kilobytes.
• Schlüssel werden automatisiert erzeugt, gespeichert und rotiert. Kein Mensch kopiert eine PEM-Datei in eine Konfiguration.
• Die Konfiguration liegt pro Stack an einer Stelle, sodass der nächste Wechsel einer Gruppe oder eines Algorithmus eine einzige Änderung ist.

Häufige Fehler

• Mit einem alten Client testen. openssl s_client aus OpenSSL 3.0 oder ein dagegen gelinktes curl bietet das Hybridverfahren nie an. Dann sieht jeder Server klassisch aus, auch solche, die schon migriert sind.
• Den CDN-Edge für die ganze Verbindung halten. Die Strecke vom Browser zum Edge ist oft mit Post-Quanten-Verfahren geschützt, die Strecke vom Edge zum Origin bei derselben Anfrage dagegen nicht.
• Das Hybridverfahren abschalten, um eine defekte Middlebox wieder zum Laufen zu bringen. Damit fällt der Schutz für jede Verbindung weg. Repariere das Gerät oder ersetze es.
• Mit allem auf öffentliche ML-DSA-Zertifikate warten. Das Inventar, die Bibliotheks-Updates und die Zertifikatsautomatisierung brauchst du ohnehin, und sie dauern länger als das Warten.
• „Nach 2030 veraltet“ als „bis 2035 erlaubt“ lesen. Daten, die du 2029 mit klassischem Schlüsselaustausch verschlüsselst, sind während ihrer gesamten Vertraulichkeitsdauer gefährdet. Die Fristen dienen der Compliance, nicht der Sicherheit.

Eine Checkliste für den Rest des Jahres 2026

1. Scanne jeden öffentlichen und internen TLS-Endpunkt mit OpenSSL 3.5 und halte Gruppe, Zertifikatsalgorithmus und Bibliotheksversion fest.
2. Aktualisiere die TLS-Bibliotheken in den Basis-Images. Entferne fest konfigurierte Gruppenlisten. Scanne erneut.
3. Teste das Hybridverfahren durch jede Middlebox auf dem Pfad, auch auf der Strecke vom Edge zum Origin.
4. Aktualisiere SSH-Server für ML-KEM auf OpenSSH 9.9 oder neuer (ab 9.0 gibt es bereits das Hybridverfahren mit sntrup761) und Netzwerk-Appliances, sofern es Firmware dafür gibt.
5. Liste jeden langlebigen Signaturschlüssel und Vertrauensanker mit seinem Ablaufdatum und den Algorithmen auf, die sein HSM unterstützt.
6. Richte eine ML-DSA-Test-CA ein und stelle Zertifikate für einen internen Dienst aus.
7. Automatisiere Ausstellung und Rotation von Zertifikaten überall dort, wo sie noch manuell laufen.
8. Frage deine Anbieter schriftlich nach Terminen für die Unterstützung von ML-KEM und ML-DSA.

Quellen

• NIST IR 8547 ipd, Transition to Post-Quantum Cryptography Standards (November 2024), Tabellen 2–4.
• NSA, Announcing the Commercial National Security Algorithm Suite 2.0 (CSA PP-22-1338, September 2022): Algorithmen und Zeitplan für den Übergang.
• A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, EU PQC Workstream, Version 1.1, 11. Juni 2025.
• NCSC, Timelines for migration to post-quantum cryptography (März 2025).
• FIPS 203, FIPS 204, FIPS 205, SP 800-208.
• OpenSSH, Post-Quanten-Kryptografie, sowie die Versionshinweise zu OpenSSH 9.0, 9.9, 10.0 und 10.1.
• OpenSSL, Release-Strategie (3.5 LTS bis 08.04.2030). Versionshinweise zu Go 1.24, JEP 527.
• Google Security Blog, Cultivating a robust and efficient quantum-safe HTTPS (Februar 2026).

Die Scans liefen am 20. Oktober 2026 in node:24.22.0-trixie (OpenSSL 3.5.7, OpenSSH 10.0p2).