Quantum Safe HSM

What quantum-safe readiness requires from an HSM

A hardware security module that cannot generate and sign with post-quantum algorithms cannot support a post-quantum certificate authority. HSM capability is therefore a gating dependency for the whole migration, and in most cases it is delivered through firmware rather than hardware replacement.

Why the HSM decides the migration timeline

The private keys of a certificate authority live in an HSM. If the HSM cannot generate an ML-DSA key or produce an ML-DSA signature, the certificate authority cannot issue post-quantum certificates, regardless of what the CA software supports.

The same applies to code signing, document signing, payment key hierarchies and any other function where key material is held in hardware. The HSM is not one item on the migration plan; it is the item that determines whether the others can proceed.

There is a second, less obvious dependency. A root certificate key generated today with fifteen or twenty years of validity must remain unforgeable into the 2040s. Generating a new root under a classical algorithm now commits the organisation to a trust anchor that will be quantum-vulnerable for its entire life, which makes root ceremony timing a decision worth taking deliberately rather than by schedule.

What quantum safe cryptography requires from the hardware

The last row is the one most often missed. An HSM verifies its own firmware using a vendor key, and if that verification is classical then the device's update path is itself quantum-vulnerable. This is a vendor question rather than a customer configuration, but it belongs in the assessment.

Stateful signatures and the state management problem

LMS and XMSS are the right answer for firmware and secure boot signing, because verification requires only hash operations, which is cheap on constrained hardware, and because they were approved earlier than the main standards and have established hardware support.

They are also the most dangerous algorithms to operate incorrectly. Each private key may produce a limited number of signatures, and each signature must consume a distinct one-time key. If state is duplicated, through a restored backup, a cluster synchronisation error or a failover to a secondary that has been signing independently, the scheme's security collapses.

This makes state management an HSM procurement criterion rather than an operational detail. The questions to ask are how the device guarantees state uniqueness, what happens to state during backup and restore, how state is handled in a high availability pair, and whether the vendor's disaster recovery procedure preserves the guarantee. A vendor unable to answer those precisely should not be used for stateful signing.

Firmware upgrade or hardware replacement

The good news is that most current-generation HSMs gain post-quantum capability through firmware. Thales released post-quantum support in Luna 7.9 in July 2025, and comparable firmware has shipped from other major vendors. Crypto4A designs its platforms as quantum-safe from the outset.

Three checks determine whether that applies to a given estate. Whether the specific model is on the vendor's support matrix for the post-quantum firmware, since older models frequently are not. Whether the deployed firmware version is the one with support, rather than a version several releases behind. And whether upgrading requires a maintenance window, a re-validation, or in regulated environments a change to an accreditation position.

Where the answer is hardware replacement, the lead time matters more than the cost. Procurement, delivery, installation and key ceremony for a replacement HSM estate is a programme measured in quarters, which is why this assessment belongs early in discovery rather than at the point of migration.

Capacity and performance planning

Two changes compound each other and are usually planned separately.

Post-quantum keys and signatures are larger, which consumes more object storage and more of each signing operation's throughput. And certificate lifetimes are shortening under the CA/Browser Forum schedule, reaching 47 days for publicly trusted TLS certificates in 2029, which multiplies signing volume.

An HSM sized for today's renewal rate and classical key sizes may not be sized for the 2029 position. Capacity should be modelled against projected volume at the shortest expected lifetime with post-quantum key sizes, not against current load, as covered in how shorter certificate lifetimes enable post-quantum migration.

The root ceremony question

A post-quantum hierarchy requires a new root, because existing roots cannot be converted. That means a key ceremony, with the associated planning, witnesses, documentation and, in accredited environments, approval.

Two decisions arise. Which algorithm signs the new root, where SLH-DSA is a defensible choice for a long-lived trust anchor because its security rests only on hash function properties, at the cost of a large signature that is signed rarely. And whether the new hierarchy runs in parallel with the existing one for a transition period, which is almost always the answer, since relying parties cannot all be moved simultaneously.

Because ceremonies are expensive and infrequent, the practical implication is to align a planned root refresh with the post-quantum decision rather than performing two ceremonies within a few years.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport. We hold partnerships across the HSM landscape, which gives us visibility of shipped firmware capability rather than roadmap statements.

We assess deployed HSM models, firmware versions and capacity against post-quantum requirements through our PKI health check, and design and deliver hardware security module architecture including key ceremonies for new post-quantum hierarchies through our PKI design and build practice. Because we are vendor-neutral, the recommendation follows the estate and the accreditation position rather than a single manufacturer's line.