What Google’s 2029 Deadline Means for Your Organization & How to Move Ahead 

On March 25, 2026, Google announced that it plans to complete its migration to Post-Quantum Cryptography (PQC) across all internal systems and customer-facing infrastructure by 2029. For an organization operating at Google’s scale, this is not a routine technology upgrade. It is a clear signal that the quantum computing threat is now being treated as a real-world security and business risk, not a distant research problem. 

The significance of this announcement extends far beyond Google itself. Every modern organization depends on cryptography to secure identities, certificates, software updates, communications, financial transactions, and critical infrastructure. The same cryptographic foundations that protect Google’s ecosystem also protect enterprise networks, cloud platforms, PKI environments, and digital trust systems worldwide. This blog explains what drove Google’s decision, what the underlying research actually shows, what it means for your organization’s infrastructure, and what a practical response looks like. 

What Drove Google’s Decision 

Three things converged to produce this announcement, and understanding each of them matters because together they explain why the timeline has shifted so significantly and so suddenly. The three driving factors are: 

1. Quantum Hardware is Advancing Faster

Progress in superconducting qubit architectures and quantum error correction has consistently outpaced what most public timelines projected, and the gap between expectation and reality is growing. 

The engineering ambition behind multiple active quantum hardware programs has expanded significantly as early milestones have been reached ahead of schedule. 

2. New Resource Estimates

Google Quantum AI published findings in April 2026 showing a roughly 20-fold reduction in the number of physical qubits required to break 256-bit Elliptic Curve Cryptography on a superconducting architecture, which is the mathematical foundation protecting most of the world’s digital infrastructure. 

The best prior published estimate placed the physical qubit requirement at around 9 million qubits on a photonic architecture, which placed the threat comfortably beyond the near horizon for most planning purposes. 

The new figure is under 500,000 physical qubits, and that threshold is within the engineering ambition of programs that exist, are funded, and are actively scaling today. 

3. The Migration Path is Clear

NIST finalized its first three post-quantum cryptography standards in 2024, giving organizations a clear and actionable set of algorithms to migrate toward for the first time. 

The tooling, meaning the cryptographic libraries and software infrastructure needed to implement these algorithms in real systems, is maturing, and reference implementations are available for teams to build from. OpenSSL 3.5, released in April 2025, introduced native support for ML-KEM, ML-DSA, and SLH-DSA, and the Open Quantum Safe project has made tested implementations available across multiple languages and platforms. There is no longer a reasonable technical basis for deferring migration planning while waiting for standards to settle. 

It is also worth noting that the announcement was co-authored by Google’s Vice President of Security Engineering and its Senior Staff Cryptography Engineer. This is not a research paper from an academic team. It is an organizational commitment made at the highest level of security leadership, and it came with an explicit call for engineering teams across the industry to follow suit. 

What the New Resource Estimates Actually Mean 

A technical paper from Google Quantum AI, co-authored with researchers from UC Berkeley, the Ethereum Foundation, and Stanford, has significantly updated our understanding of how close quantum computers are to breaking modern encryption. The findings are not incremental refinements to existing estimates. They represent a meaningful compression of the timeline that most security planning has been built around, and they go a long way toward explaining why 2029 is increasingly cited as a critical deadline.  

Before getting into the findings, it is worth noting how the authors chose to publish them. Rather than releasing full technical details, they withheld the specific attack mechanics and validated their resource estimates using a zero-knowledge proof, a cryptographic technique that allows independent parties to verify the figures are genuine without the paper becoming a practical guide for carrying out the attack. This approach adapts the coordinated vulnerability disclosure practices of the cybersecurity community to quantum cryptanalysis, where patching the underlying vulnerability takes years rather than weeks. Here is what the paper reveals: 

Breaking 256-Bit ECC

The paper substantially lowers the estimated threshold for what is required to break modern elliptic curve cryptography. According to the authors, breaking 256-bit elliptic curve cryptography now requires: 

• Fewer than 1,200 logical qubits, which is a dramatically lower figure than any previously published estimate for this problem. 
• Fewer than 90 million Toffoli gates, representing the computational operations required to execute the algorithm at the logical level. 
• Under 500,000 physical qubits on a superconducting architecture, which is roughly 20 times fewer than prior estimates suggested for the same superconducting architecture. 
• Approximately 9 minutes of computation time on a superconducting quantum computer. Bitcoin’s average block time is 10 minutes, which means a fast-clock superconducting quantum computer running these algorithms would have roughly a 41% probability of stealing Bitcoin from an active transaction before it confirms on the blockchain. The same logic applies to any system where cryptographic verification happens within a short window, including TLS handshakes, payment authorization flows, and identity federation requests. 

256-bit ECC underpins TLS, SSH, code signing, secure boot, digital signatures, and the entire blockchain ecosystem. A 20-fold reduction in the resources required to break it is not a marginal refinement. It is a fundamental shift in the threat picture. 

Three Quantum Attack Models Organizations Need to Understand  

Here is something that often gets lost in high-level discussions about quantum risk. Not all quantum threats require the same level of capability, and not all of them arrive at the same time. Understanding this distinction is what allows organizations to make smart sequencing decisions rather than treating the entire problem as one undifferentiated challenge. There are three attack types: 

1. At-Rest Attacks

At-rest attacks target any public key that has been exposed and remains visible over a long period of time, giving an attacker as much time as they need to derive the corresponding private key. 

A Cryptographically Relevant Quantum Computer, or CRQC, refers to a quantum computer capable of breaking currently deployed public-key cryptography at a scale and speed that creates real-world security risks. At-rest attacks do not require a fast CRQC. Any CRQC, regardless of its clock speed or architecture, can execute this type of attack from the moment it is capable of running Shor’s algorithm. This makes at-rest attacks the first category of quantum threat that will become exploitable, and it means the exposure window for this attack type opens before on-spend or on-setup attacks become feasible. 

Enterprise exposure in this category includes long-lived TLS certificates, SSH host keys, code signing keys, and PKI hierarchies where public keys have been publicly visible for extended periods. 

2. On-Spend Attacks

On-spend attacks target operations where a cryptographic signature must be verified within a short processing or settlement window, requiring the attacker to derive a private key faster than the underlying system can finalize the transaction. 

They require a fast-clock quantum computer, specifically superconducting architectures with short error correction cycle times that allow the algorithm to run quickly enough to beat the settlement window. 

Slower quantum architectures based on neutral atoms or ion traps operate orders of magnitude more slowly and are not expected to reach the speed necessary for on-spend attacks at the same time as superconducting systems. 

Enterprise exposure in this category includes TLS handshakes, API authentication tokens, real-time payment authorization, and single sign-on and identity federation flows where verification happens within seconds. 

3. On-Setup Attacks

On-setup attacks target protocols that rely on fixed public parameters generated through a one-time cryptographic ceremony, and a quantum computer is required only once to extract the secret embedded in those parameters. 

After that single computation, the attacker possesses a persistent backdoor that allows them to exploit the protocol indefinitely using nothing more than a classical computer. The backdoor produced is reusable across every instance of the protocol and can be transferred to other actors who never had direct access to a quantum computer, making this category of attack uniquely dangerous from a proliferation standpoint.  

Enterprise exposure in this category includes zero-knowledge proof systems, secure multi-party computation protocols, and privacy-preserving audit and verification systems built on pairing-based cryptography. 

Understanding Exposure: The Blockchain Example 

Blockchain infrastructure is useful here for one specific reason. All transaction data is public, which means quantum exposure can be measured precisely and independently verified rather than estimated. These are not projections based on modelling assumptions. They are figures drawn from live production systems running on public ledgers right now, and they give a concrete sense of what this kind of structural vulnerability looks like at scale. 

The Bitcoin Exposure 

As of the Google Quantum AI paper’s publication in April 2026, approximately 6.9 million BTC is currently vulnerable to at-rest quantum attacks across all standard address types, representing a significant fraction of the total circulating supply. Of that total, 1.7 million BTC is held in scripts that expose public keys directly on the blockchain with no hash protection, including coins widely attributed to Satoshi Nakamoto that have never moved since the early days of the network. 

An additional 2.3 million BTC has not moved in over five years and cannot be migrated to a quantum-safe address without the original private keys, making these funds a permanently accessible target for any actor with a functioning CRQC. 

The Ethereum Exposure 

Unlike Bitcoin, Ethereum’s quantum exposure spans multiple layers of the ecosystem, affecting not only user accounts but also consensus, governance, and scaling infrastructure:

Attack Vector	What Is at Risk
Account Vulnerability	20.5 million ETH across accounts that have ever sent a transaction and therefore exposed their public key
Admin Vulnerability	2.5 million ETH and roughly $200 billion in stablecoins and tokenised real-world assets governed by smart contracts with exposed admin keys
Code Vulnerability	15 million ETH across Layer 2 networks and bridges using quantum-vulnerable cryptographic primitives
Consensus Vulnerability	37 million staked ETH securing the Proof-of-Stake mechanism through BLS signature aggregation
Data Availability Vulnerability	The entire Layer 2 ecosystem dependent on KZG polynomial commitments introduced in the 2024 Dencun upgrade

The figures above reflect the state of the Ethereum ecosystem as of the Google Quantum AI paper’s publication in April 2026. Given how rapidly the Ethereum ecosystem evolves, the specific numbers will have changed, but the structural vulnerabilities they represent remain. 

What This Means Beyond the Cryptocurrency Context 

These are not poorly designed systems. They are correctly designed systems built for the threat environment that existed at the time, and that threat environment has now changed in ways that were not anticipated when the architecture decisions were made. 

The same statement applies to the enterprise infrastructure most organizations are running today, and the implications are identical even if the visibility is not. Blockchain vulnerabilities are publicly visible and precisely measurable because the underlying data is public. Enterprise vulnerabilities are not publicly visible, but they are not smaller, and in many cases they are larger because enterprise systems handle data and credentials whose compromise would not produce any visible signal before significant damage had already occurred.  

How Global Technology Infrastructure is Deploying PQC 

The migration to post-quantum cryptography is not a future intention or a pilot program being run by a handful of early adopters. It is in production at global scale across some of the largest technology and infrastructure organizations in the world, and the pace is accelerating. Here is how Google and other leading organizations are deploying PQC in practice: 

Google

• Android 17 integrates ML-DSA signatures into Android Verified Boot, protecting the device boot sequence against quantum signature forgery from the moment a device powers on and before any user software has loaded. 
• Android Keystore natively supports ML-DSA within the Trusted Execution Environment, enabling post-quantum digital signatures to be generated and stored entirely within secure hardware without exposure to the main operating system. 
• Google Play App Signing introduces hybrid signature blocks that combine classical and ML-DSA keys for application packages, covering billions of active installs with no action required from end users or developers. 
• Chrome has deployed hybrid ML-KEM key encapsulation by default since late 2024, meaning post-quantum protection is already active for the majority of HTTPS connections made through the browser. 
• Google Cloud KMS offers PQC-capable key management for enterprise customers, currently available in preview with general availability expected to follow. 

The Broader Ecosystem

• AWS: AWS has deployed ML-KEM across customer-facing service endpoints including S3, CloudFront, and KMS, bringing post-quantum key encapsulation to a significant portion of global cloud traffic. 
• Microsoft: Microsoft has integrated ML-KEM and ML-DSA into SymCrypt, the cryptographic library that underpins Windows, Azure, and Microsoft 365, with PQC APIs generally available to developers since 2025. 
• Cloudflare: As of April 2026, Cloudflare reports that over 65% of human-initiated traffic passing through its network is now protected with post-quantum encryption, representing a substantial share of global internet traffic. 
• Akamai: Akamai set hybrid ML-KEM as the default configuration for all customers, extending post-quantum key encapsulation to the content delivery and edge security layer. 
• Algorand: Algorand executed its first PQC-secured transaction in 2025 using Falcon signatures and has made Falcon signature verification available as a native primitive for smart contract developers building on the platform. 
• Blockchain Platforms: Blockchains including the Quantum Resistant Ledger, Mochimo, and Abelian were built on post-quantum cryptographic foundations from inception, demonstrating that full PQC deployment in production distributed systems is not only feasible but operational. 

While global organizations are deploying PQC in production, the process carries its own challenges, which we will discuss in the next section. 

The Challenges in PQC Migration

The migration to PQC is technically and operationally complex, and organizations should go in with a clear understanding of where the difficulty lies. Here is what organizations need to plan for explicitly: 

1. Performance Costs

ECDSA signatures, which are what most systems currently use, run between 64 and 73 bytes in size. Falcon signatures, one of the NIST-standardized post-quantum options, run approximately 1,280 bytes, representing a roughly 18-fold increase in signature size. ML-DSA signatures range from 2,420 to 4,595 bytes depending on the security level selected, which is between 33 and 63 times larger than a comparable ECDSA signature. 

Across systems that process signatures at scale, these size differences translate into measurable increases in bandwidth consumption, storage requirements, certificate management overhead, and TLS handshake processing load that need to be engineered for rather than simply absorbed. 

2. Implementation Maturity

PQC libraries are newer and have had significantly less real-world exposure and adversarial testing than the classical implementations they are replacing, which means edge cases and implementation vulnerabilities are more likely to surface during early deployment. 

Some post-quantum schemes involve mathematical operations, such as sampling from discrete Gaussian distributions in Falcon, that have historically introduced timing-based side-channel vulnerabilities when implemented without specific countermeasures. 

Hardware security modules and trusted execution environments require specific engineering work to accommodate the larger key sizes, signature sizes, and memory footprints that post-quantum algorithms require, and not all current HSM models support the necessary algorithms natively. 

3.  The Supply Chain Problem

Hardware refresh cycles in enterprise environments typically run five to ten years, which means equipment purchased today will still be in service well past 2029 and will need to support post-quantum algorithms for that entire operational period. 

Third-party libraries, vendor-supplied firmware, HSMs, network appliances, and legacy systems all carry their own independent migration timelines that are outside your direct control, and that may not align with your internal planning horizon. 

Engaging vendors now on their post-quantum roadmaps and building PQC algorithm support into procurement requirements before the next hardware purchase cycle is not premature planning. For many hardware categories, particularly those with long lead times and slow replacement cycles, it is already overdue. 

4. Two Major Deadlines Converging In 2029

The CA/Browser Forum is mandating a reduction in maximum TLS certificate lifespans to 47 days by 2029, representing an eightfold increase in renewal frequency compared to today’s standard of 398 days. For most organizations, this alone represents a significant operational challenge. Combined with PQC migration arriving on the same horizon, it becomes a compounding pressure that most security teams are not currently structured to absorb.  

Most organizations still rely on manual certificate management processes that will not scale to 47-day renewal cycles. Without automated certificate lifecycle management already in place, the volume of renewals required by 2029 will exceed what security teams can handle, creating gaps in cryptographic coverage precisely when quantum-safe infrastructure needs to be most reliable. 

The infrastructure required for 47-day certificate cycles and the infrastructure required for PQC migration overlap substantially. Organizations that treat them as separate workstreams will build the same foundational infrastructure twice and absorb the cost of two separate programs rather than one coherent one. 

These challenges are real, but they are manageable when migration is approached systematically and executed in a well-sequenced, phased manner. 

How to Begin Your PQC Transition?

If the challenges above feel daunting, the most useful thing to remember is that every organization that has successfully navigated a large-scale cryptographic migration started with the same first step: understanding what they were actually running.

Step 1: Build Your Cryptographic Inventory

The first step is understanding exactly where vulnerable cryptography exists across your environment: 

• Identify every system, protocol, library, and application across your environment that is currently using RSA, ECDSA, ECDH, or any other ECC-based cryptographic scheme, including systems you may not directly control such as third-party integrations and vendor-supplied components. 
• Include third-party dependencies, vendor-supplied firmware, hardware security modules, cloud services, and legacy systems in scope, because your migration is only as complete as the weakest link in the chain. 
• Map the data flows that depend on each cryptographic primitive so you understand which systems are connected to which, and where a migration in one place creates a dependency in another. 
• Identify which systems handle data that must remain confidential for years into the future, because these are your harvest now, decrypt later priority targets and they require protective action before any quantum computer exists, not after. This is where a CBOM becomes one of an organization’s most valuable assets. Encryption Consulting’s CBOM Secure identifies vulnerable cryptography across the enterprise and maintains a continuously updated, live inventory, ensuring asset data remains accurate and current in real time.
  

Step 2: Prioritize Authentication and Signature Systems 

Start with the areas where cryptographic failure would have the widest systemic impact: 

• Key management systems and certificate authorities carry the longest lead times and the highest consequence of failure if compromised, and they should be at the top of your migration priority list for both reasons. 
• Software signing pipelines and build infrastructure should be migrated early because a compromised signing key enables undetectable distribution of malicious code across every system that trusts the signed artifacts. 
• Remote attestation and device identity services are foundational to zero-trust architectures and need to be quantum-safe before the broader authentication stack can be considered secure. 
• Authentication services and identity providers are high-value targets because compromising them provides access to everything that depends on them, and they typically have complex dependencies that require long migration timelines. 
• Blockchain signing infrastructure and wallet management systems are directly exposed to the on-spend attack vector and should be assessed for migration readiness as a distinct workstream. 

Step 3: Deploy Hybrid Configurations

Hybrid deployments provide a practical way to begin migration without requiring the entire ecosystem to transition at once: 

• Running ML-KEM alongside existing classical key encapsulation algorithms provides quantum resistance for sensitive data in transit while maintaining full interoperability with systems that have not yet completed their own migration. 
• This hybrid approach means you do not need to wait for every system in your environment to be migrated before you begin protecting the most sensitive data flows, which is particularly important given the active data harvesting threat that exists right now. 
• Chrome’s production deployment of hybrid ML-KEM at global scale is the operational reference model for this approach and demonstrates that it is both technically sound and operationally manageable. 

Step 4: Engage Your Vendors Now

Migration readiness depends not only on your own systems, but on the preparedness of the broader vendor ecosystem supporting them: 

• Request explicit PQC roadmaps from every major hardware and software vendor in your environment, and treat the absence of a clear roadmap as a procurement risk that needs to be addressed before your next renewal or purchase decision. 
• Build post-quantum algorithm support into procurement requirements for all new hardware purchases going forward, so that every device entering your environment from this point has a viable path to quantum-safe operation for its full operational lifetime. 
• Identify systems with long replacement cycles, particularly HSMs, network appliances, and embedded systems, and prioritize early engagement with their manufacturers so that firmware or hardware updates can be planned well ahead of when they will be needed. 

Step 5: Design for Crypto-Agility

Future systems should be designed with adaptability in mind so cryptographic transitions can happen without major architectural disruption: 

• Every new system built or procured from this point forward should be designed to swap cryptographic algorithms without requiring full re-architecture, so that future algorithm transitions can be executed at the library or configuration level rather than the system level. 
• Cryptographic agility is not a short-term migration convenience that becomes less important once the current transition is complete. It is a permanent operational capability that every organization will need indefinitely as the cryptographic landscape continues to evolve. 
• Systems that cannot adapt quickly to algorithm changes are a compounding liability, because each successive migration cycle will require disproportionately more effort and cost to address them. 

Step 6: Test and Validate Your Migration Plan

Migration planning should be treated as an operational exercise that needs to be validated under realistic execution conditions: 

• Simulate the operational impact of migrating your highest-priority systems on a compressed timeline so that you understand what the actual execution challenges are before you are facing them under real deadline pressure. 
• Test your organization’s ability to revoke and reissue certificates at scale under time pressure, because this capability will be essential both for the 47-day certificate mandate and for any emergency response to a cryptographic incident. 
• Identify the specific dependencies and bottlenecks in your environment that would prevent you from completing migration by 2029, so that you can address them proactively rather than discovering them when the deadline is close and options are limited. 

These steps form the foundation of Encryption Consulting’s approach to PQC migration, which we will outline below. 

How Encryption Consulting Can Help 

Encryption Consulting is a trusted partner for organizations working toward quantum-safe security. We guide you through every phase of the transition, from initial discovery through full production migration, with a methodology built on practical experience and proven expertise. 

Cryptographic Discovery and Inventory

We start by mapping your entire cryptographic landscape, identifying every system across on-premises, cloud, and hybrid environments that relies on cryptographic keys, certificates, algorithms, and dependencies across applications, APIs, networks, and databases. 

Most organizations are surprised by the scope of what this uncovers. You cannot prioritize what you cannot see, and this step is the foundation that everything else is built on. 

A key part of making this discovery structured and actionable is the Cryptographic Bill of Materials, or CBOM. A CBOM is a complete and queryable record of everything your environment uses for cryptography, organized in a way that directly supports migration planning, risk prioritization, and compliance reporting. Without one, organizations are effectively navigating their PQC migration blind.  

CBOMSecure is Encryption Consulting’s purpose-built platform for generating and maintaining that record. It automatically discovers and inventories every cryptographic asset across your environment, maps quantum-vulnerable assets to NIST PQC standards, and continuously monitors your cryptographic posture so that new vulnerabilities, expiring certificates, and configuration drift are caught before they become incidents. For organizations facing the convergence of the 47-day certificate mandate and PQC migration on the same 2029 horizon, CBOMSecure provides the foundational visibility that makes both programs manageable. You cannot migrate what you cannot find, and you cannot automate what you have not inventoried. 

PQC Impact Assessment 

We evaluate exposure across every cryptographic asset in your environment that relies on RSA, ECC, or similar algorithms. 

We assess your PKI, HSMs, and applications for PQC readiness and deliver a prioritized report that identifies your highest-risk areas and maps them to a clear set of migration needs.  

PQC Strategy and Roadmap

With risks clearly defined, we build a tailored, phased migration strategy aligned with your business priorities, compliance obligations, and technical constraints. 

This includes policy updates, algorithm agility design, and a clear roadmap covering pilot deployments, hybrid configurations, and full production migration in a sequence that is realistic for your organization. . 

Vendor Evaluation and Proof of Concept 

We help you select and test PQC-ready solutions by defining technical and business requirements for RFI and RFP processes, running proofs of concept to evaluate vendor offerings, and delivering a vendor comparison matrix with a clear recommendation report.

Not every vendor claiming PQC readiness is equal, and this step ensures your decisions are based on evidence rather than marketing. 

Pilot Testing and Scaling

Before full deployment, we validate PQC configurations in pilot environments to confirm interoperability, surface integration issues early, and minimize disruption when the rollout scales to production. 

Feedback from technical and business stakeholders during the pilot phase is used to fine-tune the approach before it touches live systems. 

PQC Implementation

We execute full-scale migration, integrating post-quantum cryptography into your live environment across your PKI, applications, infrastructure, cloud services, and APIs, while maintaining compliance continuity and hybrid algorithm support throughout the transition. 

Every engagement includes hands-on training for your teams, detailed technical documentation for ongoing maintenance, and monitoring systems and lifecycle management processes to track cryptographic health, detect anomalies, and support future upgrades. 

Transitioning to post-quantum cryptography is one of the most complex infrastructure challenges organizations have faced in a generation, but you do not have to navigate it alone.

Conclusion 

The combination of Google’s 2029 deadline, the new resource estimates from Google Quantum AI, and converging regulatory pressure tells a consistent story. The post-quantum transition is no longer a future planning exercise. It is an active operational challenge that is already being addressed by the largest technology organizations in the world, and the window for an orderly migration is narrowing with every year that passes. 

Transparency in quantum computing research is likely to decrease as programs approach commercial viability, meaning the public signals that organizations typically rely on to calibrate their planning will become less reliable precisely when the threat is most acute. The first indication that a cryptographically relevant quantum computer exists may not come from a press release. It may come from an unexpected pattern of compromised systems. 

The organizations that will navigate this well are not necessarily the ones with the largest budgets. They are the ones that start with honest visibility into their own cryptographic exposure, sequence their response around the highest-risk systems first, and build the cryptographic agility that makes future transitions manageable rather than disruptive. 

Google has drawn its line at 2029. Regulators have drawn theirs. The question every security and technology leader needs to answer is not whether migration is necessary, but whether there is enough runway left to do it well, on their own terms, before the deadline forces their hand. 

If you are not sure where to start, that is exactly where Encryption Consulting can help. Reach out at [email protected] and let us help you understand where you stand and what it will take to get where you need to be.