Executive Summary

Three findings drive this assessment.

Board members should be asking: can we reconstruct, for any historical transaction, the full approval chain that authorized it? If the answer depends on a vendor’s word, the architecture is not done.

Technology Overview

The three architectures answer the same question — who can move the assets? — in structurally different places. Multisig answers it on-chain. MPC answers it inside a cryptographic protocol. HSM-backed single-key answers it in hardware procurement. Everything else about their risk profiles follows from that placement.

On-chain multisignature

A multisig wallet is a smart contract (or native script, on Bitcoin) that requires M of N independent signatures before executing a transaction. Each signer holds a complete, independent private key. The quorum policy — 3-of-5, 4-of-7 — is written into the contract and visible to anyone.

That visibility is the point and the problem. A DAO treasury can prove to token holders that no single founder can drain it. But the same explorer page tells an attacker exactly which N addresses to phish, and how many they need. The enforcement record around bridge and treasury compromises tells a consistent story: attackers did not break the multisig math, they harvested enough signer keys — or compromised the front-end the signers trusted — to meet the quorum legitimately. The February 2025 Bybit theft is the canonical case: $1.5B moved, attributed by the FBI to North Korea’s TraderTraitor operation, after the signing interface was compromised and the quorum approved what it was shown^[4].

Multisig is also chain-specific. An EVM Safe deployment, a Bitcoin P2WSH script, and a Cosmos multisig are three different implementations with three different audit surfaces. Your compliance team inherits one policy-enforcement codebase per chain.

Multi-party computation (MPC)

MPC threshold signing splits the private key into shares such that the complete key never exists — not at generation, not at signing^[5]. A threshold of share-holders runs an interactive protocol and emits one ordinary signature. On-chain, an MPC wallet is indistinguishable from a single-key wallet.

Three operational consequences follow. Signing policy lives off-chain in the coordination layer, so it can be changed without an on-chain migration. One architecture covers every chain that uses a supported curve. And there is no public quorum for an attacker to enumerate — but also no public quorum for a stakeholder to verify. The gray zone here is exactly that trade: MPC moves the policy from the chain into vendor software, and your assurance over that software becomes the load-bearing control.

HSM-backed single key

The traditional model: one private key, generated and held inside a hardware security module validated to FIPS 140-3^[1], with signing exposed through an authenticated API. The cryptographic boundary is excellent. The governance boundary is whatever you build around the API — and that is where this architecture concentrates its risk. One credential set, one device cluster, one operations team.

Security Analysis

Here’s what most compliance teams get wrong about custody security: they rank architectures by cryptographic strength, when the loss events that actually materialize are governance failures. We tier the failure modes accordingly.

Tier 1 — failure modes that actually drain wallets

Authorization compromise. An attacker who controls enough approval surface — signer laptops, the MPC coordination service’s admin plane, the HSM’s API credentials — moves funds through the front door. This is the dominant institutional loss pattern across the incidents we have analyzed — Bybit’s $1.5B loss ran through compromised signing infrastructure, not broken cryptography^[4] — and it is architecture-independent. MPC and multisig raise the number of surfaces an attacker must control; neither eliminates the pattern. I’ve seen this fail when an institution ran a textbook 3-of-5 multisig whose five signers all approved from the same managed-laptop image — one endpoint exploit was, functionally, five.

Policy-layer manipulation. The signing policy is enforced somewhere: a smart contract, a vendor’s policy engine, an internal approval service. Whoever can change the policy can bypass it. Multisig at least makes policy changes public on-chain. MPC policy changes happen inside vendor software — if your contract does not guarantee you an immutable policy-change log, you cannot reconstruct what your own controls were on a given date.

Tier 2 — serious, less frequent

Key-generation ceremony defects. A bad ceremony undermines everything downstream. For MPC, demand evidence that shares were generated via distributed key generation, never assembled, and that the ceremony was witnessed — the CryptoCurrency Security Standard’s key- and wallet-generation aspects give you an auditable checklist to demand it against^[6]. For HSM, FIPS 140-3 validation^[1] covers the module, not your procedure around it; NIST’s key-management lifecycle guidance — generation through destruction — is the benchmark for the procedure itself^[7].

Insider collusion below threshold visibility. M-of-N thresholds are calibrated assuming independent signers. Organizational reality — one team administering all signer devices, one vendor operating two of three MPC nodes — quietly collapses N. Count administrative domains, not key shares.

Tier 3 — monitor, do not over-invest

Cryptographic breaks of the underlying schemes, and exotic protocol-level MPC attacks. Real research exists on threshold-protocol vulnerabilities — Aumasson and Shlomovits demonstrated practical attacks on deployed threshold-signature wallets, including one exchange’s cold-wallet implementation^[8] — and vendor patch latency is worth tracking. But as of June 2026 we are aware of no institutional loss attributable to a break of correctly-implemented threshold cryptography. Spending board attention here while signer endpoints run unmanaged is a misallocation we still see in due-diligence reviews.

Comparative Evaluation

We score the three architectures against the five factors that decide real procurements. Weights reflect what we see driving institutional outcomes — security of the authorization path counts double, because that is where losses happen.

5-Factor Comparison

Two scores deserve defense. MPC’s policy auditability is marked conditional, not strong — the platform can produce excellent evidence, but only if your contract obligates the vendor to immutable policy-change logs and ceremony attestation. We have reviewed MPC deployments where neither was contractually available, which converts the architecture’s biggest advantage into its biggest assurance gap. And multisig’s poor agility is structural: rotating a compromised signer or changing quorum is an on-chain transaction, sometimes a full treasury migration, and during an active incident that latency is painful.

Recommendation

For a regulated institution building custody in 2026: MPC-first, with key shares held in FIPS 140-3 validated hardware^[1], split across at least two administrative domains, and contractual rights to ceremony evidence and immutable policy logs. This is the only configuration that scores well on both the security and the evidence dimensions that MiCA Article 75^[3] and NYDFS Part 200 supervision^[9] examine in practice.

Choose multisig instead when public verifiability is itself the requirement — DAO treasuries, protocol funds, any structure whose stakeholders will not accept “trust our vendor’s logs” as an answer. A protocol compliance lead’s problem is not a bank compliance head’s: the protocol needs the quorum on-chain precisely because it has no examiner relationship to lean on.

Do not build new HSM-only custody. Keep HSMs where they excel — as the hardware root under MPC shares.

The honest caveat: MPC concentrates a new dependency in a thin vendor market, and the enforcement record has not yet tested how supervisors treat an MPC vendor failure mid-custody. As of June 2026, no major regulator has published architecture-specific custody guidance that names MPC — the closest is HKMA’s 2024 custody circular, which stays architecture-neutral but writes the full key lifecycle (generation, distribution, storage, use, destruction, backup) into supervisory expectations^[10]. We lean toward MPC anyway — the governance evidence it can produce outweighs the vendor concentration risk — but that judgment should be revisited the first time a supervisor speaks.