up:: In the Protocols MOC

PQC in Hardware (HSMs, TPMs, PKCS11)

Post-quantum support in hardware is the arrival of the new algorithms, chiefly ML-KEM and ML-DSA, inside the dedicated cryptographic hardware that guards keys: hardware security modules, Trusted Platform Modules, and smart cards, reached through standard interfaces like PKCS#11. The hardware layer matters because it holds the highest-value keys, the ones an organization most needs to keep unforgeable through the quantum transition, and because a regulated deployment can only use cryptography inside a validated module.

The load-bearing distinction across this whole domain is between an algorithm and a module. NIST’s algorithm-validation program (CAVP) confirms an ML-KEM or ML-DSA implementation is correct in isolation, and the module-validation program (CMVP) confirms the entire FIPS 140-3 module carrying it is validated. Vendors are shipping firmware with CAVP-tested ML-KEM and ML-DSA today, and the FIPS 140-3 certificates that put those algorithms inside a validated boundary trail behind on the CMVP queue, so “our HSM supports PQC” and “our HSM is FIPS-validated for PQC” are two different claims.

Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov.

The short version:

• Hardware security modules, TPMs, and smart cards are where the highest-value keys live, so post-quantum support here protects the keys an organization most needs to keep unforgeable.
• The interfaces are being extended: PKCS#11 3.2 adds mechanisms for ML-KEM, ML-DSA, and SLH-DSA, and the TPM 2.0 Library Specification v1.85 adds ML-KEM and ML-DSA.
• The load-bearing gap is CAVP versus CMVP. An algorithm passing NIST’s CAVP algorithm test is a prerequisite to submitting the whole module to CMVP, and only a completed FIPS 140-3 CMVP certificate covers the algorithm inside a validated boundary.
• As of early 2026, leading HSM vendors have CAVP-tested ML-KEM and ML-DSA in firmware, but a FIPS 140-3 module validated with PQC inside is still working through the certification queue, a lag typically measured in many months. [OPERATOR VERIFY]
• Hardware is where the constrained-resource challenge bites hardest, because smart cards and secure elements have tight memory, storage, and compute budgets, and the larger post-quantum keys and signatures press against them.

Think of an HSM as a bank vault for keys, with a standardized teller window (PKCS#11) through which applications ask it to sign or unwrap something without ever seeing the key. Adding post-quantum support means teaching the vault two new operations and adding two new request slips at the teller window. The vault can perform the new operations as soon as its firmware learns them, which is happening now. But a bank that answers to a regulator can’t call the vault approved for the new operations until an inspector has re-certified the whole vault with those operations inside it, and that inspection runs on its own, slower schedule.

Why does post-quantum support in hardware matter?

Because hardware is where the keys that matter most are deliberately concentrated, and those keys have the longest and highest-stakes exposure. An HSM exists to generate and hold private keys so they never leave a tamper-resistant boundary, which is why organizations put their root certificate-authority keys, their code-signing keys, their payment and database master keys, and their highest-privilege identity keys inside one. Every one of those is a key an attacker with a quantum computer would most want to forge or recover, so the hardware layer is exactly where post-quantum protection has to reach.

Two roles make this concrete. As a signer, an HSM protects the private key behind a signature, so migrating it to ML-DSA (or, for firmware, the stateful hash-based schemes) is what keeps that signature unforgeable after a quantum computer arrives. As a key store and key-establishment engine, a module that supports ML-KEM can generate and use post-quantum key-establishment keys without the private material ever leaving the boundary. A stateful hash-based firmware signer is a special case that NIST SP 800-208 actually requires to run in hardware, because only a module that never exports the key can guarantee a one-time key is never reused. So for a whole class of the transition, hardware support is not a convenience but a compliance prerequisite.

Source: NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, csrc.nist.gov.

How do PKCS#11 and the TPM spec add post-quantum algorithms?

They add them the way they add any algorithm: by defining new mechanisms and object types in the interface standard, so an application can ask the hardware to perform a post-quantum operation through the same API it already uses. Two standards carry the bulk of this.

1. PKCS#11 3.2. PKCS#11 is the near-universal C API through which applications talk to HSMs, smart cards, and software tokens. Version 3.2, approved as an OASIS standard in 2026, adds mechanisms for the NIST post-quantum standards, ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), so an application can generate a post-quantum key pair, encapsulate, or sign through the standard interface rather than a vendor extension.
2. TPM 2.0 Library Specification v1.85. A Trusted Platform Module is the small root-of-trust chip in a platform, used for measured boot, attestation, and sealing keys to a machine’s state. The Trusted Computing Group updated the TPM 2.0 Library Specification to v1.85 to add the post-quantum algorithms ML-KEM and ML-DSA, including for attestation keys, so a platform’s root of trust can eventually attest and seal with quantum-resistant signatures.

Source: OASIS, “PKCS #11 Specification Version 3.2,” docs.oasis-open.org.

Source: Trusted Computing Group, “New computing specification implements PQC measures to protect users from quantum attacks,” trustedcomputinggroup.org.

The pattern to hold onto is that the interface work and the silicon work are separate. A standard defining the mechanisms is what lets software address the algorithm portably, and a given chip or module supporting those mechanisms in its firmware is a separate event, gated by the vendor’s firmware cadence.

What is the difference between CAVP and CMVP for post-quantum hardware?

CAVP validates an algorithm implementation in isolation, and CMVP validates the whole module that ships it, and a post-quantum compliance claim turns on the second, not the first. This distinction is the single most consequential thing to get right when reading a hardware vendor’s post-quantum claims.

1. CAVP (Cryptographic Algorithm Validation Program). This confirms that a specific implementation of an algorithm, say ML-KEM-768, produces correct results against NIST’s test vectors. A CAVP certificate says the math is implemented right. It says nothing about the module around it.
2. CMVP (Cryptographic Module Validation Program). This validates the entire cryptographic module, the FIPS 140-3 boundary, its key management, its physical protections, its self-tests, at a security level (Level 1 through 4). A CMVP certificate is what a regulated deployment actually requires.

The two are sequenced: an algorithm has to pass CAVP first, because a CAVP algorithm certificate is a prerequisite to submitting the module to CMVP. So the normal path is CAVP-tested firmware first, then a module validation that folds the algorithm into the validated boundary. That ordering is why, in a period like early 2026, HSM vendors can truthfully say their firmware has CAVP-tested ML-KEM and ML-DSA while no module yet holds a completed FIPS 140-3 certificate with those algorithms inside its boundary, with the modules sitting in the “Implementation Under Test” or “Modules in Process” stages of the CMVP queue. [OPERATOR VERIFY: the specific per-vendor CAVP and CMVP statuses move continually; confirm the current CMVP module list before citing any vendor as validated.]

Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov.

Which hardware vendors support post-quantum algorithms?

Support is broad and moving fast as of early 2026, and every specific vendor status here is the kind of claim to re-verify against the primary source before relying on it, because firmware and certification states change from quarter to quarter. The general shape holds even as the details move: major HSM and secure-element vendors have CAVP-tested ML-KEM and ML-DSA in firmware, and the corresponding FIPS 140-3 module validations are in the CMVP pipeline rather than complete.

Hardware	Reported post-quantum support	Validation status	Verify
Entrust nShield 5 HSM	Firmware with CAVP-tested ML-DSA, ML-KEM, and SLH-DSA	Module validation in the CMVP pipeline	[OPERATOR VERIFY]
Thales Luna HSM	Firmware integrating ML-KEM and ML-DSA natively	Next FIPS candidate build; validation pending	[OPERATOR VERIFY]
TPM 2.0 secure elements (multiple vendors)	ML-KEM and ML-DSA per TPM 2.0 v1.85	Vendor samples and firmware, per-part validation varies	[OPERATOR VERIFY]

Source: Encryption Consulting, “Are Your HSMs PQC-Ready?,” encryptionconsulting.com.

The load-bearing read is not any single vendor’s status but the structure behind it. The algorithms are implemented and CAVP-tested in current firmware, so you can generate and use ML-KEM and ML-DSA keys in leading hardware today, and the completed FIPS 140-3 module certificates that a strict Level 3 mandate requires are the trailing item, expected to take many months to clear the validation queue after the algorithms are available. A hardware post-quantum plan tracks the validated-module date separately from the firmware-feature date, exactly as it does for the software libraries. [OPERATOR VERIFY: vendor and timeline specifics.]

Why is hardware where the constrained-resource challenge bites hardest?

Because the smallest cryptographic hardware has the tightest budgets, and the post-quantum artifacts are larger than what it was built to hold. A high-end network HSM has ample compute and memory, so running ML-KEM or ML-DSA there is not a resource problem. The pressure is at the small end: smart cards, secure elements, TPMs, and embedded roots of trust, which have kilobytes of RAM, limited persistent storage, and modest processors, often chosen for cost and power rather than performance.

The post-quantum schemes strain those budgets in specific ways:

1. Key and signature sizes. Post-quantum public keys, ciphertexts, and signatures are substantially larger than the elliptic-curve values they replace, so they consume more of a card’s scarce storage and more of the transmission budget over a slow contactless or serial interface.
2. Memory during the operation. Lattice operations need working memory that a tiny secure element may not have spare, which can force careful implementation or rule out some parameter sets on the smallest parts.
3. Stateful-scheme constraints. Where LMS or XMSS are used in an embedded signer, the requirement to reliably persist and never duplicate state adds its own storage and integrity demands on a constrained part.

This is the same binding constraint covered in depth in Constrained-Device PQC, where artifact size rather than raw speed is usually the limiting factor. The consequence for hardware is that post-quantum readiness is uneven across the form factors: it arrives comfortably in big HSMs and presses hard against the smallest secure elements, so a hardware inventory has to account for which end of that range each key actually lives on.

Source: NIST, “Cryptographic Module Validation Program,” csrc.nist.gov.

Common misconceptions

• “Our HSM supports ML-KEM, so we’re FIPS-compliant for post-quantum.” Firmware support means the algorithm is CAVP-tested and usable, and FIPS compliance for a regulated deployment turns on a completed FIPS 140-3 CMVP certificate with the algorithm inside the module’s validated boundary, which is a separate and later event.
• “CAVP and CMVP are the same certification.” CAVP validates an algorithm implementation in isolation; CMVP validates the whole module. CAVP is a prerequisite for CMVP, so an algorithm certificate says nothing about whether the module carrying it is validated.
• “Post-quantum is the same job on every piece of hardware.” It is easy on a big HSM and hard on a smart card or secure element, where the larger post-quantum keys and signatures press against tight memory and storage. Readiness is uneven across form factors.
• “PKCS#11 already handles the new algorithms, so nothing changes.” PKCS#11 3.2 added the ML-KEM, ML-DSA, and SLH-DSA mechanisms, and an application and its hardware both have to support that version for the standard interface to reach them. Older stacks need updating.
• “A TPM can already attest with post-quantum signatures.” The TPM 2.0 v1.85 specification adds ML-KEM and ML-DSA, but a given platform’s TPM has to ship firmware implementing v1.85 for that to be real, and much deployed hardware predates it.

Questions people ask

Do HSMs support ML-KEM and ML-DSA today? Leading HSM vendors have CAVP-tested ML-KEM and ML-DSA in current firmware, so you can generate and use those keys now. Whether the module holds a completed FIPS 140-3 certificate with the algorithm inside its boundary is a separate question, and those validations are still working through the CMVP queue. [OPERATOR VERIFY]

What is the difference between CAVP and CMVP? CAVP validates that an algorithm implementation is correct against NIST test vectors; CMVP validates the entire cryptographic module against FIPS 140-3 at a security level. A regulated deployment needs the CMVP module certificate, and CAVP is a prerequisite step toward it.

How does an application use a post-quantum key in an HSM? Through PKCS#11, the standard interface to HSMs and smart cards. Version 3.2 adds the mechanisms for ML-KEM, ML-DSA, and SLH-DSA, so an application addresses the hardware the same way it already does, once both the application and the module support that version.

Can a TPM do post-quantum yet? The TPM 2.0 Library Specification v1.85 added ML-KEM and ML-DSA, including for attestation keys, so the capability is specified. A specific machine’s TPM has to ship firmware implementing v1.85 for it to be usable, and most deployed TPMs predate that revision. [OPERATOR VERIFY]

Why is post-quantum harder on smart cards than on big HSMs? Because smart cards and secure elements have tight memory, storage, and compute budgets, and the larger post-quantum keys and signatures press against them. A high-end HSM has room to spare, so it is the small form factors where the constrained-resource challenge bites.

How long until my HSM is FIPS-validated for post-quantum? The lag between an algorithm being available in firmware and a module being FIPS 140-3 validated with it inside is typically measured in many months, driven by the CMVP validation queue. Track the validated-module date separately from the firmware-feature date. [OPERATOR VERIFY: current queue timing.]

Which keys should move to post-quantum hardware first? The ones with the longest life and the highest privilege: root certificate-authority keys, code-signing and firmware-signing keys, and top-level identity keys. Those are the keys an HSM exists to protect and the ones a quantum attacker would most want, so they anchor the hardware migration.

Go deeper

The module concept and its roles live in HSM (Hardware Security Module), and the validation standard is FIPS 140-3. The size-versus-budget problem at the small end is Constrained-Device PQC. The interface itself is PKCS. The algorithms are ML-KEM, ML-DSA, SLH-DSA, and the hardware-required stateful firmware signers LMS and XMSS. The hub that maps this into every other protocol is In the Protocols MOC.

---

Everything here is the map, given freely. When your team needs its HSMs, TPMs, and smart-card estate assessed for where post-quantum keys can actually live today and where a FIPS-validated boundary is still pending, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.