Copy-Based Resilience Is the One Habit This Signature Scheme Cannot Allow
Before a bank had a database, it had a book of numbered receipts. Every leaf carried a serial, every leaf could be issued once, and the counterfoil left in the spine recorded what had gone out. The paper hardly mattered. The number carried the whole system, and it only worked because there was a single book. Keep a duplicate in a second branch for safety and the numbering stops meaning anything: two clerks, two receipts, one serial, and no honest way afterwards to say which was real.
That constraint has come back, in hardware, and it is beginning to hurt. It surfaced in the banking press this week from an unlikely direction — a Swiss custody bank explaining why a blockchain's cryptography plan is an operational problem today rather than in 2029.
Practical takeaway. Almost everything on a post-quantum migration list is a scheduling exercise. One small class of keys is not, because the scheme that protects them forbids the copy that ordinary recovery design assumes. That class has to be settled at key generation, not at cutover.
The claim being tested
The public record now reads as a calendar. Germany's BSI, in the January 2026 revision of its Technical Guideline TR-02102-1, gave classical key agreement — RSA and (EC-)Diffie-Hellman — a recommendation that runs only to the end of 2031, with hybrid post-quantum key exchange expected from 2032. Classical digital signatures were given until the end of 2035. In July, Switzerland's FINMA published Guidance 05/2026 after surveying sixty banks, insurers, asset managers and market infrastructures between November 2025 and January 2026, and reported that the institutions understood the risk but that "in most cases, however, there is a lack of a clear roadmap and sufficiently forward-looking planning for the migration to quantum-safe encryption." CryptoSlate's account of the same guidance, cited below, put numbers on it: roughly seventy-two percent had neither planned nor implemented quantum-safe measures, and eight percent had a specific roadmap. We read that guidance when it landed, and the mid-2027 roadmap expectation it set remains the nearest thing in European finance to a date for the planning itself.
The implied claim in all of this is that migration is a sequencing problem. Inventory your cryptography, rank what breaks first, swap the primitives, book the budget. For key establishment that claim holds, and we have watched it hold in public — post-quantum key exchange has already turned into a platform setting rather than a project, and the awkwardness that remains is operational rather than mathematical.
What the record actually says
For one family of signatures the claim fails, and it fails on a clause rather than on a schedule. NIST Special Publication 800-208, Recommendation for Stateful Hash-Based Signature Schemes, was published in October 2020 to approve LMS, HSS, XMSS and XMSS^MT for federal use. Its first page states the price of admission: the recommendation "requires that key and signature generation be performed in hardware cryptographic modules that do not allow secret keying material to be exported, even in encrypted form."
Section 8.1 turns that into conformance language. "The cryptographic module shall not allow for the export of private keying material." Before a signature leaves the module, the module "shall increment the leaf index of the private key ... and shall store the incremented leaf index value in nonvolatile storage." And then, flatly: "The cryptographic module shall not use an OTS key to generate a digital signature more than one time."
The reason is arithmetic rather than caution. A stateful hash-based private key is a large set of one-time keys, and the publication states the cost of a repeat twice. Section 9.1 puts it that if an attacker obtains signatures on two different messages made with the same one-time key, "it would become computationally feasible for that attacker to create forgeries." Section 1.1 is more specific about the reach: "it would become computationally feasible for that attacker to forge signatures on arbitrary messages." The exposure is a computational feasibility rather than an instant break, and it comes from outside, with no further access to the module.
Where it meets the recovery plan
The FINMA guidance cited here does not require anyone to duplicate a signing key. What supervisors require is that service survive the loss of a site, and many conventional recovery designs built to satisfy that are copy-based. That is where the trouble starts, and it is conditional rather than automatic. A snapshot that restores an older leaf index, or replicas that advance their own counters without state-aware coordination, will reissue a one-time key that has already been spent. Neither outcome is inevitable — state-aware backup is a solved problem in the sense that solutions exist — but both are the default behaviour of ordinary, audited disaster-recovery machinery pointed at a stateful key. The IETF's post-quantum use-in-protocols working group has produced guidance on precisely this, and its document on state and backup management for hash-based signatures reads as a catalogue of the safer mechanisms an institution would have to adopt deliberately.
It reached the banking conversation on 14 August, when CryptoSlate reported remarks by Thomas Brunner, who runs custody and staking at Sygnum Bank, on Ethereum's post-quantum roadmap: a validator-key registry, then a move from BLS aggregation toward hash-based signatures such as leanXMSS. His point was about banking rather than blockchains: standard resilience design, carried over unchanged to a stateful signing key, is where the exposure comes from.
Neither instinct is careless here, which is what makes the case interesting. Recovery obligations exist for a plain human reason: a customer should still be able to reach their money after a data-centre fire, and a supervisor should be able to prove in advance that they can. The signature clause exists for an equally plain one: a signature is a claim that a particular instruction really came from a particular institution, and a scheme that quietly tolerates a duplicated counter cannot support that claim. Two protective habits, both sound, and they cannot both be honoured by making a copy.
The answer the standard already published
Here the record contains something the coverage has mostly walked past. NIST saw the failure problem in 2020 and answered it in the same document, in a section of its own — Section 7, Distributed Multi-Tree Hash-Based Signatures. It states the difficulty in one sentence — "in the case of most digital signature schemes, a common solution is to make copies of the private key. However, in the case of stateful HBS schemes, simply copying the private key would create a risk of OTS key reuse" — and then offers two architectures instead of a backup.
Generate several independent hash-based keys on several modules and have verifiers accept a signature from any of them, distributing the public keys at once or over time through a mechanism like the Hash Of Root Key certificate extension. Or generate a single HSS or XMSS^MT key as a two-level tree, with the upper tree on one module and the lower trees instantiated on others, so that separate hardware holds separate one-time keys without any private material ever crossing a boundary. Redundancy through topology rather than through duplication.
That distinction is the operational heart of the thing. A backup can be added late, after an audit finding, by a team that did not build the system. A key topology cannot. It is fixed at the ceremony where the keys are generated, and everything downstream — how many modules, in which sites, verified by which relying parties — is decided there. For an institution whose plan says "migrate by 2031," the date that actually binds is the day it generates its first stateful key, and that day tends to arrive years earlier and with far less ceremony than the word implies.
NIST has been working on the export restriction for a while. On 8 November 2024 Dustin Moody told the pqc-forum list that NIST had "received feedback from some in industry in regards to the restriction against private key export as laid out in 208," and wanted to share an approach to revising the publication "that would enable key export, but also mitigate security concerns." John Kelsey gave that outline four days later in a talk titled, plainly enough, Stateful HBS Backups — Revising 208. Twenty-one months later the revision has not been published, and the 2020 text is still the one a validation lab tests against.
How narrow the bite is
The claim deserves testing in the other direction too, because most of what a bank is migrating never touches SP 800-208 at all. ML-KEM handles key establishment. ML-DSA and SLH-DSA handle signatures and are both stateless, which removes the index problem specifically — the custody, export, hardware-module and supervisory controls around any signing key still apply, but restoring an uncompromised key does not create the state-reuse vulnerability. The whole apparatus of inventory, sequencing and deadline applies cleanly there, and the argument about which lattice assumptions to trust is a separate conversation that has been running loudly all year, with the signature side of the standards track the most unsettled part of it.
Stateful schemes survive in the places where a public key is expensive to replace and the signing rate is low: firmware, secure boot, code signing, root certificates that live in silicon for fifteen years. Small in number, awkward in kind, and now facing a proposed new use case that nobody anticipated in 2020 — validator keys on public chains, where the verifier would be neither a customer nor a regulator but every node in the network. The residue that a deadline cannot fix is small, and it is the part that most resembles a permanent architectural decision.
How Quentir Reads It
The instructive pattern is not that a standard is inconvenient. It is that engineering correctness and institutional practice were each developed to a high polish, separately, and that nobody was assigned to check the seam. SP 800-208 is precise about the one thing it must protect. Recovery design is precise about the one thing it must protect. The gap between them was invisible for six years because almost nobody in a regulated institution had generated a stateful key, and it became visible the moment a bank looked at a validator roadmap and asked what its own disaster-recovery rehearsal would do to it.
We expect more of these, and in the same shape. The post-quantum transition is being run as a substitution exercise, primitive for primitive, and substitution is a fair description of about ninety percent of it. The remaining fraction is where a new primitive carries an operating model with it, and an operating model cannot be swapped on a schedule. When we looked at the sovereign instruments of this summer the same asymmetry appeared: the announcements moved at the speed of policy, the consequences at the speed of procurement. Here the announcements move at the speed of standards and the consequences at the speed of a key ceremony, which is slower and much harder to reverse. The institutions that come out of this well will be the ones that noticed which of their cryptographic decisions were purchases and which were architecture.
Our Signature Brief tracks this seam edition by edition — the SP 800-208 revision as it lands, what validation labs accept in the interim, and which supervisory texts have started to name stateful signing directly. The post you have just read is the analysis; the edition adds the dated tracking, the scope note and the internal-use licence that make it usable in a migration file. If you are only orienting, the free monthly digest on the same page carries the headline movements without the tracking.
Published intelligence, built to inform your own decisions. Published: August 15, 2026.
Sources.
NIST Special Publication 800-208, Recommendation for Stateful Hash-Based Signature Schemes,
October 2020 (sections 1, 1.1, 7, 8.1 and 9.1),
doi.org/10.6028/NIST.SP.800-208.
Dustin Moody, "Update on SP 800-208," NIST pqc-forum, 8 November 2024,
groups.google.com.
John Kelsey, "Stateful HBS Backups — Revising 208," NIST, 12 November 2024,
csrc.nist.gov.
Thom Wiggers, Kaveh Bashiri, Stefan Kölbl, Jim Goodman and Stavros Kousidis,
Hash-based Signatures: State and Backup Management, IETF pquip working-group
Internet-Draft draft-ietf-pquip-hbs-state, latest revision 27 February 2026, IESG-approved and in the RFC Editor queue,
datatracker.ietf.org.
FINMA, Guidance 05/2026: quantum computing, 9 July 2026,
finma.ch.
Gino Matos, "Ethereum's post-quantum roadmap puts banks on a 2027 deadline nobody is talking
about," CryptoSlate, 14 August 2026, reporting remarks by Thomas Brunner of Sygnum Bank,
cryptoslate.com.
BSI Technical Guideline TR-02102-1 (January 2026 revision) end-of-life dates for classical key
agreement and signatures, as reported by heise online,
heise.de.
Public sources checked 15 August 2026.
Published intelligence, built to inform your own decisions. Published: August 15, 2026.