Crypto Wallet Security Guide

Whoever controls a wallet's private key controls the funds, and a blockchain will not reverse a transfer that the key signed. That makes a signing key the most privileged credential most organisations will ever hold: there is no help desk, no chargeback and usually no second chance. This guide covers how wallets and seed phrases work, custody models from hardware wallets to MPC and smart contract accounts, organisational key management, signing hygiene, wallet supply chain risk, and recovery and custody standards. It is for security teams, treasury operations and individuals who hold their own keys. Scams and wallet drainers are covered separately in the Crypto Scam and Drainer Guide.

Key takeaways

• The seed phrase is the wallet. A BIP-39 recovery phrase regenerates every key derived from it, so anyone who reads it owns the funds on every device and every chain that wallet uses.
• Custody is a design choice, not a product. Custodial, hardware, multisig, MPC and smart contract accounts each move the single point of failure somewhere different; pick the model whose failure you can manage.
• Signing is where well-protected keys still lose funds. Hardware and multisig only help if each signer verifies what the device shows; blind signing and trusted web interfaces undo them.
• Wallet software is supply chain. Extensions, connector libraries and signing front ends change constantly, and their publishing credentials are as sensitive as the keys they handle.
• Recovery must be designed before it is needed. Tested backups, quorum recovery and inheritance plans decide whether a lost device, departed signer or death becomes a permanent loss.

Wallet types and custody models

A wallet holds or controls keys, not coins. What matters is who holds the key material, where signing happens and what policy sits in front of it.

A traditional externally owned account (EOA) is just a key pair. As ethereum.org puts it, "If you lose your keys they can't be recovered", and a stolen key gives the thief immediate control. Every model above is a way of putting process, redundancy or policy around that fact.

How seed phrases and HD wallets work

• BIP-39 mnemonic: the wallet generates 128 to 256 bits of entropy (12 words for 128 bits, 24 words for 256), appends a checksum (the first ENT/32 bits of its SHA-256 hash) and splits the result into 11-bit groups, each an index into a 2,048-word list. The phrase is stretched into a 512-bit seed with PBKDF2 using HMAC-SHA512 and 2,048 iterations, with the salt "mnemonic" plus an optional passphrase.
• BIP-32 hierarchical deterministic (HD) wallets: one seed derives a tree of keys. Extended keys carry a chain code and serialise as xprv (private) or xpub (public). BIP-44 conventions organise the tree as purpose, coin type, account, change and address index.
• Extended public keys are sensitive: an xpub reveals every address and the full transaction history of that account. Worse, BIP-32 warns that knowledge of a parent extended public key plus any non-hardened child private key "is equivalent to knowing the parent extended private key". Hardened derivation is used at the account level for this reason. Share account-level xpubs only with watch-only tools and auditors who need them.
• The optional passphrase: BIP-39 notes that "every passphrase generates a valid seed", so a passphrase creates a separate hidden wallet. It defends against theft of the written phrase, but there is no checksum: a mistyped or forgotten passphrase silently opens an empty wallet, and the funds are lost.

Seed phrase handling and backups

• Generate on the signing device: never accept a pre-printed phrase, a phrase from a website or a "pre-configured" device.
• Never digitise it: no photos, cloud notes, email drafts or screenshots; infostealers hunt for these. See the Infostealer Threat Guide.
• Use durable media: stamped or engraved metal survives fire and water better than paper. Store copies in at least two separate secure locations.
• Separate the passphrase from the phrase: if a passphrase is used, store it apart from the words, and make sure the recovery plan says where both are.
• Split rather than copy where it matters: SLIP-39 standardises Shamir's secret sharing for HD wallets, with group and member thresholds (for example 2-of-3 shares) and shares of 20 or 33 words. SLIP-39 is not compatible with BIP-39 in most respects, so the choice is made at wallet creation. Splitting the 24 words into thirds by hand is not secret sharing: each fragment leaks a large part of the secret.
• Test recovery before funding: restore the wallet from the backup on a second device (or the same device after a reset) while the balance is still small, and confirm the first receiving address matches.

Smart contract wallets and account abstraction

ERC-4337 (Final) adds account abstraction "without modifying Ethereum's core protocol". Users submit a UserOperation to a separate mempool; bundlers package them into a call to the singleton EntryPoint contract, which runs each account's validateUserOp before execution. Paymasters can sponsor gas and factories deploy accounts. The specification lists "different signature schemes, multisig configuration, custom recovery" as benefits. ethereum.org records the EntryPoint reaching Ethereum Mainnet on 1 March 2023.

EIP-7702 (Final, shipped in the Pectra upgrade in May 2025) lets an ordinary EOA delegate its code to a smart contract through a signed authorisation in a new transaction type (0x04). It brings smart account features to existing addresses, and a new risk.

• Delegation is total: the specification warns that a poorly implemented delegate can "allow a malicious actor to take near complete control over a signer's EOA", and states that "Applications must not expect that they can suggest the user sign an authorization." Treat any request to sign a 7702 authorisation from a website as hostile unless it comes from the wallet's own upgrade flow.
• Scope authorisations: a chain ID of 0 makes an authorisation valid on every chain; a specific chain ID limits it. Delegating to the zero address clears a delegation.
• Audit the contract, not just the key: smart accounts move risk into code. Prefer audited, widely deployed account implementations, restrict who can install modules or upgrade the account, and put a time lock on changes to owners, guardians and recovery settings.

Key management for organisations

Organisations combine three building blocks, often in layers: hardware security modules (HSMs), multi-party computation (MPC) and on-chain multisig, governed by a policy engine.

• Curves and validation: Bitcoin and Ethereum use secp256k1. NIST SP 800-186 states that this curve "is allowed to be used for blockchain-related applications", which matters for regulated buyers checking HSM configurations. NIST's CMVP has validated against FIPS 140-3 since 22 September 2020, and FIPS 140-2 certificates move to the Historical list after 21 September 2026.
• Threshold cryptography is maturing: NIST describes threshold schemes as applying multi-party computation principles to achieve "a secure distribution of trust", and published NIST IR 8214C, its First Call for Multi-Party Threshold Schemes, in January 2026. Ask MPC vendors which protocol they implement, whether it has been independently reviewed, and how shares are refreshed.
• Quorums and segregation: separate the people who propose, approve and administer. No individual should be able to both change the policy and approve a payment under it. Spread approvers across teams, locations and devices. See the Segregation of Duties Guide.
• Wallet tiers: cold reserves (offline, quorum-controlled, slow by design), warm wallets for scheduled movements and hot wallets holding only a day's needs, refilled under quorum.
• Key ceremonies: scripted, witnessed, on clean hardware, with a signed record.

Choosing a model

• Individuals: a hardware wallet with a tested metal backup; add a passphrase or a 2-of-3 multisig once holdings would be painful to lose.
• Small organisations: a qualified custodian, or an on-chain multisig with hardware signers held by at least three named people and a written signing procedure. Avoid building MPC in-house.
• Large or high-volume operations: MPC or HSM-backed signing behind a policy engine for hot and warm flows, with cold reserves under multisig or a separate custodian so one platform failure cannot reach everything.
• Choose MPC over multisig when you need many chains, privacy of the signing policy or frequent signer rotation; choose multisig when you want policy enforced by the chain and independence from a single vendor.

Transaction signing hygiene and blind signing

Blind signing means approving a hash or raw call data the device cannot decode. ERC-7730 (Draft) defines JSON descriptors that let wallets render contract calls and EIP-712 typed messages in readable form, describing "Properly validating a transaction on a hardware wallet's screen (also known as Clear Signing)" as a security practice.

• Verify on the device: read destination, amount, token, network and function on the hardware screen, not the computer. If the device cannot show it, do not sign.
• Disable blind signing by default: enable it only for a specific, understood transaction, then disable it. Ban it on treasury wallets.
• Independent verification for multisig: at least one signer should recompute the transaction or safe hash with a separate tool on a separate machine and compare it with what the hardware device shows.
• Simulate first: check expected balance changes, and treat any approval, permit, ownership or delegation change as spending authority.
• Connection hygiene: WalletConnect's Verify API labels a requesting domain as VALID, UNKNOWN, INVALID or isScam, and wallets should warn on the last three. It is, in WalletConnect's words, "not designed to be bulletproof but to make the impersonation attack harder."
• Dedicated signing devices: no email, chat or browsing on signer machines. See the Endpoint Security Guide.

Wallet software supply chain

Wallet extensions, connector libraries and multisig front ends ship code that sits between the user and the key, and attackers have repeatedly hijacked the publishing path. The Ledger Connect Kit npm compromise shipped a drainer through a former employee's unrevoked npm access, and the Lottie Player npm compromise pushed a drainer to websites with a developer's stolen access token.

• For users: install wallets from the vendor's site or verified store listing, buy hardware from the manufacturer or authorised resellers and keep firmware current.
• For organisations embedding wallet libraries: pin exact versions, use lockfiles and Subresource Integrity for any script loaded from a CDN, and review diffs before upgrading. See the Open Source Security Guide.
• For wallet publishers: require phishing-resistant MFA and short-lived, scoped tokens for package publishing, sign releases and record build provenance, and remove access on the day a person leaves. See the SLSA and Build Provenance Guide and the CI/CD Pipeline Identity Security Guide.
• For signing front ends: host treasury signing interfaces you control or verify independently, because a tampered interface can show one transaction and request another.

Where identity fits

A signing key is a privileged credential with no revocation, so wallet security is privileged access management in its purest form.

• Key holders are privileged identities: signers, policy administrators and recovery share holders need named accounts, phishing-resistant MFA on every supporting system and leaver processes that rotate them out of quorums immediately. See the Privileged Access Management Guide and the Hardware Security Keys Guide.
• Automated signers are non-human identities: hot wallet services, trading bots and payment engines authenticate to MPC or HSM platforms with API keys, certificates or cloud roles. Vault them, scope them to policy-limited wallets and rotate them. The BitMart hot wallet hack shows what one stolen hot wallet key is worth. See the Secrets Management Guide.
• Custodial accounts are identity accounts: exchange and custodian logins need passkeys or security keys, withdrawal allowlists and delays on allowlist changes. The Coinbase insider breach shows customer data leaking through bribed support agents, which is why custodial customers should expect impersonation attempts.
• Lifecycle discipline: generation, storage, rotation, compromise response and destruction follow the usual key lifecycle. See the Cryptographic Key Management Guide.

Recovery, inheritance, insurance and custody standards

• Recovery design: decide in advance how each wallet survives a lost device (restore), a lost backup (move funds to a new wallet), a departed signer (replace under quorum) and a compromised key (sweep to a prepared wallet).
• Inheritance: a sealed letter of wishes stating what exists and where, held separately from secrets; a multisig where an executor or professional holds one key; or a custodian with named beneficiaries. Never put a seed phrase in a will, which may become a public record after probate.
• Smart account recovery: program guardian or backup-key recovery with a delay so the real owner can cancel a hostile attempt.
• CryptoCurrency Security Standard (CCSS): maintained by the CCSS Steering Committee, current version 9.0, with certification at Level 1, 2 or 3, each "building on the requirements of the previous one." Its v9.0 aspects cover key and seed generation, wallet creation, key storage, key material access, key usage, key compromise protocol, security audits, data sanitisation, proof of reserve and audit logs. Level 2 adds controls such as geographic separation of key backups and quorum-based keyholder authorisation. Use it to question custodians or as an internal baseline.
• Insurance: check what a custodian's policy covers, what it excludes (account takeover and social engineering are common exclusions) and the insured amount relative to assets held. See the Cyber Insurance Guide.

Rolling out a wallet security programme

1. Inventory: every wallet, chain, balance, custodian, signer, key share, backup location, xpub shared with a tool and API credential that can trigger signing.
2. Classify and tier: set value limits for cold, warm and hot tiers and move excess balances to cold storage under quorum.
3. Pilot the new model: stand up the multisig, MPC or custodian arrangement on testnet or with a small balance. Run a full cycle: deposit, signed withdrawal, signer replacement and recovery from backup.
4. Write the signing procedure: include on-device verification, independent hash checks and a deliberate wrong-destination drill that every signer must reject.
5. Migrate in tranches: move funds in increasing amounts, confirming receipt and control after each. Keep the old wallet and its backups intact until the new one has completed a recovery test, which is the rollback path.
6. Retire and review: mark emptied addresses decommissioned, revoke their approvals and destroy obsolete backups under witness; review signers, policies, allowlists and insurance quarterly.

Detection and measurement

What to monitor: transfers to non-allowlisted destinations; changes to multisig owners, thresholds, modules or 7702 delegations; policy and allowlist changes; new token approvals; rejected signing requests; signing-platform API use from unexpected sources; and wallet library version changes in production.

Common failure patterns

• Trusting the interface: in the Bybit hack, a wallet developer's AWS session tokens led to a tampered signing interface, and multisig signers approved a malicious transaction. The FBI attributed the roughly $1.5 billion theft to North Korea's TraderTraitor activity.
• Seed phrase in the cloud: a photo or note of the recovery phrase synced to a cloud account turns an email compromise into a wallet loss.
• Single-key hot wallets with large balances: one compromised server or key drains everything because no quorum or limit sits in front of it.
• Forgotten access: former staff left as signers, policy admins or package publishers.
• Untested passphrases and backups: a passphrase nobody wrote down, or a backup never restored, discovered only when the device fails.

Framework mapping

Practitioner checklist

• Inventory every wallet, signer, key share, backup and signing API credential, with a named owner for each.
• Generate seed phrases on the signing device only, store them on durable offline media in two locations and never digitise them.
• Test recovery of every wallet from backup before funding it and at least annually.
• Hold reserves under multisig, MPC or a qualified custodian with quorums spread across people, teams and locations.
• Separate policy administration from transaction approval and require two people for allowlist or signer changes.
• Disable blind signing on treasury wallets and require on-device verification plus an independent hash check.
• Pin and review wallet library versions, and protect package publishing with phishing-resistant MFA and short-lived tokens.
• Remove departing staff from quorums, policy engines and publishing rights on the day they leave.
• Document recovery and inheritance arrangements, and check custodian insurance scope against assets held.
• Benchmark custody controls against CCSS and rehearse a key compromise once a year.

Standards and references

• Bitcoin BIPs: BIP-39 Mnemonic code for generating deterministic keys
• Bitcoin BIPs: BIP-32 Hierarchical Deterministic Wallets
• Ethereum Improvement Proposals: ERC-4337 Account Abstraction Using Alt Mempool
• Ethereum Improvement Proposals: EIP-7702 Set Code for EOAs
• Ethereum Improvement Proposals: ERC-7730 Structured Data Clear Signing Format
• NIST CSRC: Multi-Party Threshold Cryptography
• NIST CSRC: Cryptographic Module Validation Program
• CryptoCurrency Certification Consortium: CryptoCurrency Security Standard (CCSS)

Related NHI Mgmt Group resources: Crypto Scam and Drainer Guide · Cryptographic Key Management Guide · Hardware Security Keys Guide · Privileged Access Management Guide · Secrets Management Guide