Migrating Between HSM Vendors During PQC Adoption

Quick answer: A PQC-driven HSM refresh is also, frequently, a natural moment to reconsider vendor choice, since a hardware change is already on the table. Migrating between HSM vendors during that window adds real complications on top of the algorithm migration itself: private keys generally cannot move between vendors’ hardware in plaintext, so migration means generating new keys and re-issuing certificates, not porting existing key material; both HSM platforms need to run in parallel during the transition; key ceremonies need to be repeated for the new hardware under the same dual-control discipline as the original; and every application, CA, and integration pointing at the old HSM needs an explicit, tested cutover. This guide is a vendor-neutral operational playbook for that migration.

Vendor migration and algorithm migration are two different projects that happen to share a timeline when a PQC refresh triggers both at once. Treating them as one undifferentiated “HSM project” is how key portability assumptions, ceremony requirements, and cutover sequencing get missed until they cause a production incident.

Key Takeaways

• Private keys generally cannot be exported in plaintext between different vendors’ HSMs; cross-vendor migration means generating new keys and reissuing certificates, not porting existing key material directly.
• Both HSM platforms need to run in parallel for the duration of the migration, the same coexistence discipline covered in parallel CA hierarchy migrations, applied at the hardware layer.
• Key ceremonies for the new vendor’s hardware need to be planned and executed under the same dual-control, split-knowledge discipline as the original ceremony, not treated as a simplified repeat.
• Every application, CA instance, and integration currently pointed at the old HSM needs an explicit inventory and a tested cutover plan; an untracked integration is the most common source of a failed migration.
• Audit evidence from the old HSM’s operational history needs to be preserved and remain accessible after decommissioning, since compliance retention requirements do not reset with a hardware change.

Key Portability: What Actually Moves and What Doesn’t

This is the assumption most likely to derail a vendor migration if left unchecked: private keys do not generally move between different vendors’ HSMs as plaintext key material, by design, since that would undermine the hardware security boundary each vendor’s platform is built around. What does sometimes move is encrypted key material between HSMs of the same vendor and compatible security domain, not across vendors. For a cross-vendor migration, the realistic path is generating new key pairs on the new hardware and reissuing certificates against those new keys, not attempting to transplant existing keys. Plan the migration around reissuance from the start, rather than discovering partway through that direct key portability was never available for your specific vendor pairing.

Parallel Operation

Both HSM platforms, old and new, need to operate simultaneously for the duration of the migration: the old hardware continues serving existing certificates and integrations that have not yet cut over, while the new hardware comes online and is validated before taking on production traffic. This mirrors the coexistence discipline covered in our parallel PKI migration guide, applied specifically at the hardware layer rather than the certificate hierarchy layer, and it means budgeting for both platforms’ licensing, support, and operational overhead concurrently, not a clean handoff on a single date.

Key Ceremonies for the New Hardware

Generating root or high-value keys on the new vendor’s hardware needs the same formal ceremony discipline as the original key generation event: documented dual control, split-knowledge custodianship of any backup material, a witnessed and recorded process, and pre-defined success criteria. Do not treat this as a lower-stakes repeat because the organization has “done this before”; a new vendor’s hardware, tooling, and ceremony script are different enough from the original that the ceremony should be planned and rehearsed as its own event, not assumed to follow identically from institutional memory of the last one.

High Availability and Clustering Across Vendors

HA and clustering configurations are vendor-specific and do not carry over conceptually from one platform to another; confirm the new vendor’s clustering model, failover behavior, and synchronization mechanics explicitly, since assuming feature parity with the outgoing vendor’s HA architecture is a common source of an incompletely tested failover path. Run failover tests on the new platform independently, the same way you would for a first-time HA deployment, rather than assuming the previous vendor’s tested failover behavior transfers.

Rollback Planning

Define an explicit rollback position before cutting any production integration over to the new hardware: what conditions trigger a rollback, how quickly the old hardware can resume serving traffic for that integration, and what state the new hardware is left in if a rollback occurs. Since keys are being freshly generated rather than ported, a rollback generally means reverting the integration to the old, still-operational hardware and its existing keys, not attempting to reverse a key migration, which reinforces why the old platform needs to stay fully operational, not decommissioned, until every integration has successfully and durably cut over.

Audit Evidence and Compliance Continuity

Operational logs, ceremony records, and compliance evidence generated on the old HSM platform need to remain accessible after that hardware is decommissioned, since regulatory retention requirements attach to the evidence, not the hardware that produced it. Export and archive audit logs, ceremony documentation, and validation certificates from the old platform as an explicit migration step, in a format and location that remains queryable independent of the decommissioned hardware, rather than assuming the records stay accessible by default once the old HSM is powered down.

Application Cutover: The Inventory Problem

Build a complete inventory of every application, CA instance, and integration currently pointed at the old HSM before beginning cutover planning, since an untracked integration is the most common way a vendor migration fails, not a technical incompatibility. Sequence cutover by criticality and complexity, moving well-understood, lower-risk integrations first to validate the new platform’s behavior before addressing higher-consequence dependencies, the same risk-based sequencing principle covered in our parallel PKI migration guide.

What We’d Actually Recommend

Plan around key reissuance, not key portability, from the outset of any cross-vendor migration. Treat the new vendor’s key ceremony, HA configuration, and failover behavior each as first-time events requiring their own testing, not assumed continuations of the outgoing vendor’s behavior. Build the application and integration inventory before sequencing cutover, and archive audit evidence from the old platform explicitly before decommissioning it, keeping the old hardware fully operational until every dependent integration has durably cut over.

How Encryption Consulting Can Help

The complete inventory of applications, CAs, and integrations pointed at your current HSM, the foundation any safe cutover sequencing depends on, is exactly what CBOM Secure is built to produce, so a vendor migration starts from a verified dependency map rather than institutional memory of what points where.

Our PQC Advisory Services plan the parallel operation, cutover sequencing, and rollback strategy this guide describes as a coordinated program, distinct from but timed alongside your algorithm migration. Our HSM Services team runs the key ceremonies and validation testing on the new hardware with the same dual-control discipline as any first-time HSM deployment.

Two Migrations, One Timeline

A vendor migration triggered by PQC readiness is genuinely two projects running concurrently: moving to new algorithms, and moving to new hardware, each with its own risks and its own discipline. Keys do not port across vendors as plaintext material, which means planning around reissuance rather than portability from the start. Parallel operation, fresh key ceremonies, an honest application inventory, and preserved audit evidence are what separate a vendor migration that completes cleanly from one that drags on for years with untracked integrations still pointed at hardware everyone assumed was already retired.

Frequently Asked Questions

Can private keys be moved directly from one HSM vendor’s hardware to another’s?

Generally no, not as plaintext key material, since that would undermine the hardware security boundary each platform is built around. Cross-vendor migration typically means generating new keys on the new hardware and reissuing certificates against them, not porting existing keys.

How long should both HSM platforms run in parallel during a vendor migration?

Until every application, CA instance, and integration that depended on the old hardware has been confirmed to have durably cut over to the new platform. The old hardware should stay fully operational, not decommissioned, throughout that period to preserve a rollback option.

Do key ceremonies need to be repeated when migrating to new HSM hardware?

Yes, under the same dual-control and split-knowledge discipline as the original ceremony. Treat the new vendor’s ceremony as its own first-time event, since tooling and procedural details differ enough between vendors that institutional memory of the previous ceremony is not a substitute for planning the new one explicitly.

What happens to audit logs and compliance evidence from the old HSM once it’s decommissioned?

They need to be explicitly exported and archived before decommissioning, since regulatory retention requirements attach to the evidence itself, not the hardware that generated it, and remain independently queryable after the old platform is powered down.

What is the most common cause of a failed HSM vendor migration?

An untracked application or integration still pointed at the old HSM that was missed during inventory and cutover planning, rather than a technical incompatibility between the platforms themselves.