An allocator's diligence questionnaire on a digital asset manager or custodian usually asks who can move the assets. The honest answer is rarely a person. It is a hardware boundary, a signing policy spread across several parties, or a set of key shares that no single machine ever assembles into a whole key. Three designs dominate institutional practice: the hardware security module, the onchain multisignature wallet and multi-party computation. They are not interchangeable, and the differences show up exactly when something goes wrong. This is not investment, legal or tax advice.
Where the key actually lives
A hardware security module, or HSM, is a dedicated, tamper-resistant device that generates and stores a complete private key inside its own boundary and signs there, without releasing the key in the clear. NIST's Cryptographic Module Validation Program validates such modules against FIPS 140, and that standard is mid-transition. FIPS 140-3 has been in effect for validation submissions since 22 September 2019, and NIST's transition page gives 22 September 2026 as the date remaining FIPS 140-2 certificates move to the historical list. NIST says it still supports buying and using historical modules for existing systems, and recommends that purchasers review all validated modules that meet their requirements, whichever version they were validated against. A buyer asking whether an HSM is "FIPS-validated" should therefore ask which standard, which level and whether the certificate is active or historical.
An onchain multisignature wallet takes the opposite approach. There is no single private key, only several complete, independent keys, and a smart contract or protocol rule requires a threshold of them to sign before a transaction executes. Safe, formerly Gnosis Safe, is a widely used implementation on Ethereum, and Bitcoin has supported native multisig scripts for years. The policy lives onchain, in the contract or script, not in any one signer's hardware.
Multi-party computation, or MPC, removes the whole key altogether. Rather than splitting an existing key into shares and reassembling it to sign, threshold-ECDSA protocols such as GG18 and GG20 let several parties jointly produce a valid signature for one public key without any party holding the complete private key. NIST published an overview of threshold schemes, NISTIR 8214, in 2019, and on 20 January 2026 published NIST IR 8214C, its first call for multi-party threshold schemes, run by its threshold cryptography project. It is a call for submissions, organised in three phases (previews, packages and analysis), not a finished standard. MPC wallets in commercial use today run on protocols their vendors selected and had reviewed, not on a NIST threshold-signature standard.
How signing policy is enforced, and by whom
An HSM enforces policy inside its boundary: dual control, quorum approval and similar rules can be configured so the module will not bypass them, whatever the surrounding software does. The trust boundary is the box. The application that decides what to ask the HSM to sign sits outside that guarantee.
An onchain multisig enforces policy in public code. The threshold, the signer set and any time-lock can be read by anyone before a transaction executes, which is a real auditability advantage. But the contract sees only signatures, not what each signer believed they were approving. Our threat model for institutional DeFi puts it directly: multisignature approval reduces dependence on one key only when signers, devices, software and verification channels are meaningfully independent.
MPC enforces policy in the coordination protocol and the platform around it. Which parties must take part, from which devices and under which approval workflow is usually configured in the vendor's software rather than in public code. That allows flexibility, including changing participants without an onchain transaction, but the policy is only as auditable as the vendor's logs and attestations.
Recovery, and where each design is still fragile
HSMs concentrate recovery risk in the device and its backups: lose the module, its secure backup and the administrator credentials needed to restore it, and the key is gone. Clustering and key ceremonies mitigate this, but the ceremony itself, who attends and what quorum they need, becomes the thing an institution has to govern.
Multisig depends on signer key hygiene, and a flaw in the enforcing code is severe because the code is public and hard to change. In November 2017 a GitHub user took ownership of an uninitialised library contract that Parity multisig wallets deployed after 20 July 2017 relied on, then triggered its self-destruct function. Parity's post-mortem put the frozen balance at about 513,774 ETH, and contemporaneous legal commentary counted more than 500 affected wallets. The wallets' thresholds were never defeated; the shared library they depended on was left open.
MPC recovery depends on the vendor's backup and share-refresh design, which an institution usually cannot fully inspect. CVE-2023-33241 shows why the mathematics of a scheme and its implementation are separate questions. Fireblocks researchers published it on 9 August 2023 after a 90-day disclosure process, begun on 5 May 2023, involving more than ten wallet providers, blockchains and libraries. Implementations of GG18 and GG20 did not check counterparties' Paillier public keys for small prime factors; in the worst case Fireblocks described, an attacker could extract the key after as few as 16 signatures. Libraries it named include BNB Chain's tss-lib, Safeheron's, ZenGo-X's, Apache Milagro MPC and BitGoJS. The protocols' design goal held; the deployed code's validation of an untrusted input did not.
Vendor dependence and auditability
HSMs come with the most established external validation of the three: FIPS 140 is a government-run programme, and common interfaces such as PKCS#11 make changing vendors disruptive but familiar. Validation covers the module's cryptographic implementation and physical security. It says nothing about who is authorised to invoke the module, which is a governance question.
Onchain multisig is the easiest to check from outside, in one specific sense: the signer set, the threshold and every past transaction are visible to a counterparty, an auditor or a regulator without the custodian's cooperation. Our piece on what proof of reserves proves sets out the limit of that: a ledger can show assets and control at an address, not who legally owns them. And what is public is the signed transaction, not the screen each signer relied on, as the Bybit case below shows.
MPC is the hardest to check from outside as typically deployed. No onchain contract states the threshold, so an outside party relies on the vendor's account of its configuration, key generation and share refreshes. Institutions address this as they would any vendor-dependent control, through SOC 2 reports, penetration test summaries and contractual audit rights, none of which gives the direct visibility an onchain threshold does.
Known failure modes, dated
Three incidents sit at different layers, and none was publicly attributed to a break of the underlying signature cryptography.
- Multisig as a label, not a guarantee. In August 2016 about 119,756 bitcoin were stolen from Bitfinex, even though the exchange secured the funds with BitGo's multisignature service. Bitfinex never published a full technical post-mortem, so the precise path is not public record. The lesson is narrower: using multisig says nothing on its own about how the keys and approvals around it are operated.
- A threshold held by fewer parties than it appears. On 23 March 2022 attackers took about 173,600 ETH and 25.5 million USDC from the Ronin bridge, which needed five of nine validator signatures. Ronin said the attacker gained control of four Sky Mavis validators and a validator run by Axie DAO. The fifth signature came through an allowlist permission, granted during a late-2021 arrangement to distribute free transactions, that was never revoked. Nine signers were only as independent as the parties operating them and the permissions left in place.
- The interface, not the signature. In February 2025 more than $1.4 billion in assets, including 401,347 ETH, were drained from a Bybit cold wallet. According to NCC Group's analysis of 10 March 2025, malicious JavaScript was injected into the Safe{Wallet} interface through a compromised developer machine; Bybit's signers, at least three of whom had to approve, signed valid data that had been altered to replace the wallet's implementation with the attacker's contract. The multisig worked as designed. What failed was the signers' ability to confirm that what they saw was what they signed. Our piece on quantum risk and the custody key covers a different, slower threat to the same signing keys.
What this means for diligence
None of the three designs is safer in the abstract; each moves the point of failure somewhere specific, so asking only "HSM, multisig or MPC?" misses the point. The useful questions are specific. For an HSM: who can invoke it, under what quorum, and against which FIPS 140 version and level is it validated, with an active or historical certificate. For a multisig: are the signers, their devices and their verification channels independent of each other and of the interface that renders transactions. For MPC: how are key generation and share refreshes run, has the implementation been independently reviewed since CVE-2023-33241, and what do the SOC 2 and penetration-testing scopes cover. Our review of who actually holds institutional custody explains why none of these designs settles who owns the assets if a custodian fails; that is resolved by insolvency law and contract, not technology.