In the first six months of 2025, $3.1 billion in crypto was lost to theft and fraud. That figure, reported by security auditing firm Hacken, made the first half of 2025 the worst period for crypto crime on record. Chainalysis independently confirmed the trend, noting that losses in H1 2025 already exceeded all of 2024.
The pattern behind most of these losses is not exotic. It comes down to three failure modes: lost or compromised private keys, slow or absent incident response, and weak wallet security practices.
Each one is preventable with proper planning. This guide walks through all three areas step by step, anchored in standards you can map to your existing risk frameworks.
Why Key Recovery Is a Risk Management Problem, Not Just an IT Problem
In traditional finance, if you lose your bank credentials, the institution can reset them. Blockchain has no such mechanism. Private key loss means permanent, irreversible loss of assets. There is no central authority, no customer service line, no rollback.
An estimated 29% of all circulating Bitcoin may already be permanently inaccessible, trapped in wallets where the keys have been lost.
For institutions holding digital assets (whether pension funds evaluating crypto allocations, exchanges custodying client assets, or corporates with treasury exposure) key recovery is not a technical convenience. It is a business continuity requirement that should sit in your Business Impact Analysis alongside every other critical system dependency.
Understanding BIP-39: The Foundation of Key Recovery
Nearly every modern crypto wallet generates private keys using the BIP-39 standard (Bitcoin Improvement Proposal 39). When you set up a wallet, the device generates a random sequence of 12 or 24 words drawn from a standardised list of 2,048 words.
This sequence, called a seed phrase or recovery phrase, is the master backup for every private key the wallet will ever produce.
The process works like this. The wallet generates 128 to 256 bits of random entropy. A SHA-256 checksum is appended for integrity verification. The combined bits are split into 11-bit groups, each mapping to a specific word from the BIP-39 wordlist.
These words form the mnemonic phrase. When recovery is needed, the phrase is processed through PBKDF2 with HMAC-SHA512 (2,048 iterations) to regenerate the 512-bit seed, from which all private keys are derived.
Because BIP-39 is an open standard, the same seed phrase will regenerate identical keys on any compatible wallet. This is both the power and the danger: recovery is portable, but so is theft.
Anyone who obtains your seed phrase has complete control of every asset associated with it. For a more detailed treatment of how to protect these credentials, see our guide on private key backup and recovery procedures.
Step-by-Step Key Recovery Procedures
Step 1: Generate and record the seed phrase securely. When creating any new wallet, generate the seed phrase on-device (never on a web browser or cloud-connected machine). Write the words in exact order on a physical medium.
Best practice is metal engraving (products like Cryptosteel or Billfodl) for fire, water, and corrosion resistance. Paper works as a short-term backup if stored in a fireproof safe, but degrades over time. Never photograph, screenshot, email, or store seed phrases in any digital format, including password managers or cloud storage.
Step 2: Apply the 3-2-1 backup rule. Keep at least three copies of the seed phrase, on two different media types (for example, one metal and one paper), with one stored offsite in a geographically separate location.
For institutional holdings, consider bank safe-deposit boxes or dedicated secure storage facilities. Each storage location should have access controls and an audit trail. Your IT risk management lifecycle should capture these backup locations as critical dependencies.
Step 3: Use a BIP-39 passphrase (the 25th word). BIP-39 supports an optional passphrase (sometimes called the 25th word) that alters the root seed. The same 24 words with a different passphrase produce entirely different wallets.
This provides plausible deniability: even if someone obtains your seed phrase, they cannot access passphrase-protected wallets without the additional secret. Document the existence of the passphrase (not the passphrase itself) in your recovery notes. Losing the passphrase means permanent loss of access to the associated wallets.
Step 4: Record derivation paths. Different wallets and cryptocurrencies use different derivation paths (the BIP-44 standard defines the hierarchy as m/purpose’/coin_type’/account’/change/index).
Restoring the same seed on a different wallet application may show different addresses if the default path differs. Always record which derivation paths are in use alongside your seed phrase backup. This is a common source of confusion during recovery and can be mistaken for key loss when it is actually a configuration mismatch.
Step 5: Test recovery quarterly. Buy a spare hardware wallet. Restore from your seed phrase backup. Verify that a small test transaction can be signed. Confirm that the BIP-44 derivation path matches and all expected addresses appear.
This is the only way to be certain your backup works. Document each drill in your business continuity test log. If the drill fails, you have found the problem before it costs you assets.
Step 6: Implement M-of-N controls for institutional holdings. For significant holdings, use multi-signature wallets requiring M-of-N key holders to approve any transaction. This eliminates single points of failure. Combine multisig with geographic separation of key holders and documented key ceremony procedures.
Ensure that the loss of any single key holder (departure, incapacitation) does not lock access to assets. Your three lines of defence model should assign clear ownership: 1st line operates the wallets, 2nd line defines custody policy and monitors compliance, 3rd line audits key management controls.
Crypto Incident Response: A Framework That Moves at Blockchain Speed
Standard incident response frameworks apply to crypto, but the timeline is compressed to near-zero. On a blockchain, stolen funds can be laundered through thousands of addresses, mixers, and cross-chain bridges within minutes.
There is no “next business day” in crypto incident response. NIST recognised this urgency when it released SP 800-61 Revision 3 in April 2025, restructuring its incident response guidance around the six functions of NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond, and Recover.
Here is how to adapt that framework to digital asset incidents.
Phase 1: Preparation (Govern, Identify, Protect). Build your incident response playbook before you need it. Define who has authority to declare an incident, who leads the response, and what the escalation thresholds are.
Map your wallet infrastructure (which wallets exist, what they hold, who has access). Identify your blockchain analytics capability: do you have in-house tools (Chainalysis, TRM Labs, Elliptic), or will you need to engage an external provider under retainer?
Pre-establish relationships with exchanges (for asset freezing requests), law enforcement (for filing reports), legal counsel (for regulatory notifications), and your communications team (for public disclosure).
Conduct tabletop exercises that simulate wallet compromises. Your cybersecurity key risk indicators should include wallet-specific metrics: anomalous outbound transfers, failed multi-sig approvals, and hot wallet balance spikes.
Phase 2: Detection and Analysis (Detect). Monitor for indicators of compromise in real time. These include unauthorised transaction signing attempts, unexpected wallet balance changes, anomalous API calls to wallet infrastructure, failed authentication attempts on key management systems, and social engineering attempts targeting key holders.
CertiK reported that in 2025, the majority of crypto losses came from wallet compromises and phishing targeting individual users rather than protocol-level exploits. Your detection capability needs to cover the human layer (phishing, social engineering, insider threats) as heavily as the technical layer.
Deepfake voice phishing rose by 1,633% in Q1 2025 according to Right-Hand cybersecurity, and attackers have successfully used deepfake video calls to authorise fraudulent transfers worth millions.
Phase 3: Containment (Respond). Once a compromise is confirmed, act within minutes, not hours. Freeze all affected wallets immediately. Revoke any compromised keys or API tokens. If using multisig or MPC, disable the compromised signer’s authority.
Activate your blockchain analytics provider to begin tracing fund movements in real time. Contact any exchanges where stolen funds may land and request emergency freezes. In the Bybit incident (February 2025), $1.5 billion was stolen and $300 million became irrecoverable because it was laundered faster than containment could proceed.
The first 48 hours after a crypto incident are critical; after that window, recovery rates drop sharply.
Phase 4: Eradication and Recovery (Respond, Recover). Fix the root cause before resuming operations. If a smart contract was exploited, patch or redeploy. If keys were compromised, generate entirely new wallet infrastructure with new seed phrases. Do not reuse any component of the compromised system.
Reconcile blockchain transactions against your internal records to confirm asset balances. Reinitialise wallet infrastructure and verify cryptographic integrity. For regulatory reporting, under DORA (EU), major ICT incidents must be reported within hours.
Under NYDFS BitLicense, breaches must be reported promptly. Under GDPR, personal data breaches require notification within 72 hours. Design your response timeline to meet the most demanding of these. See our analysis of MiCA, DORA, and BitLicense regulatory requirements for detailed timelines.
Phase 5: Lessons Learned (Govern, Identify). Conduct a root cause analysis. Update your playbook based on what worked and what failed. Share findings with your board risk committee.
Chainalysis reports that 80% of its retainer clients recovered more in stolen funds than they invested in incident response services, evidence that preparation pays for itself. Update your enterprise risk management technology practices to reflect any new controls, tools, or procedures implemented post-incident.
Wallet Security: Building Defence in Depth
Wallet security is not a single control. It is a layered architecture where each layer compensates for potential failures in the others. Here is how to structure it.
Layer 1: Hardware isolation. Use hardware wallets (Ledger, Trezor, or equivalent) that store private keys in tamper-resistant secure elements. Keys never leave the device. Even if the connected computer is compromised by malware, the hardware wallet signs transactions internally.
Always verify transaction details (recipient address, amount) on the hardware wallet screen, not on the computer screen, because clipboard-hijacking malware can substitute addresses without visible indication on the host machine.
Layer 2: Firmware and software hygiene. Update wallet firmware regularly through official channels only (Ledger Live, Trezor Suite). Security patches address newly discovered vulnerabilities.
Ledger’s internal security team (Donjon) continuously identifies and patches threats. Running outdated firmware is equivalent to running an unpatched server: the vulnerabilities are known and actively exploited.
Layer 3: Authentication and access control. Set a strong, unique PIN on every hardware wallet. Enable app-based two-factor authentication (never SMS-based, which is vulnerable to SIM-swapping attacks).
For institutional wallets, implement role-based access with segregation of duties: the person who initiates a transaction should not be the same person who approves it. Your qualitative risk assessment for IT infrastructure should evaluate access controls on every wallet tier.
Layer 4: Transaction policies. Implement whitelisting (pre-approved destination addresses), time-delayed withdrawals for amounts above defined thresholds, velocity limits (maximum daily/weekly transaction volumes), and mandatory multi-signature approval for high-value transfers. These policies create friction that slows attackers even if they gain partial access.
Layer 5: Monitoring and alerting. Deploy real-time monitoring on all wallet addresses. Flag any transaction that was not initiated through your normal workflow. Set alerts for balance changes outside expected parameters.
Monitor for known malicious addresses interacting with your wallets. Integrate wallet monitoring into your broader security operations centre (SOC) or NIST cybersecurity KRI dashboard.
Layer 6: Physical security. Hardware wallets and seed phrase backups are physical assets. Store them in safes, vaults, or secure facilities with access logging.
For institutional cold storage, implement dual-custody requirements: two authorised individuals must be physically present to access the device. Geographic separation of key components (store different multisig keys in different locations) protects against localised disasters or targeted physical attacks.
Current Attack Vectors to Watch in 2026
The threat landscape shifts continuously. As of early 2026, these are the attack vectors causing the most losses.
Phishing and social engineering remain the dominant attack vector. CertiK identified wallet compromises and phishing as the source of the majority of 2025 crypto losses. Attacks have evolved beyond email: deepfake video calls impersonating executives have authorised multi-million-dollar fraudulent transfers (the Arup incident cost $25 million). Fake reCAPTCHA prompts trick users into executing malicious code.
Phishing sites clone legitimate wallet interfaces pixel-for-pixel. Training your team to verify through independent channels before authorising any transaction is the single highest-impact control you can implement.
Supply chain attacks on wallet infrastructure target the software and hardware that wallets depend on. Compromised firmware updates, malicious browser extensions posing as wallet providers, and tampered hardware devices purchased from unofficial resellers have all been documented.
Only buy hardware wallets directly from the manufacturer. Only install software from official sources. Verify checksums on every update.
Clipboard malware and address substitution silently replace copied wallet addresses with attacker-controlled addresses. The user copies their intended destination, pastes it into the send field, and unknowingly transmits funds to the attacker.
The only defence is on-device verification: always confirm the address on the hardware wallet screen before signing.
For a broader view of how these threats fit into your overall cyber risk posture, see our guide on CIS risk assessment method v2.0 and data integrity risk assessment.
Integrating Wallet Security Into Your ERM Framework
Wallet security, key recovery, and incident response should not exist as standalone procedures. They need to plug into your enterprise risk management framework as formally as any other operational risk domain.
Add wallet-related risks to your risk register with defined inherent and residual risk ratings, specific controls mapped to each risk, and clear ownership. Include key recovery RTO (how quickly can you restore wallet access from backup?) as a metric in your Business Impact Analysis.
Schedule annual wallet security assessments aligned with your ISO 27001 risk assessment methodology. Map your controls to the five-step risk management process (identify, analyse, evaluate, treat, monitor) so they integrate with your existing governance structure.
Brief your board on digital asset exposure and the adequacy of your controls, using a quantitative risk management approach to express wallet risk in financial terms.
Next Steps: What To Do This Quarter
First, inventory every wallet in your environment by type, custodian, backup method, and value held. Second, verify that every seed phrase backup is recoverable by performing a test restore on a spare device. Third, review your incident response playbook for crypto-specific procedures; if it does not have them, build them now.
Fourth, confirm your blockchain analytics capability: either in-house tooling or an external retainer. Fifth, assess your monitoring coverage: are you detecting anomalous wallet activity in real time?
Sixth, schedule a tabletop exercise simulating a wallet compromise and walk through the full response chain from detection to regulatory notification. Seventh, update your risk register with wallet-specific risks, controls, and residual ratings.
The organisations that took these steps before 2025’s wave of incidents recovered faster, lost less, and maintained stakeholder confidence. The ones that did not are still counting the cost.
Want more actionable risk content?
Explore more at riskpublishing.com. Related articles: hot wallet vs cold wallet architecture, privacy risk assessment template, GDPR risk assessment template, and ITIL change management risk assessment.
References and Further Reading
NIST: SP 800-61 Rev. 3: Incident Response Recommendations (CSF 2.0)
NIST: SP 800-57 Rev. 5: Recommendation for Key Management
Sygnia: Incident Response in Crypto: Best Practices for Readiness
Chainalysis: The Crypto Industry Needs Proper Incident Response Solutions
BitGo: Crypto Disaster Recovery: Safeguarding Your Digital Assets
Crypto ISAC: Tracing Crypto Attacks: Best Practices for On-Chain Incident Response
Ledger: Crypto Wallet Security Checklist 2026
Coin Bureau: Common Hardware Wallet Mistakes and How to Prevent Them
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.