Google just committed to completing its post-quantum migration by 2029. NIST says deprecate by 2030, disallow by 2035. The NCSC targets 2035. The G7 says 2034. The NSA’s CNSA 2.0 gives national security systems until 2033. (Full timeline.) Google is not waiting for those deadlines. That tells you two things: they think the cost of delay is high, and they think the work is doable now.
Both of those match what we see in deployment.
Google Controls the Stack
Google can commit to 2029 because it owns the full vertical. Chrome ships PQC key exchange to billions of devices through auto-update. Android 17 integrates ML-DSA at the verified boot layer. Cloud KMS rotates algorithms without customer intervention. When your TLS library, your certificate authority, your OS, and your application runtime are all internal products, migration is an engineering program with a known dependency graph.
Most organizations have a different architecture. TLS termination runs on a vendor’s load balancer. The certificate comes from an external CA. The application depends on a framework that depends on a runtime that depends on an OS cryptographic provider. That means more coordination, but it also means much of the heavy lifting is already happening upstream. AWS, Azure, and Cloudflare already offer PQC-enabled TLS policies. In the deployments we work on, enabling hybrid PQC on a cloud load balancer is typically a configuration change: a TLS policy swap, not a rewrite.
The SHA-1 to SHA-2 migration took over twelve years, but that was before cloud infrastructure made configuration changes deployable in minutes. Post-quantum migration involves larger keys and new protocol behavior, but the tooling is further along than most coverage suggests. Google itself shifted from X.509 to Merkle Tree Certificates three weeks ago. The ecosystem is moving fast.
Why Google Is Accelerating
The regulatory timelines (2030, 2033, 2035) assume the threat stays on schedule. Those buffers only work if a cryptographically relevant quantum computer does not arrive early. We wrote about the gap between theoretical timelines and operational reality earlier this month. Google’s researchers published findings last year estimating that roughly one million noisy qubits could factor RSA-2048 in under a week. Google responded by accelerating, not by waiting for the deadlines.
That acceleration is itself a signal. Google has more visibility into quantum computing progress than nearly any other organization on earth. When a company with that visibility decides to finish by 2029 instead of coasting to 2035, it is telling you something about how much margin it thinks exists. And the harvest-now-decrypt-later window is already open. Every session recorded today with classical-only key exchange is a future liability regardless of when the hardware arrives.
The Trusted Computing Group surveyed 1,500 security professionals across the US and Europe. 91% have no formal PQC migration roadmap yet. 81% say their cryptographic libraries and hardware security modules need updates. Gartner’s data adds context: 61% of organizations lack full visibility into their cryptographic systems. The gap between awareness and action is mostly an inventory problem. Three quarters of respondents say they understand the threat. What they have not done yet is measure what they are running.
What We See in the Field
We run continuous scans across 899 NIS2 Directive targets in all 27 EU member states. The pattern is consistent: organizations that have enabled hybrid PQC did it in a single configuration change and stayed there. The ones that have not are stationary, not because the work is hard, but because they have not started the inventory that tells them where to point the change.
The practical sequence we see working in deployment projects:
- External scan first. Know your TLS versions, cipher suites, and key exchange algorithms across public-facing endpoints. This surfaces the quick wins: load balancers and CDNs where hybrid PQC is already supported and just needs to be switched on.
- Enable hybrid where the platform supports it. AWS ALBs, Cloudflare, and nginx with OpenSSL 3.5 all support ML-KEM today. These changes are low-risk because hybrid negotiation falls back gracefully. Clients that do not support PQC key exchange still connect with classical algorithms.
- Inventory internal cryptographic dependencies. Certificates, keystores, HSMs, embedded devices. This is where the longer timelines live, and where knowing your vendor roadmap matters.
Each of these is a discrete step with immediate value. The external scan gives you a baseline. The hybrid enablement closes the harvest-now-decrypt-later window for that traffic. The internal inventory tells you what your actual migration timeline looks like.
What Google’s Timeline Really Shows
Mainstream coverage frames Google’s announcement as a warning about quantum timelines. The Independent calls it a “quantum apocalypse.” That framing misses the point. Google is showing that PQC migration is an engineering problem with a known solution, not an unsolved research challenge. The algorithms are standardized. The implementations ship in production libraries. The infrastructure providers are deploying support. And the company with the best view of quantum progress thinks waiting is more expensive than acting.
The six-year spread between Google’s 2029 and the G7’s 2035 is time that can be used, but it is not time that can be counted on. We track this trajectory across EU critical infrastructure on the NIS2 monitor. The organizations making progress started with a scan and worked outward from there.