Ethereum’s post-quantum migration could create a problem for regulated banks years before any quantum computer poses a real threat to validator keys.
Thomas Brunner, Sygnum Bank’s Head of Custody and Staking, thinks differently about quantum risk in crypto than most people do.
Ethereum’s Post-Quantum team says layer-1 upgrades could be completed by 2029, though it stresses there is no fixed date and the roadmap can still shift. The plan starts with a post-quantum validator-key registry before eventually replacing today’s BLS validator signatures with hash-based alternatives such as leanXMSS.
Ethereum shows why bank backups become the danger
BLS is the signature scheme that Ethereum validators use today, and it carries no state to manage, allowing a validator to sign as many times as needed. leanXMSS is built from a structure of one-time keys, and signing twice with the same index hands an attacker the material needed to forge a signature.
NIST’s SP 800-208 standard requires stateful hash-based signing to occur within a hardware module, bars the export of private key material, and expects the private key to exist in one instance.
Brunner said that the standard is blunt about the consequences and lacks a backup copy, which directly conflicts with how banks normally build resilience.
Backup, replication, hot standby, failover, and disaster recovery all either duplicate the signing environment or roll it backward in time. Restoring from an old snapshot reuses the index, and failing over to a standby that has been advancing its own counter does as well.
NIST is already working on a future revision that would allow controlled key export with mitigations, which would ease the non-export rule creating this conflict, but that update does not exist yet.
| Bank resilience control | Normal purpose | XMSS/stateful-signature risk |
|---|---|---|
| Backup | Preserve recoverability if infrastructure fails | Restoring an old copy can roll the signing index backward |
| Replication | Keep duplicate systems available across sites | Two copies can diverge or reuse the same signing state |
| Hot standby | Allow rapid failover during outage | Standby signer may not share the exact current key state |
| Failover | Move signing to another system after disruption | A stale failover target can reuse one-time signing material |
| Disaster recovery testing | Prove the bank can recover critical systems | Testing can accidentally create live duplicate signing states |
The multi-year runway banks need
Brunner said a full cryptographic inventory, mapping every place a key lives and what depends on it, typically takes six months to a year on its own, before a bank touches anything.
Banks sign inside hardware security modules, and Brunner said the bank cannot move faster than its vendors ship and certify post-quantum support with reliable state handling, a validation cycle it does not control.
Key ceremonies and dual-control procedures then need to be redesigned, followed by internal risk approval, external audit and, where relevant, supervisory review. Put those steps in series, and the arithmetic alone produces a multi-year timeline.
A bank beginning its inventory in 2027 would be roughly on time for a 2029 target.
| Migration step | Why it matters | Timing pressure |
|---|---|---|
| Cryptographic inventory | Map every key, dependency, vendor, and control path | 6–12 months before changes begin |
| HSM/vendor readiness | Banks depend on certified signing hardware and state handling | Outside the bank’s direct control |
| Key ceremony redesign | Existing dual-control and recovery procedures may not fit XMSS | Requires operational rewrite |
| Risk approval | Internal control owners must approve the new model | Adds governance lead time |
| External audit | Auditors must retest the custody-control description | Cannot happen at the last minute |
| Supervisory review | Regulators may need to understand the changed custody process | Adds uncertainty before launch |
Regulators are already flagging the planning gap
Switzerland’s FINMA surveyed 60 financial institutions on quantum computing risk between November 2025 and January 2026 and found most understood the danger but lacked a clear migration roadmap.
The regulator’s July report found that 72% of institutions had neither planned nor implemented measures for quantum-safe encryption, and only 8% had a specific roadmap.
FINMA’s findings describe a broader planning gap across traditional finance, one Brunner said is the cheapest part of the problem to close because a roadmap alone would fix it.
Ethereum’s proposed validator-key registry would cap the number of post-quantum keys the network processes per slot, with researchers currently using 16 registrations per slot as a representative parameter to spread the transition over weeks or months.
Whoops, looks like there was a problem. Please try again.
You’re subscribed. Welcome aboard.
Ethereum Research has warned that a last-minute rush to register could overload the queue and leave validators unable to sign once BLS is deprecated, threatening finality itself.
Brunner’s point about the queue is that a bank arriving late registers alongside every other latecomer and cannot control where it lands in line. Being early is the only way a bank can gain any real influence over its place in that queue.
What breaks first
Brunner’s sequence for how a bank runs into trouble starts with the audit itself. If the signature scheme underneath a bank’s custody process moves to something new but its documented controls have not been redesigned and retested, the attestation no longer describes what the bank is doing. Auditors rely on that description holding.
A validator that cannot produce signatures accepted under the prevailing consensus rules stops performing its duties, and any resulting penalties are borne directly by client positions.
Brunner said a bank that cannot describe and evidence a compliant custody process should not keep onboarding client assets into it. Cryptographic compromise, the scenario most people picture first, arrives last in his sequence.
| Failure stage | What happens | Why it matters |
|---|---|---|
| 1. Audit/attestation breaks | Documented controls no longer match how keys are actually handled | The bank can no longer evidence control of client assets |
| 2. Validator operations degrade | Validators fail to produce accepted signatures | Staking performance and penalties affect client positions |
| 3. New onboarding slows or stops | The bank cannot evidence a compliant custody process | Business impact arrives before cryptographic compromise |
| 4. Cryptographic compromise | Quantum or state-reuse attack becomes practical | This is the last risk in Brunner’s sequence, not the first |
Ethereum can show how the transition could go from here
The bull case has hardware vendors shipping state-aware signing modules in time, with monotonic counters and atomic state updates giving auditors a clean pattern to test against.
NIST’s anticipated revision to its export rules gives banks a safer way to build redundancy without duplicating usable key material, and Ethereum’s registry incentives keep registration spread out as intended. Banks that started their inventories in 2027 clear internal and external review with room to spare.
The bear case has a bank starting its inventory in 2028 or later, discovering validator keys embedded across vendor stacks, staking providers, and disaster-recovery procedures it cannot fully map in time.
Auditors issue a qualified finding once they realize that the documented controls no longer align with how keys are handled, and that new staked-ETH onboarding slows or stops. The bank still has to join Ethereum’s registration queue behind everyone else who waited too.
Reaching an ordinary audit day without being able to prove control of validator keys is enough to fail Ethereum’s quantum transition, with or without a working quantum computer anywhere in sight.
