Key takeaways
The three models answer one question in different ways: who, or what, must agree before a transaction is signed.
- An HSM holds a whole key inside one hardware module. FIPS 140-3, published by NIST on 22 March 2019, is the standard such modules are tested against, at one of four security levels.
- MPC splits signing across several parties, so no complete key sits in one place. NIST published its call for threshold schemes on 20 January 2026; its work so far consists of reports, not a standard.
- Multisig is a rule that the blockchain enforces. On Bitcoin, BIP 11 proposed M-of-N transactions as a standard type in 2011, and its status today is Deployed.
- No model removes custody risk. Approval governance, staff controls and tested recovery matter as much as the key technology.
- Hex Trust states that it keeps keys in HSMs validated to FIPS 140-3 Level 3.
This guide is for information only and is not investment advice. It belongs to a series written for risk and technology reviewers: see more custody guides in Insights.
What each model is
HSM, MPC and multisig are three ways to control a private key, the secret number that authorises a transfer from a blockchain address. Whoever can use the key can move the assets. Each model is a way to make sure that no single person or machine can use it alone.
Hardware security modules (HSM)
A hardware security module is a dedicated device that creates, stores and uses keys inside a tamper-resistant boundary. In HSM custody the whole key exists, but only inside the module: software outside sends a transaction in and receives a signature back. The reference standard is FIPS 140-3, Security Requirements for Cryptographic Modules, which the US National Institute of Standards and Technology (NIST) published on 22 March 2019 to supersede FIPS 140-2. It provides “four increasing, qualitative levels of security”, Level 1 to Level 4.
Multi-party computation (MPC)
Multi-party computation lets several parties produce one signature together while each holds only a share of the key. Custody uses the threshold form, written t-of-n: any t of the n share holders can sign, and fewer cannot. NIST's Multi-Party Threshold Cryptography project describes threshold schemes as applying MPC principles to achieve “a secure distribution of trust” in cryptographic operations. The NIST Threshold Call (NIST IR 8214C) adds the mechanics: the operation is computed in a distributed way while the private key stays secret-shared across the parties. The network sees one ordinary signature and cannot tell that several parties made it.
Multisignature (multisig)
Multisig is a rule, enforced by the blockchain itself, that a transfer needs signatures from m of n separate keys. Each key is a whole key with its own holder. On Bitcoin, BIP 11, “M-of-N Standard Transactions”, assigned on 18 October 2011, proposed such transactions as a standard type, at first for up to three keys. Its two motivating cases were a wallet protected by a second signer and a three-party escrow. On account-based chains such as Ethereum, multisig is usually a smart-contract wallet, so the rule lives in contract code.
- Signature The proof, made with the private key, that a network checks before it accepts a transaction.
- Threshold (m-of-n) The number of approvals needed out of the number that exist. 2-of-3 means any two of three.
- Key share A piece of a key that reveals nothing alone. Each MPC party holds one.
- Wrapped key A key stored encrypted under another key, so that a copy is useless without the wrapping key.
- Key ceremony A scripted, witnessed session in which keys are generated, backed up or restored.
- Air gap The state of a system that has no network connection to the outside.
How a transaction is signed in each model
At the moment of signing, the key material sits in one device (HSM), in several shares (MPC) or in several whole keys (multisig). The figure shows all three with an illustrative 2-of-3 threshold. The steps before signing look alike in every model: a user proposes a transfer, a policy engine checks it against limits and address lists, and the approvers confirm.
Worked example: one withdrawal under three models
The figures are illustrative and describe no real client or custodian. A fund asks to withdraw 50 BTC to an address on its allowlist. Its policy needs two of three named approvers.
- HSM. Both approvals reach the policy engine, which passes the transaction to the module. One key signs once. Keys used: 1. Signatures on-chain: 1.
- MPC, 2-of-3. The client, the custodian and a backup provider hold one share each. Two of them run the signing protocol. Shares used: 2. Signatures on-chain: 1.
- Multisig, 2-of-3. Three keys are named in the wallet's script. Two holders sign in turn. Keys used: 2. Signatures on-chain: 2, and the 2-of-3 rule can be read on-chain.
The arithmetic is the same for any m-of-n scheme. An attacker needs m shares or keys, and the scheme survives the loss of n minus m. So 2-of-3 tolerates one lost key and needs two compromises; 3-of-5 tolerates two and needs three.
HSM vs MPC vs multisig: comparison table
The three models differ most on two points: what an independent party can certify, and where the approval rule is enforced. The table sets them side by side on eight questions. Products differ, so read each cell as a prompt for a question to the custodian.
| Question | HSM | MPC | Multisig |
|---|---|---|---|
| Where the key lives | One whole key inside a hardware module, with wrapped backups elsewhere | Shares held by separate parties; the full key is not assembled to sign | Several whole keys, each with its own holder or device |
| What an attacker must compromise | The module, or the approval path that tells it to sign | A threshold of share holders at once, or the protocol software | A threshold of key holders, or the wallet script or contract |
| Independent certification | Module validation under FIPS 140-3, listed by NIST's validation programme | No equivalent module standard yet; NIST standards work is in progress | The chain enforces the rule; the storage of each key needs its own assurance |
| Chain and token coverage | Any chain whose signature algorithm the module supports | Any chain whose signature algorithm has a threshold protocol | Only chains that support multisig natively or by smart contract |
| Signing speed | One operation; delay comes from approvals and air-gap procedures | Several message rounds; the parties must be online together | Signers act one after another; transactions are larger |
| Backup and recovery | Wrapped key backups in separate sites; key ceremonies | Share backups; ask how a lost share is replaced | Survives the loss of n minus m keys; a new signer may mean a new wallet |
| Policy enforcement | Off-chain, in the custodian's policy engine | Off-chain, by each party before it contributes its share | Quorum on-chain; finer rules off-chain or in contract code |
| Typical failure modes | Hardware and vendor dependency; weak approval governance | Protocol or implementation flaws; shares that are not independent | Script or contract errors; a scheme that is visible on-chain |
Compiled from FIPS 140-3, the NIST validation-programme and threshold-cryptography pages and BIP 11, opened on . A general description, not a rating of any provider.
Certification and standards: what can be verified independently
Only the HSM model has a public, product-level validation scheme that a reviewer can look up; MPC and multisig are verified in other ways. That difference is about evidence, not about which model is stronger. No standard certifies any of the three as secure.
FIPS 140-3 security levels
FIPS 140-3 places a cryptographic module at one of four levels, and a validation applies to one named module and version. The standard covers eleven requirement areas, among them physical security, authentication of roles, management of sensitive parameters and self-tests. Each level adds its own requirements to those common to all modules; the detailed text sits in ISO/IEC 19790:2012, as modified by NIST's SP 800-140 documents.
Independent accredited laboratories do the testing, and the Cryptographic Module Validation Program (CMVP), which NIST runs with the Canadian Centre for Cyber Security, reviews each submission. 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 ask a custodian for the certificate number, then check the module name, the firmware version, the level and the status on the CMVP list.
A Level 3 certificate describes the module. It says nothing about the approval process around it.
The limit of any hardware certification
Where MPC standards stand
MPC has no module-level certification that matches FIPS 140-3: NIST is still gathering and studying threshold schemes. Its threshold-cryptography project lists its main publications so far as internal reports. The Threshold Call was published on 20 January 2026 and asks for public submissions, with preview rounds running through 2026. Until a standard and a validation programme exist, assurance for an MPC product rests on other evidence: the published protocol and its security proof, independent code audits, penetration tests and the provider's SOC reports. Some designs keep each share inside an HSM or a secure enclave. The hardware may then hold a certificate while the protocol does not.
Multisig as an on-chain rule
Multisig needs no certificate for the rule itself, because the network's consensus enforces it and anyone can read it on-chain. What needs review is everything around the rule. On Bitcoin the script is short, and its standard form goes back to BIP 11 in 2011. On smart-contract chains the wallet is code, so its audit history and upgrade rights matter. In both cases each of the n keys still sits somewhere, on a hardware device, in an HSM or in software, and that storage needs its own assurance. Regulators treat multisig as one tool among several: Part III of the Custody Services Rulebook of Dubai's Virtual Assets Regulatory Authority says custodians should consider multi-signature approaches where appropriate.
Operational trade-offs
Each model pays for its protection in speed, coverage or complexity, and each has at least one clear drawback. The differences show up in four parts of daily operations.
Speed and availability
HSM signing is a single operation, so speed depends on the approval path and on how isolated the module is. An air-gapped module needs a person and a procedure, which is why cold withdrawals carry service levels counted in hours. MPC needs its parties online at the same moment and exchanges several rounds of messages, which suits frequent, automated transfers. Multisig lets signers act one after another, even days apart, at the price of a larger transaction and, on some chains, a higher network fee.
Chain and token coverage
HSM and MPC custody reach the most chains, because both end in an ordinary signature that a network cannot tell from any other. The limit is the signature algorithm: the module, or the threshold protocol, must support the one each chain uses. A chain with a new algorithm can mean new firmware for an HSM or a new protocol for MPC. Multisig depends on the chain. Bitcoin supports it in its script language, with a standard form proposed in 2011. Other chains offer it natively, through smart contracts or not at all, and each version is separate work to audit.
Recovery and key ceremonies
Recovery is where the three models ask for the most different kinds of effort. HSM custody relies on key ceremonies in which keys are generated and wrapped backups are written, then stored on separate sites. Its drawback is hardware dependency: a restore needs compatible modules, trained staff and time, and the vendor becomes part of the risk. MPC backs up shares, not keys. Its drawback is complexity, since the protocol and its implementation are hard to review. Multisig survives the loss of n minus m keys by design, but replacing a signer often means moving the assets to a new wallet. Whatever the model, VARA's rulebook requires key and seed backups to be kept in a separate location from the primary, with encryption at least as strong.
Approval policies and segregation of duties
The key model decides how a signature is produced; the approval policy decides whether it should be. A policy sets who may propose a transfer, who must approve it, which addresses are allowed and what limits apply. In HSM and MPC custody these checks run off-chain, in the custodian's software, so their quality depends on design and audit. Multisig puts the quorum on-chain, but a finer rule such as a daily limit still runs off-chain unless a smart contract encodes it. Segregation of duties applies to all three. VARA's rules ask custodians to weigh whether the people who create a key should be barred from signing with it.
What none of the three models removes
No key model removes custody risk: each one moves the weak point from the key to the people and software around it. Four risks survive every architecture.
- Insider collusion A quorum protects against one bad actor, not against enough of them acting together. VARA's rulebook requires custodians to assess and mitigate collusion between authorised signatories in recurring risk assessments.
- Weak approval governance If one administrator can change the approver list or the address allowlist, the quorum is decoration. Ask who can change a policy and how many people that takes.
- Software supply-chain faults Wallet software, firmware, signing libraries and smart contracts are code that someone else wrote. A flaw or a tampered update reaches the signing path in any model.
- Operational error Wrong addresses, mishandled backups and untested recovery plans cause losses without any attacker.
Insurance, the segregation of client assets and the legal structure of the custodian also sit outside the key model. The crypto custody due diligence checklist covers those points, and a companion guide explains how custody is regulated in Dubai, Singapore and Hong Kong.
How Hex Trust applies HSM custody
Hex Trust states that it keeps private keys in hardware security modules validated to FIPS 140-3 Level 3, and it names the vendor: Securosys. The points below come from the company's public pages. They are its own descriptions and were not tested for this guide. The service is described in full under Hex Trust institutional crypto custody.
- Module validation
- FIPS 140-3 Level 3
- HSM model
- Securosys Primus X200
- Key generation
- True random generator, in the HSM
- Keys at rest
- Always wrapped
- Vault environment
- Air-gapped, with data diodes
- Encrypted keys
- Several vaults, different locations
- Wallet tiers
- Hot, warm and cold
- Approval quorum
- m-of-n, sizes not published
- Cold-wallet withdrawals
- 2-hour SLA
From the live trust centre, storage arrangement and Hex Safe pages, read on .
In the terms of this guide, that is a whole-key HSM model with physical isolation. The storage arrangement page adds that keys are not exposed in clear text, and that the air-gapped vaults connect to the outside through data diodes, which pass data in one direction only. Access to the vaults that hold the encrypted keys needs more than one approval.
The Hex Safe page names the module model, Securosys Primus X200, and describes two vaults. Safe Vault is listed with near-instant access and an m-of-n approval quorum. Safe Plus Vault is listed as offline cold storage with access in under two hours, and it adds an authorisation quorum from Hex Trust's operations team. The same page gives a “2-hour SLA for cold wallets and near instant for warm wallets”.
Signing follows the first lane of the figure: a client starts a transaction, it passes several approval stages, and the module signs it. As described, each quorum is an approval rule in front of the module. It is not a split of the key, as in MPC, or an on-chain rule, as in multisig.
The trade-offs set out above apply here as they do to any HSM custodian: the model depends on specific hardware and on physical procedures, and cold withdrawals take hours by design. The pages read for this guide do not give the certificate number of the modules, the number or location of the vaults, or the size of the approval quorums. They do not say whether MPC or on-chain multisig is used for any asset. Nor do they carry a named expert's account of why the company chose this model.
The trust centre also lists a SOC 2 Type II report completed in December 2023 by AssuranceLab. Reports and certifications are set out under Hex Trust security architecture and reports. Which company would hold your assets depends on where you are: see the page about Hex Trust and its legal entities.
From the key model to the custody service
The service page sets out segregation, key storage, insurance and the licensed companies that hold client assets.
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.
Questions to ask a custodian about key management
Ten questions cover most of what a key-management review needs, whatever model the custodian uses. Ask for documents and not descriptions: a certificate number, an audit report, a test record.
- Where and how is each key or share generated, and who is present?
- Does a whole key ever exist outside validated hardware, even briefly?
- What exactly is certified, by whom, and under which certificate number and version?
- Which signing algorithms run inside the validated module, and in which mode?
- Who can approve a transfer, and who can change the approver list, the limits or the allowlist?
- How many people would have to collude to move assets, and what evidence supports that number?
- Where are backups kept, how are they encrypted and who can reach them?
- When was recovery last tested from backups alone, and how long did it take?
- What happens to my assets if the hardware vendor, a share holder or a co-signer stops operating?
- What has changed in the key architecture since the last independent audit?
To put these questions to Hex Trust, speak to the custody team.
FAQ
Is MPC safer than HSM custody?
Neither is safer in general: the answer depends on implementation and governance. An HSM protects a whole key inside hardware that can be validated under FIPS 140-3. MPC removes the single place where a key exists, but it adds protocol and software complexity and has no equivalent certification yet. In both models the approval process is as exposed as the cryptography, so review it with the same care.
Can HSM and MPC be combined?
Yes. The models are not exclusive. A custodian can keep each MPC share inside an HSM, use HSMs for cold storage and MPC for frequent transfers, or place HSM-held keys behind an on-chain multisig rule. Each layer adds protection and also adds parts that can fail, so ask which model protects which wallets and what evidence exists for each layer.
Do institutions still use multisig?
Yes. Multisig remains in use where the chain supports it well: on Bitcoin, where BIP 11 proposed M-of-N transactions as a standard type in 2011, and in smart-contract wallets on other chains. VARA's custody rulebook tells Dubai custodians to consider multi-signature approaches where appropriate. The limits are uneven support across chains and a signing scheme that is visible on-chain.
What does FIPS 140-3 Level 3 mean?
It means that a cryptographic module was tested by an accredited laboratory and validated at the third of four security levels in FIPS 140-3, the NIST standard published on 22 March 2019. The validation covers one named module and version and appears, with a certificate number, on the list of the Cryptographic Module Validation Program. It does not certify a custodian's wider systems or procedures.
Does the key model change insurance or licensing?
Not directly. Licensing rules set outcomes and do not name a key technology: Part III of VARA's Custody Services Rulebook, in the version effective from 19 June 2025, covers key generation, storage, backups and collusion risk without prescribing HSM or MPC. Insurance terms are agreed policy by policy, so ask whether cover depends on a storage method and read the exclusions.
Sources
Standards, protocol documents and rulebook pages opened for this guide, with the date each one was read.
- NIST, FIPS 140-3: Security Requirements for Cryptographic Modules, published 22 March 2019, opened .
- NIST, Cryptographic Module Validation Program: overview and transition dates, opened 12 October 2026.
- NIST, Multi-Party Threshold Cryptography project: overview and publications, opened 12 October 2026.
- NIST, NIST IR 8214C: NIST First Call for Multi-Party Threshold Schemes, January 2026, opened 12 October 2026.
- Bitcoin Improvement Proposals, BIP 11: M-of-N Standard Transactions, by Gavin Andresen, assigned 18 October 2011, status Deployed, opened 12 October 2026.
- VARA, Custody Services Rulebook, version effective from 19 June 2025, opened 12 October 2026.
- VARA, Custody Services Rulebook, Part III, section C: VA Wallet Management, opened 12 October 2026.
Statements about Hex Trust come from three pages of the live website, read on the same day: the trust centre (/trust-center), the digital asset storage arrangement (/digital-asset-storage-arrangement) and the Hex Safe page (/hex-safe).
This guide is for information only and is not investment advice, legal advice or a security assessment of any provider. It describes key-management models in general terms. Digital assets are volatile, and no custody model removes the risk of loss: see the risk disclosure for digital asset services. Check every statement about a custodian against its own documents before you rely on it.