Direct answers, no hedging.

No. No publicly known quantum computer can break the encryption protecting banking, messaging or cryptocurrency. Today's machines have far too few stable logical qubits, and error rates remain the binding constraint. The risk is forward-looking, which is exactly why migration timelines matter more than current capability.

A cryptographically relevant quantum computer (CRQC) is one large and stable enough to break deployed public-key cryptography. Estimates put that at millions of physical qubits supporting thousands of error-corrected logical qubits. Headline qubit counts describe physical qubits, so they overstate progress toward this threshold.

Public-key cryptography is at risk: RSA, Diffie-Hellman, and elliptic-curve schemes like ECDSA and Ed25519 would all fall to Shor's algorithm. Symmetric encryption and hashing are not broken — Grover's algorithm only halves effective key strength, which AES-256 and SHA-256 absorb comfortably.

Yes, for practical purposes. Grover's algorithm reduces AES-256's effective security to roughly 128 bits, which remains far beyond reach. AES-128 drops to about 64 bits of quantum security, so long-life data should prefer AES-256, but there is no urgency comparable to replacing RSA or ECDSA.

Largely yes. Quantum search offers only a square-root speedup against hash functions, so SHA-256 retains a wide margin and Bitcoin's proof-of-work is not meaningfully threatened. Hash functions are secure enough that SLH-DSA builds an entire post-quantum signature scheme on them alone.

Post-quantum cryptography is software: new algorithms that run on today's hardware and protect data everywhere. Quantum key distribution is hardware: it uses quantum physics to exchange keys over dedicated links. PQC is the practical path for almost every organisation, and the NSA does not recommend QKD for national-security systems.

Not today, and not from every address even in future. Bitcoin's exposure is narrow: an attacker with a CRQC could derive a private key only from a public key that is already visible on-chain. Addresses that have never spent publish only a hash, which keeps the key hidden.

P2PK outputs are most exposed, because they contain the raw public key — many early mining rewards are still held this way. Next come any addresses that have already spent, since the first spend publishes the public key. Unspent P2PKH and SegWit addresses are the least exposed.

Not a sudden network-wide failure. The first realistic attack would target a small set of high-value addresses with already-exposed public keys. The network response would be a signature-scheme upgrade shipped as a soft fork, with a migration window for users to move funds to quantum-resistant outputs.

No. Ethereum accounts use ECDSA and consensus uses BLS signatures, neither of which is post-quantum. The Ethereum Foundation funds active research into hash-based and STARK-based migration paths, and account abstraction gives Ethereum more flexibility to change signing schemes than Bitcoin has, but nothing is deployed.

Very few, and the claim deserves scrutiny. Quantum Resistant Ledger uses XMSS hash-based signatures by design, and Mochimo uses WOTS+. Algorand uses Falcon for state proofs but ordinary accounts still use Ed25519. Treat 'quantum-safe' marketing as a claim to verify, not a property to assume.

Proof-of-work is not the vulnerable part. Quantum computers threaten signatures, not mining: Grover's algorithm would offer only a modest advantage in hashing, and mining difficulty adjusts. The exposure sits in the elliptic-curve signatures that authorise spending.

Almost certainly not in the strict sense — nearly every mainstream wallet signs with ECDSA or Ed25519. What varies is exposure: a wallet using fresh addresses that have never spent reveals no public keys, which removes the practical attack surface even though the underlying cryptography is classical.

No — and moving can make things worse. Spending from an address publishes its public key, so a panic transfer converts a hidden key into an exposed one. Reduce address reuse going forward, keep long-term holdings in unspent addresses, and wait for protocol-level migration guidance.

It means the full public key for an address is visible on-chain rather than hidden behind a hash. This matters because Shor's algorithm derives a private key from a public key — so an address whose key is still hashed is not a viable target, regardless of its balance.

Yes, materially. The first spend from an address publishes its public key permanently. Every subsequent deposit to that address therefore sits behind an already-exposed key. Using a fresh receive address per payment is the single most effective mitigation available to individuals today.

A hardware wallet protects your private key from malware and theft, not from cryptanalysis. It signs with the same ECDSA or Ed25519 as any other wallet, so quantum exposure is identical. Hardware wallets remain strongly recommended — just not for this particular threat.

No. A seed phrase is a backup of the same private key, derived through hashing. It changes nothing about whether the resulting public key is exposed on-chain. Seed phrases guard against device loss, not against future cryptanalysis.

No. A High score means the address shows the signals that would matter if a cryptographically relevant quantum computer existed — typically an exposed public key from prior spending. Nothing can act on that today. Treat it as a prompt to improve address hygiene, not a reason to move funds.

It is the practice of recording encrypted traffic today to decrypt it once a quantum computer becomes available. It is the only quantum risk already underway, and it means any data that must stay confidential for a decade or more is effectively exposed the moment it crosses the network.

Anything with a long confidentiality lifetime: health records, genomic data, legal discovery, financial archives, government and defence communications, and identity systems. NIST names long-life sensitive data as the priority migration target for precisely this reason.

Start with a cryptography inventory — every algorithm, key, certificate, protocol, library and vendor dependency you rely on. You cannot replace what you cannot enumerate, and the inventory usually surfaces more RSA and ECDSA in more places than teams expect.

A structured record of where and how your organisation uses cryptography: TLS endpoints, VPNs, SSH, code signing, backups, certificates, payment systems and third-party dependencies. It is increasingly produced as a cryptographic bill of materials alongside a conventional SBOM.

Crypto-agility is the ability to swap cryptographic algorithms, parameters or libraries without redesigning the systems that use them. It matters because post-quantum migration will not be the last migration — agility turns the next one from a rewrite into a configuration change.

Ask which algorithms they use for data in transit and at rest, whether they support hybrid key exchange today, what their migration timeline to ML-KEM and ML-DSA is, how they would rotate algorithms in an emergency, and whether they can produce a cryptographic bill of materials.

The inventory and planning stages are cheap; the cost sits in embedded systems, long-lived certificates and third-party dependencies you do not control. Starting early spreads the work across normal refresh cycles, which is substantially cheaper than a compressed migration against a deadline.

NIST finalised three in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for general-purpose signatures, and FIPS 205 (SLH-DSA) for hash-based signatures. A fourth, FN-DSA (Falcon), is expected as FIPS 206.

ML-KEM is the NIST-standardised post-quantum key encapsulation mechanism, formerly CRYSTALS-Kyber. It replaces RSA key transport and elliptic-curve Diffie-Hellman for establishing shared secrets. ML-KEM-768 is the common default and is already deployed in TLS 1.3 across major browsers and CDNs.

Use ML-DSA by default — it is the general-purpose choice with practical signature sizes and speed. Choose SLH-DSA where you need diversification away from lattice assumptions or very long-lived trust, such as firmware and root signing, and can tolerate much larger signatures.

Because it fails safe. A hybrid scheme stays secure as long as either component holds, which hedges against both a future quantum attack and an undiscovered weakness in the newer post-quantum algorithm. It is the recommended posture for TLS through at least 2030.

Nobody knows, and precise predictions should be treated with suspicion. The Global Risk Institute's expert survey puts roughly a 1-in-7 chance of a cryptographically relevant quantum computer by 2033. Plan against a range, not a date.

It states you have a problem if the time your data must remain secret, plus the time your migration takes, exceeds the time until a quantum computer arrives. Ten-year confidentiality plus a five-year migration means today's decisions already sit inside the risk window.

Yes. NIST IR 8547 proposes deprecating RSA-2048 and ECDSA-P256 by 2030 and disallowing them by 2035. The NSA's CNSA 2.0 sets a similar trajectory for national-security systems. Even where neither binds you, both function as defensible internal deadlines.

It is too early to panic and about right to plan. Harvest-now-decrypt-later means long-life data is already exposed, migrations of this scale historically take five to ten years, and the standards you would migrate to are finished and shipping. The inexpensive work — inventory and agility — is worth doing now.