Hardware Security Modules (HSMs)
- Hardware Security Modules (HSMs) are specialized, tamper-resistant devices that generate, manage, and safeguard cryptographic keys while performing internal operations through secure APIs.
- They enforce cryptographic policies by isolating key usage within robust physical boundaries and implementing lifecycle controls, threshold mechanisms, and distributed trust architectures.
- Modern research explores diverse HSM architectures, including cloud-based, enclave-backed, and distributed systems, to merge hardware security with scalable software controls.
Hardware Security Modules (HSMs) are trusted machines that perform sensitive operations in critical ecosystems and keep sensitive credentials and cryptographic keys inside tamper-resistant hardware, so that every operation is done internally through a suitable API and such sensitive data are never exposed outside the device (Focardi et al., 2021). In mainstream practice, they combine a hard physical boundary, tamper resistance/tamper response, secure key storage, controlled key usage, internal trusted buses, authenticated firmware, secure execution and access control (0803.4479). Contemporary research treats the HSM not only as a monolithic appliance, but as a family of architectures spanning cloud-hosted API surfaces, threshold and fleet-based trust splitting, enclave-backed key managers, embedded secure elements, and materials-level security primitives that can supply identity, randomness, or tamper evidence to future secure hardware (Mavroudis et al., 2017, Chakrabarti et al., 2017, Spasojevic et al., 15 Jul 2025).
1. Core definition and security boundary
The defining function of an HSM is controlled cryptographic use rather than raw key exposure. In the standard view adopted across cloud, industrial, and secure-hardware work, an HSM should generate and manage keys, perform cryptographic operations, and store sensitive information in a way that is hard to extract (Amael et al., 2024). The intended security properties are confidentiality of keys, integrity of cryptographic operations, availability of key services, isolation or tamper resistance, and controlled use rather than direct export of the protected material (Shaikh et al., 23 Jul 2025).
This boundary is narrower than a general secure computer and broader than a single cryptographic primitive. An HSM may still sign, decrypt, or unwrap on behalf of an authorized caller, so compromise of the calling application can enable misuse of HSM functionality even when the secret key itself remains non-exportable. That distinction is central to modern HSM research: the catastrophic event is not merely unauthorized computation, but loss of the root secret such that the device’s functionality can be cloned outside the protected boundary (Focardi et al., 2021). For this reason, HSM design is increasingly discussed as a system property, not just a packaging property.
2. APIs, key attributes, and lifecycle control
In deployed systems, the HSM security boundary is mediated by an API, most prominently PKCS#11. PKCS#11 models keys as objects with attributes such as sensitive, extractable, encrypt, decrypt, wrap, unwrap, trusted, and wrap_with_trusted, and decades of work have shown that dangerous combinations of these attributes can reintroduce key-extraction paths at the API level (Focardi et al., 2021). Two classical attack patterns are wrap-then-decrypt and encrypt-then-unwrap: in both cases the hardware boundary remains intact physically, but conflicting roles assigned to keys allow the protected value to be reconstructed outside the device.
A major line of HSM research therefore focuses on lifecycle discipline rather than API restriction. A formally verified cloud configuration preserves full PKCS#11 compliance by separating Security Officers, Key Managers, and Normal Users, and by enforcing that sensitive keys are either non-extractable or can be exported only under trusted wrapping keys; trusted keys are generated fresh in the device, marked trusted only by the Security Officer, and used only for wrap and unwrap during their whole lifetime (Focardi et al., 2021). This approach reflects a general principle: HSM security is not achieved solely by making keys non-exportable, but by constraining which identities can create, mutate, share, wrap, unwrap, and re-import protected objects.
The same issue appears in simplified or low-cost modules. In an FPGA-centered industrial design, for example, the module authenticates use of an RSA private key through a PUF-based check, but decryption occurs on the Jetson Nano after successful authentication; that architecture is explicitly described as an FPGA-based HSM-inspired security module rather than a full-featured conventional HSM (Amael et al., 2024). The distinction is important because an HSM normally keeps key use and key custody inside the same protected boundary.
3. Threshold, quorum, and fleet-based HSM architectures
A conventional HSM concentrates trust in one validated tamper-resistant module. A different research trajectory replaces “trust one chip” with “trust at least one among many diverse chips,” yielding what is explicitly called a backdoor-tolerant architecture (Mavroudis et al., 2017). In Myst, a quorum of commercial secure crypto-coprocessors holds additive shares of a private key, so the aggregate public key is
while the confidence that a quorum is secure is estimated as
The prototype board contains 120 JavaCard secure elements arranged as 40 quorums of 3 cards, and reports less than computational overhead for both decryption and signing, with throughput scaling to 315 ops/sec for decryption and 77 ops/sec for signing when all 40 quorums are active (Mavroudis et al., 2017). In HSM terms, thresholding converts single-package catastrophic failure into a distributed-assurance problem.
A second distributed model appears in SafetyPin, which uses a large fleet of low-cost HSMs for PIN-protected encrypted backups (Dauterman et al., 2020). The client chooses a hidden subset of HSMs as a function of public metadata and the secret PIN, encrypts Shamir shares of the backup key to those HSMs, and later recovers the backup only by contacting the correct subset. The client never explicitly provides its PIN to the HSMs; knowing which HSMs to contact acts as an implicit proof of PIN knowledge. Evaluated on a cluster of 100 low-cost HSMs, SafetyPin reports a recovery time of $1.01$ seconds, and estimates that a deployment handling $1$B recoveries a year would need about low-cost HSMs (Dauterman et al., 2020). This architecture shows that HSM trust can scale with fleet size rather than contract to a few maximally trusted boxes.
These systems change the meaning of HSM assurance. The relevant question is no longer whether one device is perfect, but whether compromise of a small subset, a single supply chain, or a transient management path suffices to recover the protected secret. Threshold cryptography, quorum diversity, puncturing, and distributed logging all become part of the HSM design space.
4. Cloud, enclave, and software-adjacent HSMs
Cloud HSMs expose a different problem: the hardware boundary remains strong, but the surrounding ecosystem is dynamic, API-driven, and identity-saturated. A real-world taxonomy of cloud failures classifies recurring problems as misconfigurations, API exploits, privilege escalation, and multi-tenancy risks, and emphasizes that cloud HSM failures are usually ecosystem failures rather than cryptographic failures (Shaikh et al., 23 Jul 2025). In this setting, IAM roles, temporary credentials, CI/CD secrets, control-plane integrations, and service-to-service trust relationships become part of the effective HSM perimeter.
One response is enclave-backed key management. An SGX-based Barbican crypto plugin places KEK handling, secret encryption, and attestation logic inside an enclave, using remote attestation, mutual attestation, sealing, and tenant-bound authenticated encryption to approximate the function of an HSM-backed Barbican plugin (Chakrabarti et al., 2017). The authors conclude that the design offers “almost the same security guarantees as a hardware HSM” while retaining software-like deployment and scale. In the reported measurements, a single-node SGX Barbican processes 5.28 requests per second versus 5.83 for legacy Barbican, while a 4-node SGX deployment reaches 18.68 requests per second (Chakrabarti et al., 2017). The approximation is functional rather than certifiable: the work does not claim the tamper-resistant packaging or compliance regime of a conventional HSM.
At the lower-cost end, SoftHSM on a Jetson Nano is positioned as a software-based approximation of an HSM for industrial use, with PKCS#11-mediated RSA private-key storage and OpenSSL-based hybrid AES/RSA encryption (Amael et al., 2024). For a 500 MB file, the reported averages are 3.293 s encryption, 0.018 s slot access, and 2.558 s decryption. The paper is explicit, however, that the trust basis is weaker than that of a certified hardware HSM, because the Jetson Nano is a general-purpose embedded platform rather than a dedicated tamper-resistant boundary (Amael et al., 2024).
Mobile and virtualized trust anchors extend the same pattern. A removable SIM-hosted TPM can behave as a small hardware-backed HSM for mobile devices, with on-card key protection, PCR state, sealing, attestation, and measured-boot integration, but it remains closer to a secure-element-hosted TPM than to an enterprise HSM (Chakraborty et al., 2019). Likewise, virtual TPM work shows how a small amount of trusted hardware can anchor many software-maintained states through hash trees or incremental hashing, a design pattern directly relevant to multi-tenant HSM services (Alsouri et al., 2013).
5. Embedded, package-level, and materials-level primitives
Not every hardware-rooted security mechanism is itself an HSM. Some papers contribute secure primitives that can strengthen HSMs without replacing their full function set. A clear example is the magneto-ionic FeCoN platform in “Magneto-Ionic Hardware Security Primitives,” which is explicitly described as not a complete HSM in the conventional sense, but highly relevant to HSM design because it supplies a materials-level primitive for embedded TRNGs, PUF-based identity, anti-counterfeiting, and potentially tamper-evident layers (Spasojevic et al., 15 Jul 2025). Its security value lies in nonvolatile, low-energy, voltage-controlled magnetic states whose probabilistic fingerprints can be enrolled and later distinguished statistically.
Advanced-packaging proposals based on NEMS make a similar move. NEMS-based PUFs, shape memory materials, resonance-based fingerprints, and physical locking or unlocking architectures are proposed as device-level security primitives for physical assurance, tamper detection, and authentication (Kottur et al., 24 Jun 2026). The paper does not provide explicit mathematical equations or quantitative benchmark tables, but it maps these mechanisms directly onto HSM concerns such as hardware root of trust, package intrusion indication, secure activation, and anti-counterfeiting. The implication is that future HSMs may derive some of their strongest guarantees not from one monolithic secure enclosure, but from package-integrated physical effects distributed across die, interposer, substrate, and redistribution layer.
Other work pushes HSM-like capability outward to the edge. The CTC chip for blockchain-based transactive energy is best classified as an embedded secure element and hardware root of trust with HSM-like functions, not as a conventional standalone HSM (Saha et al., 2020). It provides hardware-backed key storage, on-chip signing, proof of origin, and provisioning under the Eco-Secure Provisioning process. Likewise, KLJN-based proposals focus on trusted internal channels between processors, memories, storage devices, and peripherals rather than on a complete HSM blueprint; their contribution is architectural, namely secure inter-chip communication and obfuscatory key storage inside distributed hardware fabrics (0803.4479).
6. Failure modes, misconceptions, and current research frontiers
A persistent misconception is that any hardware-rooted module is therefore an HSM. The current literature does not support that equivalence. FPGA PUF authenticators, SoftHSM on SBCs, SIM-hosted TPMs, magneto-ionic fingerprints, and NEMS package sensors all implement subsets of the HSM problem—identity, randomness, secure release, attestation, or tamper evidence—but often lack the complete combination of secure key vaulting, policy-controlled API use, internal execution, certified packaging, auditability, and lifecycle governance that define a conventional HSM (Amael et al., 2024, Amael et al., 2024, Spasojevic et al., 15 Jul 2025).
A second misconception is that hardware isolation alone is sufficient in cloud deployments. Cloud failure analysis shows that the practical HSM perimeter extends through IAM, APIs, orchestration systems, CI/CD pipelines, control planes, and tenant-isolation mechanisms (Shaikh et al., 23 Jul 2025). The strongest hardware boundary can still be operationally defeated if an attacker gains the privileges needed to invoke key operations through legitimate service paths. For that reason, recent defensive thinking is layered and context-aware: confidential computing, decentralized key management, policy separation, strong auditability, and crypto agility are framed as complements to hardware trust anchors rather than replacements for them (Shaikh et al., 23 Jul 2025).
Research also explores physically unconventional HSM deployments. SpaceHSM places the signing key in a CubeSat and uses orbital inaccessibility as its tamper-resistance mechanism; the satellite generates its own keypair after launch and exposes a narrow signing interface for CA use (Michalevsky et al., 2017). The architecture is HSM-like by function, but its operational envelope is very different: the stated communications budget is enough for one certificate request every 20 seconds, communication is available for about 10 minutes every 90 minutes, and the estimated marginal cost is approximately \$170,000 for one satellite (Michalevsky et al., 2017). This work illustrates a broader point: the HSM concept is portable across very different physical substrates, but every shift in substrate changes the balance among confidentiality, integrity, availability, throughput, cost, and operational trust.
Across these lines of work, the durable conclusion is that an HSM is best understood as a system for enforced cryptographic custody. Tamper-resistant hardware remains central, but modern HSM design increasingly includes formally verified API configurations, threshold trust distribution, attestation-aware cloud services, edge secure elements, and material or package-level primitives that harden identity and tamper evidence. The field’s open problem is not whether hardware matters, but how to compose hardware roots of trust with cloud-scale software, diverse supply chains, and physically heterogeneous deployment environments without collapsing the protection model back into ordinary software key management.