Whoever controls the keys controls the assets, so choosing a digital asset custodian or wallet infrastructure provider is really choosing who can sign, under which policy, and what happens when a signer, device or interface is compromised. Buyers often compare custody offers on supported chains, fees and insurance headlines, then find that the approval policy can be overridden by one administrator, the insurance excludes the loss scenarios that matter, or the assurance report does not cover the signing systems. This vendor-neutral guide covers custody models, key generation ceremonies, policy engines, insurance, SOC reports, regulatory status and how to test a shortlist. It is for treasury, security and risk leads at funds, corporates, exchanges and fintechs buying either a full custody service or self-hosted wallet infrastructure. Security practice for running wallets yourself is covered in the Crypto Exchange Identity and Key Security Guide and the Crypto Wallet Security Guide.
Key takeaways
- Decide the custody model before the provider. Fully outsourced custody, co-managed keys and self-hosted infrastructure move liability, regulatory status and operational burden in very different ways.
- The policy engine is the real control. Ask who can change approval rules, quorums and allowlists, and whether those changes need the same multi-party approval as a withdrawal.
- Sign what you see. Signing interfaces and transaction data must be verified independently of the systems that build them, because attackers target the path to the signer, not only the keys.
- Read the insurance and assurance scope. Check which wallets, systems and loss types the policy and the SOC report actually cover, and for which period.
- Regulatory status is jurisdiction specific. In the EU, custody of crypto-assets for clients is a MiCA authorised service with defined custody duties and liability; elsewhere, check the specific licence or charter your obligations require.
Define requirements
- Who you are: an investment fund, a corporate treasury, an exchange or broker serving clients, or a fintech embedding wallets. Client asset obligations change what you can delegate and to whom.
- Regulatory perimeter: in the EU, MiCA Article 3(17) defines custody and administration as "the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets", and MiCA has applied in full since 30 December 2024. Article 75 requires a client agreement, a register of positions and a custody policy, and Article 75(8) makes the custodian liable for losses from incidents attributable to it, up to market value. See the MiCA and DORA for Crypto-Asset Service Providers Guide. In the US and elsewhere, ask counsel which custodian status your own rules require.
- Assets and chains: the networks, token standards, staking and governance actions you need, now and over the contract term.
- Operating profile: withdrawal volume and speed, the split between hot, warm and cold storage, and the business hours in which approvals must be possible.
- Approval model: who must approve which transactions, at what value thresholds, with which quorums, and how approvers authenticate.
- Integration: APIs for trading, payments or treasury systems, and the machine credentials those integrations will use.
Capability areas
| Custody model | Who holds key material | Suits | Watch for |
|---|---|---|---|
| Third-party qualified or licensed custodian | The custodian, in HSMs or MPC under its control | Funds and institutions that must or prefer to place client assets with a regulated custodian | Withdrawal speed, chain coverage, sub-custody arrangements, segregation of client assets |
| Co-managed (shared control) | Key shares or multisig keys split between you and the provider | Organisations wanting a provider's operations without giving it sole control | Recovery if either party is unavailable; who is liable for which failure |
| Self-hosted wallet infrastructure | You, using the provider's software, HSM or MPC stack | Exchanges and fintechs operating at volume with their own security team | You carry the custody obligations; depth of your own key management and monitoring |
| On-chain smart contract multisig | Signers' own keys; policy enforced by the contract | Treasuries and DAOs needing transparent, chain-enforced quorums | Contract upgrade rights, interface integrity, chain support |
Key technologies
- Hardware security modules: check the module's FIPS 140-3 validation certificate and level, and which keys are generated and used inside it. See the FIPS 140-3 and Cryptographic Module Validation Guide.
- Multi-party computation (MPC): key shares held by separate parties produce signatures without the full key existing in one place. Ask about the protocol, share refresh, and where shares live. See the Secret Sharing and Threshold Cryptography Guide.
- Multisig: several independent keys must sign on chain. Transparent but chain specific.
- Key ceremonies: generation and backup of root keys under dual control, with witnesses, scripts and recorded evidence. See the Cryptographic Key Ceremony Template.
- Policy engine: rules for amounts, destinations, velocity, time windows and approver quorums, enforced at signing, ideally inside the secure boundary rather than in an application layer.
Evaluation criteria
An illustrative weighting: 25% key management and signing security, 20% policy and governance controls, 15% assurance and insurance, 15% regulatory status and legal structure, 15% operations and recovery, 10% commercials.
| Criterion | Strong answer | Weak answer |
|---|---|---|
| Key generation and storage | Documented ceremony with dual control, validated HSMs or audited MPC, geographically separated backups | Keys generated on general purpose servers; ceremony evidence not available |
| Policy engine | Quorum, allowlist and limit changes need multi-party approval and are logged immutably | One administrator can change policy or add destinations |
| Transaction verification | Approvers see transaction details decoded independently on trusted devices; the signer checks what it signs | Approvals rely on a web interface the signer cannot verify |
| Assurance | SOC 1 or SOC 2 Type 2 report whose scope names the custody, signing and policy systems, plus penetration tests and, where relevant, assessment against the CryptoCurrency Security Standard | Type 1 only, or a report covering corporate IT but not the wallet systems |
| Insurance | Policy schedule showing limits, covered wallets (hot or cold), covered perils and exclusions | Headline figure with no schedule; cover shared across all clients without disclosure |
| Legal structure | Client assets segregated and protected in insolvency, set out in the custody agreement and legal opinion | Assets pooled with the provider's own holdings; terms silent on insolvency |
| Recovery and continuity | Tested key recovery and provider exit plan; ability to move assets if the provider fails | No exit route without the provider's cooperation |
For reading assurance reports, see the How to Read a SOC 2 Report Guide and the CryptoCurrency Security Standard Guide.
Where identity fits
Every signing path ends in an identity: an approver's authenticator, an API key used by a trading system, or a service account in the provider's cloud. The 2025 cold wallet theft analysed in our breach database left keys and multisig intact: stolen cloud session tokens of a supplier's developer let attackers alter the interface signers trusted. Require phishing-resistant authentication for approvers, scoped and rotated API credentials with IP and destination limits, and evidence of how the provider protects its own developer and deployment identities. See Crypto exchange breaches for more lessons on the signing path.
Questions to ask vendors
- Where exactly is key material generated, stored and used, and can we see evidence of the last key ceremony?
- Who can change approval policies, quorums, limits and allowlists, and what approval does each change require?
- How do approvers verify what they are signing independently of the system that built the transaction?
- Which systems, locations and periods does your SOC report cover, and can we read the full report and any exceptions?
- What does your insurance cover, for which wallets and perils, at what limits, and is cover shared across clients?
- Which licences or authorisations do you hold, in which jurisdictions, for which services, and how are client assets treated in insolvency?
- Do you use sub-custodians, and how are they selected and monitored?
- How would we recover or move our assets if you stopped operating, and when did you last test that?
- How do you protect your own developer, deployment and cloud identities from compromise?
Red flags
- Policy changes or new withdrawal destinations that one person can approve.
- Insurance claims you cannot see in a policy schedule.
- Assurance reports that do not name the wallet or signing systems in scope.
- Vague answers on licensing, or licences held by an affiliate that does not contract with you.
- No independent transaction verification for approvers.
- No documented exit or key recovery path that works without the provider.
Proof of concept
- Diligence pack first: collect licences, the full SOC report, insurance schedule, custody agreement, legal opinion on segregation and a ceremony evidence summary.
- Configure policies: set up your real approval quorums, limits and allowlists in a test environment or on a test network.
- Attempt policy bypass: try to add a destination, raise a limit or change a quorum with one approver, and confirm it is blocked and logged.
- Test verification: present an approver with a transaction whose destination differs from the request, and check it is caught.
- Integrate and rotate: connect one system by API, rotate its credentials and confirm scoping and alerts work.
- Rehearse recovery and exit: walk through key recovery and asset migration with the provider, with small amounts.
Once live, track policy changes approved by quorum, time to approve urgent withdrawals, failed policy bypass attempts, API credentials past rotation date, and reconciliation breaks between provider records and the chain.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for custody and wallet infrastructure, with a focus on signing identities, machine credentials and approval controls. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Crypto Exchange Identity and Key Security Guide · HSM Deployment and Operations Guide · MiCA and DORA for Crypto-Asset Service Providers Guide · AI Agents with Crypto Wallets Security Guide