The HSM problem: why PQC plans stall in procurement

Talk to most PQC programme managers and the HSM line item reads something like: "Q2 — update HSM firmware to PQC-capable build. One sprint." Talk to anyone who has actually shepherded a key ceremony in an Indian bank, and the same line item reads: "six to nine months, three approvals, one operations weekend, and a small chance the vendor doesn't ship in time."

Both are right — for different HSMs.

The firmware-vs-replacement question

The major HSM vendors all shipped PQC-capable firmware between 2023 and 2025. The publicly documented support landscape, as of the standards finalisation cycle:

• Thales Luna — PQC support across the Network HSM 7 and Luna PCIe HSM lines on firmware 7.13.0 and above. ML-KEM, ML-DSA, SLH-DSA, and a maintained set of NIST round-3 schemes for legacy interop.
• Utimaco SecurityServer — PQC firmware across the CryptoServer CSe-Series under specific support contract tiers. ML-KEM and ML-DSA confirmed in published release notes; SLH-DSA on a forward-roadmap track.
• Entrust nShield — PQC support in nShield Connect XC and Solo XC on Security World 13.x. ML-KEM and ML-DSA; SLH-DSA depending on regional release.
• AWS CloudHSM — ML-KEM and ML-DSA exposed through the AWS-LC cryptographic SDK in supported regions. Region availability lags the public roadmap; check cloudhsm-client version before depending on a capability.

If you're on any of these recent platforms with a current support contract, the migration looks like a firmware update plus key-ceremony work. That's the easy path.

The hard path is the install base nobody publishes about: HSMs bought in the 2010s, off support, running firmware lines that the vendor has end-of-lifed. PQC firmware was never released for those. The fix is replacement.

When upgrade isn't possible — six months, if you start today

For an Indian regulated bank, an HSM replacement breaks into five phases. Parts run in parallel; the critical path is roughly six months if every phase moves on schedule:

1. Vendor selection and POC (months 0–2). Shortlist, RFP, proof of concept against your actual workloads. If you have specific PKCS#11 mechanisms you depend on, test them in the POC — vendor PQC implementations don't expose identical mechanism lists.
2. Procurement and import (months 1–3). Purchase order, vendor lead time, import documentation, landed-cost reconciliation. Most HSMs ship from outside India; plan for the import cycle.
3. STQC submission and evaluation (months 3–5). For deployments under specific regulatory obligations, STQC evaluation of the deployed hardware configuration is the bottleneck. Submit the moment hardware arrives. STQC turnaround is unpredictable — eight weeks is fast.
4. Deployment and integration (months 4–5). Rack, cluster, configure HA pairs, integrate with KMS and application clients. Update PKCS#11 paths and runtime configuration. Validate failover.
5. Key migration (months 5–6). Move keys from the old HSM. For non-extractable keys, this means either re-issuing the certificates the keys protected or using vendor-supported key cloning into the new HSM. Each partition requires a maintenance window; the SOC must schedule and approve.

Hidden costs nobody plans for

Three line items routinely missing from the budget:

• Key ceremony time. Two key custodians, ops witness, audit witness, scribe. A clean key ceremony for one HSM partition is half a day; a contested one is a week. Banks with strict M-of-N policies should budget for multiple ceremonies per HSM.
• Application reconfiguration. Every client with hard-coded PKCS#11 slot IDs needs updating. The inventory of those clients is rarely current. Read the crypto-agility piece for the reason this hurts.
• Audit and re-attestation. Every key whose location moves needs to be re-attested. For SOX-relevant or regulator-tracked keys, that paperwork is a week each.

What to do this quarter

If a CISO reading this isn't sure whether their HSMs are on the firmware-upgrade path or the replacement path, that uncertainty is itself the project. The first thing to do this quarter is finalise that answer for every HSM in the estate. The work splits cleanly into three groups:

• Group A — current support, current firmware. Schedule the firmware upgrade. Roll out PQC mechanisms gradually behind a config flag. This is fast.
• Group B — current support, old firmware. Schedule the firmware update with the vendor. Most vendors will provide the path; check release notes for forward compatibility of existing keys.
• Group C — off support. Initiate the replacement programme today. The six-month clock starts when the PO is approved, not when you discover you need one.

The cheapest mistake in PQC migration is discovering Group C three months before a regulator wants evidence of progress. The cheapest decision is finding out which group each HSM is in now.