Privacy officers are hearing a lot about quantum threats right now. Most of it's wrong.
Google Cloud has published a three-phase roadmap through 2028, with the first deadline in 2027. The timeline is aggressive because the threat window is narrow. Google warned in March that a cryptographically relevant quantum computer could arrive as early as 2029. But myths about post-quantum cryptography are causing teams to either panic or procrastinate, and neither response protects your data.
Here's what you actually need to know.
Myth 1: Your Cloud Provider Will Handle Everything
Reality: Google's roadmap states that customers must update client-side software to manage post-quantum handshakes and their own asymmetric key lifecycles.
This isn't a backend patch you'll wake up to one morning. When Google Cloud API endpoints began offering quantum-safe key exchange using NIST-standardized ML-KEM in hybrid mode, that was only half the equation. Your applications, SDKs, and any custom integrations that establish TLS connections need corresponding updates. If your team built a mobile app three years ago that pins certificates or hardcodes cipher suites, that app won't benefit from Google's work until you ship new code.
The shared responsibility model doesn't pause for quantum threats. Cloud providers can upgrade their infrastructure, but they can't rewrite your client applications or update the firmware on IoT devices you deployed in 2019.
Myth 2: You Have Until 2029 to Start Planning
Reality: The first major deadline is the end of 2027, targeting store-now-decrypt-later (SNDL) risk.
SNDL attacks don't require a working quantum computer today. An adversary can harvest encrypted traffic now and store it until quantum decryption becomes feasible. If you're transmitting data with a 10-year confidentiality requirement, financial records, health information, trade secrets, proprietary research, that data is already at risk.
Google organized its roadmap into three risk domains. SNDL mitigation completes by the end of 2027. Hardening digital signatures against forgery and rebuilding key management for cryptographic agility both run to the end of 2028. The 2029 date Google set alongside Cloudflare and Microsoft is a target for cryptographically relevant quantum computers to arrive, not a deadline for when you should finish your migration.
If you start planning in 2028, you're defending data that's already been exfiltrated.
Myth 3: Post-Quantum Cryptography Is Just a Drop-In Replacement
Reality: Post-quantum signatures are large enough to degrade certificate chain validation performance, forcing architectural changes like Merkle Tree Certificates.
This isn't swapping one algorithm for another. Jason Soroko at Sectigo explained that Merkle Tree Certificates replace multiple large signatures with one compact inclusion proof, keeping overhead near current levels. The approach also integrates transparency logging into issuance: if a certificate isn't in the tree, it doesn't exist.
That's a fundamental shift in how certificate validation works. Your performance budgets, network overhead calculations, and certificate lifecycle tooling all need review. Google's application and proxy load balancers now support hybrid key exchange for TLS 1.3, but it's initially Consent so customers can validate without disrupting existing applications. That Consent period is your testing window, not a grace period.
Myth 4: Hardware Upgrades Can Wait
Reality: Google stated that the timeline for some physical components may extend beyond 2029, depending on natural equipment replacement cycles.
You can't patch quantum resistance into a hardware security module that doesn't support ML-KEM or ML-DSA. Cloud KMS reached general availability for ML-KEM, ML-DSA, and SLH-DSA in 2025, and quantum-confidential ALTS completed the same year. But if your on-premises infrastructure relies on HSMs purchased in 2020, those devices likely can't run NIST-standardized post-quantum algorithms without replacement.
Budget cycles matter here. If your hardware refresh happens every five years and you just completed one in 2024, you're looking at 2029 before your next natural replacement window. That's the same year cryptographically relevant quantum computers might arrive. Start the procurement process now, or accept that you'll need an unscheduled capital expense.
Myth 5: This Is Purely a Cryptography Problem
Reality: Post-quantum migration intersects with data retention policies, breach notification obligations, and cross-border transfer mechanisms.
Under GDPR Article 32, you must implement appropriate technical and organisational measures to ensure security appropriate to the risk. If quantum computers can decrypt your archived backups from 2025, and those backups contain personal data, you're storing data you can no longer adequately protect. That creates a Retention Rule conflict: you may be required to keep records for seven years, but you can't keep them secure for seven years with current cryptography.
The same logic applies to breach notification. If an adversary harvests encrypted data in 2026 and decrypts it in 2030, when did the breach occur? Your 72-hour notification clock under GDPR Article 33 doesn't start ticking until you become aware of the breach, but the harm began when the data was exfiltrated. This temporal mismatch complicates your incident response planning.
What to Do Instead
Start with an inventory of cryptographic dependencies. Identify every system that uses asymmetric encryption: TLS endpoints, code signing infrastructure, VPN concentrators, API authentication, digital signature workflows. Map their upgrade paths and vendor support timelines.
Next, classify your data by confidentiality horizon. Anything that must remain confidential past 2029 requires quantum-safe protection now. That includes backups, archives, and data in transit to Data Archiving.
Then test hybrid mode where available. Google's load balancers offer hybrid key exchange as an Consent feature specifically so you can validate the change without production risk. Use that window to measure performance impact and identify incompatible clients.
Finally, align your hardware refresh cycles with post-quantum requirements. When you're specifying new HSMs, VPN appliances, or certificate authorities, verify that they support ML-KEM, ML-DSA, and SLH-DSA. The devices you purchase in 2025 need to remain viable through 2030 and beyond.
The quantum threat isn't theoretical anymore. Google's roadmap gives you specific dates and specific deliverables. Your job is to match those dates with your own infrastructure reality, not wait for a crisis to force the decision.
