As organizations prepare to issue their first post-quantum certificates, a practical and surprisingly question keeps coming up: do PQC certificates require a special “quantum-safe” hardware security module, or will the HSMs already in production handle them just fine?
It is a fair question, and the answer is more interesting than a simple yes or no. The term “quantum-safe HSM” appears across vendor marketing, procurement checklists, and architecture discussions, often without a clear definition of what it actually means. Some organizations assume their existing HSMs are obsolete the moment they touch a PQC certificate. Others assume the opposite, that an HSM is just a secure box and the algorithms inside the certificate do not concern it at all. Both assumptions are wrong in instructive ways.
This blog unpacks what an HSM actually does, what “quantum-safe” means when applied to one, why the distinction matters for protecting PQC certificates, and what you should actually verify before assuming your hardware is ready.
What an HSM Actually Protects
To generate, store, and use the private keys behind PQC certificates with the same security guarantees you expect for classical keys, you need an HSM that natively supports the post-quantum algorithms involved, primarily ML-DSA (FIPS 204) for signatures and ML-KEM (FIPS 203) for key establishment. An HSM that does not support these algorithms cannot perform PQC key operations inside its secure boundary, which defeats the entire purpose of using an HSM in the first place.
But the phrase “quantum-safe HSM” is doing a lot of unstated work, and that is where the confusion begins. An HSM is not made “quantum-safe” in the way that an algorithm is quantum-resistant. The hardware itself is not vulnerable to quantum attack. What matters is whether the HSM’s firmware and cryptographic library can perform post-quantum algorithm operations natively, inside the hardware boundary, so that the private key never leaves protected hardware.
When you sign a certificate or a piece of software using an HSM, the operation works like this: the data to be signed, or more commonly a hash of it, is sent into the HSM. The HSM performs the signing operation internally using the private key that lives inside it, and returns only the signature. The private key never leaves the hardware. This is the entire value proposition of an HSM. It means that even if every other system in your environment is compromised, the private key remains protected.
The FIPS 140-3 Shift
FIPS 140 is the US government standard for validating cryptographic modules, including HSMs. The validation confirms that a module correctly implements approved algorithms and meets defined physical and logical security requirements. For decades, FIPS 140-2 was the relevant version. It was introduced about 25 years ago and was officially retired from new validations in 2021. Every validation since then has been against FIPS 140-3.
This timing creates a direct and important consequence for post-quantum cryptography: all PQC FIPS validations are FIPS 140-3 validations, not FIPS 140-2. The post-quantum algorithms were standardized by NIST in August 2024, well after FIPS 140-2 stopped accepting new validations. The CMVP updated its standards and tooling so that ML-KEM, ML-DSA, and SLH-DSA can be included in new FIPS 140-3 submissions. There is no path by which a PQC algorithm receives a FIPS 140-2 validation, because that program no longer accepts new submissions.
There is also a deadline that sharpens the urgency: NIST is moving all FIPS 140-2 certificates to Historical status in September 2026. Modules on the Historical list may no longer be suitable for new procurements in many federal and regulated contexts.
The practical takeaway is that an organization serious about PQC certificate issuance should be looking specifically for HSMs with FIPS 140-3 validation that includes the relevant PQC algorithms, or with a clear, committed roadmap to that validation. Several vendors have already achieved milestones here. As of late 2025 and into 2026, vendors including Crypto4A, Entrust, Idemia, Kryptus, Marvell, Securosys, and Utimaco obtained CAVP algorithm certification for ML-KEM, ML-DSA, and SLH-DSA, and HSMs including the Entrust nShield 5, Marvell LiquidSecurity 2, and Thales Luna G7 and K7 have been progressing through FIPS 140-3 validation with PQC support.
Technical Challenges of PQC Keys in Hardware
Supporting PQC in HSMs is not a trivial firmware update, and understanding the technical challenges involved explains why vendor support has rolled out gradually rather than all at once.
Larger Key and Signature Sizes Strain Hardware Constraints
PQC keys are substantially larger than their classical equivalents. An ML-DSA private key can range from roughly 1.6 KB to 4 KB depending on the parameter set, compared to a few hundred bytes for ECDSA. HSMs operate with fixed memory and storage budgets, and some constrained modules struggle with the larger PQC key material. This is a hardware constraint, not a flaw, but it illustrates why not every HSM model handles PQC equally well.
Seed-Based Key Generation Introduces a Tradeoff
ML-DSA and SLH-DSA support generating keys from a compact seed, sometimes as small as 32 to 64 bytes, rather than storing the full expanded private key. This mitigates the storage problem by keeping only the small seed in the HSM. The tradeoff is computational: the full private key must be derived from the seed on demand each time it is needed, which increases the processing overhead of each operation. The IETF has been working through the implications of this dual key format, where a key can be represented either as a compact seed or as a larger expanded key, because it complicates PKCS#12 file handling, HSM integration, and interoperability between systems that expect different formats.
Performance Overhead Is Real
Post-quantum algorithms require more computational resources than their classical equivalents. ML-KEM key generation uses roughly three times more cycles than ECDH, and ML-DSA signing requires roughly five times more cycles than ECDSA on equivalent hardware. HSMs with fixed computational budgets may see reduced throughput after migrating to PQC. For high-volume signing or key establishment operations, this throughput impact needs to be tested and planned for rather than assumed away.
Large Payloads Hit Network Limits
When signing large objects such as big certificate revocation lists, the amount of data that can be sent to an HSM over the network is often limited. This is why client-side hashing, sending only the hash of the data to the HSM rather than the full payload, is the recommended pattern for PQC signing. It keeps the data crossing the HSM boundary small regardless of the size of the artifact being signed.
Standardization Is Still Settling
PKCS#11, the standard interface for HSM operations, is still catching up. LMS and HSS were standardized in PKCS#11 version 3.1, while ML-DSA, SLH-DSA, and ML-KEM are being standardized in PKCS#11 version 3.2. Several REST-based HSMs already support these algorithms ahead of full PKCS#11 standardization, but the practical result is that PQC support varies meaningfully between vendors and even between firmware versions of the same product.
Best Practices for PQC Key Protection
Here are the practices that consistently distinguish well-architected PQC certificate deployments.
Keep PQC Private Keys in Hardware, along with Classical Keys
The single most important principle is consistency. The hardware protection standard you apply to classical certificate keys must apply equally to PQC keys. This requires PQC-capable HSMs, not because the hardware was vulnerable, but because hardware protection requires hardware-native algorithm support.
Standardize on FIPS 140-3 Validated Hardware
With FIPS 140-2 moving to Historical status and all PQC validations being FIPS 140-3, aligning HSM procurement to FIPS 140-3 with PQC algorithm support positions the organization correctly for both current operations and regulatory expectations.
Use Client-Side Hashing for Signing Operations
Sending only hashes to the HSM rather than full payloads keeps the data crossing the boundary small, which matters more with PQC given the larger signatures and the network limits on HSM communication.
Adopt Hybrid Certificates During the Transition
Hybrid is the recommended transitional path. Ensure the HSM protects both the classical and post-quantum halves, so the hybrid approach does not introduce a software-held key.
Test at Production Scale Before Committing
Because PQC support varies by vendor and firmware version, and because key sizes and throughput characteristics differ meaningfully from classical algorithms, early production-scale testing is essential. Validate that operations like large CRL signing work within your HSM’s constraints before you depend on them.
Build for Crypto-Agility
Design certificate and signing infrastructure so that algorithms can change without rebuilding the whole system. The PQC transition is not the last cryptographic change you will manage, and infrastructure designed for agility absorbs future changes at far lower cost.
How Encryption Consulting Can Help
The question of whether PQC certificates require quantum-safe HSMs sits at the intersection of cryptographic architecture, hardware procurement, and PKI governance, which is precisely where Encryption Consulting’s product portfolio and advisory services operate.
With our CodeSign Secure platform, which is built around the principle we discussed, that is, PQC private keys deserve the same hardware protection as classical keys, you can perform ML-DSA and SLH-DSA signing operations inside FIPS-validated HSMs from Thales, Entrust, Utimaco, and Securosys, with the private key never leaving the hardware boundary. It supports LMS for firmware signing, and uses client-side hashing so that only hashes, not full artifacts, cross the HSM boundary. For organizations issuing or using PQC certificates for code and firmware signing, CodeSign Secure provides the hardware-aligned trust chain from key generation to signature.
CertSecure Manager is another platform with which help you manage the certificate lifecycle through the PQC transition, including the issuance and management of post-quantum certificates. Its crypto-agility supports running classical and post-quantum algorithms in parallel during the hybrid deployment phase, and its centralized governance ensures that PQC certificates are tracked, renewed, and managed with the same rigor as classical ones.
Our Post-Quantum Cryptographic Advisory Services help organizations answer exactly the kind of architecture and procurement questions we covered in this blog: which HSMs in your environment are PQC-capable, which need firmware upgrades or replacement, how to structure a hybrid certificate deployment, and how to align your hardware roadmap to the FIPS 140-3 transition and the September 2026 deadline for FIPS 140-2 historical status.
Conclusion
So, do PQC certificates require quantum-safe HSMs? The most accurate answer is this: PQC certificates require HSMs that natively support post-quantum algorithms, if you want the private keys behind those certificates to have the hardware protection. The “quantum-safe HSM” label is really shorthand for an HSM whose firmware can perform ML-DSA, ML-KEM, and related operations inside its secure boundary.
The HSM hardware was never quantum-vulnerable. What changed is that protecting a quantum-resistant certificate’s private key in hardware requires the hardware to understand that key’s algorithm. An HSM that cannot perform ML-DSA operations cannot protect an ML-DSA key, and a quantum-resistant certificate whose private key sits unprotected in software has a weak link that defeats the migration’s entire purpose.
At Encryption Consulting, our products and advisory services are designed to help you make these decisions correctly, from discovering your cryptographic inventory to issuing PQC certificates backed by hardware-protected keys.
