Post-quantum key management: HSMs, crypto-agility, and CNSA 2.0

Cryptographic algorithms are the easy part of a post-quantum transition. Anyone can drop ML-KEM into a handshake library. The hard part is everything around the algorithm: where the keys live, how they are generated under tamper protection, how they are distributed to thousands of fielded nodes, how they are rotated when a parameter set changes, and how the whole apparatus stays interoperable with peers that have not migrated yet. That apparatus is key management, and for defense systems it is the load-bearing element of the move to CNSA 2.0. This article examines how to build post-quantum key management for classified and controlled systems: hardware security module integration, hybrid key exchange, crypto-agility as an architectural property, and a migration sequence that survives contact with operational reality.

Why key management – not the algorithm – is the real migration

The standardized post-quantum primitives are now stable. NIST finalized ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative, alongside the long-standing stateful hash schemes LMS and XMSS for software and firmware signing. Implementations exist in mainstream TLS and VPN stacks. If choosing an algorithm were the whole problem, the migration would already be over.

It is not, because the keys these algorithms consume are larger, more numerous, and longer-lived than the systems managing them were designed for. A classical ECDH key on the P-384 curve is well under a hundred bytes. An ML-KEM-1024 key pair and an ML-DSA-87 key pair are measured in kilobytes. Multiply that across every TLS endpoint, every radio, every signed firmware image, and every stored data-at-rest key in a fielded program, and the constraints land on the key management system: slot capacity in the HSM, bandwidth on the distribution channel, storage in the key vault, and the time it takes to rotate everything when an algorithm changes.

This is why the credible programs treat the transition as a key management program with a cryptographic component, rather than the reverse. The algorithm is a dependency; the key lifecycle is the project.

HSM integration: the root of trust under post-quantum load

For any system handling classified or controlled data, post-quantum keys must be generated and held inside a hardware security module validated to FIPS 140-3 – the same root-of-trust requirement that governed classical keys. The HSM is where entropy is gathered, where private keys never leave in plaintext, and where signing and key-encapsulation operations execute behind tamper protection.

Post-quantum support across HSM product lines is arriving, but unevenly. Several validated lines now offer ML-KEM and ML-DSA in validated firmware or in a pre-validation early-access channel, and most offer LMS and XMSS for code signing because those schemes are mature and standardized. The integration work is less about whether the algorithm is present and more about the second-order effects of larger keys.

Key-slot capacity and backup

An HSM has a finite amount of protected key storage. Replacing tens-of-bytes classical keys with kilobyte-scale post-quantum keys can exhaust slot capacity far sooner than expected, particularly on appliances sized years ago for a classical key population. Backup and restore formats must also be re-sized, and the key-wrapping scheme that protects exported key material must itself be post-quantum so the backups are not a harvest target. Plan capacity for the post-quantum key population, not the classical one it replaces.

Performance under realistic load

ML-DSA signing and ML-KEM encapsulation have different performance profiles from RSA and ECC, and those profiles vary widely by HSM model. Signing throughput, in particular, can become a bottleneck in a code-signing pipeline or a high-volume mutual-TLS gateway. Benchmark the specific model under the load it will actually see – concurrent sessions, signing rate, key-generation bursts during mass re-keying – rather than assuming parity with classical operations. A migration plan built on a datasheet number that does not hold under load is a plan that fails in the field.

Crypto-agility as an architectural property

Crypto-agility is the ability to change algorithms, parameter sets, and protocols across a system without rebuilding applications or breaking interoperability. It is not a feature you bolt on; it is a property of how the system references cryptography. In an agile design, an application never names an algorithm directly. It requests an operation – "establish a session key for this peer," "sign this firmware image" – against a key identifier and a policy. The policy names the algorithm and parameter set; the key management layer resolves it.

The payoff is operational. When ML-KEM parameter selection guidance shifts, when a new signature scheme is added to the suite, or when a deployed primitive needs to be retired, the change is a policy update distributed through the key management plane – not a firmware recompile pushed to every node in the field. For defense systems with ten- and twenty-year service lives and primitives that are still maturing, this is the difference between a configuration change and a re-fielding program.

Agility also constrains the design in useful ways. It forces clean separation between key material and the code that uses it, explicit versioning of cryptographic policy, and negotiation of capabilities at connection time so a migrated node can still talk to one that has not migrated. Those are exactly the properties a multi-year transition needs. Building crypto-agility into the secrets and signing pipeline early is far cheaper than retrofitting it once a parameter set has to change under deadline pressure.

Hybrid key exchange during the transition

The mainstream approach to deploying post-quantum key establishment without betting everything on a young algorithm is hybrid key exchange. A hybrid handshake runs a classical key agreement (typically ECDH on P-384) and a post-quantum KEM (ML-KEM) in parallel, then derives the session key from both shared secrets through a standard key-derivation function. The combined secret is only as weak as the stronger of its two inputs.

The risk this hedges is concrete. The post-quantum algorithms are new; an implementation flaw or an unforeseen weakness in a young primitive cannot be ruled out. If that happens, the classical component still protects the session against any adversary without a quantum computer. Conversely, when a cryptographically relevant quantum computer arrives, the post-quantum component protects sessions whose classical key exchange would otherwise fall. Neither component alone has to be perfect; both have to fail for the session to break.

From a key management standpoint, hybrid mode roughly doubles the per-session key material and the handshake's CPU cost, and it requires capability negotiation so a hybrid-capable node can fall back gracefully when its peer supports only classical or only post-quantum. The key management layer is where that negotiation policy lives, where the two key types are tracked together, and where the audit record proves which sessions actually used the post-quantum component. The same hybrid principle underlies physical-layer approaches such as quantum key distribution for tactical links, though QKD addresses key agreement over a different channel rather than replacing the key management plane.

CNSA 2.0 and the harvest-now-decrypt-later clock

CNSA 2.0 sets the destination and the schedule. It mandates ML-KEM for key establishment, ML-DSA for general signatures, and LMS or XMSS for software and firmware signing across national security systems, with a phased timeline: software and firmware signing first, then networking and key management equipment, with full adoption expected by 2033. Key management equipment is explicitly in scope – it must generate, store, and distribute these post-quantum keys, ideally inside validated hardware.

The deadline is not the real driver, though. The driver is harvest-now-decrypt-later: an adversary recording encrypted defense traffic today and storing it until a future quantum computer can break the classical key exchange that protected it. Any data whose confidentiality must outlast the time-to-quantum is already exposed, regardless of the 2033 target. That reframes prioritization entirely – the first links to migrate are the ones carrying the longest-lived secrets, not the ones that are easiest to touch.

Sequencing the migration without breaking the field

A workable sequence starts with a cryptographic inventory: every point where the system generates, stores, exchanges, or verifies keys, annotated with the algorithm, key lifetime, and the confidentiality or integrity lifetime of the protected data. That inventory drives prioritization. Firmware and software signing migrate early – they are CNSA 2.0's first phase and they protect the supply chain itself – followed by the links carrying the longest-lived secrets, then the broad population of ephemeral sessions.

Each migrated component moves through the crypto-agile abstraction, runs hybrid where interoperability with un-migrated peers is required, and is backed by an HSM sized for the post-quantum key population. Throughout, the key management layer enforces shortened key lifetimes and automated rotation so the exposure window for any single key stays small. For programs already planning a broader cutover, this dovetails with the CNSA 2.0 compliance and migration roadmap; see the companion guide on CNSA 2.0 compliance for defense organizations for the program-level view.

The discipline that ties it together is the crypto-agility drill: periodically swap a parameter set end to end in a representative environment to prove the migration path is still exercisable. A migration capability that is never tested is a capability you do not actually have when the next algorithm change arrives.