Client Portal
Access your security dashboard and reports
Hardware Security Modules represent the physical instantiation of trust—tamper-evident boundaries within which cryptographic operations occur with assurance levels unattainable in general-purpose computing environments. The transition to FIPS 140-3 fundamentally alters validation requirements.
On September 21, 2026, all FIPS 140-2 certificates will transition to the NIST Historical List. Federal agencies and contractors will be prohibited from procuring cryptographic modules without FIPS 140-3 validation. Organizations must inventory existing HSM deployments and plan migration paths.
Key changes in FIPS 140-3: Fifth "control output" interface requirement, enhanced periodic self-testing, CVE tracking obligations, and prohibition of RSA PKCS#1-v1.5 padding for decrypt/unwrap operations.
An HSM's security assurance derives from the physical-logical boundary—a tamper-evident enclosure wherein cryptographic keys exist only in plaintext form. This boundary instantiates what Anderson and Kuhn termed "tamper resistance" in their foundational 1996 work, distinguishing between tamper-evidence (detection of intrusion), tamper-resistance (prevention of intrusion), and tamper-response (active countermeasures such as key zeroization).
The formal security model for HSMs derives from Yao's garbled circuits and subsequent work on secure multi-party computation (MPC). Modern threshold signature schemes—wherein k of n parties must collaborate to produce a valid signature—extend these foundations to distributed key management architectures resistant to single points of compromise.
The transition from FIPS 140-2 to FIPS 140-3 (ISO/IEC 19790:2012) introduces structural changes that impact both HSM selection and deployment architecture. The new standard's fifth interface— control output—enables the module to indicate operational state changes to external systems, facilitating automated monitoring and incident response.
Perhaps most significant for cryptographic architects: FIPS 140-3 explicitly prohibits RSA PKCS#1-v1.5 padding for key transport (decrypt/unwrap) operations, mandating OAEP or equivalent. Legacy systems relying on PKCS#1-v1.5 key wrapping must be redesigned.
| Vendor | Product | Level | Certificate | Notes |
|---|---|---|---|---|
| Thales | Luna K7 (A790) | Level 3 | #4684 | First FIPS 140-3 Level 3 HSM (April 2024) |
| AWS | CloudHSM hsm2m.medium | Level 3 | #4703 | Cloud-native, single-tenant |
| Entrust | nShield 5 | Level 3 | #4892 | August 2024 validation |
| IBM | Hyper Protect Crypto | Level 4 | Pending | Only cloud HSM targeting Level 4 |
Key ceremonies represent the ritualized instantiation of cryptographic trust—procedural safeguards ensuring that key generation occurs under conditions of witnessed integrity. The DNSSEC root signing ceremony, conducted quarterly by ICANN at geographically separated facilities, exemplifies the most rigorous ceremony design in production use.
Our ceremony design methodology draws from the formal verification work of Abadi and Needham on authentication protocols, adapted to physical key management contexts. Each ceremony is structured as a finite state machine with explicit pre-conditions, invariants, and post-conditions—enabling formal reasoning about security properties.
Single-HSM architectures represent single points of cryptographic failure—the physical compromise of one device enables complete key extraction. Threshold signature schemes distribute trust across n participants such that any subset of k participants can produce valid signatures, but fewer than k participants learn nothing about the key.
The theoretical foundations trace to Shamir's Secret Sharing (1979) and were extended to threshold signatures by Desmedt and Frankel (1990). Modern implementations leverage Distributed Key Generation (DKG) protocols that generate keys collaboratively without any party ever possessing the complete key material.
The NIST Multi-Party Threshold Cryptography (MPTC) Project published NISTIR 8214C Second Public Draft in March 2025, with the MPTS 2026 Workshop scheduled for January 2026. This standardization effort encompasses threshold schemes for existing NIST primitives (RSA, ECDSA) and emerging post-quantum algorithms (ML-DSA, ML-KEM).
Our threshold implementations align with the NIST reference architecture while incorporating practical considerations for enterprise deployment: HSM heterogeneity (multi-vendor), network partition tolerance, and byzantine fault detection.
Our cryptographic engineers assess your HSM deployment against FIPS 140-3 requirements and design migration paths before the September 2026 deadline.
Tell us about your security requirements. We respond within 24 hours.
Access your security dashboard and reports