Notifications
Clear all
Topic starter
24/06/2026 7:36 pm
TL;DR: As post-quantum cryptography moves into production, HSMs which can perform PQC operations are not always the same as quantum-safe HSMs, because immutable classical boot keys can preserve quantum-vulnerable trust at the hardware root, according to DigiCert. The distinction matters because certificate assurance depends on whether cryptographic trust or operational controls are actually carrying the security model.
NHIMG editorial — based on content published by DigiCert: Do PQC Certificates Require Quantum-Safe HSMs?
By the numbers:
- The FIPS 140-2 validation process was introduced 25 years ago and retired in 2021.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The device-level explanation of how immutable public keys participate in HSM boot verification.
- The author’s side-by-side discussion of quantum-safe HSMs versus HSMs with PQC.
- The practical trade-offs between replacing legacy hardware and layering compensating operational controls.
- The article’s framing of certificate trust when operational security, rather than cryptographic assurance, carries part of the model.
👉 Read DigiCert's analysis of whether PQC certificates require quantum-safe HSMs →
Quantum-safe HSMs and PQC certificates: do your controls hold up?
Explore further
25/06/2026 4:57 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Quantum-safe HSMs and PQC certificates: what trust really changes
