Best HSM Vendors With Documented PQC Firmware Upgrade Paths
An HSM that can receive firmware updates is not automatically an HSM with a documented post-quantum upgrade path. The relevant evidence names the product family, firmware or application package, supported algorithms and client/application prerequisites.
Three particularly concrete directions in the current official evidence are Thales Luna firmware 7.9, Utimaco Quantum Protect for the u.trust GP HSM Se-Series and Entrust nShield 5 firmware. This is a deliberately narrow shortlist, not a claim that only three HSM vendors work on PQC.
What this comparison can establish
We distinguish algorithm support from an application using that algorithm, and algorithm validation from validation of a complete cryptographic module. NIST’s FIPS 204 specifies ML-DSA; the existence of the standard does not certify a vendor’s complete deployment.
This article uses official documentation and attributed vendor announcements. We did not install firmware, perform key operations, verify an implementation’s security or validate a certification record independently.
| Vendor direction | Concrete official evidence | Why it qualifies for investigation | Procurement limit |
|---|---|---|---|
| Thales Luna | Announcement names firmware 7.9 and native ML-KEM/ML-DSA | A named firmware-level capability rather than only an old external module | Confirm supported hardware/client and exact validation status |
| Utimaco u.trust GP HSM Se-Series | Quantum Protect described as an in-field upgrade; installation docs exist | A named application-package and update route | Package version, licence, hardware and provider prerequisites |
| Entrust nShield 5 | Version matrix and vendor firmware-upgrade announcement | Named family and version-specific algorithm evidence | Security World/client versions, support branch and certified configuration |
Thales Luna: a named firmware release, not a universal family claim
Thales’ Luna 7.9 announcement describes ML-KEM and ML-DSA integrated into firmware, distinct from earlier external functionality-module approaches. The same announcement describes FIPS 140-3 Level 3 validation as in progress.
That is concrete evidence for a firmware-level evaluation, but do not restate “NIST-approved algorithms” as completed module validation. Ask for the current supported hardware and client matrix, release notes and applicable certificate/security policy. The announcement’s broad readiness and ecosystem claims remain vendor claims; it does not prove every installed Luna device can be upgraded identically.
Utimaco: evaluate Quantum Protect as the named package
Utimaco’s Quantum Protect offering describes an in-field upgrade for the u.trust GP HSM Se-Series. Its installation guidance provides a more concrete software/package route.
This is a useful starting point when retaining supported hardware is part of the requirement. Request the exact package, firmware, licence and application-provider combination. A working integration guide for one software stack should not be presented as proof of support for every PKI, TLS or signing application.
Entrust: start with the nShield 5 version matrix
Entrust’s nShield 5 hardware/software/firmware matrix identifies version-specific support, including ML-DSA-related firmware information. Its PQC announcement describes firmware algorithm implementation and CAVP certification.
Investigate the exact family and support branch, not “all nShield HSMs.” CAVP algorithm evidence and full-module validation answer different questions. Ask which Security World release, provider, licence and operational procedure are required, and whether the proposed configuration matches the organisation’s validation requirements.
Why firmware agility alone is not enough
Securosys documents Primus firmware updates, including maintenance/support and licence constraints. That is useful operational evidence, but a generic update procedure alone does not identify every PQC algorithm on every model/version. Its CloudHSM feature description is a separate service scope.
Likewise, Crypto4A’s design paper describes firmware-signature roots of trust. Protecting firmware updates with a PQ signature is not the same claim as adding an application-facing ML-KEM or ML-DSA operation to an older installed device. Futurex’s PQC announcement merits a model/version-specific follow-up rather than automatic equivalence here.
These vendors are not declared unsuitable. They are not padded into the confirmed named-upgrade table on evidence that answers a different question.
The evaluation should follow one real application
Choose a bounded non-production signing or key-establishment use case. Record the exact algorithm/parameter set, HSM model, firmware, client/provider and application versions. Confirm key generation, permitted export or backup behaviour, recovery, access controls and interoperability through the approved test process.
Then evaluate operational change: cluster compatibility, maintenance sequencing, backups, rollback restrictions, retained keys and support ownership. These are procurement checks, not instructions to update a production HSM. Follow the vendor’s authorised procedure and the organisation’s security change process.
An HSM upgrade does not make every certificate, protocol peer, stored ciphertext or firmware trust chain post-quantum. Identify which boundary changes and what remains classical before assigning a readiness label.
Costs and selection
Compare support contracts, feature licences, firmware/application packages, client upgrades, integration work and maintenance downtime. An available upgrade can still be inappropriate for an unsupported hardware generation or an application that cannot consume the new operation.
Use the PQC vendor questionnaire to request the missing evidence. NIST PQC standards explained supplies the algorithm context; it should not be turned into a blanket vendor certification.
Evidence reviewed 20 October 2026. No keys, firmware, certificates or production services were changed. No independent certification claim or paid inclusion.