Hardware security modules (HSM) are the most conservative component in most cryptographic architectures. They are expensive, certified, slow to change, and deliberately so, because they hold the keys that everything else trusts. Yet 2026 is shaping up to be a year of unusual HSM movement, and the reason is post-quantum cryptography. The leading vendors have shipped firmware that brings NIST’s post-quantum algorithms directly into the module, and that single change is prompting organizations to reassess platforms, consolidate estates, and, in some cases, migrate between vendors.
Migrating keys between HSM platforms is one of the highest-stakes operations a cryptography team can undertake. Done well, it is invisible. Done poorly, it can break signing services, invalidate a root of trust, or leave key material in a non-compliant state. This article explains why the PQC refresh is driving HSM migrations now, what the migration actually involves at a technical level, the specific risks to plan for, and how to sequence the work so that assurance and availability are preserved throughout.
Why This Matters Now?
Three developments have turned HSM vendor migration from a rare, painful project into a live question for many teams in 2026. The post-quantum algorithms are now standardized and shipping in mainstream HSM firmware; the certification status of that firmware varies sharply between vendors; and the performance and key-format changes that PQC brings give organizations a natural reason to re-evaluate the platform their root of trust runs on. This is no longer anticipatory work: ML-KEM-based hybrid key exchange is already enabled by default in major browsers and TLS stacks, so the algorithms an HSM must support are the ones in production today, not a future state.
PQC has moved inside the module
For years, post-quantum support in HSMs meant an add-on or an experimental option pack. That changed in 2025. Entrust announced that its nShield 5 HSMs completed implementation of post-quantum algorithms in firmware and received CAVP certification for ML-DSA, ML-KEM, and SLH-DSA, with the milestone delivered in firmware v13.8.0 released in August 2025. Thales followed with Luna HSM firmware v7.9, which delivers native ML-KEM (FIPS 203) and ML-DSA (FIPS 204) integrated into firmware, explicitly eliminating the need for an external functionality module. When the two dominant general-purpose HSM platforms both ship production PQC in the same window, the refresh cycle accelerates across the whole market.
The standardized set is also still expanding. Alongside ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), NIST selected the code-based HQC in March 2025 as a backup key-encapsulation mechanism built on a different mathematical foundation from ML-KEM, and FN-DSA (FALCON) is expected as FIPS 206. A module bought today should therefore be judged on how easily it can add algorithms later, not only on which ones it ships now.
Refresh cycles force platform decisions
A firmware upgrade that adds PQC is rarely a standalone event. It often coincides with hardware end-of-life, capacity planning for larger post-quantum key material, and contract renewals. Those are exactly the moments when organizations re-evaluate whether to stay on their current platform or move. PQC also changes the performance calculus: post-quantum algorithms are heavier than their classical equivalents, and both their keys and signatures are substantially larger while signing and key-establishment operations cost more compute per operation than RSA or ECC.
The size jump is concrete: an ML-DSA-65 signature is roughly 3.3 KB and an ML-KEM-768 public key about 1.2 KB, against a 64-byte ECDSA P-256 signature and a 256-byte RSA-2048 key. Published throughput benchmarks vary widely with parameter set and platform, but the direction is consistent: more cycles per operation and far more storage per key and per signature. An HSM sized for an RSA and ECC workload may need re-sizing for a post-quantum one, which is a procurement trigger in itself. That makes the PQC upgrade a natural decision point for whether to renew the current platform or move to a different vendor entirely.
The certification gap complicates regulated migrations
Buyers in regulated sectors face a subtle timing problem. Algorithm certification and module certification are separate processes, and they are not arriving together. As of late 2025, several vendors hold FIPS 140-3 Level 3 CMVP validation for their HSMs and separately hold CAVP certification for the PQC algorithms, but none had yet obtained FIPS 140-3 Level 3 validation with PQC support combined, with all still at the Modules in Process or Implementation Under Test stage. Thales has described its Luna firmware v7.9.2 as the next FIPS candidate with PQC, and Entrust has submitted nShield 5 firmware for updated FIPS 140-3 Level 3 validation through the CMVP.
For an organization with a strict FIPS 140-3 Level 3 mandate, this means PQC can be tested and piloted now but may need to run outside the validated boundary until the combined certification lands. That nuance should shape migration timing. In practice, it means treating the combined FIPS validation as a gating milestone for production cutover, while allowing PQC pilots only in a clearly marked, non-validated environment. Two external clocks sharpen this further.
First, the FIPS 140-2 era is ending: on September 21, 2026, NIST’s CMVP moves all remaining FIPS 140-2 certificates to the Historical List, after which federal agencies should not cite them for new procurements, so many organizations are already running a FIPS 140-3 refresh that now doubles as the PQC refresh. Second, the migration is increasingly mandated rather than optional.
NSA’s CNSA 2.0 requires National Security Systems to move to ML-KEM-1024 and ML-DSA-87, with new acquisitions expected to support the suite from 2027 and software and firmware signing carrying the earliest exclusive-use deadline of 2030, and Executive Order 14144 in January 2025 reinforced the federal timeline. For affected buyers, the HSM decision is no longer purely technical; it is a procurement-deadline problem.
How HSM Migration Works?
Moving keys between HSM vendors is constrained by what an HSM is built to do, namely protect private keys from extraction. Planning a migration safely starts with understanding what actually moves, what stays locked inside the module, and how the two leading platforms now implement post-quantum algorithms. The sections below take each in turn.
What HSM migration actually moves
Migrating between HSMs is not a file copy. Key material in an HSM is generally non-exportable in plaintext by design; it leaves the module only under wrap, or it never leaves at all and is regenerated. A migration therefore has to account for the keys themselves, the access and authentication model around them (such as partitions, roles, and quorum or PED authentication), the policies that constrain how keys may be used, and the trust relationships that depend on the keys, including certificate authority hierarchies and application integrations bound through PKCS#11.
The vendor migration model
Vendors provide structured migration paths, and understanding the mechanics matters even if you are moving between different vendors rather than upgrading within one. Thales documents three methods for moving keys to a new Luna HSM: backup and restore, direct slot-to-slot cloning, and cloning through a temporary high-availability group created solely for the migration. The Thales guidance is explicit that all three methods invoke the cloning protocols behind the commands you issue, and that after a temporary HA group is used for migration it should be removed, since its members are not on the same software version.
The detail that catches teams out is protocol compatibility between firmware generations. In the Luna model, older HSMs prior to firmware 7.8.0 use an earlier cloning protocol that is unaware of multiple domains, so the older HSM can interact only with the designated primary domain on a newer HSM. The practical consequence, per Thales, is that the common domain between source and target must be set as the primary domain on any HSM at firmware 7.8.0 or newer before cloning. Cross-generation and cross-vendor moves live or die on exactly these compatibility constraints.
Roles and authentication carry over too
Migration is not only about keys; it is about who controls them. The Luna procedures require specific partition roles, the Partition Security Officer to perform HA operations and create the Crypto Officer, and the Partition Crypto Officer to perform the backup, restore, and cloning operations. Where the source uses multifactor quorum (PED) authentication and the target is password-authenticated, the documentation notes that password-authenticated HSMs cannot use Remote PED, so a PED must be connected locally. These operational details are part of the migration design, not afterthoughts.
Cross-vendor migration is harder than in-vendor upgrade
When the source and target are different vendors, convenient cloning and HA paths generally do not exist because cloning protocols are vendor-specific. Those paths rely on a shared, proprietary cloning protocol and a common security domain that exist only within a single vendor’s ecosystem, so a Luna partition cannot clone to an nShield, or the reverse. The only bridges across vendors are standards-based mechanisms such as PKCS#11 key wrapping, and even those work only when key policy permits export and both platforms implement a compatible wrapping mechanism.
Cross-vendor migration usually means one of three approaches: regenerating keys on the new platform and re-issuing the certificates or credentials that depend on them, which is cleanest where keys can be rotated; wrapping and importing keys where both platforms support a compatible key-wrapping mechanism and policy allows export; or, for a certificate authority, standing up a new CA rooted in the new HSM and cross-certifying or migrating subordinate trust over time. The right choice depends on whether the keys can be rotated, whether they must remain inside a FIPS boundary throughout, and how much downtime the dependent services can tolerate.
Risks and Pitfalls
HSM migrations concentrate several categories of risk into a single change window.
| Risk | Cause | Consequence |
|---|---|---|
| Loss of root of trust | CA signing keys mishandled or not migrated correctly. | Issued certificates can no longer be validated or renewed. |
| Non-compliant key state | Keys imported into a configuration outside the validated boundary. | Loss of FIPS 140-3 Level 3 compliance for regulated workloads. |
| Protocol incompatibility | Source and target firmware use mismatched cloning protocols. | Migration fails or silently uses a weaker path. |
| Service downtime | Signing or TLS services depend on keys mid-migration. | Outages in PKI, code signing, or transaction processing. |
| Capacity shortfall | HSM sized for classical workloads, not PQC. | Throughput degradation after post-quantum algorithms go live. |
| Authentication mismatch | PED-authenticated source moved to password-authenticated target. | Operational lockout or insecure workarounds. |
The compliance window is the hardest constraint
For regulated buyers, the single most important planning input is the certification gap described earlier. Running PQC keys in a configuration that is not yet covered by a FIPS 140-3 Level 3 CMVP validation may be acceptable for testing and pilots, but it is not the same as running them inside the validated boundary. Organizations under FedRAMP, FISMA, or similar regimes should map their migration timeline against the vendors’ CMVP progress and decide deliberately whether to deploy PQC in production now, outside the combined validation, or to stage it until the certification lands. This is a documented risk decision, not a detail to discover during an audit.
Key export policy can block the obvious path
Teams sometimes assume keys can simply be wrapped and moved. In a strict FIPS 140-3 Level 3 Security World, the HSM only supports approved algorithms and key types, and non-exportable keys cannot be extracted at all. Thales also notes a current Luna restriction that for the v7.9.0 release, wrapping-off of ML-DSA and ML-KEM keys is not supported, which directly affects how post-quantum keys can be moved. Confirm export and wrapping policy for every key class before committing to a migration method.
Implementation Best Practices
A disciplined HSM migration sequences discovery, design, and cutover so that the root of trust is never at risk. The steps below run in order, each assuming the previous is complete, because skipping discovery or compatibility checks is how a migration strands a key it cannot move.
- Inventory every key and its dependencies: Catalog keys by type, exportability, policy, owner, and the services that depend on them. A certificate authority signing key, a code-signing key, and a TLS key each demand different handling, and you cannot plan a migration method without knowing which keys can rotate and which cannot. Keys protected by hardware non-exportability, such as a CA root, need a different strategy from keys that can simply be re-issued. Encryption Consulting’s CBOM Secure automates this discovery, building a Cryptography Bill of Materials that maps every key to its owner, policy, and dependent systems.
- Decide the migration method per key class: Use rotation and re-issuance where keys can change, vendor cloning or backup and restore for in-vendor upgrades, and key wrapping only where both platforms and policy support it. Do not assume one method fits the whole estate, and document the chosen method for each key class so the cutover plan is auditable.
- Resolve firmware and protocol compatibility first: For in-vendor upgrades, confirm cloning protocol versions and domain settings before any key moves, including setting the shared domain as primary on newer firmware where required.
- Pin down the compliance posture: Map the migration against vendor CMVP progress, and explicitly document whether PQC will run inside or outside the validated boundary during the transition. Get sign-off on that decision before deployment. PQC Advisory Services read the CMVP certificate and security policy rather than the brochure, so the posture rests on what the validation actually covers.
- Size for post-quantum load: Validate HSM throughput against the heavier PQC algorithms in a pilot, and plan for vendor acceleration where available. Entrust, for example, notes that nShield 5 uses an FPGA-based security processor whose PQC acceleration can be rolled out via a subsequent firmware upgrade. Confirming whether acceleration is present in the firmware you are validating avoids a nasty surprise when throughput is measured under load. Where standing up validated, PQC-capable hardware in-house is impractical, HSM-as-a-Service provides it on demand.
- Preserve availability with parallel running: Stand up the new platform alongside the old, migrate or regenerate keys, validate dependent services against the new HSM, and only then cut over. For CA hierarchies, consider cross-certification so trust transitions gradually.
- Rehearse, then retain a rollback: Test the full procedure in a non-production environment, keep the source HSMs available and backed up until the migration is verified, and decommission only after dependent services are confirmed stable on the new platform. A migration is not finished when keys arrive on the new HSM; it is finished when the old platform can be retired without anyone noticing.
What It Means for Security Teams?
An HSM migration during the PQC refresh is not a single team’s project; it reaches everyone who depends on the root of trust. Responsibilities differ by role, but the combination of a vendor change and a cryptographic transition raises the stakes for all of them.
CISOs carry the risk of a migration that touches the organization’s root of trust, and need assurance that compliance posture is preserved across the change, since a lapse in validated coverage during the move is itself an audit finding. A PQC Advisory engagement gives them a defensible, documented migration plan to point to.
Cryptography and PKI teams own the mechanics: key handling, CA hierarchy continuity, and the per-key migration decisions that determine success. PKI-as-a-Service can carry the CA hierarchy through the move without gaps.
Security architects decide whether the refresh is also the moment to consolidate vendors, adopt crypto-agility, and re-platform around post-quantum readiness. A CBOM Secure inventory shows them what actually needs to move first.
Infrastructure engineers plan the parallel-running environment, HA groups, and capacity for heavier PQC workloads. HSM-as-a-Service can absorb that load without a hardware purchase.
Compliance and audit teams need the documented record of how keys were migrated and whether they remained within a validated boundary throughout. That evidence trail is a direct output of the same advisory engagement.
How Encryption Consulting Can Help?
HSM migration during the PQC refresh is rarely an isolated hardware swap; it is one workstream inside a larger cryptographic modernization, and the hardest parts are judgment calls: which keys can move, what the CMVP certificate actually covers, and how to sequence a cutover without breaking the root of trust. This is exactly where Encryption Consulting’s Post-Quantum Cryptographic Advisory Services fit. The team assesses your quantum exposure, reads the certificate and security policy rather than the vendor brochure, and builds a migration plan matched to your compliance mandate, spanning cryptographic discovery, HSM readiness, algorithm selection, hybrid deployment, and a phased cutover.
Where the plan needs tooling to execute, the same engagement draws on CBOM Secure for cryptographic discovery and a living Cryptography Bill of Materials, HSM-as-a-Service for FIPS-validated, PQC-capable key protection without standing up hardware in-house, and PKI-as-a-Service where the migration involves rebuilding or cross-certifying CA hierarchies. The result is a single, expert-led program that turns an HSM vendor migration from a risky one-off project into a controlled step toward crypto-agility. To scope yours, talk to Encryption Consulting about a post-quantum readiness assessment and HSM transition roadmap.
Conclusion
The arrival of native post-quantum cryptography in nShield 5 and Luna 7.9 firmware has turned the HSM from the most static part of the stack into an active migration target. That is an opportunity to modernize, but HSM migration concentrates real risk: the root of trust, regulatory compliance, service availability, and key confidentiality all ride on getting it right. The certification gap, where PQC algorithms are CAVP-validated and modules are FIPS 140-3 Level 3 validated but the two are not yet combined, is the defining constraint for regulated buyers and should drive timing.
Migrating between HSM vendors during the PQC refresh rewards preparation above all. Inventory every key and its dependencies, choose a migration method per key class, resolve firmware and protocol compatibility before anything moves, decide your compliance posture deliberately, and run in parallel with a tested rollback. Treat the HSM migration as the careful relocation of a root of trust rather than a hardware upgrade, and the post-quantum refresh becomes a controlled step toward crypto-agility instead of a threat to the keys everything else depends on.
