Institutional Crypto Custody Standards: MPC, Multisig, and Recovery

Institutional Crypto Custody Standards: MPC, Multisig, HSMs, and Recovery Controls

Short answer: Institutional crypto custody is not defined by one wallet technology. A sound design proves legal ownership, isolates key authority, separates transaction preparation from approval, limits destinations and amounts, reconciles every balance, survives staff and provider failure, and can recover without creating a new theft path. MPC, multisig, HSMs, and cold storage can support those goals, but none is a complete custody standard by itself.

The board-level question is not “Do we use MPC?” It is “Which people, providers, devices, contracts, and recovery mechanisms can cause assets to move, and what independent evidence shows those controls work?”

This guide was reviewed against NIST key-management guidance and FIPS 140-3, 2025 U.S. banking-agency crypto safekeeping material, OCC custody interpretations, and the SEC's April 2025 custody roundtable materials through July 11, 2026. Regulatory requirements depend on the entity, asset, customer relationship, and jurisdiction. This is an operational framework, not legal or compliance advice.

Custody is control, not mere possession of a secret

For a bearer-like crypto asset, control often depends on the ability to create an accepted transaction. But a corporate custody system includes more than the signing secret:

legal title and contractual rights;

wallet and account identifiers;

key generation and storage;

policy administrators;

transaction preparation and simulation;

approval and signing;

network broadcast and finality monitoring;

balance and ownership reconciliation;

backup, recovery, and succession;

service-provider and subcustodian dependencies;

incident response and insurance.

A company can lose effective control without losing a key. A custodian can suspend withdrawals. An administrator can replace an allowlist. A smart-account upgrade key can bypass ordinary signers. A lost policy database can make valid shares unusable. A legal dispute can prevent the company from reaching assets held through another entity.

The custody inventory must therefore include every path that can enable, block, or redirect a transfer.

The custody-boundary map

Build a diagram and register for each asset pool:

Layer	Evidence required	Typical hidden dependency
Legal owner	Entity records, custody agreement, account title	Affiliate or omnibus account holds the contractual claim
Blockchain account	Chain, address, script or account code, creation record	Proxy, module, bridge, or token administrator changes control
Key or key shares	Generation ceremony, module, backup, participants	Vendor-controlled recovery or policy credential
Policy system	Rules, administrators, change approvals, logs	One administrator can lower limits or add destinations
Signing devices	Inventory, attestation or validation, firmware, custody	Shared device, cloud console, or insecure update path
Provider	Exact legal entity, services, subcustodians, controls	Undisclosed subcontractor or settlement venue
Network and asset	Nodes, finality rule, fork policy, token contract	Centralized token freeze or bridge failure
Reconciliation	Independent data, statements, ownership evidence	Same system prepares and verifies transactions
Recovery	Trigger, quorum, materials, locations, test evidence	Recovery route is easier to exploit than normal signing

If one row is unknown, “institutional grade” is only a label.

MPC, multisig, and secret sharing solve different problems

Native or script-based multisig

Multisig requires authorization from multiple keys according to an onchain script or smart-account rule. The threshold and, depending on design, participant structure can be visible and independently verified. It can reduce single-key risk and preserve control across independent parties.

It also introduces wallet compatibility, transaction-size, privacy, script, smart-contract, recovery, and coordination issues. A threshold of three out of five is not strong if four keys are stored in the same office or managed by the same administrator.

Threshold signatures and MPC

Threshold-signature systems allow multiple parties to produce a standard signature without one party holding the complete signing secret in ordinary operation. MPC protocols can support distributed key generation, signing, and in some implementations resharing.

MPC does not inherently provide:

independent business approval;

destination or transaction limits;

legal segregation of client assets;

protection from a compromised policy administrator;

reliable recovery;

safe software updates;

proof that participant devices are independently controlled.

The phrase “the private key never exists” is imprecise marketing when used without a protocol description. Some systems generate shares without reconstructing a complete secret; other backup or import paths may begin with or reconstruct key material. Review the exact implementation.

Secret sharing

Secret-sharing schemes divide a secret or recovery material into shares. They are not automatically threshold-signature systems. Reconstructing a seed from shares can expose the complete secret at the recovery location, and dynamic participant changes may require resharing or a new wallet depending on the design.

The original claim that an executive share can always be revoked without moving assets was too broad. Ask whether the system supports proactive resharing, whether the public key remains unchanged, which participants must cooperate, what happens to old shares, and how the resharing event is authenticated and audited.

Hardware security modules

An HSM provides a controlled cryptographic boundary for key operations. It can enforce authentication, roles, key handling, and other safeguards. It does not decide whether a proposed transaction is economically or legally appropriate.

FIPS 140-3 defines security requirements for cryptographic modules across interfaces, authentication, software and firmware security, physical security, sensitive security parameter management, self-tests, lifecycle assurance, and related areas. It superseded FIPS 140-2. A vendor saying “FIPS compliant” is not enough: verify the module's Cryptographic Module Validation Program certificate, exact hardware or software version, approved mode, security level, and whether the production configuration falls inside the validated boundary.

FIPS validation addresses a cryptographic module. It does not certify the entire custodian, wallet workflow, cloud architecture, or recovery process.

Choose a custody model by control requirements

Model	Main benefit	Main risk	Evidence to demand
Third-party custodian	Specialist operations, contractual service, reporting	Provider, subcustodian, insolvency, availability	Legal terms, control reports, key architecture, financial and exit evidence
Collaborative custody	Company participates in signing while provider supplies infrastructure	Shared responsibility can be misunderstood	Exact key/control split, failure modes, recovery, policy rights
Company-operated multisig	Direct control and visible threshold	Internal expertise, succession, backup, signer concentration	Key ceremony, device inventory, independent locations, tested recovery
Company-operated MPC	Standard signatures and flexible policy options	Complex protocol, software, administrator and vendor dependencies	Protocol review, participant independence, resharing, update and recovery evidence
Exchange custody	Rapid trading and settlement	Venue concentration, prefunding, withdrawal and insolvency risk	Balance limits, withdrawal controls, legal entity, settlement and contingency plan
Single hardware wallet	Simple for low-value testing	Key-person, backup, coercion and continuity risk	Not suitable as sole control for material institutional reserves

Hybrid designs are common. A company might hold strategic reserves at two custodians, use a company-controlled multisig for contingency reserves, and maintain a capped exchange balance for execution. Diversification only helps when providers and control paths are genuinely independent.

Legal and contractual custody comes before architecture

The OCC has long treated cryptocurrency custody as a form of safekeeping activity for national banks, while stressing safe and sound operation and compliance with law. In 2025, the OCC clarified that banks may outsource permissible custody and execution activities subject to appropriate third-party risk management. A separate 2025 interagency statement on crypto-asset safekeeping discussed governance, key management, asset segregation, subcustodians, recordkeeping, and other controls.

Those statements do not make every provider a qualified custodian or approve every service model. SEC officials at the April 2025 custody roundtable described unresolved questions for advisers, funds, broker-dealers, and crypto assets under different federal securities-law frameworks.

For each relationship, counsel should determine:

which legal entity is the client;

which legal entity is the custodian;

whether the service is fiduciary, non-fiduciary, advisory, technical, or another form;

who has legal title or a security entitlement;

whether assets are segregated onchain, in books, or both;

how omnibus holdings and internal records establish the client's interest;

whether the provider can lend, pledge, stake, or reuse assets;

which subcustodians and venues may be used;

the treatment of assets in insolvency;

liability standard, indemnity, limitation, and claims process;

governing law and dispute forum;

termination, transfer, and data-export rights.

Do not infer legal segregation from a separate wallet address alone, or beneficial ownership from a dashboard balance alone.

Hot, warm, and cold are operational states

“Cold” is often used as a security badge. Define each tier by connectivity, key activation, policy, funding, and service objective.

Tier	Purpose	Typical controls	Funding principle
Hot	Routine payments, fees, or trading	Automated limits, allowlists, continuous monitoring, rapid revocation	Minimum needed for near-term operations
Warm	Planned rebalancing and periodic settlement	Human approval, delayed policy changes, stronger device isolation	Bounded operating buffer
Cold	Long-horizon reserve	Offline or highly isolated signing, separate locations, formal ceremony, long lead time	Majority of non-operating reserve where appropriate
Recovery	Restore control after loss or compromise	Separate materials, independent quorum, sealed procedure, monitored activation	No routine transaction use

Air gaps reduce remote exposure but create transfer-media, procedural, firmware, supply-chain, and human-verification risks. A disconnected signer that displays an unreadable hash can still authorize malicious transaction data imported from a compromised online machine.

Cold operations need human-readable transaction verification, trusted decoding, controlled data transfer, and reconciliation after broadcast.

Wallet register and control record

Every institutional wallet or custody account should record:

owning legal entity and business purpose;

asset, chain, address, script, smart-account modules, and proxy implementation;

provider and exact service account;

custody tier;

key or share holders by role, not only by name;

threshold and participant independence;

policy administrators and their privileges;

approved destinations and methods;

transaction, daily, and rolling limits;

supported tokens, contracts, and networks;

creation, key ceremony, and test evidence;

backup and recovery references;

monitoring and reconciliation owner;

fork, airdrop, staking, and token-administration policy;

last access and recovery test;

decommission procedure and final balance evidence.

The register should be access-controlled but available during an incident. Avoid storing raw secrets, seed words, or sufficient recovery shares in the same system.

Key ceremony: evidence from the beginning

A key ceremony should create a repeatable record without exposing sensitive material.

Preparation

1.Approve the wallet purpose, threshold, participants, locations, and recovery design.

2.Verify devices, modules, firmware, software packages, and checksums through controlled sources.

3.Define the clean-room or isolated environment and prohibit unauthorized electronics.

4.Assign ceremony leader, operators, witnesses, recorder, and security observer.

5.Prepare tamper-evident materials, serial numbers, logs, and abort criteria.

6.Rehearse with non-production keys.

Generation

1.Authenticate participants and devices.

2.Generate keys or shares under the documented protocol.

3.Record public keys, wallet descriptors, addresses, module identifiers, and configuration.

4.Verify that no unauthorized export, camera, printer, network, or logging path exists.

5.Test address derivation independently.

6.Create backups under the approved protection method.

Activation

1.Fund with a small controlled transaction.

2.Verify receipt through independent nodes or data sources.

3.Execute a test transfer using the production approval path.

4.Verify thresholds, policy rejection, limits, monitoring, and reconciliation.

5.Seal and distribute backup materials to independent locations.

6.Sign the ceremony record and register the wallet.

The record should prove what occurred, who witnessed it, and which public configuration resulted. It should not contain the private material needed to spend.

NIST key-management principles applied to custody

NIST SP 800-57 Part 1 provides general guidance on cryptographic key lifecycle, protection, cryptoperiods, backup, recovery, compromise, and destruction. It is not a cryptocurrency custody recipe, but its lifecycle discipline is useful.

Map each key or share through:

1.generation;

2.registration and association with an identity or role;

3.distribution or installation;

4.activation;

5.normal operation;

6.rotation, resharing, or replacement;

7.suspension or revocation;

8.recovery;

9.deactivation;

10.archival where appropriate;

11.destruction;

12.compromise investigation.

Crypto assets add a hard constraint: changing a signing key may require an onchain transfer or account update. The policy must account for fees, congestion, timelocks, destination validation, tax and accounting records, and the possibility that a compromised key can act before migration completes.

The transaction evidence packet

Every material movement should leave one evidence package:

request ID and business purpose;

source legal entity and wallet;

destination legal owner, address, and verification method;

asset, quantity, fiat value, and valuation timestamp;

decoded transaction intent, contract method, approvals, and expected state changes;

policy and limit checks;

sanctions or counterparty review where applicable;

simulation or test results;

preparer, reviewer, approvers, and signers;

exact chain ID, nonce, fees, calldata, and expiry;

transaction hash and replacement history;

confirmations and finality evidence;

actual balance and event changes;

accounting, tax-lot, and reconciliation entries;

exceptions and incident references.

Approvers should see human-readable intent and independently verified destination details. “The wallet platform displayed green” is not sufficient evidence.

Policy controls must surround the signer

A signer should enforce or receive the results of deterministic controls:

asset and chain allowlist;

destination allowlist with delayed additions;

contract and function allowlist;

transaction and rolling value limits;

exact-token approval limits;

time windows and expiry;

required approver roles;

independent destination verification;

price and slippage thresholds;

simulation requirements;

velocity and anomaly controls;

mandatory pause after repeated failures;

emergency revocation.

Do not let the same administrator silently modify a policy and approve a transaction under the new policy. High-impact configuration changes should require independent approval, delay, and monitoring.

Provider due-diligence questionnaire

Legal and financial

Which entity contracts with us, and which entities or subcustodians hold assets or keys?

How are client assets identified, segregated, and treated in insolvency?

What capital, insurance, regulatory, audit, and assurance arrangements apply?

Which losses are contractually covered, excluded, capped, or subject to negligence standards?

Can assets be rehypothecated, lent, staked, or pledged?

Key and technology

Is the system multisig, threshold signature, MPC, HSM-based, smart-account based, or hybrid?

How are keys or shares generated, distributed, backed up, rotated, reshared, revoked, and destroyed?

Which cryptographic modules are independently validated, and what exact versions are in scope?

Who can change policy, code, firmware, participants, recovery contacts, or destinations?

What happens if the provider, cloud, HSM, network, or policy database is unavailable?

Operations

Which controls are manual, automated, or customer-controlled?

What are withdrawal cut-offs, review queues, finality rules, and emergency procedures?

How are new chains, tokens, forks, airdrops, staking, and smart contracts admitted?

How are balances and client books reconciled to onchain data?

What logs and evidence can the client export?

Security and resilience

What independent assurance, penetration testing, code review, and incident testing exist?

How are privileged access, employee screening, separation of duties, and departures managed?

What recovery-time and recovery-point objectives apply?

When was a full client recovery or exit last tested?

How are incidents disclosed, and what evidence is preserved?

A glossy architecture diagram cannot substitute for contract terms, control reports, test evidence, and a successful withdrawal.

Understand subcustodian chains

A custodian may use cloud providers, key-technology vendors, banks, OTC desks, validators, staking providers, and subcustodians. The company should know which functions are outsourced and whether concentration defeats diversification.

Two custodians can share:

the same subcustodian;

the same cloud region;

the same HSM vendor and firmware;

the same banking rail;

the same transaction-policy platform;

the same token bridge;

the same insurance underwriter;

the same recovery service.

Provider count is not independence. Build a dependency matrix and set concentration limits on critical shared components where evidence permits.

Reconciliation and proof boundaries

Onchain balances are transparent, but ownership and completeness are not automatically proven. Reconciliation should compare:

1.the company's wallet and account register;

2.custodian subledger or statement;

3.independently obtained blockchain balances and transactions;

4.general ledger and tax records;

5.pending trades, staking, bridges, collateral, and unsettled transfers;

6.restrictions, liens, or encumbrances.

Proof-of-reserves can show that specified assets or addresses existed at a point in time. It may not show liabilities, ownership, encumbrances, borrowed assets, offchain obligations, operational control, or subsequent movement. Do not treat a Merkle proof or signed address as a full custody audit.

Recovery is a separate security domain

Recovery must be possible under staff loss, provider failure, device destruction, policy corruption, and partial compromise. It must also resist attackers who invoke recovery fraudulently.

Recovery design questions

Which events authorize recovery?

Who declares the event, and who independently confirms it?

What material exists, where, and under whose custody?

Is the recovery quorum independent of the normal signing quorum?

Can one provider block recovery?

Does recovery reconstruct a complete secret?

How are replacement destinations verified?

How does the company distinguish lost access from an active insider dispute?

Can recovery be delayed or canceled after public notice?

What monitoring detects activation?

How are old keys or shares invalidated?

Automatic dead-man switches are risky. Travel, illness, communication failure, or a denial-of-service attack can mimic disappearance. A safer design uses documented escalation, independent legal and security confirmation, bounded waiting periods, and a controlled recovery ceremony.

There is no recognized universal “Whale Recovery Kit” standard. Any product using that label should be evaluated by its actual cryptography, custody, legal, and operational controls.

Recovery drill

A tabletop discussion is not enough. Conduct a controlled drill with non-production or low-value assets:

1.Declare a realistic scenario, such as one unavailable signer plus a failed provider console.

2.Locate current procedures and contacts without advance hints.

3.Authenticate recovery participants through independent channels.

4.Retrieve the required backup materials from separate locations.

5.Reconstruct or activate only inside the approved environment.

6.Derive and verify the expected public address.

7.Build and sign a bounded test transaction.

8.Confirm destination, broadcast, finality, and reconciliation.

9.Destroy temporary sensitive material and reseal backups.

10.Record elapsed time, failures, undocumented dependencies, and remediation owners.

Do not expose production secrets merely to prove recovery. The drill design should validate the real process while controlling risk, and production recovery elements should receive assurance appropriate to their sensitivity.

Personnel and succession controls

Custody fails when role design follows titles rather than independence. Avoid making the CEO, CFO, and treasurer a threshold if they travel together, report through one line, or share administrators.

A resilient signer and administrator design considers:

geographic and organizational independence;

employment and contractor status;

device and account separation;

conflicts and coercion exposure;

planned and immediate departure;

disability or death;

vacation coverage;

background checks and training;

prohibited sharing and remote-access tools;

dual control for enrollment and removal;

periodic access recertification.

Do not name individual executives permanently in an onchain script without a replacement path. Use controlled role succession and test it before the current holder leaves.

Incident playbooks

Suspected signer compromise

Pause affected accounts and policy changes, preserve device and service logs, identify every wallet and administrative privilege associated with the signer, revoke sessions, invoke the approved replacement or migration path, and inspect all pending and recent transactions. A clean device does not prove the key or share remains safe.

Policy-administrator compromise

Treat this as a signing incident if the administrator can add destinations, lower thresholds, change participants, or enable recovery. Compare every configuration change with approved records and delay all outbound transactions until the policy state is trusted.

Custodian withdrawal suspension

Confirm the exact scope, legal entity, asset status, and reason through authenticated contacts. Stop new deposits, reconcile independently, preserve statements and agreements, assess near-term liquidity, and use an alternate provider only through pre-verified destinations. Do not create a new emergency wallet under pressure.

Lost quorum

Determine whether participants are unavailable, compromised, disputing authority, or technically unable to sign. Follow the specific succession or recovery path. Do not combine shares informally or transmit sensitive material through ordinary communications.

Wrong-chain or wrong-contract transfer

Stop further activity, preserve transaction evidence, identify whether the destination is controlled and whether the asset is native, wrapped, or unsupported, and coordinate with the provider and legal team. Avoid unverified “recovery services” contacting the company after public detection.

Chain fork or reorganization

Suspend movement under the chain-specific trigger, verify finality through independent nodes, follow replay-protection and asset-recognition policy, and reconcile both sides before resuming.

Insurance: read the covered event

Insurance may cover specified theft, employee crime, cyber, physical damage, or professional liability risks. It rarely turns a custody program into guaranteed principal protection.

Document:

named insured and loss payee;

covered wallets, providers, locations, and activities;

policy limit and aggregate use across clients;

deductible and retention;

exclusions for social engineering, voluntary transfer, protocol failure, insider conduct, war, sanctions, lost credentials, and asset-price loss;

valuation date and claims process;

notification and evidence deadlines;

whether subcustodian and hot-wallet losses are included.

Compare the maximum plausible loss with the portion insurance could actually pay.

Board custody dashboard

Exposure

assets by legal entity, custodian, subcustodian, wallet tier, chain, and activity;

hot and exchange balances versus limits;

unsettled, staked, bridged, or encumbered assets;

concentration in shared dependencies;

uninsured or disputed exposure.

Control health

wallet and privileged-access changes;

policy exceptions and rejected transactions;

reconciliation breaks and aging;

backup, signer, device, and recovery-test status;

provider assurance and due-diligence expiry;

incidents and near misses;

software, firmware, smart-account, and network changes.

Resilience

time to pause, recover, and move a test position;

unavailable signers or providers;

untested assets or chains;

alternate bank, custodian, and node readiness;

open remediation owners and deadlines.

Boards should receive evidence of exceptions and tests, not only a claim that “all assets are in cold storage.”

Institutional custody scorecard

Score each domain from 0 to 2: absent, documented but untested, or implemented with current evidence.

Domain	Evidence question
Legal title	Can the entity prove its rights and insolvency treatment for every account?
Control map	Are all keys, shares, administrators, contracts, providers, and blockers known?
Independence	Are preparation, policy, approval, signing, and reconciliation separated?
Key lifecycle	Are generation, activation, rotation, recovery, compromise, and destruction controlled?
Module assurance	Are exact validated modules and production boundaries documented where claimed?
Transaction policy	Are assets, destinations, methods, values, velocity, and changes bounded?
Provider oversight	Are legal entity, subcustody, finances, assurance, incidents, and exit tested?
Reconciliation	Do independent records agree on balance, ownership, completeness, and restrictions?
Recovery	Can access be restored without a weaker authorization path?
Resilience	Can one signer, provider, site, cloud, or bank fail without losing control?
Incidents	Have key, admin, provider, chain, and transfer scenarios been rehearsed?
Board evidence	Are exposure, control failures, tests, and remediation visible?

A score below 16 of 24 suggests material custody should not launch or expand. A high score is not regulatory approval, an audit opinion, or a guarantee. Any zero in legal title, control map, transaction policy, reconciliation, recovery, or incident response should block material funding.

Frequently asked questions

Is MPC safer than multisig?

Not universally. Each supports different signatures, policies, compatibility, privacy, and recovery models. Security depends on protocol implementation, participant independence, devices, administrators, recovery, and operations.

Does an MPC wallet have no private key?

Threshold systems can generate and use shares without reconstructing a complete signing secret during normal operation. Exact generation, import, backup, export, and recovery paths vary and must be reviewed.

Does FIPS 140-3 certify a crypto custodian?

No. It specifies requirements for cryptographic modules. Verify the exact validated module and configuration, then separately assess the wallet system, provider, people, policies, and recovery process.

Is cold storage always safest?

It can reduce online attack exposure but may increase procedural, physical, recovery, and response-time risk. The correct tier depends on transaction needs and a tested control design.

Can a custodian lend our assets?

Only according to the contract and applicable law. The agreement should explicitly address rehypothecation, staking, pledging, subcustody, and client consent. Never infer the answer from a marketing page.

Is proof of reserves enough?

No. It may show specified assets at a point in time but not complete liabilities, ownership, encumbrances, operational control, or later movements.

How often should recovery be tested?

Set frequency by value, change rate, and risk. Test after material changes and on a regular schedule. Avoid exposing production secrets; use controlled evidence and bounded assets.

Should executives be wallet signers?

Only when their role, independence, availability, security practices, succession, and liability fit the design. Senior title is not a cryptographic control.

Source note and analytical limits

NIST sources support the cryptographic-module and key-lifecycle discussion; they do not prescribe a digital-asset custody architecture. OCC and interagency materials support the focus on safe and sound operation, subcustodians, key management, segregation, third-party risk, and internal controls for banking organizations. SEC roundtable materials establish that custody remains a live regulatory issue across advisers, funds, and broker-dealers; commissioner remarks do not by themselves create new rules.

The custody-boundary map, wallet tiers, key-ceremony checklist, transaction evidence packet, provider questionnaire, dependency analysis, recovery drill, incident playbooks, dashboard, and scorecard are CryptosEyes operational frameworks. They do not certify any custodian or replace legal, audit, security, or regulatory review.

What to read next

Read the multisignature and threshold-signature analysis for protocol mechanics. Then use the wallet recovery checklist for personal and small-team backup practices, and the corporate digital-asset policy framework to connect custody controls to board authority and liquidity limits.

The practical takeaway: custody quality is demonstrated by independent control and successful recovery evidence. A cryptographic acronym, cold-storage claim, or insurance logo cannot prove that the right entity can move the right assets under the right conditions.

About the Editorial Team

CryptosEyes publishes independent, source-grounded custody research. Cryptographic techniques are separated from legal ownership, provider controls, recovery, and operational assurance.