RFC 10033, published in September 2026, addresses an operational property that makes some post-quantum signatures very different from ordinary signing systems: their security depends on maintaining mutable state. The document covers LMS, HSS, XMSS, and XMSSMT, where individual one-time signing keys must never be reused. If two different messages are signed with the same one-time key, an attacker may be able to create forgeries.
RFC 10033 is an Informational RFC, not an Internet Standards Track specification. It nevertheless represents IETF community consensus and received public and IESG review. Its value for operators is not a mandate to deploy stateful hash-based signatures everywhere. In fact, the RFC says they are not general-purpose schemes and points most applications toward stateless alternatives such as SLH-DSA or ML-DSA. The document is most useful where a tightly controlled signing environment—such as firmware signing or a specialized certificate authority—makes stateful signatures a considered option.
The key is not only a secret
In a conventional inventory, a private key may be described by its algorithm, location, owner, purpose, and lifecycle dates. A stateful hash-based private key adds a changing record of which one-time indices have already been consumed. That state must advance with every signature. Security depends not only on protecting the static secret but also on preserving the integrity, uniqueness, and durability of the counter or equivalent state.
This changes what “backup” means. Restoring an old copy of a conventional key may be risky for other reasons, but restoring an old stateful signing snapshot can cause the signer to reuse an index that production already consumed. Cloning a virtual machine can create two signers starting from the same state. Running concurrent signing operations without correct synchronization can do the same. A disaster-recovery procedure intended to improve availability can therefore destroy the signature scheme’s security.
RFC 10033 says signing and state update should appear as an atomic transaction: a signature must not be released unless the state is irrevocably and correctly advanced. It describes the familiar ACID properties—atomicity, consistency, isolation, and durability—as requirements for the state-management system. That framing turns a cryptographic deployment into a database, concurrency, hardware, and recovery design problem.
Capacity becomes a governed resource
A stateful key can sign only a finite number of messages. The available capacity may be divided across devices, sectors, or subtrees, and an organization needs to know where each allocation resides. RFC 10033 suggests configurable warnings as exhaustion approaches. Those warnings need owners and escalation paths; a dashboard alarm that nobody acknowledges does not prevent an expired signing capability from halting a firmware release.
Long lifetimes complicate the picture. The document discusses keys expected to operate for ten to twenty years or more, across media degradation, hardware replacement, personnel turnover, and changing external dependencies. Recovery must be tested without creating duplicate active state. Succession planning and separation of duties need to survive organizational change, not just the first deployment ceremony.
What the cryptographic record should capture
- Purpose and boundary. Record the firmware, software, or CA function being signed and the exact device or service authorized to sign.
- Algorithm and parameters. Track the scheme, parameter set, public key, validation basis, and interoperability constraints.
- State authority. Identify where authoritative state lives, how updates become durable, and how concurrency or cloning is prevented.
- Capacity allocation. Record total and remaining signatures, per-device allocations, warning thresholds, and rotation triggers.
- Backup and recovery evidence. Link each protected backup to its state epoch, recovery procedure, test result, and controls that prevent stale restoration.
- Dependencies and ownership. Include HSMs, storage, time sources, transparency services, operators, approvers, and incident contacts.
A CBOM can identify that an implementation uses a stateful hash-based signature scheme, but that alone cannot prove correct state management. The system of record must connect the cryptographic asset to the operational evidence that makes its use safe.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. It can help teams connect a signing algorithm and key to assets, owners, dependencies, capacity findings, recovery evidence, and remediation work. Vista Core is source-available and includes discovery, inventory, compliance/PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista tracks and governs post-quantum migration; it does not generate stateful signing keys, synchronize counters, configure HSMs, or perform every recovery test. Selected-asset Active Scan is not indiscriminate network scanning. Vista is not a vulnerability scanner, and a discovery gap is not proof of absence. See Vista’s post-quantum approach.
What remains uncertain
RFC 10033 catalogs multiple approaches and trade-offs rather than prescribing one universal design. Whether stateful signatures are appropriate depends on signing volume, hardware, availability, recovery, and operator controls. Teams should treat the RFC as a basis for architecture review and evidence requirements, not as proof that any product labeled LMS, HSS, or XMSS is safely deployed.
Sources
- RFC 10033: Hash-Based Signatures: State and Backup Management, IETF, September 2026.
- NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes, NIST, October 2020.