Google Cloud announced a phased PQC roadmap through 2029, prioritizing quantum-risk reduction by 2027 and broader deployment across identity,
Google Cloud recently announced its post-quantum cryptography (Post-Quantum Cryptography, PQC) deployment roadmap, aiming to complete the overall transition by 2029; by the end of 2027, it will first prioritize reducing the risk that existing encrypted data could be cracked by quantum computers in the future, and by the end of 2028 it will further advance PQC deployment in areas such as identity, digital signatures, and key management. This plan shows that the quantum threat has shifted from a long-term issue to a practical engineering task that cloud platforms must address in phases.[1]
At present, Google Cloud API endpoints already provide quantum-safe key exchange and use a hybrid model that simultaneously employs existing key exchange mechanisms and the post-quantum cryptographic algorithm ML-KEM; Application load balancer and Proxy load balancer can also optionally enable hybrid key exchange mechanisms. Cloud KMS now officially supports ML-KEM, ML-DSA, and SLH-DSA, all of which are post-quantum cryptographic algorithms standardized by NIST.[1][2]
The core technical focus of this roadmap is addressing the Store Now, Decrypt Later (SNDL) risk first. The SNDL threat model is straightforward: attackers first intercept large amounts of encrypted data that cannot be broken today, then decrypt it later once quantum computing capabilities mature, meaning that even if data appears secure now, its long-term confidentiality may still be compromised.[1][3]
Google Cloud has divided the transition sequence into multiple layers, beginning with data transport and edge traffic, then gradually extending to digital signatures and identity controls, which have higher verifiability and longer lifecycles. This ordering reflects the practical difficulty of PQC migration: transport layers can first reduce risk through hybrid key exchange, but certificates, signatures, and identity systems involve broader trust chains, dependent packages, and compatibility validation, so they require a longer adoption cycle.[1][3]
It is worth noting that Google Cloud is adopting a hybrid model rather than switching entirely to a single PQC algorithm immediately. This means the current design philosophy is progressive security enhancement: on one hand, it preserves the interoperability of existing mature mechanisms; on the other, it uses quantum-safe algorithms such as ML-KEM to build a new protection layer, reducing the risks caused by single points of failure and ecosystem immaturity.[1]
From a standardization perspective, Cloud KMS now supports ML-KEM, ML-DSA, and SLH-DSA, which means PQC is no longer just an experimental feature but has entered the formal deployment phase for cloud key management. For enterprises, this also means PQC migration has moved from algorithm selection to the engineering phase of asset inventory, system compatibility, and operational process adjustment.[1][2]
The organizations most affected by this roadmap are first those that rely on Google Cloud for data transport, cross-site connectivity, and internal service interoperability. Cloud VPN, Cloud Interconnect, and other data-transport-related services are expected to introduce PQC support between 2026 and 2027, meaning that if enterprise traffic passes through these channels, it may eventually need to align with new cipher suites and connection strategies.[1][3]
The second affected area is the identity and certificate ecosystem. Once digital signatures, digital certificates, identity verification, and access control enter the PQC transition period, enterprises will need not only to update server-side settings, but also to re-examine the compatibility of client-side systems, SRE tools, certificate issuance workflows, signature verification, and automated deployment pipelines.[1][3]
The third affected area is key management and governance. Although Cloud KMS already supports multiple quantum-safe algorithms, enterprises still cannot effectively prioritize migration without first inventorying keys, certificates, and related cryptographic assets. In other words, PQC is not just a security feature upgrade, but a reorganization of asset governance and risk management.[1]
Enterprises should first establish a complete cryptographic asset inventory, covering at least keys, digital certificates, certificate chains, TLS usage points, API integration points, and cross-cloud connection channels. Only by clarifying which systems carry long-term sensitive data can it be determined which data should be prioritized against SNDL risk.[1]
Second, development and operations teams should check whether existing applications can function properly under quantum-safe APIs and hybrid key exchange modes. Google Cloud already provides some available features, so the testing focus is not just whether connections can be established, but also whether certificate validation, handshake compatibility, proxy forwarding, and automation scripts are affected.[1]
Third, dependent libraries and toolchains should be updated in advance so that development, deployment, and monitoring workflows can support PQC-related mechanisms. This is especially important for internal SRE, CI/CD, and infrastructure-as-code workflows, because changes to cipher suites often propagate downstream and create hidden failures.[1]
Finally, enterprises should incorporate PQC into their medium- to long-term cybersecurity and compliance planning rather than waiting until the quantum threat matures and then responding passively. Google’s roadmap clearly shows that PQC migration will begin with the transport layer and then extend to signatures, identity, and key management; therefore, the earlier inventorying and validation are completed, the lower the later switching costs and operational disruption risks will be.[1][3]