Wallets and custody security lessons from recent crypto thefts
a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}
Why wallet security now means custody security
The security of wallets and custody arrangements has become a board-level risk because many major crypto losses are no longer simple hot-wallet drains. Recent industry reporting from Chainalysis and TRM Labs points to private key compromise, signer manipulation, privileged access abuse, and infrastructure attacks as recurring causes of high-value theft. The practical lesson is clear: a cold wallet is not secure by default, a multisig is not secure by default, and a qualified custodian is not a substitute for due diligence. Security depends on how keys are generated, stored, approved, monitored, recovered, and governed across people, devices, vendors, and on-chain permissions. For more background on this topic, see our wallets and custody coverage.
Asset holders and operators are trying to answer the same basic questions: how to protect digital assets, how self-custody differs from third-party custody, and which controls actually reduce the risk of loss. There is no single product or architecture that solves the problem. Effective custody is a layered operating model that limits the blast radius if one signer, workstation, vendor, or smart contract permission is compromised.
The threat model changed from wallets to workflows
Traditional wallet advice often focuses on one point of failure: the private key or seed phrase. That still matters. However, many high-value custody failures involve the workflow around the key. Attackers target people, interfaces, cloud credentials, developer machines, signing policies, and approval routines because those controls decide when a transaction becomes valid.
Chainalysis reported that private key compromises accounted for the largest share of stolen crypto in 2024, while its 2025 updates highlighted a damaging rise in service-level theft and personal wallet compromises. TRM Labs described infrastructure attacks in 2025 as including compromises of private keys, seed phrases, wallet infrastructure, privileged access, and front-end surfaces. The same conclusion runs through both sets of reporting: custody risk is operational as much as cryptographic.
The February 2025 Bybit incident is widely discussed for that reason. Public post-incident reporting described a manipulated multisig signing flow linked to third-party wallet infrastructure. The important security lesson is not only that a large amount was stolen. It is that signers can be tricked into approving something different from what they believe they are approving if transaction verification relies too heavily on a browser interface, a familiar app screen, or an incomplete hardware-wallet display.
Self-custody, exchange custody, and institutional custody compared
Different custody models assign responsibility in different ways. Self-custody gives the holder direct control, but it also makes that holder responsible for backup, recovery, device security, and inheritance planning. Exchange custody is convenient for trading, but users depend on the platform’s controls, solvency, withdrawal policies, and incident response. Institutional custody can add segregation, policy controls, insurance arrangements, reporting, and independent assurance, but it still requires careful review of the actual security scope.
| Custody model | Main advantage | Main security risk | Controls that matter most |
|---|---|---|---|
| Self-custody | Direct control of keys and transactions | Seed loss, phishing, malware, poor backup, coercion | Hardware wallet, offline backup, passphrase strategy, multisig for larger balances |
| Exchange custody | Fast trading and simple onboarding | Platform compromise, withdrawal freeze, account takeover, counterparty risk | Withdrawal allowlists, account security, limited balances, review of incident history |
| Professional custodian | Policy controls, reporting, operational support | Vendor dependency, opaque key management, legal and operational complexity | Segregation, audit scope, approval workflow, insurance limits, recovery procedures |
| Hybrid model | Balance between control and convenience | Complex responsibility split | Clear asset allocation, documented authority, tested transfers, emergency playbooks |
No model is universally safer. A disciplined self-custody setup can be stronger than a weak institutional process, while a mature custodian can reduce risks that most individuals cannot manage alone. The right model depends on asset size, transaction frequency, governance needs, regulatory obligations, and the user’s ability to maintain secure procedures over time.
Controls that separate secure custody from security theater
Many custody providers and wallet systems use similar language: cold storage, multisig, MPC, insurance, proof of reserves, institutional-grade security, and military-grade security. Those labels are not enough. The stronger question is how the system fails when something goes wrong.
Key generation and storage
Key material should be generated in a controlled environment, using audited processes and devices that minimize exposure. For self-custody, this means avoiding seed generation on internet-connected computers or phones. For institutions, it means documented ceremonies, hardware security modules or hardened signing devices, access logs, and separation between people who request transfers and people who approve them.
Multisig and MPC
Multisignature wallets and multiparty computation both reduce reliance on a single private key, but they do it in different ways. Multisig usually records multiple signers on-chain and can be transparent, but it may depend on chain-specific smart contracts, wallet interfaces, and signer coordination. MPC splits signing authority cryptographically so that no single party holds a full key, but it introduces implementation, vendor, and protocol risks that must be assessed.
The practical point is that neither architecture is magic. A 3-of-5 multisig can still fail if three signers use compromised devices or trust the same manipulated interface. An MPC system can still fail if policy controls, endpoint security, or vendor operations are weak. Architecture has to be paired with independent transaction verification and strong operational discipline.
Transaction verification
Every high-value transfer should answer three questions before approval: where are the funds going, what exactly is being authorized, and what can the recipient contract do after approval? Address, amount, asset, chain, smart contract method, and permission changes should be verified outside the same interface that creates the transaction. Depending on the setup, this can include trusted-display signing, offline transaction review, contract simulation, pre-approved address books, and human call-backs for exceptional transfers.
Governance and separation of duties
Secure custody requires more than technical signing. The person who creates a withdrawal should not be the only person able to approve it. Policy should define spending limits, emergency stops, time locks, destination allowlists, signer rotation, onboarding and offboarding, vendor access, and escalation paths. NIST’s Cybersecurity Framework 2.0 is useful here because it adds governance as a core function alongside identify, protect, detect, respond, and recover.
A practical risk map for wallet and custody security
The following map turns common failure modes into controls that can be checked by individuals, funds, exchanges, and corporate treasuries.
| Risk | What it looks like | Control response |
|---|---|---|
| Seed phrase theft | Cloud backup exposure, fake wallet app, phishing page, photo of recovery phrase | Offline backup, no digital copies, hardware wallet, recovery phrase education |
| Signer compromise | Malware on an approval device or browser session | Dedicated signer devices, no general browsing, endpoint monitoring, signer rotation |
| Interface manipulation | Displayed transaction differs from signed transaction | Trusted-display verification, contract decoding, out-of-band approval review |
| Excessive hot-wallet exposure | Too much liquidity in wallets connected to online systems | Balance caps, automated sweeps, velocity limits, cold-storage replenishment rules |
| Vendor dependency | Custody process depends on one wallet provider, cloud account, or admin console | Vendor risk review, access segmentation, contingency plan, independent monitoring |
| Slow incident response | Teams discover theft after funds have bridged, mixed, or moved across exchanges | Real-time alerts, exchange contact list, law enforcement path, stablecoin issuer escalation where applicable |
For institutions, the CryptoCurrency Security Standard is another relevant reference because it focuses directly on systems that store, manage, or interact with digital assets. Its areas include key and seed generation, wallet creation, key storage, key usage, compromise protocols, audit controls, and logging. That specificity matters because general cybersecurity standards may not fully cover blockchain signing and key-management risks. See also: Blockchain Technology.
What investors should ask before trusting a custodian
Due diligence should be concrete. A custodian’s marketing page may mention cold storage or insurance, but the key questions are operational. Who can initiate a transfer? Who can approve it? How many approvals are required at each value threshold? Are destination addresses allowlisted? Can smart contract approvals be blocked or limited? Are signer devices isolated? How are employees removed from signing authority? How quickly can the firm freeze, rotate, or migrate wallets after a suspected compromise?
Proof of reserves can improve transparency, but it does not prove full custody safety by itself. It may show that assets exist at a point in time, but it does not necessarily prove liabilities, segregation, withdrawal governance, legal ownership, or the strength of signing controls. Audit reports are also scope-dependent. A SOC 2, ISO 27001, or CCSS-related assessment is more useful when the report covers wallet operations, key management, incident response, vendor controls, and production access rather than only corporate IT.
Insurance should be read carefully. Policies may exclude social engineering, insider activity, smart contract failure, nation-state activity, or losses outside specified custody environments. The presence of insurance is not the same as guaranteed reimbursement. Investors should understand limits, exclusions, the claims process, and whether coverage applies to the specific account structure being used.
How self-custody users can reduce avoidable risk
Individual users do not need an institutional control room, but they do need a repeatable security routine. For small balances, a reputable hardware wallet, offline seed backup, strong device hygiene, and phishing awareness may be enough. For larger balances, users may consider splitting funds across multiple wallets, using multisig, adding a passphrase only if it can be backed up safely, and documenting recovery steps for trusted heirs or legal representatives.
The most common self-custody mistakes are simple: typing a seed phrase into a website, saving it in a password manager without understanding the risk, approving unlimited token allowances, installing fake wallet extensions, ignoring test transactions, or keeping all funds in one address. Users should also be careful with wallet-drainer signatures, which may not look like ordinary transfers but can still grant harmful permissions.
A stronger self-custody habit is to separate daily activity from long-term storage. Use one wallet for DeFi, a different wallet for medium-term transfers, and deeper cold storage for assets that do not need frequent movement. The more often a wallet interacts with new contracts, airdrops, bridges, or unknown apps, the less suitable it is for long-term savings.
The bottom line for 2026 custody planning
The central lesson from recent crypto thefts is that custody security must be tested as a process, not assumed from a label. Cold storage, multisig, MPC, audits, and regulated custody can all be valuable, but each can fail if governance, transaction verification, vendor risk, or incident response is weak.
For individuals, the priority is to eliminate preventable mistakes: protect the seed, verify every approval, separate risky activity from savings, and plan recovery before it is needed. For institutions, the priority is to reduce single points of failure across signers, devices, interfaces, policies, vendors, and emergency response. In both cases, the strongest custody model is the one that still protects assets when one layer fails.
Frequently asked questions
Is a hardware wallet enough for crypto custody security?
A hardware wallet is a strong starting point, but it is not enough by itself. Users still need safe seed backup, phishing resistance, trusted transaction verification, device security, and a recovery plan. For large balances, multisig or professionally managed custody may be appropriate.
Is MPC safer than multisig?
MPC and multisig have different trade-offs. MPC can avoid creating one complete private key and may work across many chains, while multisig can provide on-chain transparency and simpler independent verification on supported networks. The safer option depends on implementation quality, signer controls, vendor risk, and transaction approval procedures.
What is the biggest custody mistake institutions make?
The biggest mistake is treating custody as a technology purchase rather than an operating model. Institutions need policies for who can request, approve, verify, monitor, and stop transactions. They also need tested response plans for signer compromise, vendor incidents, and suspicious withdrawals.
Does proof of reserves prove a custodian is safe?
No. Proof of reserves can support transparency, but it does not automatically prove liability coverage, legal segregation, withdrawal controls, key security, insurance coverage, or operational resilience. It should be one part of due diligence, not the whole assessment.
