Why Experts Now Put the Quantum Crypto Threat at Around 2029

# When the Timeline Moved: How One Investment Advisory Firm Started Preparing for Quantum Encryption Threats

The moment a threat stops being theoretical, preparation stops being optional. For most of the past decade, post-quantum cryptography was a concern held by security researchers, government agencies, and a small number of enterprise risk managers. The general posture at most small and mid-sized firms was comfortable deferral: yes, this will matter eventually; no, it does not matter yet.

That posture became difficult to maintain in late 2024 and early 2025. Scott Aaronson, one of the most respected quantum computing theorists working today and a former skeptic of near-term timelines, published a direct and unambiguous assessment. He wrote that serious researchers he trusted now expected a fault-tolerant quantum computer capable of running Shor's algorithm on meaningful key sizes by approximately 2029. Alongside that, Google DeepMind released results showing that its AlphaQubit AI system could reduce quantum error rates with state-of-the-art accuracy, addressing one of the most persistent obstacles to building reliable large-scale quantum hardware.

This article traces how one small registered investment advisory firm, managing approximately fifty million dollars in client assets across three advisors, absorbed that news and began moving from awareness to action. The names are not the point. The process is.

The Morning They Stopped Treating the Timeline as Speculative

The firm's managing advisor read the Aaronson post on a Tuesday morning and forwarded it to the other two advisors with a single question: what are we actually exposed to?

The reason the post landed differently than previous quantum security warnings was the source. Aaronson had spent years being the person in the room who explained why the more alarming timelines were overstated. His reversal was not a sensationalist headline from a publication that did not understand the technical nuance. It was a careful person updating his view on the basis of evidence, specifically the AI-assisted error reduction work coming out of DeepMind. AlphaQubit was not theoretical progress. It was a deployed system demonstrating measurable reduction in the qubit error rates that had been the limiting factor in scaling up fault-tolerant quantum hardware.

The AlphaQubit connection matters because it links the quantum threat to AI development trajectories in a way that earlier analyses did not. Progress toward reliable quantum computers is no longer happening only through classical hardware engineering. It is being accelerated by machine learning systems that can model and correct quantum errors more effectively than any previous approach. That changes the rate of advance in a way that is hard to project linearly.

The critical technical point that the firm's advisors needed to understand clearly was this: Shor's algorithm does not work by trying every possible key. It works by exploiting the mathematical structure that makes public-key cryptography function, specifically the difficulty of factoring large numbers or solving the discrete logarithm problem. Adding more digits to the key does not help, because the algorithm makes the underlying math stop being hard. What is currently secure with a 2048-bit RSA key or elliptic-curve cryptography does not become secure with a 4096-bit key when the math itself is broken.

This means the protection most organizations rely on is not designed to scale against this specific threat. When the firm's advisors understood that, the question shifted from "should we be concerned about this eventually" to "what do we actually have that depends on this kind of cryptography right now."

The Exposure Inventory That Took Three Hours and Surfaced More Than Anyone Expected

The firm spent the next week building an inventory. The goal was simple: list every system they used that relied on public-key cryptography. The list that resulted was longer than any of the three advisors had expected before they started.

Portfolio management software: connected to custodians via encrypted API, relying on TLS certificates built on RSA or elliptic-curve keys. Client portal: authentication and session security built on the same infrastructure. Email: the firm used a managed email provider whose TLS encryption was standard public-key based. Document storage: cloud-based, with encryption at rest using keys that were ultimately secured by public-key methods at the certificate authority layer. Software the firm paid for and installed on local machines: those updates were signed with digital signatures relying on the same cryptographic infrastructure.

Satellite communications was not in scope for a three-person firm. Banking integrations were, because the firm transmitted ACH instructions through encrypted channels. The custodian relationships involved authenticated API calls. Every one of those connections used public-key cryptography somewhere in the chain.

One advisor noted that the exposure inventory felt like learning that a building they worked in had been built with a specific material before a certain year. The building was fine today. The question was whether the material would remain acceptable under conditions that did not yet exist but had a credible probability of existing within a planning horizon that was shorter than the usual seven-to-ten-year infrastructure replacement cycle.

The store-now-decrypt-later dimension made the inventory more urgent than a future-focused threat assessment usually feels. Any adversary with sufficient resources, whether a state actor or an organized criminal operation, who captures encrypted data transmitted today can hold that data and decrypt it when fault-tolerant quantum hardware becomes available. For an investment advisory firm, the data in transit today includes client account numbers, Social Security numbers, transaction histories, and tax information. The data being encrypted today for long-term storage has the same exposure profile. The threat is not purely future-tense. The clock on stored data started the day it was captured.

The Vendor Conversation That Turned a Technology Question Into a Contract Question

With the inventory complete, the firm scheduled a call with the customer success team at their primary portfolio management software vendor. The vendor serves hundreds of advisory firms and has a dedicated compliance and security track in their annual conference. The firm's expectation was that this would be a brief technical check-in.

The call lasted ninety minutes.

The vendor's security team was prepared to discuss the topic and had clearly been fielding the question more frequently. What they could not provide was a specific committed timeline for post-quantum migration of their infrastructure. Their position was that they were monitoring NIST's post-quantum cryptography standardization process, which finalized its first set of algorithms in 2024, and that they expected to begin migration planning in 2026 with implementation following the standards as they matured.

The firm's advisors pressed on a more specific question: would the vendor's infrastructure be fully migrated to post-quantum standards before 2029? The vendor's answer was that it was too early to commit to a specific date but that this was on their roadmap.

That answer turned a technology question into a contract question. The firm's service agreement with the vendor included standard data security language but no specific post-quantum commitment. The firm's compliance officer began drafting language for the next contract renewal cycle that would require the vendor to provide a documented post-quantum migration roadmap with milestone dates and notify the firm of any material changes to that timeline.

The same conversation, in shorter form, happened with the firm's email provider and its document storage provider. The pattern was consistent across all three vendors: awareness of the issue, active monitoring of the standards landscape, no committed migration date, no contractual obligation to migrate by any specific time.

The practical lesson from these conversations was that vendor dependency is a category of post-quantum exposure that is distinct from the firm's own infrastructure choices. Even if the firm took every preparatory step available to it, its actual security posture would depend in significant part on whether its vendors moved on a timeline consistent with the emerging threat.

A 36-Month Preparation Plan Built Around What the Firm Can Actually Control

The firm structured its preparation around four phases, each tied to a specific milestone in the post-quantum cryptography landscape and in its own vendor relationships.

In the first twelve months, the focus is on documentation and vendor engagement. The exposure inventory becomes a living document updated annually. Every vendor contract that comes up for renewal gets post-quantum language added to the data security section. The firm engages its cybersecurity insurance provider to ask whether post-quantum migration status will affect coverage terms in the 2026 renewal cycle.

In months twelve through twenty-four, the focus shifts to monitoring and alerting. NIST is finalizing additional post-quantum algorithm standards. The firm tracks these and establishes a relationship with a security consultant who can translate standards developments into practical implications for its specific technology stack. Any vendor who has not provided a migration roadmap by the eighteen-month mark gets a formal written inquiry with a thirty-day response deadline.

In months twenty-four through thirty-six, the firm begins active migration of the components under its direct control. This includes updating any internal tools that use encrypted communication, rotating to post-quantum compatible certificates as they become available from certificate authorities, and moving to post-quantum key exchange for any encrypted communications the firm manages directly. The target is to complete migration of directly controlled components before the thirty-six-month mark, leaving the remaining exposure concentrated in vendor-dependent systems where the firm's leverage is contractual rather than technical.

The illustrative cost comparison is instructive. A post-quantum migration of the kind described above, engaging a security consultant for fifteen to twenty hours spread over thirty-six months, updating service agreements, and upgrading directly controlled infrastructure, runs somewhere between fifteen thousand and forty thousand dollars for a firm of this size. That range accounts for consultant fees, staff time, and technology updates.

Against that, a breach event in which retroactively decrypted client data is exposed to a third party carries a materially different cost profile. For a registered investment advisory firm, a data breach involving client personally identifiable information triggers SEC incident reporting requirements, potential FINRA inquiry, and direct client notification obligations. Legal and notification costs for a small firm handling a breach of this nature routinely exceed two hundred thousand dollars before any regulatory fine or civil liability is assessed. The firm's cybersecurity insurance covers some portion of that, but premiums have been rising and coverage limits have been tightening across the industry.

The preparation cost is not a guarantee of safety. No preparation eliminates the risk before quantum computing reaches the threshold where it becomes operational. What preparation does is reduce the attack surface, demonstrate due diligence for regulatory purposes, and ensure the firm is not among the organizations that will be scrambling to migrate infrastructure on an emergency timeline when the threat becomes imminent rather than probable.

The Compliance Document That Did Not Exist Before and Now Has To

The final output of the firm's initial assessment process was a structured document that had not previously existed in its compliance file: a post-quantum cryptography risk assessment and preparedness timeline.

The document records the exposure inventory, the dates and outcomes of each vendor conversation, the contractual language changes made or requested, and the four-phase preparation timeline with milestone dates. It also notes the specific technical basis for the updated timeline assessment, including Aaronson's public statement and the AlphaQubit research publication, so that the document is grounded in citable sources rather than general security anxiety.

The purpose of the document is dual. First, it functions as a project management artifact. The firm reviews it quarterly, updates the vendor engagement log, and tracks progress against the phase milestones. Second, it functions as a compliance artifact. If the firm is ever asked by a regulator, an auditor, or a client to demonstrate that it had identified and begun addressing this category of risk, the document provides a contemporaneous record of when it learned what, what it did in response, and on what timeline.

Both Google and Cloudflare have stated publicly that they are targeting 2029 as the date by which they expect to have completed migration to post-quantum security for their core infrastructure. That timeline is not arbitrary. It reflects the best current assessment of when fault-tolerant quantum hardware capable of breaking current encryption standards could be operational.

A three-advisor investment advisory firm is not Google. But the encryption protecting its clients' data is the same encryption Google is preparing to replace. The timeline is the same. The question is whether small firms treat that timeline as relevant to them now, or wait until larger organizations have completed their migrations and the threat has moved closer before paying attention. The firms that start building the compliance artifact today are the ones who will be able to show a regulator, three years from now, that they took a credible professional assessment seriously when it was published and acted on it methodically. That record has value independent of whether 2029 is exactly right.