Key takeaways
- An HSM holds a whole private key inside one hardware module; the key is used there and is not exposed to the server around it.
- FIPS 140-3, published by NIST on 22 March 2019, is the reference standard for such modules, with four security levels.
- A validation covers one named module and version. It does not certify a custodian's wider systems or procedures.
- An HSM does not decide whether a transfer should happen. Approval policies, roles and backups still need review.
- Hex Trust states that it keeps private keys in HSMs validated to FIPS 140-3 Level 3.
How a hardware security module works
An HSM is a purpose-built device with its own protected boundary. Keys are generated inside it, used inside it and, in normal operation, never leave it in readable form. A private key is the secret number that authorises a transfer from a blockchain address, so whoever can use the key can move the assets.
The module therefore works as a signing service. A system outside it, such as a custodian's transaction engine, passes in the transaction to be signed. The module checks that the caller is an authorised role, signs inside the boundary and returns only the signature. The network then sees an ordinary signature, indistinguishable from any other.
Protection comes from the hardware and from controls on who may ask it to sign. NIST's FIPS 140-3 lists areas such as physical security, authentication of roles, management of sensitive parameters and self-tests as requirements for a cryptographic module. For the comparison with other key models, read MPC vs HSM vs multisig custody compared.
- Cryptographic module The hardware, software or firmware that performs cryptographic functions inside a defined boundary. An HSM is one kind.
- Key ceremony A documented, witnessed procedure in which keys are generated and backups are written.
- Air-gapped Kept physically disconnected from networks, so a withdrawal needs a person and a procedure.
- Validation Independent testing of a named module against a standard, followed by listing on a public register.
HSMs in digital asset custody
Custodians use HSMs to keep the signing key out of general-purpose servers, where malware or an insider could copy it. A typical flow is: a client proposes a transfer, a policy engine checks it against limits and address lists, approvers confirm, and only then does the HSM sign.
The module is usually one layer among several. A custodian may keep keys for frequently used wallets in connected modules and keys for long-term holdings in air-gapped ones, which is why cold withdrawals can carry service levels counted in hours. Some custodians also combine HSMs with multi-party computation (MPC), keeping each key share inside a module.
Where the key sits is separate from how client assets are divided. Wallet structure is covered in omnibus vs segregated wallets, and the question of whether to hold keys at all in custody vs self-custody for institutions. Regulators set outcomes rather than technologies: Part III of VARA's Custody Services Rulebook covers key generation, storage, backups and collusion risk without prescribing HSM or MPC.
FIPS 140-3 and how HSMs are validated
FIPS 140-3, Security Requirements for Cryptographic Modules, was published by the US National Institute of Standards and Technology (NIST) on 22 March 2019. It provides four increasing levels of security, Level 1 to Level 4, and replaced FIPS 140-2.
Accredited laboratories test modules, and the Cryptographic Module Validation Program (CMVP), run by NIST with the Canadian Centre for Cyber Security, reviews each submission. A validated module appears on a public list with a certificate number, and a validated module stays on the active list for five years, or two for an interim validation. The CMVP also states that FIPS 140-2 certificates move to its historical list after 21 September 2026, so check the status of any older certificate.
Three limits apply. The validation covers one named module and firmware version, not the custodian. It reflects testing at a point in time. And it says nothing about how the module is configured, who administers it or how the policy in front of it is governed. Use the certificate as one piece of evidence and ask for the rest.
Strengths and limits of HSM custody
| Topic | Strength | Limit |
|---|---|---|
| Key exposure | The key is used inside a tamper-resistant boundary, not on a general server. | A whole key exists in one module, so the module and its administration are a concentrated point of risk. |
| Certification | A public, product-level validation scheme that a reviewer can look up. | It covers one module and version, not the custodian's operations. |
| Chain support | Ends in an ordinary signature, so it can reach many chains. | The module must support each chain's signature algorithm, which can need new firmware. |
| Recovery | Backups are written and stored under a documented ceremony. | A restore needs compatible modules, trained staff and time; the vendor becomes part of the risk. |
| Governance | Roles and quorums can be enforced on the device. | Approval policies mostly run off-chain in software, so their quality depends on design and audit. |
Prepared for this guide from the sources listed below. A general description, not a rating of any provider. Last reviewed .
An HSM is a strong control against one class of failure, theft of the key from a server. It is not a guarantee of safety. If one administrator can change the policy and then sign, the hardware cannot help.
How Hex Trust answers on key storage
Hex Trust states that it keeps private keys in HSMs validated to FIPS 140-3 Level 3, and its live trust centre names the vendor as Securosys (read 6 October 2026). The same page describes air-gapped offline tiers, key generation with a true random generator and encrypted backups in several locations.
Gap: these are the company's own descriptions and were not tested for this guide. The certificate number and key ceremony record are not published on the pages read, so request them from the contracting entity. Entities and licences are listed on the About page.
What to ask a custodian that uses HSMs
- Which module and firmware version holds my keys, and what is its FIPS 140-3 certificate number and level? Is the listing still active?
- Who generates keys, where, and can I see the key ceremony record?
- Where are backups kept, how are they protected and when was recovery last tested?
- How many approvers does a withdrawal need, and can one person change the policy and then sign?
- Which wallets sit in connected modules and which in air-gapped ones, and what is the withdrawal time for each?
The wider list is in the crypto custody due diligence checklist, and short answers about Hex Trust are in the Hex Trust FAQ.
FAQ
What does HSM stand for?
HSM stands for hardware security module: a dedicated device that creates, stores and uses cryptographic keys inside a tamper-resistant boundary. In custody, software outside the device sends a transaction in and receives a signature back, while the private key never leaves the module in usable form.
Is an HSM a hardware wallet?
They share the idea of keeping a key in dedicated hardware, but they serve different users. A hardware wallet is a personal device operated by one holder. An HSM is institutional equipment that sits behind a custodian's approval policies, with roles, logging and a validation scheme that a reviewer can look up.
What does FIPS 140-3 Level 3 mean for an HSM?
It means an accredited laboratory tested one named module and version, and it was validated at the third of four security levels in FIPS 140-3, the NIST standard published on 22 March 2019. It does not certify the custodian's wider systems, staff or procedures. Check the certificate number on the NIST validation list.
Can an HSM be hacked?
No device is beyond attack. Validation shows a module met stated requirements when tested, not that it is unbreakable. Weaknesses more often sit around the module: the approval policy, administrator access, firmware updates and backups. Ask how those are controlled and independently tested.
Does Hex Trust use HSMs?
Hex Trust states that it keeps private keys in HSMs validated to FIPS 140-3 Level 3, and its trust centre names the vendor as Securosys. These are the company's own statements. Ask the contracting entity for the module's certificate number and the key ceremony record that applies to your wallets.
Sources
Standards bodies and regulator rulebooks relied on for this guide.
- National Institute of Standards and Technology, FIPS 140-3, Security Requirements for Cryptographic Modules, published 22 March 2019.
- National Institute of Standards and Technology, Cryptographic Module Validation Program.
- Virtual Assets Regulatory Authority, Custody Services Rulebook, version effective from 19 June 2025, Part III.
These pages were last opened on 12 October 2026 for the MPC vs HSM vs multisig guide and were not re-read for this article; check them before relying on them. Statements about Hex Trust come from its live website trust centre, read on 6 October 2026.
This guide is for information only and is not investment advice, legal advice or tax advice. It does not recommend any custodian or any digital asset. Digital assets are volatile, and the risk disclosure for digital asset services sets out the main risks.
Ask how your keys would be protected
Ask institutional sales which module holds your keys, the certificate behind it, the key ceremony record and the approval policy for your account.
Risk warning. Not financial advice. Crypto is highly volatile and may drop in value significantly. You may lose the amounts you invest and your investments do not benefit from any form of financial protection.