SaaSFort Das Bemerkenswerte an Post-Quantum-TLS im Jahr 2026 ist, dass die Clientseite fertig ist. Chrome, Firefox und Edge liefern die hybride Gruppe X25519MLKEM768 seit Version 131 standardmäßig aus. Etwa neunzehn von zwanzig Post-Quantum-TLS-Handshakes im Internet nutzen sie.
Die Serverseite ist nicht fertig. Die Unterstützung auf Origin-Seite lag 2026 bei etwa zehn Prozent, ein Zuwachs um rund das Zehnfache im Jahresvergleich, nachdem Akamai sie im Januar für Origin-Verbindungen standardmäßig aktiviert hatte.
Diese Lücke ist die eigentliche Nachricht. Die Browser Ihrer Besucher fragen nach quantenresistenter Schlüsselvereinbarung. Die meisten Server lehnen ab.
Was tatsächlich geschützt wird
Post-Quantum-Schlüsselaustausch schützt Sie nicht vor einem Angriff, der heute stattfindet. Er schützt Sie vor einem Angriff, der später gegen heute aufgezeichneten Verkehr stattfindet.
Die Bedrohung hat einen Namen: Harvest now, decrypt later. Ein Angreifer mit dem nötigen Budget zeichnet verschlüsselten Verkehr auf, speichert ihn und wartet. Die Sitzungsschlüssel, die diesen Verkehr schützen, wurden per Diffie-Hellman auf elliptischen Kurven vereinbart, was ein hinreichend leistungsfähiger Quantencomputer rückwirkend bricht. Alles Aufgezeichnete wird dann lesbar, auch was Jahre zuvor mitgeschnitten wurde.
Die relevante Frage für einen SaaS-Anbieter lautet deshalb nicht “ist Quantencomputing da”, sondern “wie lange bleiben die Daten über diese Verbindung sensibel”. Bei Authentifizierungstoken: Stunden. Bei Kundendaten, Gesundheitsdaten, Finanzpositionen oder Rechtsdokumenten: Jahrzehnte.
Was X25519MLKEM768 ist
Ein Hybrid: klassisches Diffie-Hellman über die Kurve X25519 kombiniert mit ML-KEM-768, dem vom NIST standardisierten gitterbasierten Schlüsselkapselungsverfahren. IANA-Codepoint 4588, also 0x11ec.
Der hybride Charakter ist entscheidend. Die Sitzung bleibt sicher, wenn einer der beiden Bestandteile hält. Sollte sich ML-KEM als schwach erweisen, schützt X25519 weiterhin, und umgekehrt. Deshalb empfehlen ETSI und das EUCC-Rahmenwerk den hybriden Einsatz mindestens bis 2028 und halten rein post-quantenbasierte Deployments für verfrüht.
Für andere Sicherheitsniveaus und für FIPS-Umgebungen existieren zwei Varianten: SecP256r1MLKEM768 und SecP384r1MLKEM1024.
Aktivierung
Die Änderung ist eine Zeile Serverkonfiguration, kein Architekturprojekt. Mit OpenSSL 3.5 hinter Nginx:
ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;
Die Reihenfolge ist Absicht. In TLS 1.3 sendet der Client seine Key Shares vorab. Hat er eine Share für Ihre erste Präferenz angeboten, ist der Handshake nach einem Roundtrip abgeschlossen. Andernfalls sendet der Server einen HelloRetryRequest, und der Handshake kostet einen zusätzlichen Roundtrip.
Da praktisch jeder aktuelle Browser bereits eine X25519MLKEM768-Share anbietet, ist die Voranstellung der schnelle Weg für die Mehrheit und ein Rückfall für alle anderen. Clients ohne Unterstützung verhandeln X25519 wie bisher, ohne clientseitige Änderung und ohne Kompatibilitätsbruch.
Für einen gestaffelten Rollout auf latenzkritischen Endpunkten belassen Sie X25519 an erster Stelle und ergänzen den Hybrid lediglich in der Liste, um nach der Messung umzusortieren.
Der FIPS-Vorbehalt
ML-KEM ist FIPS-zugelassen. X25519 nicht. Der streng FIPS-konforme Hybrid ist daher SecP256r1MLKEM768, den Chrome nicht standardmäßig ausliefert. Unter FIPS-Auflagen werden Sie P256MLKEM768 bevorzugen und in Kauf nehmen, dass die meisten Browser ihn nicht verwenden.
Wenn Sie TLS in Go terminieren, ist zudem ein offener Fehler zu beachten: Im Modus fips140=only lehnt die Laufzeitumgebung crypto/ecdh.X25519 bedingungslos ab, was hybride Handshakes bricht, obwohl die Gruppe auf der Liste zugelassener Kurven steht.
Was damit nicht gelöst ist
Hybrider Schlüsselaustausch schützt die Vertraulichkeit der Sitzung. Für die Authentifizierung leistet er nichts: Ihr Zertifikat ist weiterhin mit RSA oder ECDSA signiert, und diese Signaturen bleiben klassisch.
Das wiegt weniger schwer, als es klingt. Eine gefälschte Signatur muss während einer laufenden Verbindung erzeugt werden, um nützlich zu sein, ein Harvest-now-Äquivalent für Authentifizierung gibt es also nicht. Die Migration der Zertifikatskette ist ein späteres Problem, und keines, das Sie heute im Alleingang lösen können.
Zuordnung zu Rahmenwerken
- NIS2 Artikel 21(2)(h), Kryptografie und Verschlüsselung. Prüfer fragen zunehmend nach Krypto-Agilität, also nach Ihrer Fähigkeit, Algorithmen ohne Neuarchitektur zu wechseln.
- ISO/IEC 27001:2022 A.8.24, Einsatz von Kryptografie.
- DORA Artikel 9, für Finanzunternehmen, wo Aufbewahrungsfristen lang sind und das Harvest-now-Argument am stärksten wiegt.
Prüfung
openssl s_client -connect ihredomain.de:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i "negotiated\|Cipher"
Ein erfolgreicher Handshake belegt die Unterstützung. Ein Fehlschlag belegt für sich genommen nichts, denn der Host könnte schlicht nicht erreichbar sein. Deshalb wiederholt jede ehrliche Prüfung den Handshake ohne Einschränkung, bevor sie irgendetwas schlussfolgert.
So arbeitet die SaaSFort-Prüfung: Sie versucht einen auf die hybride Gruppe beschränkten Handshake und bestätigt bei Fehlschlag, dass der Server überhaupt TLS beantwortet, bevor sie die Abwesenheit meldet. Das Ergebnis wird als Information gemeldet, nicht als Fehler, denn 2026 ist ein fehlender Post-Quantum-Schlüsselaustausch eine Exposition mit verzögerter Wirkung, keine Fehlkonfiguration.
Kurzfassung
Eine Konfigurationszeile. Keine Clientänderung. Kein Kompatibilitätsrisiko, da der Rückfall automatisch erfolgt.
Der Grund, es jetzt statt 2028 zu tun, ist, dass die heute aufgezeichneten Daten heute aufgezeichnet werden. Rückwirkend verschlüsseln können Sie sie nicht.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.