HSMs & Crypto Machines

Hardware security modules, cloud key-management services, and Chinese 密码机 (crypto machines) are where post-quantum keys actually live in production. Through 2025-2026 the major HSM vendors shipped native ML-KEM/ML-DSA/SLH-DSA firmware, the big clouds turned on PQC signing and hybrid TLS, and Chinese vendors fielded full anti-quantum 密码机 lines. This page snapshots confirmed products, the standards that bind them, and where validation is still pending.

Western HSMs

The pattern across Western HSMs is consistent: algorithm support arrived first via firmware, CAVP algorithm testing followed, and full FIPS 140-3 module validation is the slow last step. Thales Luna and Entrust nShield 5 added the full lattice + hash trio natively; Utimaco's "Quantum Protect" is notable for being field-activatable on existing Se-Series hardware, so deployed fleets can gain PQC without a hardware swap, including the stateful LMS-HSS/XMSS schemes. Marvell's LiquidSecurity is the engine behind Azure's Cloud HSM, blurring the line between on-prem HSM and cloud KMS below. A clear distinction matters: CAVP is algorithm-implementation validation, while CMVP / FIPS 140-3 is full cryptographic-module certification; a "CAVP" mark in the table means the algorithm implementation passed testing, not that the whole HSM has achieved FIPS 140-3 PQC module certification.

Cloud KMS

The clouds split PQC into two tiers. Software keys get post-quantum signing and hybrid key exchange fastest — AWS made ML-DSA signatures generally available and rolled ML-KEM hybrid TLS through KMS, ACM, and Secrets Manager, while Google Cloud KMS offers ML-DSA-65 and SLH-DSA-128s for software-backed keys. Microsoft pushed PQC into the SymCrypt engine that underpins Windows. Hardware-backed cloud HSM PQC lags: AWS CloudHSM ML-DSA is in preview, Google Cloud HSM hardware PQC is on the roadmap, and Azure Managed HSM relies on the underlying vendor module (Marvell). Plan migrations around what is GA in your key-protection tier, not just the headline announcement.

Standards binding HSMs & KMS

OASIS PKCS#11 v3.2 (2025) standardizes ML-DSA, SLH-DSA, and ML-KEM mechanisms, giving applications a portable API instead of vendor-specific extensions — a quiet but important enabler for crypto-agility. On the compliance clock, US FIPS 140-2 certificates stop counting for federal procurement after 2026-09-21, which is pushing the FIPS 140-3 + PQC validation backlog noted above. Stateful hash signatures (LMS/XMSS) deserve special care: their security depends on never reusing a one-time key, so state must be managed inside the HSM and never duplicated across replicas or backups — see xmss-lms.html.

China: anti-quantum 密码机

Chinese 密码机 vendors pair internationally standardized PQC with domestic SM compatibility and frequently with QKD-supplied keys. Sansec fields the broadest anti-quantum line — crypto machines, cards, UKeys, gateways, CA, and KMS — and supports both NIST algorithms and domestic candidates (Aigis-enc/sig, LAC), with a disclosed 14.85M RMB R&D commitment. 问天量子's HUST chip-level card and the openHiTLS open-source project (offering ML-KEM/ML-DSA/SLH-DSA) broaden the supply chain, while Jit's 元密一体机 and Sunyard's finance-targeted "量子安全 + 商用密码" show PQC packaged for specific verticals. For the wider vendor and case-study picture, see cn-vendors.html; for the chips beneath these machines, see pqc-hardware.html.

One caveat on completeness: many other 国密 密码机 vendors — 江南天安, 渔翁, 卫士通, 格尔, 数字认证, 信安世纪 and others — are publicly pursuing PQC, but at this snapshot we could not confirm individually dated, shipping PQC products from each. Treat their PQC status as "in progress" rather than delivered until a dated product confirmation appears.

Standards & references

• OASIS PKCS#11 v3.2 (2025) — standardized ML-DSA/SLH-DSA/ML-KEM mechanisms.
• NIST FIPS 203/204/205 and the CMVP/CAVP programs — https://csrc.nist.gov/.
• xmss-lms.html — stateful hash signatures and where state management belongs.
• cn-vendors.html — Chinese PQC vendors and case studies.
• pqc-hardware.html — the chips and IP cores inside these modules.
• side-channels.html / implementations.html — implementation hazards.
• Resources — full standards register