Google Says Prepare for Quantum. Here Is What They Left Out.

On February 6, 2026, Google's Kent Walker and Hartmut Neven published a blog post urging enterprises to begin quantum migration immediately. Their message was clear: the quantum threat is real, the timeline is accelerating, and organizations that wait will pay for it. They are right on all three counts. But they left out the hardest part.

What Google Got Right

Google's core argument is sound. NIST finalized three post-quantum cryptography standards in August 2024—ML-KEM, ML-DSA, and SLH-DSA—giving enterprises a concrete migration target for the first time. The message: start now, because migration takes years and the threat window is shrinking.

They correctly identify the cloud as a starting point. Major cloud providers are already integrating PQC into TLS handshakes, key management services, and certificate authorities. For organizations running primarily on cloud infrastructure, upgrading transport-layer cryptography is becoming a configuration change rather than a re-architecture.

This is genuinely good advice—as far as it goes.

The Discovery Gap

Cloud migration addresses the transport layer. It does not address the application layer, the data layer, or the dependency layer. And that is where most quantum exposure actually lives.

Consider a typical enterprise environment. The TLS certificates that encrypt data in transit represent perhaps 15% of the total cryptographic surface. The remaining 85% includes:

• RSA and ECDSA keys hardcoded in application configurations
• Ephemeral key material logged by debugging frameworks
• Legacy PKCS#11 integrations with hardware security modules
• Third-party API endpoints still negotiating RSA-2048 key exchange
• Database encryption using AES-128 with RSA-wrapped keys
• Certificate pinning in mobile applications that will break during migration

None of this shows up in a cloud provider's migration dashboard. You cannot migrate cryptography you have not inventoried. And most enterprises have never inventoried their cryptographic dependencies at the depth quantum migration requires. QSolve migration advisory fills this gap with discovery and roadmap planning.

Store Now, Decrypt Later Is Already Happening

The “Harvest Now, Decrypt Later” threat means the exposure window is not future—it is present. Nation-state adversaries are already capturing encrypted traffic for future decryption. Data with retention periods exceeding 10 years—healthcare records, financial transactions, classified communications, intellectual property—is vulnerable today, regardless of when a cryptographically relevant quantum computer arrives.

This changes the urgency calculation entirely. The question is not “when will quantum computers break RSA?” The question is “when was the data I am protecting today first captured by an adversary?”

The Resource Curve

Craig Gidney's 2024 research demonstrated that RSA-2048 factorization requirements are dropping faster than expected—from an estimated 20 million physical qubits to potentially under 1 million with improved error correction. NIST IR 8547, published in November 2024, formally deprecates SHA-1 and plans to deprecate 112-bit security (including ECDSA P-256) by 2030.

Apply the Mosca inequality: if the shelf life of your data (X) plus your migration time (Y) exceeds the time until quantum computers can break your encryption (Z), you are already late. For organizations with 15-year data retention and 3-year migration timelines, the break-even point was 2023. Three years ago.

Five Deliverables for Quantum Readiness

Cloud migration is step one. But a complete quantum readiness program requires five deliverables that no cloud provider migration tool produces:

1. Cryptographic inventory across all systems—not just TLS certificates, but every RSA key, ECC curve, AES implementation, and hash function across applications, databases, APIs, and third-party dependencies.
2. Data sensitivity classification by retention period—mapping each data asset to its required protection timeline. A 90-day session token and a 30-year medical record cannot share the same migration priority.
3. Quantum exposure timeline per asset—calculating when each cryptographic implementation becomes vulnerable based on algorithm, key length, and adversary capability projections.
4. Prioritized migration roadmap—sequencing the transition from highest-risk assets to lowest, accounting for dependency chains, budget constraints, and operational continuity requirements.
5. Continuous monitoring for cryptographic drift—ensuring that new deployments, dependency updates, and configuration changes do not reintroduce quantum-vulnerable cryptography after migration.

The Bottom Line

Google is right that enterprises need to act now. But acting means more than upgrading cloud TLS. It means knowing where every piece of cryptography lives in your stack, understanding which data faces the most urgent quantum exposure, and building a migration plan that accounts for the full attack surface—not just the part your cloud provider can see.

QScoutwas built for exactly this gap: a 7-day cryptographic discovery assessment that inventories every algorithm, key, and protocol across your enterprise and produces the prioritized migration roadmap that cloud migration alone cannot provide.