A new Europol report reminds the crypto industry that quantum risk is neither one event nor an equal threat to every layer of the system. The practical challenge is to build an exposure map, understand who can replace each key and rehearse the transition before urgency dictates the process.
What Europol actually said
Europol's European Cybercrime Centre published its report Quantum Computing and Cryptocurrencies on October 7, 2026. Its central warning is specific: a sufficiently capable quantum computer could undermine the public-key cryptography used to authorise many cryptocurrency transactions. Where a public key is exposed, an attacker with the necessary machine and algorithm could in principle derive the corresponding private key and sign an unauthorised transaction. The report does not say that blockchains have already been broken, nor does it present a date on which that will happen.
The distinction matters because a blockchain uses more than one kind of cryptography. Hash functions support transaction identifiers, block linking and data integrity; digital-signature schemes prove authority over an account. Europol describes the hash layer as comparatively resistant while identifying signatures and exposed public keys as the more immediate migration problem. Treating every cryptographic primitive as equally vulnerable produces poor priorities. The first operational question is not 'When does quantum arrive?' but 'Which assets depend on which keys, and how could those keys be replaced?'
This is a preparedness problem under uncertainty. No publicly evidenced cryptographically relevant quantum computer can currently execute the attack at the scale required for major networks. Yet wallets, custody policies, hardware, smart contracts and protocol rules cannot all be replaced in a weekend. Europol therefore recommends inventories, prioritisation, stronger key management, phased transition and crypto-agility. That is a product and operating model, not a prediction market on a breakthrough date.
Exposure begins with the life of a key
A useful risk model follows a key from creation to retirement. Which device or service generated it? Which signature scheme protects it? Has its public key already appeared on-chain? Is the same key reused across addresses, networks or applications? Who can rotate it, and what approvals are required? An address balance alone cannot answer these questions. Two accounts holding the same value may have radically different migration risk because one can upgrade through a governed smart account while the other depends on an inaccessible owner and a fixed signature rule.
Public-key exposure also varies by network and address design. In some systems, the public key becomes visible only when funds are spent; in others it is present from the start or recoverable from a signature. Reuse extends the exposure window. Custodial accounts add another layer: the user may see one balance while the provider manages pooled keys and an internal ledger. A risk inventory therefore needs the chain, account type, signature scheme, exposure state, custody model, last activity and available upgrade path—not merely the address and amount.
Good key hygiene remains valuable before post-quantum migration. Avoiding unnecessary reuse, securing signing devices, separating roles and testing recovery reduce today's threats as well as tomorrow's. Quantum readiness should not become an excuse to neglect phishing, compromised software, malicious approvals or weak operational controls. The future threat is important precisely because it must be integrated into the existing security programme, not placed in a separate laboratory document.
Inventory before algorithm
Teams are often tempted to begin by selecting a post-quantum algorithm. That is premature. NIST has standardised three foundational post-quantum standards: FIPS 203 for key establishment and FIPS 204 and FIPS 205 for digital signatures. Those standards are an important reference point, but they are not a universal drop-in replacement for every wallet, chain, hardware signer or smart contract. Signature sizes, verification cost, implementation maturity and protocol constraints differ. Architecture begins with knowing what must move.
The inventory should classify assets by business criticality and technical exposure. It should identify treasury wallets, customer assets, bridge administrators, upgrade keys, validator or sequencer controls, oracle signers, contract owners, emergency guardians, backup and recovery keys, and signing credentials in CI/CD or cloud systems. Each item needs an accountable owner, an authority model, a balance or impact estimate, an exposure state, dependencies and a tested route to rotation. Unknown ownership is itself a high-priority finding.
This work produces a migration graph. A treasury multisig may depend on five hardware devices and a policy engine. A protocol upgrade may require a governance vote, timelock and exchange coordination. A dormant customer account may have no reachable owner. A bridge may rely on an external validator set. The graph makes clear that migration risk is rarely contained in one cryptographic library. It flows through people, interfaces, vendors and governance.
Dormant assets are the difficult edge case
Active users can be asked to update a wallet, rotate a key or approve a new account. Dormant assets cannot. Some owners have lost contact details, some keys belong to estates, some organisations no longer exist and some funds sit in contracts with no upgrade mechanism. These balances may become the most visible target if an attack becomes practical, yet any attempt to move or freeze them raises serious questions of authority, ownership and false positives.
A protocol should not quietly convert technical readiness into a claim over other people's property. Possible mechanisms—opt-in migration, time-delayed protective contracts, community-approved recovery paths or restrictions on newly exposed keys—have different legal and governance consequences. The design must state who can act, what evidence is required, how owners can object and how a mistake can be reversed. If the only rollback is a contentious chain intervention, that limitation belongs in the risk register now.
This is why migration coverage should be measured separately from migration capability. A network may support a post-quantum account type while most value remains in legacy addresses. A custodian may be technically ready while customer consent and documentation are not. The readiness dashboard must show the uncovered population, not simply celebrate the existence of new code.
Migration capacity is a product constraint
A safe design can still fail if the network cannot carry the migration. Post-quantum signatures and public keys can be much larger than familiar elliptic-curve equivalents. That affects transaction size, blockspace, gas, fee estimates, hardware-wallet memory, API limits, indexers and archival storage. A mass rotation campaign may compete with ordinary activity at exactly the moment users are most anxious. Capacity therefore needs modelling and rehearsal, not a footnote.
The product team should calculate how many critical accounts can migrate per block, day and week under normal and stressed conditions. It should model failed transactions, duplicate attempts, fee spikes and users who begin on one device and finish on another. Interfaces must make the destination and consequences legible. A hurried banner saying 'secure your funds' can become a phishing amplifier if people cannot distinguish the authentic flow from an imitation.
A phased programme can start with low-value internal accounts, then non-customer operational keys, treasury policies, voluntary customer migration and finally high-dependency accounts. Each stage should have caps, monitoring, support capacity and a rollback or pause rule. The purpose of a pilot is to discover whether the whole system—contracts, wallets, support, compliance, monitoring and communication—can migrate together.
The coexistence period is where new risk appears
For a time, classical and post-quantum methods will coexist. Hybrid signatures can reduce dependence on a single primitive, but they also increase complexity. Which signature is authoritative if one verifies and the other does not? Can an attacker force a downgrade to the older path? Are recovery keys protected by the same rules as daily keys? Does a smart account accept a legacy signer forever because one emergency branch was never removed? Transition logic can become the vulnerability it was meant to solve.
Version negotiation, domain separation, replay protection and explicit deprecation dates are product requirements. A wallet needs to know not only that an account is post-quantum capable but which policy is active at a given block height. An indexer must understand both formats. Exchanges and custodians need to recognise new deposit and withdrawal rules. Monitoring must distinguish a legitimate migration transaction from unauthorised movement.
NIST defines crypto-agility as the ability to replace or adapt cryptographic algorithms across protocols, applications, software, hardware and infrastructure while preserving security and ongoing operations. The last clause is decisive. An organisation that can replace an algorithm only by stopping withdrawals, rebuilding every client and asking users to trust an improvised process is not agile. It has merely proved that change is possible under crisis.
Custodians and exchanges become migration coordinators
Large providers hold a special position because they can rotate pooled keys, update account policies and communicate with many users. They also concentrate operational risk. A rushed unilateral freeze could protect assets while denying legitimate access; a delayed response could leave exposed keys in place. Providers need pre-approved thresholds for warnings, enhanced verification, withdrawal controls and emergency actions, together with legal and customer-support review.
The provider's role is not limited to its own wallets. Deposit addresses, sweeping systems, hot and cold storage, signing services, travel-rule integrations, sanctions screening, proof-of-reserves processes and incident tooling may all rely on assumptions about address and signature formats. A migration test should follow a transaction from customer initiation through monitoring, settlement, accounting and export. Passing a cryptographic unit test proves only one link.
Communication is part of security. Messages should explain what is known, what is not, who must act and which channels are official. They should avoid countdown language unsupported by evidence. Support teams need scripts for lost devices, estates, shared corporate accounts and users in restricted jurisdictions. A technically correct migration that users cannot safely complete is not complete.
Blockchain intelligence must become forward-looking
Most blockchain intelligence describes past movement: this address sent value, interacted with a service or joined a cluster. Quantum readiness adds a prospective layer. Analysts need to map which accounts have exposed public keys, how long the exposure has existed, what balance or authority they control, whether an upgrade route exists and how quickly movement could be distinguished from theft. This is an exposure map, not an accusation map.
The labels must remain disciplined. 'Public key observed' is a fact derived from chain data. 'No known migration path' is a technical assessment. 'Owner unreachable' may come from a provider record. 'Likely quantum target' is a forecast with assumptions. None of those labels establishes ownership, intent or wrongdoing. A responsible product displays source, time and confidence for each one and allows the assessment to change without rewriting the underlying observation.
Watchlists can focus on high-impact controls such as bridge administrators, upgrade authorities and large dormant balances. Alerts should identify a change in state: first exposure, unexpected legacy signature, migration to a new account, movement after a long dormancy or activity that bypasses the planned process. The investigation begins with verification. It should not presume that every unusual transfer is a quantum event when ordinary key theft remains far more plausible.
Forensic continuity matters before an incident
A future ability to forge a signature would not automatically mean every historical transaction was fraudulent. Timing, block inclusion, network consensus and the state of the relevant technology all remain evidence. But investigators will need to explain which verification assumptions applied when a transaction occurred and whether a key was plausibly compromised at that time. That requires preservation today.
Case systems should retain raw transactions, block headers, network identifiers, contract code or verified source references, parsing versions and the signature-verification method used. Screenshots and vendor reports are not enough. When a label or cluster is material, the system should retain its source and timestamp. If a post-quantum migration moves funds to a new account, the link between old and new authorities should be documented in a way that can later be audited without exposing unnecessary personal data.
The same discipline protects legitimate owners. If an organisation later disputes a transfer, analysts need to separate an actual on-chain observation from an inference about the signer. Preserving the chain of interpretation prevents future cryptographic uncertainty from turning every old record into an unresolvable argument.
A practical migration scorecard
A board or product team does not need a single red-yellow-green quantum score. It needs a small set of measurable questions. What percentage of critical assets and signing authorities is inventoried? What share has an exposed public key? How many accounts can rotate without a protocol change? How much migration throughput is available under stressed fees? What proportion of users can be reached and supported? Can evidence and account history survive the move?
Each metric should have an owner and a test date. Inventory coverage without evidence is optimistic; a wallet marked upgradeable should have completed a rehearsal. Migration throughput should come from testnet or controlled production trials, not an estimate based only on signature size. User reachability should include bounced messages and inaccessible accounts. Evidence continuity should be tested by reconstructing a sample case across the old and new formats.
The scorecard should also record dependencies: standards maturity, hardware support, client releases, governance votes, external custodians and regulatory decisions. A dependency does not excuse inaction. It tells the team where to build options, request commitments or create a fallback. The objective is to replace an unknowable date with a visible programme of work.
A runbook should exist before urgency
The runbook begins with triggers. A standards update, credible cryptanalytic result, hardware milestone, vendor advisory or observed attack may justify different levels of response. Each trigger should have a named evaluator and an evidence threshold. Social-media speculation should not automatically activate emergency controls, but neither should the organisation wait for a confirmed theft before convening the team.
The next layer defines actions: increase monitoring, rotate selected keys, restrict the creation of new legacy accounts, open a voluntary migration, raise support capacity, pause a vulnerable function or coordinate a protocol upgrade. Every action needs authority, scope, duration, user communication and a reversal path. A tabletop exercise should include technical, legal, compliance, communications, support and executive roles because the real event will not remain inside engineering.
Finally, the runbook needs learning loops. After each rehearsal, record time to detect, time to decide, migration success rate, support volume, false alerts and unresolved accounts. Update the inventory and assumptions. Quantum readiness is not a one-off compliance document; it is the ability to make a cryptographic change without losing operational control.
Readiness is not panic
The strongest conclusion from the Europol report is not that every holder must move funds today. It is that waiting for certainty would be an avoidable management failure. Cryptographic transitions are slow because code, hardware, governance, property rights and human behaviour move at different speeds. The work that can be done now—inventory, key hygiene, standards evaluation, capacity testing, evidence preservation and clear authority—has value even if the technical timeline changes.
From Dor Arad's perspective, this is a product-quality test. Mature crypto infrastructure should know which assumptions secure each asset, who can change them and how users remain safe during the change. Blockchain intelligence should show exposure without converting forecasts into accusations. Governance should prepare protective options without treating dormant property as ownerless. Security should communicate uncertainty without hiding behind it.
Quantum risk is therefore not a countdown clock. It is a deadline with no known date and a migration with many known tasks. Organisations that begin those tasks now will be able to respond proportionately as evidence develops. Those that postpone them may discover that the hardest problem was never choosing an algorithm. It was finding every key, coordinating every dependency and moving trust without breaking it.