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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: PQC-capable HSMs are not necessarily quantum-safe, and immutable classical boot keys can keep the trust root dependent on RSA or ECC.

Why it matters: For IAM, PKI, and machine identity teams, the real decision is whether the assurance model depends on cryptographic trust from hardware root to certificate or on compensating operational controls.

Context

Post-quantum cryptography changes the trust question for HSM-backed certificates because the device’s security model starts at the hardware root, not at the certificate itself. If the immutable boot key is still classical, the platform can perform PQC later in the stack while still relying on quantum-vulnerable trust at device startup.

For identity and PKI practitioners, that distinction matters when you are deciding whether a control is cryptographically enforced or operationally enforced. In this article, DigiCert frames the issue around assurance level, upgrade path, and whether a legacy HSM can meet the trust requirements of a PQC certificate programme.

Key questions

Q: How do organisations decide whether an HSM trust model is truly quantum-safe?

A: They should verify the cryptographic primitive protecting the immutable boot key, then check whether every other trust layer depends on that same root. If the boot verifier is still RSA or ECC, the HSM can be PQC-capable without being quantum-safe. The decision should be based on assurance requirements, not on signing feature parity alone.

Q: When do operational controls become acceptable in place of full cryptographic assurance?

A: Only when the organisation explicitly accepts that the trust model is partly procedural and can enforce it with network restriction, personnel governance, and tightly controlled firmware updates. That approach can reduce risk for some deployments, but it does not replace a PQC hardware root. The burden shifts from cryptographic certainty to governance discipline.

Q: What breaks when PQC support is treated as the same thing as quantum safety?

A: The control assumption breaks at the boot chain. Teams may believe the HSM is fully modernised while the device still verifies its first code with a classical public key. That leaves the most privileged trust step dependent on RSA or ECC, which is exactly where the quantum threat still matters.

Q: What is the difference between PQC-capable HSMs and quantum-safe HSMs?

A: PQC-capable HSMs can perform post-quantum operations such as signing or verifying with ML-DSA. Quantum-safe HSMs use PQC throughout the device trust chain, including the immutable boot verification key. The former describes a function; the latter describes an end-to-end assurance model that removes classical cryptographic dependence at the root.

Technical breakdown

Immutable boot keys and the hardware root of trust

An HSM protects private keys and signs certificates, but it must first verify the firmware or bootloader that runs on the device. That verification depends on an immutable public key burned into the hardware at manufacture. If that key is RSA or ECC, the first trust decision remains quantum-vulnerable even when later firmware supports PQC algorithms. The device can become PQC-capable without becoming quantum-safe, because the root of trust was never replaced. In other words, algorithm agility in software does not automatically extend to the hardware boot chain.

Practical implication: Treat hardware-root verification as a separate requirement from PQC signing support.

PQC-capable HSMs versus quantum-safe HSMs

A PQC-capable HSM can perform post-quantum operations such as ML-DSA signing and verification. A quantum-safe HSM goes further: all internal cryptographic security mechanisms, including the immutable public key used at boot, rely on PQC. That distinction is operationally important because certificate assurance is only as strong as the weakest trust anchor in the device chain. If the boot root remains classical, the device still carries quantum exposure even when its application-layer cryptography has moved forward.

Practical implication: Separate procurement, assurance, and compliance decisions for PQC capability from those for quantum-safe architecture.

Operational controls when cryptographic assurance is not the full model

Not every deployment requires a purely cryptographic chain of assurance from HSM to certificate. Some environments rely on operational security, where network restrictions, personnel vetting, and controlled update processes carry part of the trust burden. That model can be acceptable only when the organisation explicitly accepts the trade-off and tightens governance around maintenance and firmware updates. The risk is not simply weaker cryptography, but a shift in where trust resides. Once that shift happens, governance, not just cryptographic design, determines whether the control holds.

Practical implication: Document where operational controls replace cryptographic assurance and test those controls as part of PKI governance.

Threat narrative

Attacker objective: The objective is to preserve a quantum-vulnerable trust anchor at the hardware root so that PQC capability does not equal end-to-end quantum safety.

1. Entry begins at the hardware root, where the HSM’s immutable public key verifies the first boot component and may still rely on RSA or ECC.
2. Escalation occurs if teams assume PQC signing support also means quantum-safe device trust, even though the boot path remains anchored in classical cryptography.
3. Impact is a certificate trust chain whose strongest-looking layer is not necessarily protecting the earliest and most privileged verification step.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Quantum-safe trust begins at the boot chain, not at the certificate. A device that can sign with PQC still depends on its immutable hardware key to verify the first code that runs. If that key is classical, the trust root has not been modernised, only the later stages of the stack have. Practitioners should treat root-of-trust design as a separate assurance decision, not as a side effect of PQC readiness.

HSMs with PQC and quantum-safe HSMs are not interchangeable categories. The article’s central distinction is that PQC capability describes what the device can do, while quantum-safe architecture describes what the device still depends on. That matters for PKI governance because certificates inherit the assurance model of the underlying hardware. The practical conclusion is that architecture reviews must ask which cryptographic primitive protects the immutable boot key, not only which algorithm signs the certificate.

Operational controls can supplement trust, but they do not rewrite the device’s cryptographic history. Tight network access, personnel vetting, and controlled update processes can reduce risk when legacy HSMs are retained. They do not, however, convert a classical boot root into a PQC root. That is why assurance conversations must distinguish compensating controls from cryptographic substitution.

Hardware-root integrity is becoming a policy question as much as a cryptographic one. When organisations accept operational security in place of full hardware-root quantum safety, they are making a governance decision about where trust lives. That affects procurement, lifecycle planning, and certificate policy alike. The implication for PKI teams is to define which trust assumptions are non-negotiable before migration begins.

Quantum-safe readiness will expose hidden dependence on legacy trust anchors. Many programmes will discover that moving certificates to PQC is easier than modernising the hardware or operational controls that support them. That asymmetry will shape migration sequencing across identity infrastructure, certificate authorities, and device estates. Teams should expect assurance debates to shift from algorithm selection to trust-root ownership.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.

What this signals

Quantum-safe migration is a trust-root problem before it is a cryptography problem. Teams that focus only on certificate algorithms can miss the more durable issue, which is whether the hardware root still depends on a classical boot verifier. That is why PKI and machine identity programmes need an inventory of device trust anchors as part of their migration planning.

Operational trust has to be named, not implied. If a programme accepts network controls, personnel checks, and restricted update paths as part of the assurance model, those controls need to be documented as the thing carrying trust. Otherwise, teams may believe they have end-to-end cryptographic protection when they actually have a mixed model with different failure modes.

Quantum-safe HSMs will force a sharper divide in procurement language. Security teams will need to distinguish feature support, assurance claims, and policy requirements in the same way they already separate signing capability from key custody. For IAM and PKI leaders, that means migration decisions should be written around trust assumptions, not vendor labels.

For practitioners

• Map the hardware root of trust Identify which immutable key verifies boot on each HSM model and whether it is RSA, ECC, or a PQC primitive. Classify devices by whether the boot trust anchor can ever become quantum-safe.
• Separate PQC capability from quantum-safe assurance Treat ML-DSA support, firmware updateability, and immutable boot verification as distinct review items so that signing capability is not mistaken for full device trust.
• Document compensating operational controls Where legacy HSMs remain, record the network restrictions, personnel vetting, and update governance that carry part of the assurance model.
• Re-evaluate certificate policy language Specify whether your PKI requires cryptographic assurance from the hardware root or whether an operationally controlled trust model is acceptable for some certificate classes.

Key takeaways

• PQC capability and quantum-safe architecture are not the same thing, because the boot trust root can remain classical even when later cryptographic operations have been upgraded.
• The core issue is where trust begins in the HSM lifecycle, since the immutable hardware key determines whether the device’s first verification step is still vulnerable to quantum risk.
• Practitioners should decide whether their PKI requires hardware-root cryptographic assurance or whether a compensating operational model is acceptable for specific certificate use cases.

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.
• PQC-capable HSM: An HSM that can perform post-quantum cryptographic operations such as signing or verification, but may still rely on classical algorithms at the hardware root. Capability is not the same as end-to-end quantum safety, because the boot trust anchor may remain vulnerable.
• Hardware Root Of Trust: A hardware root of trust is a device-level trust anchor, often backed by a TPM or similar mechanism, that proves a system is what it claims to be. It helps infrastructure enroll without relying on static bootstrap secrets and gives identity systems a more durable basis for issuance and attestation.
• 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.