Quantum-safe HSMs and PQC certificates: what trust really changes

At a glance

What this is: This is an analysis of whether PQC-capable HSMs are enough for certificate trust, and the key finding is that PQC support alone does not guarantee a quantum-safe trust chain.

Why it matters: It matters because IAM, PKI, and machine identity teams need to know when hardware-root assurance is still classical, when operational controls are doing the heavy lifting, and when quantum-safe replacement is the only defensible path.

By the numbers:

• The FIPS 140-2 validation process was introduced 25 years ago and retired in 2021.

👉 Read DigiCert's analysis of whether PQC certificates require quantum-safe HSMs

Context

Post-quantum cryptography changes the trust assumptions behind certificate infrastructure, but it does not automatically make every hardware security module quantum-safe. The core issue is whether the hardware root of trust, not just the software running on top of it, has been designed around PQC from the start.

For IAM and machine identity programmes, this is not a narrow PKI concern. Certificate issuance, key protection, boot verification, and lifecycle governance all depend on where the trust anchor lives, and whether the organisation can still rely on cryptographic assurance once classical algorithms are no longer considered sufficient.

Key questions

Q: How should security teams decide whether a PQC-capable HSM is enough?

A: Start by asking whether the organisation needs cryptographic assurance from hardware to certificate, or whether operational controls are acceptable for part of the chain. If the trust model requires hardware-root cryptographic assurance, a PQC-capable device with a classical immutable boot key is not enough. The decision must be based on the assurance model, not the feature list.

Q: What breaks when an HSM’s boot trust still depends on RSA or ECC?

A: The quantum-safe claim breaks at the root of trust. Even if later firmware supports PQC signing, the device still verifies its first code path with a classical algorithm that is vulnerable in a quantum future. That means the HSM may remain fit for some operational models, but it is not fully quantum-safe.

Q: How do organisations know if their PQC migration is really changing the trust model?

A: Look for evidence that the immutable trust anchor, not just the signing algorithm, has changed. If the device can do PQC but the boot verification chain still relies on classical cryptography, the migration is partial. The right signal is end-to-end trust inheritance, from hardware root through certificate issuance.

Q: Who should own the decision between replacement and compensating controls for legacy HSMs?

A: The decision should be shared by PKI, IAM, and hardware operations owners, because it crosses certificate assurance, access governance, and device lifecycle management. Where replacement is not immediate, compensating controls such as network restriction and personnel vetting must be documented as temporary risk treatment, not as proof of quantum safety.

Technical breakdown

PQC-capable HSMs versus quantum-safe HSMs

A PQC-capable HSM can perform post-quantum operations such as signing and verification with algorithms like ML-DSA, but that alone does not make the device quantum-safe. A quantum-safe HSM requires the entire security chain, including the immutable public key used at boot, to rely on PQC. If the boot key remains RSA or ECC, the device still depends on quantum-vulnerable trust at the root. The distinction matters because hardware assurance is only as strong as the first verified step in the device startup sequence.

Practical implication: classify HSM estates by trust root, not by advertised PQC support alone.

Immutable boot trust and the limits of upgrade paths

Older HSMs can often update firmware or software after boot, but they cannot replace an immutable public key burned into the device at manufacture. That means the bootloader verification path may remain tied to classical cryptography even after the appliance supports PQC operations later in the stack. In practice, this creates a split model where operational updates improve some layers while the foundational trust anchor stays unchanged. For organisations that need cryptographic assurance from hardware to certificate, that residual classical root is the real constraint.

Practical implication: treat immutable boot keys as the control boundary when deciding whether legacy HSMs can remain in scope.

Cryptographic assurance versus operational security

Not every deployment depends on pure cryptographic assurance from hardware. Some certificate trust models lean more heavily on operational security, meaning network restrictions, personnel vetting, and governance over update processes do part of the assurance work. That is a different security model from one in which the HSM itself provides end-to-end cryptographic protection. The article’s central contribution is to separate those two assumptions, because teams often conflate a strong operational posture with a quantum-safe architecture when they are not the same thing.

Practical implication: document whether your certificate trust model is cryptographic, operational, or mixed before you plan PQC migration.

NHI Mgmt Group analysis

Quantum-safe HSM is a trust-root requirement, not a marketing label. The article correctly separates devices that can perform PQC from devices whose full security chain is PQC-native. That distinction matters because certificate governance depends on the integrity of the boot trust root, not just the algorithms available to later firmware. For machine identity programmes, the practitioner conclusion is simple: do not equate PQC operations with quantum-safe assurance.

Boot-time cryptographic inheritance is the hidden control boundary. If an HSM was manufactured with an immutable RSA or ECC public key, the quantum-vulnerable assumption survives at the root even when everything above it is updated. That is a structural issue for lifecycle governance, because the device cannot be remediated into a different trust model by software alone. Practitioners should treat manufacture-time trust inheritance as a separate risk class in their hardware inventory.

Operational controls can compensate for some legacy exposure, but they do not redefine the trust model. Restricting network access, vetting personnel, and strengthening update governance can reduce risk around legacy HSMs, yet those measures shift the assurance burden away from the cryptographic root. That is acceptable only where the organisation explicitly accepts operational security as the primary control. The implication is that PQC planning must distinguish between hard cryptographic requirements and compensating operational controls.

PKI and IAM teams need one decision rule for certificate trust and another for device management. The certificate authority question is whether the environment can tolerate a classical trust anchor anywhere in the chain. The hardware operations question is whether legacy devices can be managed safely enough while replacement is staged. Those are related but not identical governance decisions, and treating them as one will produce false confidence.

Quantum-safe migration exposes identity infrastructure assumptions that have been invisible for years. The post-quantum transition makes organisations ask where trust is actually anchored, who owns that trust, and whether the current estate was built for upgradeability or replacement. That is a broader identity governance issue, not just a cryptography issue. The practitioner takeaway is to map every certificate and HSM dependency to its trust root before quantum-safe migration becomes a compliance deadline.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• If hardware-root trust is becoming a policy issue, the same governance discipline has to extend to machine identities and lifecycle controls, as explored in Ultimate Guide to NHIs.

What this signals

Quantum-safe migration is becoming an identity governance issue, not just a cryptography refresh. As hardware roots of trust become part of broader machine identity programmes, teams need to know which certificates depend on immutable legacy verification and which can survive a staged transition. The governance gap is not theoretical: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.

Trust-root mapping will matter more than feature checklists. If your inventory tells you that an HSM supports PQC but not whether its boot chain is PQC-native, you do not yet have decision-grade assurance. That is the same visibility problem that drives broader NHI risk, and it is why hardware, certificate, and access governance need the same lifecycle lens.

For practitioners

• Inventory HSM trust roots separately from PQC feature sets Record whether each device has a PQC-native immutable public key or only PQC operations layered on top of classical boot verification. Use that distinction in hardware risk registers and replacement plans.
• Segment legacy HSMs by assurance model Tag systems that depend on cryptographic assurance differently from systems that rely on operational security, including network restrictions, personnel vetting, and update governance. Do not mix the two in the same control baseline.
• Set a replacement rule for non-upgradeable trust anchors Where the immutable boot key cannot be moved to PQC, define the device as a replacement candidate rather than a long-term exception. Tie that decision to certificate criticality and regulatory exposure.
• Align certificate policy with hardware validation status Confirm that production HSMs are using the current validation regime and that certificate governance records reflect the difference between legacy and PQC-era assurance expectations.

Key takeaways

• PQC support alone does not make an HSM quantum-safe if the immutable boot trust still depends on classical cryptography.
• The practical risk is an incomplete trust transition, where firmware changes but the hardware root of trust stays quantum-vulnerable.
• Teams should classify HSMs by assurance model and replace devices whose trust anchors cannot move to PQC.

Key terms

• Quantum-safe HSM: An HSM whose full trust chain uses post-quantum cryptography, including the immutable public key used to verify the first boot code. It is quantum-safe only when the hardware root, not just the application layer, has moved to PQC.
• HSM with PQC: An HSM that can perform post-quantum cryptographic operations such as signing and verification. This capability does not guarantee quantum safety, because the device may still depend on a classical boot trust anchor that remains vulnerable to future quantum attacks.
• Immutable boot key: The public key burned into an HSM during manufacturing and used to verify the first software that runs on the device. Because it cannot be changed later, it becomes the decisive boundary between a partial PQC upgrade and a fully quantum-safe design.
• Operational security: Security that depends on procedural and administrative controls rather than cryptographic strength alone. In HSM governance, this includes network restriction, personnel vetting, and update oversight, which can reduce risk but do not alter the underlying trust root.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Do PQC Certificates Require Quantum-Safe HSMs? Read the original.