Key management technologies

Every custody model comes down to one question: how is a valid signature produced, and who can produce it? Four families of technology dominate institutional key management, and most custodians combine them. Each makes different trade-offs between transparency, flexibility, chain coverage and dependence on a vendor, and a professional should be able to explain those trade-offs to a risk committee.

Hardware security modules

A hardware security module (HSM) is a tamper-resistant device that generates, stores and uses keys so that private key material never leaves it in plaintext. Applications send the HSM a message to sign and get a signature back. Banks have used HSMs for decades for payment cards and PKI, and most institutional crypto custodians use them somewhere in their stack.

HSMs are validated under FIPS 140-3, the US and Canadian standard for cryptographic modules run by NIST's Cryptographic Module Validation Program (CMVP). FIPS 140-3 took effect on 22 September 2019 and is aligned with ISO/IEC 19790:2012 (requirements) and ISO/IEC 24759 (test methods). It defines four security levels:

Institutional custody usually targets Level 3. The older standard, FIPS 140-2, stopped accepting new submissions for testing in September 2021. On 21 September 2026 all remaining FIPS 140-2 certificates moved to the CMVP's Historical List. US federal agencies should not buy modules on that list for new systems, and most institutional buyers apply the same rule. A new HSM purchase should therefore come with a current FIPS 140-3 certificate.

A certificate covers one module, at a specific firmware version, in a specific mode. It does not certify the whole custody system. When reviewing an HSM, check the certificate number, level, firmware version, and whether the algorithms the business needs are supported: secp256k1 for Bitcoin and Ethereum, Ed25519 for chains such as Solana. A plain HSM holding one key is also a single point of control. Anyone who can log in to the HSM and submit messages can get signatures, so the policy around it matters as much as the hardware.

Multisignature wallets

A multisignature (multisig) wallet needs signatures from m of n independent keys, for example 3 of 5. The rule is enforced by the blockchain itself:

• On Bitcoin, through native scripts (P2WSH, or Taproot scripts since the 2021 upgrade).
• On Ethereum and other EVM chains, through a smart contract. The most widely used is Safe (formerly Gnosis Safe).

Multisig has clear strengths. The policy is visible on-chain, so an auditor can confirm that 3 of 5 signatures are required. Keys can sit on different devices, with different vendors, in different countries, so no single compromise is enough. The weaknesses are just as concrete. Each chain needs its own implementation, and some chains do not support multisig at all. Transactions are larger and fees higher. On Bitcoin, changing a signer means moving funds to a new address. On EVM chains, the wallet contract and its user interface become part of the attack surface. The Bybit theft in February 2025 hit a Safe multisig through its interface, not its cryptography (see the lesson Operational security threats and controls).

MPC and threshold signatures

A threshold signature scheme (TSS) uses multi-party computation (MPC) to split signing power among several parties. During distributed key generation (DKG), each party creates its own key share, and the full private key never exists anywhere, not even for an instant. To sign, any t of n parties run a protocol that outputs one ordinary signature. On-chain it looks exactly like a single-key transaction.

Common protocols include GG18, GG20 and CGGMP for ECDSA (the signature scheme of Bitcoin and Ethereum), and FROST for Schnorr and EdDSA signatures. FROST was published by the IETF as RFC 9591 in June 2024.

MPC brings real advantages:

• Chain-agnostic: any chain that uses a supported curve works, without needing multisig support on that chain.
• Lower fees and more privacy: the transaction is a single signature.
• Share refresh: shares can be rotated, or the quorum changed, without moving funds or changing the address.

It also brings real disadvantages. The quorum is invisible on-chain, so auditors must rely on the vendor's documentation and on assurance reports. The cryptography is complex and implementations have failed. In August 2023, Fireblocks researchers disclosed the "BitForge" vulnerabilities in implementations of GG18 and GG20 at several wallet providers (one was tracked as CVE-2023-33241); in some cases an attacker could extract the full key. Most solutions are proprietary, which creates vendor dependence. A custodian needs a tested way to recover assets if the vendor disappears.

Do not confuse MPC with Shamir's Secret Sharing (SSS). SSS splits a finished key into pieces for backup, but to sign, the key must be rebuilt in one place. MPC never rebuilds it. A related idea on Bitcoin, MuSig2 (BIP 327), lets n signers combine their keys so that an n-of-n Taproot spend looks like a single signature.

Smart-contract wallets and account abstraction

On Ethereum, a smart-contract account is a wallet whose rules are code. It can enforce spending limits, role permissions, session keys with narrow rights, social or institutional recovery, and gas paid by a third party. Two standards matter:

• ERC-4337, live on Ethereum mainnet since 2023, delivers account abstraction without changing the protocol. Users submit "user operations" that bundlers package into transactions through a shared EntryPoint contract. Optional paymasters can pay the gas.
• EIP-7702, activated with the Pectra upgrade on 7 May 2025, lets an ordinary externally owned account (EOA) point to contract code. The account gains smart-account features and keeps its address.

The trade-off is contract risk. A bug in the wallet code, or a badly controlled upgrade function, can lose everything. With EIP-7702, one malicious authorization signature can hand control of an account to an attacker's code, and phishing campaigns have already targeted this. Questions about upgradeability and admin keys are covered in the lesson Assessing DeFi risk.

Key generation and key ceremonies

A key is only as trustworthy as the way it was created. Institutional custodians generate high-value keys in a key ceremony: a scripted, witnessed and recorded procedure.

For MPC, the DKG ceremony should run each share on separate infrastructure, controlled by different people, so that no single team ever holds a threshold of shares.

Choosing and combining

Large custodians rarely rely on one technology. A common pattern is MPC for hot and warm wallets, where speed and chain coverage matter. Cold storage is held in HSM-protected keys or a multisig with geographically dispersed signers. Smart-contract rules add on-chain limits where the chain supports them. When assessing a provider, ask four questions:

1. Does a complete private key ever exist, and if so, where and for how long?
2. Can an outsider verify the signing policy, or only read the vendor's description of it?
3. What happens if the technology vendor fails, and has recovery without the vendor been tested?
4. Which certifications cover which components (a FIPS 140-3 certificate for the HSM, an assurance report for the overall system)?

Exam focus: what an HSM does and the four FIPS 140-3 security levels (Level 3 typical for custody); why a new HSM should carry a FIPS 140-3 certificate now that FIPS 140-2 certificates are on the Historical List; how multisig enforces m-of-n on-chain and its trade-offs (visible policy, chain-specific, higher fees); how MPC/TSS works (DKG, the key never exists, an ordinary single signature on-chain) and its trade-offs (invisible policy, implementation risk such as BitForge, vendor dependence); the difference between MPC and Shamir's Secret Sharing; ERC-4337 and EIP-7702 (Pectra, May 2025) and their contract risk; the steps and evidence of a key ceremony.