Google Cloud hat am 11. August 2026 seinen Fahrplan zur Post-Quanten-Kryptografie veröffentlicht. Die Verfahren ML-KEM, ML-DSA und SLH-DSA sind in Cloud KMS allgemein verfügbar, Load Balancer können den hybriden Schlüsselaustausch X25519MLKEM768 nutzen. Bis Ende 2027 soll der Schutz gegen "Store now, decrypt later" stehen, die volle Reife ist für 2029 geplant. Kunden sollen Schlüssel und Zertifikate inventarisieren und ihre Clients aktualisieren.
Google Cloud legt offen, wie und bis wann es seine Dienste gegen Quantenrechner absichert. Teile davon laufen schon: Cloud KMS bietet die neuen NIST-Verfahren allgemein an.
Das Wichtigste in Kürze
- ML-KEM, ML-DSA und SLH-DSA sind in Cloud KMS allgemein verfügbar. Die Verfahren decken Schlüsselaustausch und digitale Signaturen ab.
- Load Balancer können hybrid verschlüsseln. Sie nutzen X25519MLKEM768 für TLS 1.3, bisher auf Wunsch.
- Der Schutz vor "Store now, decrypt later" soll bis Ende 2027 stehen. Signaturen und Schlüsselverwaltung folgen bis Ende 2028.
- Die volle Reife plant Google für 2029. Kunden sollen jetzt Schlüssel und Zertifikate erfassen.
Der Fahrplan von Google Cloud
Google hat den Beitrag am 11. August 2026 im Cloud-Blog erstmals veröffentlicht. Zuletzt aktualisiert wurde er nicht. Er gliedert die Arbeit in drei Bereiche und nennt feste Ziele. Der erste Bereich ist der Schutz vor "Store now, decrypt later". Dabei zeichnen Angreifer heute verschlüsselte Daten auf, um sie später mit einem Quantenrechner zu lesen.
| Bereich | Ziel | Beispiele |
|---|---|---|
| Schutz vor "Store now, decrypt later" | Ende 2027 | Load Balancer, Cloud VPN, Cloud Interconnect |
| Integrität und Nachweisbarkeit | Ende 2028 | Binary Authorization, Certificate Authority Service, Cloud IAM |
| Grundlagen und Schlüsselverwaltung | Ende 2028 | Cloud KMS, Cloud HSM, External Key Management |
Insgesamt peilt Google die volle Quantenreife für 2029 an. In den 2030er-Jahren folgt die Angleichung an Vorgaben wie CNSA 2.0 und NIST IR 8547.
Was Cloud KMS und Load Balancer schon können
In Cloud KMS sind ML-KEM, ML-DSA und SLH-DSA allgemein verfügbar. Die Dokumentation führt ML-KEM-768 und ML-KEM-1024 für den Schlüsselaustausch auf, dazu mehrere Varianten von ML-DSA und SLH-DSA für Signaturen. Zusätzlich gibt es den hybriden Ansatz X-Wing, der ML-KEM-768 mit X25519 verbindet. Alle diese Verfahren gelten nur für Schlüssel mit Software-Schutzstufe.
Die Load Balancer unterstützen den hybriden Schlüsselaustausch X25519MLKEM768 für TLS 1.3. Du aktivierst ihn über die Einstellung post-quantum-key-exchange in einer SSL-Richtlinie. Er greift, sobald ein Client TLS 1.3 und dieses Verfahren anbietet. Auf den API-Endpunkten google.com und googleapis.com läuft ML-KEM im Hybridmodus bereits.
Was Kunden jetzt tun sollen
Google empfiehlt drei Schritte. Zuerst erfasst du, wo deine Organisation Schlüssel und Zertifikate einsetzt, etwa mit dem Cloud Asset Inventory. Danach aktualisierst du Software wie BoringSSL, Browser und Client-Bibliotheken, damit sie die neuen Verfahren aushandeln. Schliesslich testest du Anwendungen gegen die quantensicheren Schnittstellen und probierst die Load-Balancer-Funktion zuerst ausserhalb der Produktion aus.
Dabei gilt ein geteiltes Modell. Google sichert Netz, Transport und Zertifizierungsstellen ab. Anwendungen, Clients und die Konfiguration bleiben deine Aufgabe. Auch ausserhalb der Cloud ist das Thema relevant: Im Beitrag zu JDK 27 und Post-Quanten-TLS siehst du, wie Java dieselbe Richtung einschlägt.
Fazit
Google Cloud liefert die Bausteine bereits und nennt klare Fristen. Der grösste Hebel für dich ist ein Inventar der Schlüssel und Zertifikate, denn es zeigt, wo die Umstellung zuerst nötig ist. Beginne damit, bevor die Fristen von 2027 näher rücken.
Quellen: Google Cloud Blog vom 11. August 2026, Post-Quanten-TLS bei Load Balancern, Algorithmen in Cloud KMS. Foto: TheDigitalArtist / Pixabay. Stand: 11. August 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.