It will come as no surprise that here at DigiCert, we rely heavily on hardware security modules (HSMs) to provide trust and security for our customers. As our transition to post-quantum cryptography (PQC) continues, it’s forced us to examine how the security of these HSMs changes in the face of the quantum threat. 

In this article, we look at two options for post-quantum HSMs: deploying a new fleet of quantum-safe HSMs or using current HSMs that are upgraded to perform PQC operations. We’ll wrestle with the central question of whether we can trust any HSM with PQC, or whether a fully quantum-safe HSM is required to underpin our customers’ PQC certificates. 

How HSMs establish cryptographic trust

First, a bit of background on HSMs. As many are aware, they underpin digital trust and security. They physically store private key material and use those keys to sign certificates. Unlike standard software cryptographic libraries, these are—true to their name—hardware devices. 

HSMs include physical protections to prevent the extraction of key material or abuse of signing capabilities. Think of them like bank vaults—they’re considered the gold standard for securing keys. 

These physical devices run software or firmware. They must ensure they’re running the correct, verified, manufacturer-supplied versions of that software. To accomplish this, they use hardware-based cryptographic keys. 

`

As shown in the figure above, HSMs have an immutable cryptographic public key used to verify the first piece of software that runs on the device (usually a bootloader or boot ROM). This key is burned into the device during manufacturing and cannot be modified.

The most common cryptographic algorithms historically used for these keys are RSA and ECC. Unfortunately, these algorithms aren’t quantum-safe. To achieve quantum safety, a PQC algorithm such as ML-DSA or LMS must be used.

For devices manufactured before PQC standardization, this was not possible. Because the hardware public key is immutable, it can't be updated. While all software after the bootloader can be updated to use different cryptographic primitives, the initial boot process remains protected by quantum-vulnerable algorithms. There’s no quantum-safe upgrade path for these older devices.

Before we move forward, let’s clarify a few of the terms we’ll be using in this discussion:

Quantum-safe HSM: An HSM with an immutable public key based on a PQC algorithm (such as ML-DSA or LMS), where all internal cryptographic security mechanisms also rely on PQC.

HSM with PQC: An HSM capable of performing PQC operations (for example, ML-DSA-44 sign and verify). This doesn’t necessarily mean it’s quantum-safe; it may still rely on an immutable classical public key like RSA.

Cryptographic security: Security that depends on the mathematical hardness of the underlying cryptographic algorithms.

Operational security: Security that depends on procedural safeguards—such as access controls, network restrictions, and personnel oversight—rather than solely on cryptographic strength.

In short: All quantum-safe HSMs are HSMs with PQC, but not all HSMs with PQC are quantum-safe.

A few additional facts for those who haven’t worked with HSMs before: They’re expensive, they don’t scale easily, and each vendor provides slightly different ways to communicate with the device. This isn’t commodity hardware; it's specialized machinery designed to perform one task extremely well.

FIPS 140-3 validation and PQC compliance

The FIPS 140-2 validation process was introduced 25 years ago and retired in 2021. All validations since then have been FIPS 140-3. As a result, all PQC FIPS validations are FIPS 140-3 validations—not FIPS 140-2.

DigiCert uses only FIPS-validated HSMs in production, for both legacy and PQC use cases.

Evaluating cryptographic vs. operational security

With this background in mind, we arrive at the central question: Can we trust an HSM that can perform PQC, or do we require a quantum-safe HSM to underpin our customers’ PQC certificates?

The most straightforward and conservative answer is simple: require quantum-safe HSMs. If a customer’s security model requires cryptographic assurance from HSM to certificate, this is the only solution.

However, cryptographic security isn’t always required. Some customers rely on soft HSMs, where certificate security is enforced through software rather than dedicated hardware. In these cases, assurance depends primarily on operational controls.

Operational security is also foundational to how web browsers and certificate authorities (CAs) operate. Decisions about which roots to trust and whether a domain is controlled by the certificate requester rely on defined processes and governance—not solely on cryptographic keys.

Even some customers who deploy HSMs don’t strictly require cryptographic assurance; they may simply be selecting the highest available security option. If HSM replacement is costly, increases customer expenses, and isn’t required for every security model, does the answer to our central question change?

In some cases, yes—but only with additional safeguards.

More operational controls can be introduced when performing software updates on legacy HSMs, which may include:

• Tightly restricting network access 
• Rigorously vetting personnel responsible for updates 
• Working with vendors to strengthen boot verification mechanisms where possible.

For some customers, this layered approach may be considered sufficient.

We haven’t yet formally surveyed customers on this distinction. This discussion is intended to clarify the trade-offs and support informed decision-making as organizations navigate PQC-related transitions.

DigiCert’s current approach to quantum-safe HSMs

The distinction between PQC capability and quantum-safe architecture ultimately depends on required assurance levels.

Today, DigiCert backs our HSM-based ML-DSA certificates with quantum-safe HSMs to maintain full cryptographic alignment from hardware root to certificate. We’ll continue assessing customer needs and industry developments as PQC adoption progresses.