The New World of Quantum Computing: What Unsecured Keys Mean for Banking, Crypto, Healthcare and Energy

Almost every discussion of quantum risk collapses into confidentiality — someone reads your data. That is the least interesting of the three failure modes, and for most operators it is not the one that hurts.

Confidentiality failure is retroactive. Encrypted traffic captured and stored today becomes readable when the capability arrives. This is harvest-now-decrypt-later, and its severity is a pure function of how long your data must stay secret. If that horizon is eighteen months, you have very little exposure. If it is twenty-five years, you were already late before you read this sentence.

Authenticity failure is immediate and, in most operational settings, worse. A forged signature is not a leak; it is an instruction your systems believe. It means a payment message that looks legitimate, a firmware update a device accepts, a certificate that authenticates an attacker's server. Confidentiality failures produce breach notifications. Authenticity failures produce events.

Agility failure is the structural one. The G7's own roadmap concedes that this transition will certainly not be the last one required. An organisation that hard-codes one algorithm suite has bought itself a decade before repeating the entire exercise. The durable objective is the ability to change cryptography, not the specific replacement.

Finance is the sector taking this most seriously, and it is still the sector most likely to discover it is not actually ready. The G7 Cyber Expert Group published a quantum roadmap for the financial sector in January 2026, co-chaired by the US Treasury and the Bank of England. The Treasury followed in August 2026 with a Quantum-Readiness Task Force organised around three workstreams: sector alignment, digital-asset risk, and — the genuinely novel one — third-party and vendor readiness.

That third workstream exists because of a structural problem that no individual bank can solve. As Moody's David Tao put it, bank quantum readiness ends where third-party vendor crypto opacity begins. Everest Group's July 2026 analysis reached the same conclusion: financial institutions will not become quantum-ready on their own, because much of their cryptography sits either outside their direct control or is shared in nature.

The hardware pipeline makes this concrete. Hardware security modules supporting the new post-quantum algorithms are only now appearing, and FIPS 140-3 validation averages more than 500 days. A vendor not already in that pipeline cannot ship certified post-quantum HSM hardware before 2028 at the earliest — against a 2030 federal key-establishment deadline. The queue, not the algorithm, is the constraint.

And the intent-versus-execution gap is wide. DigiCert's 2026 survey found 87% of organisations planning post-quantum initiatives, with only 7% having deployed quantum-safe cryptography across most of their digital certificates. Planning is not migration.

The practical consequence for a bank: your inventory has to cover your counterparties and your suppliers, and your contracts need to carry post-quantum roadmap obligations. Cryptography you do not control is still cryptography you are exposed to.

Digital assets attract the loudest quantum headlines and deserve the most careful reading, because the widely-quoted numbers are wrong in both directions.

Bitcoin's genuine exposure comes from addresses whose public keys are already visible on-chain. Roughly 1.6 million BTC — about 8% of supply — sits in legacy pay-to-public-key outputs where the public key is published outright. Modern pay-to-public-key-hash and pay-to-script-hash addresses conceal the key behind a hash and stay protected until the funds are spent. CoinShares' analysis narrows it further: of that 1.6 million, only around 10,200 BTC sits in concentrations that could cause appreciable market disruption, with the remainder spread across roughly 32,607 separate ~50 BTC outputs that would each have to be attacked individually.

So the frequently-cited 25% figure is inflated, because it folds in reused exchange addresses that ordinary key-hygiene practice already mitigates. But the reassurance cuts only so far. Every protected address becomes an exposed one the moment it is spent, and the window between broadcasting a transaction and its confirmation is exactly the window an attacker needs.

The binding constraint is not cryptographic; it is governance. A bank has a chief information security officer who can mandate a migration. A decentralised network has a proposal process, contentious forks, and millions of holders who must each move their own coins — including holders who are dead, or who lost their keys, or who will not act until after the first successful theft. Q-Day for digital assets is likely to be a coordination failure long before it is a mathematics failure.

Healthcare has the least ambiguous exposure of the four, because the arithmetic is trivial and it does not favour anyone.

Harvest-now-decrypt-later is a real threat only where confidentiality outlives the migration. In healthcare it always does. A diagnosis recorded in 2026 is still sensitive in 2050. Genomic data is not merely long-lived, it is unrotatable — you cannot issue a patient a new genome after a breach, and it implicates blood relatives who never consented to anything. Mental-health records, substance-use treatment, HIV status: the harm from disclosure does not decay with time the way a stolen card number does.

There is a second, quieter problem. Connected and implanted medical devices carry cryptographic trust anchors and firmware-update mechanisms, and they stay in service for years — sometimes inside a person. Their signature verification is the thing that decides whether a firmware image is legitimate. That is an authenticity problem in a device you cannot easily reach, on a replacement cycle measured in clinical rather than IT time.

For a practice or a health system, the near-term action is unglamorous and specific: classify data by confidentiality lifetime rather than by system, and treat anything with a horizon past 2035 as already requiring a post-quantum path today.

The grid inverts the usual priority order. Eavesdropping on operational telemetry is a modest concern. A forged control instruction or a forged firmware update to a protective relay is a physical event with physical consequences.

Operational technology also breaks every assumption the migration guidance is built on. Field devices have service lives measured in decades, not years. Many cannot be patched at all without a scheduled outage, and outages in this sector are negotiated against safety and availability obligations rather than change windows. A meaningful share of installed equipment has cryptographic trust anchors fixed at manufacture. The 2030 and 2035 dates arrive well inside the service life of hardware being commissioned right now.

Which produces the sector's defining constraint: for energy, post-quantum readiness is a procurement decision far more than a software one. Equipment specified today without crypto-agility is equipment that will still be running, unmigrated, when the standards declare its signatures forgeable. The purchasing decisions being made this quarter are the migration.

Strip away the sector detail and one inequality decides whether you are late. Take how long your data must remain confidential, add how long your migration will realistically take, and compare that sum against the time until a cryptographically relevant quantum computer exists. If the sum is larger, you are already behind.

The useful property of that formulation is that you do not control the third number and you do not need to. You control the first two, and in most organisations they are both far larger than anyone has actually measured. Migration timelines in particular are routinely underestimated by years, because the work is not installing an algorithm — it is finding every place cryptography is used, including in systems nobody has an owner for.

First, build a cryptographic inventory. You cannot migrate what you cannot enumerate, and this single step surfaces more risk than any other on the list. Second, classify by confidentiality lifetime, not by system criticality — the two are not the same, and it is the long-lived data that dictates urgency. Third, put post-quantum roadmap obligations into vendor contracts now, because the queue for certified hardware is already longer than the deadline. Fourth, prioritise signatures and roots of trust in long-lived equipment ahead of transport encryption, since those are the ones you cannot retrofit later. Fifth, design for cryptographic agility rather than for a specific algorithm, because the standards bodies have said plainly that this transition will not be the last.

Every one of those is defensible on classical security grounds alone. None of them requires believing any particular forecast about when the machine arrives. That is the test of a good response to a speculative threat: it should be work you would want done anyway.