Custody Architecture Risk: MPC vs. Multisig vs. HSM Attack Surface Tradeoffs

HSMs are best understood in one of two roles: as a standalone signer holding a complete private key, or as a hardened component inside a multisig or MPC signing path. In either role, an HSM protects the key material. It does not decide whether a transaction should be signed. Anyone, or any service, that can authenticate to the HSM can use the key, so the real perimeter is the application layer and the credentials that call it.

The trust assumptions are also easy to overlook. You are relying on the vendor's supply chain, firmware integrity, certification scope, and the procedures around administrator quorum cards, backups, and key export. Geographic redundancy is bounded by physical hardware, and support for the curves digital assets need (secp256k1, Ed25519) still varies by vendor and firmware version.

A multisig wallet requires M of N independent keys to authorize a transaction, and the blockchain itself enforces the threshold. That is a clear improvement over any single signer: compromising one key is not enough, and the policy is auditable by anyone. The tradeoffs are that the policy is publicly visible, signer rotation requires an on-chain transaction, and implementation differs by chain. On EVM networks, multisig is a smart contract, which adds contract logic, upgrade paths, and module permissions to the attack surface. Recent large losses have also shown that multisig is only as strong as what signers see: if the signing interface is compromised, a quorum of honest signers can approve a malicious transaction.

With MPC, the private key is never assembled. Key shares are generated through distributed key generation (DKG) and combined only inside a signing protocol, producing a standard signature that works on almost any chain. Assuming the DKG and signing protocols are correctly implemented and independently audited, MPC is in most cases the most secure of the three. It also offers the best balance between always-on hot access and cold isolation, because shares can be spread across separate cloud tenants, availability zones, providers, and offline environments. Key refresh is a further advantage: if a share is suspected to be compromised, the remaining parties can reshare and invalidate it without changing the on-chain address, which is a significant benefit in disaster recovery.

That conditional matters. Published research in recent years has shown practical key-extraction attacks against flawed threshold signature implementations, often due to missing proofs or parameter validation rather than broken mathematics. MPC also moves policy off-chain and into an orchestration layer, so the coordinator and policy engine become critical components in their own right.

Figure 1. Where the key lives, and where the attacker goes instead. Red markers show the primary attack surface for each design. In all three, the most practical attacks target the systems that request and approve signatures rather than the key itself.

MPC's advantages come with higher operational complexity and cost: distributed infrastructure, share backup and recovery procedures, protocol upgrades, and specialist staff or a vendor relationship. For smaller organizations with modest assets under management, a well-governed multisig with hardware-backed keys is often the more proportionate choice. As assets, transaction volume, and regulatory exposure grow, the availability and recovery benefits of MPC tend to justify the overhead.

Figure 2. Tradeoffs across security, availability, and operational complexity. Ratings are relative and assume a competent implementation of each design.

In practice, the strongest institutional designs combine these primitives. MPC shares are frequently protected inside HSMs or trusted execution environments, and some large custodians pair an MPC hot and warm tier with offline cold custody for long-term reserves, so that day-to-day availability never requires exposing the bulk of assets.

MPC users also need to decide whether they run every node themselves or rely on a counterparty, such as an infrastructure provider like DFNS or Blockdaemon, to hold one signing share. Either can be sound, but a co-signer model raises specific questions. Can the provider sign on its own, or only contribute to a threshold? Can it block signing, creating an availability dependency? What happens if the relationship ends; can you reshare away from the provider without moving funds? And what are the provider's insider, jurisdictional, and incident response controls?

Every architecture eventually reduces to the same pipeline: a transaction is requested, checked against policy and sanctions screening, shown to approvers, approved, signed, and broadcast. The signer is only one step. Transaction screening and governance must be enforced before signing, and in MPC designs each signing node should ideally validate policy independently rather than trusting a single coordinator. Above all, approvers must see what they are actually signing. When approvers confirm an opaque hash or a description generated by a compromised interface, no choice of key technology will save them.

Figure 3. The signing pipeline. Choosing HSM, multisig, or MPC changes step 5. Steps 1 through 4, especially “what you see is what you sign,” determine whether a legitimate quorum can be tricked into signing a malicious transaction.

There is no universally correct answer, but there is a defensible default. Single signers, including a lone HSM, should be the exception. Multisig is the right floor for organizations that want strong guarantees with low operational overhead. MPC is the strongest posture for institutions that need high availability, multi-chain coverage, and clean disaster recovery, provided its implementation is verified rather than assumed. Whatever you choose, the controls around the signer deserve as much scrutiny as the signer itself.

Halborn reviews custody architectures end to end, from DKG and threshold-signing implementations to key ceremonies, policy engines, co-signer arrangements, and signing interfaces.