Quantenbedrohung: Googles PQC-Frist 2029 bestätigt, was Deployment-Teams längst wissen

30. März 2026

EN | DE

Google hat sich verpflichtet, seine Post-Quanten-Migration bis 2029 abzuschließen. NIST sagt: bis 2030 abwerten, bis 2035 verbieten. Das NCSC zielt auf 2035. Die G7 sagen 2034. Die CNSA 2.0 der NSA gibt nationalen Sicherheitssystemen bis 2033 Zeit. (Vollständige Zeitleiste.) Google wartet nicht auf diese Fristen. Das sagt Ihnen zwei Dinge: Sie schätzen die Kosten des Abwartens als hoch ein, und sie halten die Arbeit für jetzt machbar.

Beides deckt sich mit dem, was wir im Deployment sehen.

Google kontrolliert den Stack

Google kann sich auf 2029 festlegen, weil es die gesamte Vertikale besitzt. Chrome liefert PQC-Schlüsselaustausch per Auto-Update an Milliarden Geräte. Android 17 integriert ML-DSA auf der Verified-Boot-Ebene. Cloud KMS rotiert Algorithmen ohne Kundeneingriff. Wenn Ihre TLS-Bibliothek, Ihre Zertifizierungsstelle, Ihr Betriebssystem und Ihre Anwendungslaufzeit alles interne Produkte sind, ist die Migration ein Engineering-Programm mit einem bekannten Abhängigkeitsgraphen.

Die meisten Organisationen haben eine andere Architektur. Die TLS-Terminierung läuft auf dem Load Balancer eines Anbieters. Das Zertifikat kommt von einer externen CA. Die Anwendung hängt von einem Framework ab, das von einer Laufzeit abhängt, die von einem OS-Kryptographie-Provider abhängt. Das bedeutet mehr Koordination, aber es bedeutet auch, dass ein Großteil der schweren Arbeit bereits upstream passiert. AWS, Azure und Cloudflare bieten bereits PQC-fähige TLS-Richtlinien an. In den Deployments, an denen wir arbeiten, ist die Aktivierung von hybridem PQC auf einem Cloud-Load-Balancer typischerweise eine Konfigurationsänderung: ein TLS-Policy-Wechsel, kein Rewrite.

Die Migration von SHA-1 auf SHA-2 dauerte über zwölf Jahre, aber das war bevor Cloud-Infrastruktur Konfigurationsänderungen in Minuten ausrollbar machte. Post-Quanten-Migration bringt größere Schlüssel und neues Protokollverhalten mit sich, aber die Werkzeuge sind weiter als die meisten Berichte vermuten lassen. Google selbst hat von X.509 auf Merkle-Tree-Zertifikate gewechselt vor drei Wochen. Das Ökosystem bewegt sich schnell.

Warum Google beschleunigt

Die regulatorischen Zeitpläne (2030, 2033, 2035) gehen davon aus, dass die Bedrohung planmäßig bleibt. Diese Puffer funktionieren nur, wenn ein kryptographisch relevanter Quantencomputer nicht früher kommt. Wir haben die Lücke zwischen theoretischen Zeitplänen und operativer Realität Anfang des Monats beschrieben. Googles Forscher veröffentlichten letztes Jahr Ergebnisse, die schätzen, dass etwa eine Million verrauschte Qubits RSA-2048 in weniger als einer Woche faktorisieren könnten. Google reagierte mit Beschleunigung, nicht mit Abwarten.

Diese Beschleunigung ist selbst ein Signal. Google hat mehr Einblick in den Fortschritt des Quantencomputings als fast jede andere Organisation der Welt. Wenn ein Unternehmen mit dieser Sichtbarkeit beschließt, bis 2029 fertig zu sein, anstatt bis 2035 abzuwarten, sagt es Ihnen etwas darüber, wie viel Spielraum es noch sieht. Und das Harvest-Now-Decrypt-Later-Fenster ist bereits offen. Jede heute mit rein klassischem Schlüsselaustausch aufgezeichnete Sitzung ist eine zukünftige Belastung, unabhängig davon, wann die Hardware kommt.

Die Trusted Computing Group befragte 1.500 Sicherheitsexperten in den USA und Europa. 91% haben noch keine formelle PQC-Migrations-Roadmap. 81% sagen, dass ihre kryptographischen Bibliotheken und Hardware-Sicherheitsmodule Updates brauchen. Gartners Daten ergänzen das Bild: 61% der Organisationen haben keinen vollständigen Überblick über ihre kryptographischen Systeme. Die Lücke zwischen Bewusstsein und Handlung ist hauptsächlich ein Inventarisierungsproblem. Drei Viertel der Befragten sagen, sie verstehen die Bedrohung. Was sie noch nicht getan haben, ist zu messen, was sie betreiben.

Was wir im Feld sehen

Wir führen kontinuierliche Scans über 899 NIS2-Richtlinien-Ziele in allen 27 EU-Mitgliedstaaten durch. Das Muster ist konsistent: Organisationen, die hybrides PQC aktiviert haben, taten es in einer einzigen Konfigurationsänderung und blieben dabei. Die, die es nicht getan haben, sind stationär, nicht weil die Arbeit schwer ist, sondern weil sie die Inventarisierung nicht gestartet haben, die ihnen sagt, wo sie die Änderung ansetzen sollen.

Die praktische Abfolge, die wir in Deployment-Projekten sehen:

  • Externer Scan zuerst. Kennen Sie Ihre TLS-Versionen, Cipher Suites und Schlüsselaustausch-Algorithmen über alle öffentlichen Endpunkte. Das zeigt die Quick Wins: Load Balancer und CDNs, bei denen hybrides PQC bereits unterstützt wird und nur eingeschaltet werden muss.
  • Hybrid aktivieren, wo die Plattform es unterstützt. AWS ALBs, Cloudflare und nginx mit OpenSSL 3.5 unterstützen ML-KEM heute. Diese Änderungen sind risikoarm, weil hybride Aushandlung graceful zurückfällt. Clients, die PQC-Schlüsselaustausch nicht unterstützen, verbinden sich weiterhin mit klassischen Algorithmen.
  • Interne kryptographische Abhängigkeiten inventarisieren. Zertifikate, Keystores, HSMs, eingebettete Geräte. Hier liegen die längeren Zeitpläne, und hier ist es wichtig, die Roadmap Ihrer Anbieter zu kennen.

Jeder dieser Schritte ist eigenständig und hat sofortigen Wert. Der externe Scan gibt Ihnen eine Baseline. Die Hybrid-Aktivierung schließt das Harvest-Now-Decrypt-Later-Fenster für diesen Datenverkehr. Die interne Inventarisierung sagt Ihnen, wie Ihre tatsächliche Migrations-Zeitleiste aussieht.

Was Googles Zeitleiste wirklich zeigt

Die Mainstream-Berichterstattung rahmt Googles Ankündigung als Warnung vor Quanten-Zeitplänen. The Independent nennt es eine „Quanten-Apokalypse“. Das verfehlt den Punkt. Google zeigt, dass PQC-Migration ein Engineering-Problem mit einer bekannten Lösung ist, keine ungelöste Forschungsfrage. Die Algorithmen sind standardisiert. Die Implementierungen werden in Produktionsbibliotheken ausgeliefert. Die Infrastrukturanbieter deployen Unterstützung. Und das Unternehmen mit dem besten Blick auf den Quantenfortschritt hält Abwarten für teurer als Handeln.

Die Sechs-Jahres-Spanne zwischen Googles 2029 und dem G7-Ziel 2035 ist Zeit, die genutzt werden kann, aber es ist keine Zeit, auf die man zählen kann. Wir verfolgen diese Trajektorie über die europäische kritische Infrastruktur auf dem NIS2-Monitor. Die Organisationen, die Fortschritte machen, haben mit einem Scan begonnen und sich von dort aus vorgearbeitet.