Author: Justin Thaler

Compiled by: Plain Language Blockchain

The timeline for quantum computers related to encryption is often exaggerated—leading to urgent, comprehensive demands for a transition to post-quantum cryptography.

However, these calls often overlook the costs and risks of premature migration, and ignore the vastly different risk profiles between different cryptographic primitives:

Despite its costs, post-quantum encryption demands immediate deployment: Harvest-Now-Decrypt-Later (HNDL) attacks are underway because sensitive data encrypted today will still be valuable when quantum computers arrive, even decades from now. The performance overhead and implementation risks of post-quantum encryption are real, but HNDL attacks leave data requiring long-term confidentiality with no other option.

Post-quantum signatures face different considerations. They are less vulnerable to HNDL attacks, and their costs and risks (larger size, performance overhead, immature implementation, and errors) require careful consideration rather than immediate migration.

These distinctions are crucial. Misunderstandings can distort cost-benefit analyses, causing teams to overlook more significant security risks—such as bugs.

The real challenge in successfully transitioning to post-quantum cryptography lies in aligning urgency with actual threats. Below, I will clarify common misconceptions about the threat of quantum mechanics to cryptography—covering encryption, signatures, and zero-knowledge proofs—and focus in particular on their impact on blockchain.

How is our timeline progressing?

Despite much talk, the likelihood of a cryptography-related quantum computer (CRQC) emerging in the 2020s is extremely low.

By "cryptography-related quantum computer," I mean a fault-tolerant, error-correcting quantum computer capable of running Shor's algorithm at a sufficient scale to break elliptic curve cryptography or RSA attacks within a reasonable timeframe (e.g., within a maximum of one month of continuous computation).

Based on any reasonable interpretation of publicly available milestones and resource estimates, we are still a long way from a cryptographically relevant quantum computer. Companies sometimes claim that CRQC could be available before 2030 or even well before 2035, but publicly known progress does not support these claims.

As background, in all current architectures—trapped ions, superconducting qubits, and neutral atom systems—today’s quantum computing platforms are not close to the hundreds of thousands to millions of physical qubits (depending on the error rate and error correction scheme) required to run Shor’s algorithm attack {RSA-2048} or {secp}256{k}1.

The limiting factors are not only the number of qubits, but also gate fidelity, qubit connectivity, and the depth of the continuous error-correcting circuitry required to run deep quantum algorithms. While some systems now exceed 1,000 physical qubits, the original number of qubits is misleading: these systems lack the qubit connectivity and gate fidelity required for cryptographically related computations.

Recent systems have come close to the physical error rate at which quantum error correction begins to work, but no one has demonstrated a persistent error-correcting circuit depth of more than a few logical qubits… let alone the thousands of high-fidelity, deep-circuit, fault-tolerant logical qubits required to actually run Shor's algorithm. The gap between proving quantum error correction is feasible in principle and the scale required to implement cryptanalysis remains enormous.

In short: unless the number of qubits and the fidelity both increase by several orders of magnitude, quantum computers for encryption remain a long way off.

However, corporate press releases and media reports can be confusing. Here are some common sources of misunderstanding and confusion, including:

Demonstrations claiming "quantum advantage" are currently focused on man-made tasks. These tasks are chosen not for their practicality, but because they can run on existing hardware while appearing to exhibit significant quantum speedups—a fact often obscured in the announcements.

The company claims to have achieved thousands of physical qubits. However, this refers to a quantum annealing machine, not the gate model machine required to run Shor's algorithm to attack public-key cryptography.

The company is free to use the term "logical qubit." Physical qubits are noisy. As mentioned earlier, quantum algorithms require logical qubits; Shor's algorithm requires thousands. Using quantum error correction, a logical qubit can be implemented with many physical qubits—typically hundreds to thousands, depending on the error rate. However, some companies have extended the term beyond recognition. For example, a recent announcement claimed to have implemented a logical qubit using distance-2 codes and only two physical qubits. This is absurd: distance-2 codes can only detect errors, not correct them. A true fault-tolerant logical qubit for cryptanalysis requires hundreds to thousands of physical qubits each, not two.

More generally, many quantum computing roadmaps use the term "logical qubit" to refer to qubits that only support Clifford operations. These operations can be efficiently simulated in classical languages and are therefore insufficient to run Shor's algorithm, which requires thousands of error-correcting T gates (or more generally, non-Clifford gates).

Even if one of the roadmaps aims to "achieve thousands of logical qubits in year X", it does not mean that the company expects to run Shor's algorithm to break classical cryptography in the same year X.

These practices have severely distorted public perception of how close we are to cryptographic quantum computers, even among seasoned observers.

In other words, some experts are indeed excited about the progress. For example, Scott Aaronson recently wrote that, given the "astonishing pace of hardware development at present,"

I now believe it is a realistic possibility that we will have a fault-tolerant quantum computer running Shor's algorithm before the next US presidential election.

Aaronson later clarified that his statement did not imply a cryptographically relevant quantum computer: he argued that even a fully fault-tolerant Shor's algorithm that factored 15 = 3 × 5 would be considered an implementation—a calculation that could be done much faster with pencil and paper. The standard remains small-scale implementations of Shor's algorithm, not cryptographically relevant ones, because previous experiments on factoring 15 on quantum computers used simplified circuits, not the full, fault-tolerant Shor's algorithm. Furthermore, there's a reason these experiments consistently factored the number 15: arithmetic calculations modulo 15 are easy, while factoring slightly larger numbers like 21 is much more difficult. Therefore, quantum experiments claiming to factor 21 typically rely on additional hints or shortcuts.

In short, the expectation that a cryptographically relevant quantum computer capable of breaking {RSA-2048} or {secp}256{k}1 will emerge within the next 5 years—which is crucial for practical cryptography—has no publicly known progress to support it.

Even 10 years is still ambitious. Considering how far we are from quantum computers related to encryption, being excited about progress is entirely in line with a timeline of more than a decade.

So what about the US government setting 2035 as the deadline for a full-scale post-quantum (PQ) migration of its government system? I think that's a reasonable timeline for completing such a large-scale transition. However, it's not a prediction that cryptography-related quantum computers will exist by then.

In what situations is HNDL attack applicable (and in what situations is it not applicable)?

A HNDL (Hidden-Nearest-Decryption) attack refers to an adversary storing encrypted traffic now and then decrypting it when the associated quantum computer exists. A nation-state-level adversary would certainly be archiving encrypted communications from the US government on a massive scale, intending to decrypt them years after the CRQC (Confidential Communications Control Center) actually exists.

This is why encryption needs to be transitioned to immediately—at least for anyone with a need for confidentiality for 10-50 years or more.

However, digital signatures—which all blockchains rely on—are different from encryption: there is no confidentiality that can be traced back to an attack.

In other words, while signature forgery may indeed become possible once cryptographic quantum computers arrive, past signatures don't "hide" secrets like encrypted messages. As long as you know the digital signature was generated before CRQC, it cannot be forged.

This makes the transition to post-quantum digital signatures less urgent than the post-quantum transition to cryptography.

Major platforms are taking action accordingly: Chrome and Cloudflare have launched hybrid {X}25519+{ML-KEM} encryption for Transport Layer Security (TLS).

In this article, for ease of reading, I will use encryption schemes, although strictly speaking, secure communication protocols like TLS use key exchange or key encapsulation mechanisms rather than public-key encryption.

The term "hybrid" here means using both the post-quantum-safe scheme (i.e., ML-KEM) and the existing scheme ({X}25519) simultaneously to obtain a combined security guarantee. In this way, they can (hopefully) prevent HNDL attacks through ML-KEM, while maintaining classical security through {X}25519 should ML-KEM prove insecure even for today's computers.

Apple's iMessage also deploys this hybrid quantum encryption via its PQ3 protocol, and Signal deploys it via its PQXDH and SPQR protocols.

In contrast, the rollout of post-quantum digital signatures to critical network infrastructure is being delayed until cryptographically relevant quantum computers are truly near, because current post-quantum signature schemes introduce performance degradation (which will be discussed in detail later in this article).

zkSNARKs—zero-knowledge concise non-interactive knowledge arguments—are key to the long-term scalability and privacy of blockchains—similar to signatures. This is because even for non-post-quantum secure {zkSNARKs} (which use elliptic curve cryptography, just like today's non-post-quantum encryption and signature schemes), their zero-knowledge properties are post-quantum secure.

The zero-knowledge property ensures that no information about the secret witness is revealed in the proof—even to a quantum adversary—so there is no confidential information available for "first access" to be decrypted later.

Therefore, {zkSNARKs} are not easily vulnerable to get-first-decrypt attacks. Just as non-post-quantum signatures generated today are secure, any {zkSNARK} proof generated before the advent of cryptographically relevant quantum computers is trustworthy (i.e., the proved statement is absolutely true)—even if {zkSNARKs} use elliptic curve cryptography. Only after the arrival of cryptographically relevant quantum computers will attackers be able to find convincing proofs of false statements.

What does this mean for blockchain?

Most blockchains are not exposed to HNDL attacks:

Most non-privacy blockchains, such as Bitcoin and Ethereum today, primarily use non-post-quantum cryptography for transaction authorization—that is, they use digital signatures instead of encryption.

Similarly, these signatures are not a threat to HNDL: "get-first-decrypt" attacks apply to encrypted data. For example, Bitcoin's blockchain is public; the quantum threat is signature forgery (deriving the private key to steal funds), not decrypting already publicly available transaction data. This eliminates the immediate cryptographic urgency posed by HNDL attacks.

Unfortunately, even analyses from credible sources like the Federal Reserve have erroneously claimed that Bitcoin is vulnerable to HNDL attacks, an error that exaggerates the urgency of transitioning to post-quantum cryptography.

That said, the reduced urgency does not mean Bitcoin can wait: it faces varying timeline pressures from the enormous social coordination required to change the protocol.

The exception to date is privacy chains, many of which encrypt or otherwise hide the recipient and the amount. Once quantum computers are able to break elliptic curve cryptography, this confidentiality can now be obtained and retroactively deanonymized.

For such privacy chains, the severity of an attack varies depending on the blockchain design. For example, for Monero's curve-based ring signatures and key images (linkability tags for each output used to prevent double-spending), the public ledger itself is sufficient to retrospectively reconstruct the spending graph. But in other chains, the damage is more limited—see the discussion by Sean Bowe, a cryptographic engineer and researcher at Zcash, for details.

If it is important that users' transactions are not exposed to cryptographically-related quantum computers, then privacy chains should transition to post-quantum primitives (or hybrid schemes) as soon as feasible. Alternatively, they should adopt an architecture that avoids placing decryptable secrets on-chain.

Bitcoin's unique challenges: governance + obsolescence

For Bitcoin in particular, two realities have driven the urgency to begin the transition to post-quantum digital signatures. Neither of these is related to quantum technology.

One concern is the speed of governance: Bitcoin changes slowly. If the community cannot agree on appropriate solutions, any contentious issue could trigger a destructive hard fork.

Another concern is that after Bitcoin's transition, quantum signatures cannot be passively migrated: owners must actively migrate their coins. This means that obsolete, quantum-vulnerable coins cannot be protected. Some estimates place the number of quantum-vulnerable and potentially obsolete BTC at millions of coins, worth tens of billions of dollars at current prices (as of December 2025).

However, the quantum threat to Bitcoin will not be a sudden, overnight catastrophe… but rather a selective, gradual targeting process. Quantum computers cannot break all encryption simultaneously—Shor's algorithm must target one public key at a time. Early quantum attacks will be extremely expensive and slow. Therefore, once a quantum computer can crack a single Bitcoin signature key, attackers will selectively prey on high-value wallets.

Furthermore, users who avoid address reuse and do not use Taproot addresses—which expose public keys directly on-chain—are largely protected even without protocol changes: their public keys are hidden behind hash functions before their coins are spent. When they finally broadcast a spending transaction, the public key becomes visible, and a brief, real-time race ensues between honest spenders who need their transactions confirmed and quantum-equipped attackers who want to find the private key and spend the coins before the true owner's transaction is finalized. Therefore, the truly vulnerable coins are those with exposed public keys: early peer-to-peer K-outputs, reused addresses, and Taproot holdings.

There is no easy solution for vulnerable cryptocurrencies that have been abandoned. Some options include:

The Bitcoin community has agreed on a "mark day" after which any unmigrated coins will be declared destroyed.

The discarded quantum-vulnerable coin can be easily seized by anyone who possesses a cryptographically related quantum computer.

The second option would raise serious legal and security issues. Using a quantum computer to possess coins without a private key—even if one claims legal ownership or good faith—could raise serious problems under theft and computer fraud laws in many jurisdictions.

Furthermore, the term "obsolete" itself is based on the presumption of inactivity. But no one truly knows whether these coins lack a living owner with the keys. Evidence that you once owned these coins may not be sufficient to provide legal authorization to break the encryption and reclaim them. This legal ambiguity increases the likelihood that obsolete, vulnerable quantum coins will fall into the hands of malicious actors willing to disregard legal restrictions.

The final problem unique to Bitcoin is its low transaction throughput. Even if the migration plan is finalized and all quantum-vulnerable funds are moved to post-quantum-secure addresses, it will still take months at Bitcoin's current transaction rate.

These challenges make it crucial for Bitcoin to begin planning its subsequent quantum transition now—not because cryptographic quantum computers may arrive before 2030, but because the governance, coordination, and technical logistics required to migrate billions of dollars worth of coins will take years to resolve.

The quantum threat to Bitcoin is real, but the timeline pressure stems from Bitcoin's own limitations, not from the looming threat of quantum computers. While other blockchains face their own quantum vulnerability funding challenges, Bitcoin faces a unique exposure: its earliest transactions used pay-to-public-key (peer-to-peer K) outputs, placing the public key directly on-chain, making a significant portion of BTC particularly vulnerable to attacks by cryptographically-related quantum computers. This technological difference—coupled with Bitcoin's age, concentrated value, low throughput, and rigid governance—exacerbates the problem.

Please note that the vulnerability I described above applies to the cryptographic security of Bitcoin digital signatures—but not to the economic security of the Bitcoin blockchain. This economic security stems from the Proof-of-Work (PoW) consensus mechanism, which is not easily attacked by quantum computers for three reasons:

PoW relies on hashing, and is therefore only affected by the quadratic quantum speedup of Grover's search algorithm, not by the exponential speedup of Shor's algorithm.

The practical overhead of implementing Grover's search makes it extremely unlikely that any quantum computer could achieve even a modest speedup on Bitcoin's proof-of-work mechanism.

Even with significant speedups, these speedups would give large quantum miners an advantage over smaller miners, but would not fundamentally undermine Bitcoin's economic security model.

Costs and risks of post-quantum signatures

To understand why blockchains shouldn't rush to deploy post-quantum signatures, we need to understand performance costs and our confidence that post-quantum security is still evolving.

Most post-quantum cryptography is based on one of the following five methods:

• Hash
• Encoding
• lattices
• Multivariate quadratic systems (MQ)
• Isogenesis.

Why are there five different approaches? The security of any post-quantum cryptographic primitive rests on the assumption that quantum computers cannot efficiently solve certain mathematical problems. The more "structured" the problem, the more efficient the cryptographic protocols we can build from it.

However, this has its advantages and disadvantages: the additional structure also creates more room for attack algorithms to exploit. This creates a fundamental contradiction—stronger assumptions can achieve better performance, but at the cost of potential security vulnerabilities (i.e., an increased likelihood that the assumptions will be proven wrong).

Generally, hash-based methods are the most conservative in terms of security because we are most confident that quantum computers cannot effectively attack these protocols. However, they are also the worst performing. For example, the hash-based signature schemes standardized by NIST, even with their minimum parameter settings, are 7-8 KB in size. In contrast, today's elliptic curve-based digital signatures are only 64 bytes. That's about a 100-fold difference in size.

Lattice schemes are a major focus of deployment today. NIST has chosen lattice-based schemes for its standardization, and two of its three signature algorithms are also based. One lattice scheme (ML-DSA, formerly known as Dilithium) produces signatures ranging in size from 2.4 KB (at 128-bit security) to 4.6 KB (at 256-bit security)—making it approximately 40–70 times larger than today's elliptic curve-based signatures. Another lattice scheme, Falcon, has slightly smaller signatures (666 bytes for Falcon-512 and 1.3 KB for Falcon-1024), but involves complex floating-point operations, which NIST itself marks as a particular implementation challenge. Thomas Pornin, one of Falcon's creators, called it "the most complex cryptographic algorithm I've ever implemented."

Implementing lattice-based digital signatures is also more challenging than elliptic curve-based signature schemes: ML-DSA has more sensitive intermediates and nontrivial rejection logic, requiring side-channel and fault protection. Falcon adds the constant-time floating-point problem; in fact, several side-channel attacks on Falcon implementations have recovered the secret key.

These issues pose an immediate risk, unlike the distant threat posed by encryption-related quantum computers.

There are good reasons to be cautious when deploying higher-performance post-quantum cryptographic methods. Historically, leading candidates like Rainbow (an MQ-based signature scheme) and SIKE/SIDH (a homology-based encryption scheme) were broken classically, meaning they were broken using today's computers, not quantum computers.

This happened very late in the NIST standardization process. This is healthy science at work, but it illustrates that premature standardization and deployment can be counterproductive.

As mentioned earlier, the internet infrastructure is taking a deliberate approach to signature migration. This is particularly noteworthy given how long it takes for the internet's cryptographic transition to begin. The shift from MD5 and SHA-1 hash functions—which were technically abandoned by network administrators several years ago—took many years to be actually implemented in the infrastructure, and in some cases is still in progress. This is because these schemes are completely vulnerable, not just potentially susceptible to future technologies.

The unique challenges of blockchain and internet infrastructure

Fortunately, blockchains like Ethereum or Solana, actively maintained by open-source developer communities, can be upgraded much faster than traditional network infrastructure. On the other hand, traditional network infrastructure benefits from frequent key rotations, meaning its attack surface moves much faster than early quantum machines could target—a luxury that blockchains lack because coins and their associated keys can be exposed indefinitely.

However, in general, blockchains should still adhere to the network's well-thought-out signature migration approach. Neither signature setup exposes the network to HNDL attacks, and regardless of key persistence, the costs and risks of prematurely migrating to an immature post-quantum scheme remain significant.

There are also blockchain-specific challenges that make premature migration particularly risky and complex: for example, blockchains have unique requirements for signature schemes, especially the ability to rapidly aggregate many signatures. Today, BLS signatures are commonly used because of their ability to achieve very fast aggregation, but they are not post-quantum secure. Researchers are exploring SNARK-based post-quantum signature aggregation. This work is promising but still in its early stages.

For SNARKs, the community is currently focused on hash-based structures as the leading post-quantum option. But a major shift is on the horizon: I believe that in the coming months and years, lattice-based options will become attractive alternatives. These alternatives will offer better performance than hash-based {SNARKs} in various aspects, such as shorter proofs—similar to how lattice-based signatures are shorter than hash-based signatures.

The bigger problem now: achieving security

In the coming years, exploiting vulnerabilities will pose a greater security risk than cryptographically related quantum computers. For {SNARKs}, the primary concern is program errors (bugs).

Program errors are already a challenge for digital signatures and encryption schemes, and {SNARKs} are far more complex. Indeed, a digital signature scheme can be viewed as a very simple {zkSNARK} that states, "I know the private key corresponding to my public key, and I authorize this message."

For post-quantum signatures, immediate risks also include implementation attacks, such as side-channel and fault injection attacks. These types of attacks are well-documented and can extract secret keys from deployed systems. They pose a more pressing threat than distant quantum computers.

The community will work for years to identify and fix procedural bugs in {SNARKs} and strengthen post-quantum signature implementations to resist side-channel and fault injection attacks. Because the dust is still settling regarding post-quantum {SNARKs} and signature aggregation schemes, blockchains that transition too early risk being locked into suboptimal solutions. They may need to migrate again when better options emerge or when implementation vulnerabilities are discovered.

What should we do? 7 suggestions

Given the realities I've outlined above, I'll conclude with advice for various stakeholders—from builders to policymakers. The primary principle: Take the quantum threat seriously, but don't act on the assumption that cryptographically relevant quantum computers will arrive before 2030. This assumption has not been confirmed by current developments. Nevertheless, there are still things we can and should do now:

We should deploy hybrid encryption immediately.

Or at least when long-term confidentiality is important and the cost is acceptable.

Many browsers, CDNs, and messaging applications (such as iMessage and Signal) have deployed hybrid approaches. These hybrid approaches—post-quantum + classical—can defend against HNDL attacks while mitigating potential weaknesses in post-quantum solutions.

Use hash-based signatures as soon as the size is acceptable.

Software/firmware updates—and other such low-frequency, size-insensitive scenarios—should immediately adopt hybrid hash-based signatures. (The hybrid approach is to hedge against implementation flaws in the new scheme, not because the security assumptions of hash-based signatures are in question.)

This is conservative and provides society with a clear "lifeboat" in the unlikely event that a quantum computer for cryptography will unexpectedly appear sooner than expected. Without prior deployment of post-quantum signature software updates, we will face a bootstrapping problem after the advent of CRQC: we will be unable to securely distribute the post-quantum cryptographic fixes we need to defend against it.

Blockchain does not need to rush to deploy post-quantum signatures—but planning should begin immediately.

Blockchain developers should follow the leadership of the network PKI community and adopt a thoughtful approach to post-quantum signature deployments. This allows post-quantum signature schemes to continue maturing in terms of performance and our understanding of their security. This approach also gives developers time to re-architect systems to handle larger signatures and develop better aggregation techniques.

For Bitcoin and other L1 cryptocurrencies: the community needs to define migration paths and policies regarding abandoned, quantum-vulnerable funds. Passive migration is not feasible, so planning is crucial. And given Bitcoin's unique non-technical challenges—slow governance and a large number of high-value, potentially abandoned, quantum-vulnerable addresses—it is especially important for the Bitcoin community to begin planning now.

At the same time, we need to allow research on post-quantum {SNARKs} and aggregateable signatures to mature (which may take several more years). Again, premature migration carries the risk of being locked into suboptimal solutions or requiring a second migration to resolve implementation errors.

A note about Ethereum's account model: Ethereum supports two account types that have different impacts on post-quantum migrations—Externally Owned Accounts (EOAs), a traditional account type controlled by a {secp}256{k}1 private key; and smart contract wallets with programmable authorization logic.

In non-emergency situations, if Ethereum adds support for post-quantum signatures, upgradable smart contract wallets can switch to post-quantum verification through contract upgrades—while EOAs may need to transfer their funds to a new post-quantum secure address (although Ethereum will likely also provide a dedicated migration mechanism for EOAs).

In the event of a quantum emergency, Ethereum researchers have proposed a hard fork plan to freeze vulnerable accounts and allow users to recover their funds by proving their knowledge of their mnemonic phrases using post-quantum-secure {SNARKs}. This recovery mechanism will work for EOA and any smart contract wallets that have not yet been upgraded.

The practical impact on users: A well-audited, upgradeable smart contract wallet might offer a slightly smoother migration path—but the difference is minor and comes with trade-offs regarding trust in wallet providers and upgrade governance. More importantly, the Ethereum community continues its work on post-quantum primitives and contingency response plans.

A broader design lesson for builders: Many blockchains today tightly couple account identity to specific cryptographic primitives—Bitcoin and Ethereum with ECDSA signatures on {secp}256{k}1, other chains with EdDSA. The challenges of post-quantum migration highlight the value of decoupling account identity from any particular signature scheme. Ethereum's steps toward smart accounts and similar account abstractions on other chains reflect this trend: allowing accounts to upgrade their authentication logic without abandoning their on-chain history and state. This decoupling doesn't make post-quantum migration trivial, but it does offer more flexibility than hardcoding accounts into a single signature scheme. (This also enables unrelated features such as sponsored transactions, social recovery, and multi-signatures.)

For privacy chains, which encrypt or hide transaction details, an earlier transition should be prioritized if performance is acceptable.

The confidentiality of users on these chains is currently exposed to HNDL attacks, although the severity varies depending on the design. Chains that can achieve complete traceability and deanonymization solely through a public ledger face the most pressing risks.

Consider hybrid schemes (post-quantum + classical) to prevent the apparent post-quantum scheme from being proven to be insecure even on a classical basis, or to implement architectural changes that avoid placing decryptable secrets on the chain.

In the near term, the priority is to achieve security—rather than to mitigate the quantum threat.

Especially for complex cryptographic primitives like {SNARKs} and post-quantum signatures, program errors and implementation attacks (side-channel attacks, fault injection) will pose a much greater security risk than cryptographically relevant quantum computers in the coming years.

Invest now in auditing, fuzzing, formal verification, and defense-in-depth/layered security approaches—don't let quantum concerns overshadow more pressing procedural error threats!

Fund the development of quantum computing.

One important national security implication of all of the above is that we need to continue funding and talent development in quantum computing.

The fact that a major adversary has achieved encryption-related quantum computing capabilities before the United States poses a serious national security risk to us and the rest of the world.

Stay informed about quantum computing announcements.

As quantum hardware matures, the coming years will see numerous milestones. Paradoxically, the frequency of these announcements itself demonstrates how far we are from cryptographically relevant quantum computers: each milestone represents one of many bridges we must cross before reaching that point, and each milestone will generate its own headlines and waves of excitement.

Treat press releases as progress reports that require critical evaluation, rather than as prompts for sudden action.

Of course, there may be surprising developments or innovations that accelerate the expected timeline, just as there may be serious scaling bottlenecks that extend it.

I would not argue that it is absolutely impossible for a quantum computer with cryptography to emerge within five years, only extremely unlikely. The above recommendations are robust to such uncertainty, and following them can avoid more immediate and likely risks: implementation errors, hasty deployments, and the common pitfalls of a flawed cryptographic transition.