A hardware wallet is not “secure” in the abstract. It reduces specific failure modes under specific operating assumptions. The device can isolate signing keys and provide an independent approval screen, but it cannot repair a disclosed recovery phrase, understand an unsupported smart-contract action or rescue an undocumented inheritance plan.
This matrix is a reusable decision tool. Use it before comparing brands, after changing a custody setup and whenever the amount at risk becomes materially larger.
How to use this matrix
- Identify exposure: mark the threats that are plausible in your actual workflow, not every theoretical attack.
- Rank the consequence: ask whether the failure would cause inconvenience, temporary loss of access or permanent asset loss.
- Check recovery: decide whether you could detect the failure and move funds before the attacker or failure mechanism wins.
- Add one control at a time: every extra device, share, passphrase or person can reduce one risk while creating another.
- Test the complete process: a control does not exist operationally until it has been rehearsed.
Priority rule: start with failures that combine permanent loss, realistic exposure and weak recovery. Do not begin with the most sophisticated feature on the product page.
Hardware wallet threat model matrix
| Failure mode | Exposure signal | What the hardware wallet can reduce | Residual risk | Additional control | Failure response |
|---|---|---|---|---|---|
| Malware on the phone or computer | The same device is used for downloads, browser extensions, email and crypto transactions. | Keeps signing keys outside the general-purpose device and provides a separate approval screen. | Malware can replace an address or construct a dishonest transaction that the user still approves. | Verify asset, network, amount, destination and contract intent on the signer—not only on the computer. | Stop signing, verify the wallet software source and move funds only through a known-clean workflow if transaction integrity is uncertain. |
| Recovery phrase theft | The phrase has been photographed, typed, printed, uploaded, shared with support or stored where another person can copy it. | Nothing after the complete recovery secret is exposed. | A PIN, secure element and device possession no longer protect the wallet. | Create and store recovery material offline; separate any passphrase instructions from the seed. | Create a new wallet from fresh entropy and move assets before investigating who obtained the old secret. |
| Fake wallet software or phishing | Setup begins through a search advertisement, unsolicited message, support chat or unfamiliar domain. | A trusted screen may reveal a substituted address, but it cannot identify every fraudulent interface. | The user can still disclose recovery material or approve an attacker-controlled destination. | Bookmark official software sources, verify signatures where supported and remember that legitimate support never needs the recovery phrase. | Disconnect, preserve evidence and rotate the wallet immediately if any secret was entered outside the device. |
| Supply-chain substitution | The device came from an unknown marketplace seller, arrived initialized or included prewritten recovery words. | Authenticity checks and expected first-boot behaviour can expose some tampering. | Packaging seals and appearance alone are weak evidence. | Buy from the manufacturer or a clearly authorized seller, initialize the device yourself and run the official authenticity process. | Do not fund the device. Replace it through a trusted channel and create new recovery material. |
| Physical theft of the device | The device is carried frequently, stored with identifying records or left where an attacker has uninterrupted access. | PIN retry controls and hardened hardware can raise the cost of extracting keys. | No consumer device guarantees indefinite resistance against a capable attacker. | Keep the PIN and backup elsewhere, maintain a tested replacement path and minimize public disclosure of holdings. | Restore from the backup on a trusted replacement and rotate to a new seed when custody or extraction risk is uncertain. |
| Malicious dApp or token approval | The savings wallet regularly connects to new applications, bridges, mints or unfamiliar contracts. | May display human-readable transaction intent when the chain, wallet and integration support it. | Unsupported contract data, blind signing and unlimited approvals can still authorize loss. | Use a separate activity wallet, cap approvals, review allowances and keep meaningful savings away from routine dApp interactions. | Revoke approvals where useful, move remaining assets to a clean wallet and investigate every related signature. |
| Wrong network, address or memo | The transfer involves multiple networks, exchange deposit instructions, destination tags or a first-time address. | The screen can verify the address and transaction details supplied to the signer. | It cannot confirm that the destination service supports the selected network or that an exchange memo is correct. | Match the network at both ends, verify required tags and send a small test transaction first. | Stop further transfers and contact the receiving service with the transaction ID; recovery may be impossible or discretionary. |
| Fire, water or physical destruction | The device and complete backup are stored in the same building or container. | The device is replaceable when compatible recovery material survives. | A hardware wallet does not protect a nearby paper backup from the same event. | Use durable, geographically separated recovery storage without placing the complete secret in an easily stolen online location. | Restore on a compatible wallet and verify known addresses before moving assets. |
| Forgotten or mistyped passphrase | The passphrase exists only in memory, uses ambiguous characters or has never been restored on a second device. | Nothing. Every passphrase generates a valid but different wallet. | The device cannot distinguish a typo from the intended hidden wallet. | Document the recovery process securely, avoid improvisation and perform a controlled restore before significant funds depend on it. | Reconstruct the exact process from preserved records; repeated guessing can create false confidence because every entry opens a wallet. |
| Backup process misunderstood | The user has recorded words but does not know the standard, share threshold, passphrase use or compatible recovery software. | Vendor backup checks can identify some transcription errors. | A readable backup may still be incomplete, incompatible or operationally unusable. | Record the backup standard, share threshold, derivation requirements and compatible recovery options without exposing the secret. | Run a controlled recovery drill and correct documentation before increasing the balance. |
| Manufacturer shutdown or abandoned software | The setup depends on one companion app, proprietary service or undocumented recovery path. | Standards-based seeds and documented derivation paths can preserve recovery independence. | Firmware delivery, transaction construction and unusual assets may become difficult to support. | Confirm standards, export public account information where appropriate and record compatible alternatives before a crisis. | Restore or connect through a compatible maintained wallet, verify addresses and migrate when long-term support is doubtful. |
| Inheritance failure | Only the owner knows that assets exist, which devices matter or how the recovery process works. | Can keep an online private key away from one person or one computer. | The device does not teach heirs what exists, where instructions are or which steps are dangerous. | Separate instructions from secrets, define responsible people and rehearse the process without exposing live funds. | Use the documented recovery path and obtain qualified legal or technical help before experimenting with the only copy of a secret. |
| Coercion or targeted theft | Holdings, identity and location are publicly connected, or one person controls the complete recovery path. | Some setups support passphrase wallets, duress controls or distributed signing. | Complexity can create self-lockout and does not remove physical risk. | Reduce public exposure, distribute authority where justified and obtain professional planning for material balances. | Follow a preplanned safety process; do not improvise a complex wallet structure during an active threat. |
| Multisig coordination failure | Several signers or locations exist, but descriptors, policies, device compatibility or succession responsibilities are undocumented. | Prevents one device or key from being the sole signing authority. | Losing metadata, too many shares or access to required locations can make recovery impossible. | Preserve wallet policy and descriptors, test replacement signers and assign responsibilities. | Use remaining quorum to rotate to a new policy before another signer or record is lost. |
| Operational complexity | The process contains steps the owner skips, cannot explain or has not repeated since setup. | A well-designed device can make common actions clearer. | No product removes the risk created by an unusable recovery architecture. | Prefer the simplest design that controls the dominant failures and can be operated under stress. | Simplify the system while access is healthy; do not wait for an emergency to discover that the process is incomprehensible. |
Control types: prevention, detection and recovery
A resilient custody system does not rely on prevention alone.
- Prevention controls reduce the chance of failure: offline key generation, verified software, separate activity wallets and distributed authority.
- Detection controls reveal that something is wrong: a trusted display, address comparison, approval review, authenticity checks and balance monitoring.
- Recovery controls limit permanent loss after failure: tested backups, compatible restoration paths, replacement devices, documented policies and rehearsed succession.
A setup with excellent prevention but no tested recovery remains fragile. A setup with many backups but no privacy controls may simply create more copies for an attacker to find.
Three-step threat prioritization
1. Consequence
Would the event cause temporary inconvenience, delayed access, partial loss or permanent loss? Permanent-loss scenarios receive priority even when they are less frequent.
2. Exposure
How often does the workflow encounter the threat? A person who signs DeFi transactions every day has a different exposure from someone who makes two Bitcoin transfers per year.
3. Recoverability
How quickly would the failure be detected, and could funds be moved before the loss becomes irreversible? A stolen device with a secure backup may be recoverable. A copied recovery phrase may not be.
Choose the top three combinations of high consequence, real exposure and weak recovery. Build controls for those first.
Reference architectures
Simple long-term self-custody
- One reputable hardware signer with an independent screen
- Offline recovery material stored separately from the device
- No routine dApp interaction from the savings seed
- A documented and tested restore process
- A basic inheritance instruction that does not reveal the secret
Active multi-chain and DeFi use
- A low-value activity wallet for applications and approvals
- A separate hardware-protected savings wallet
- Transaction-intent review on the trusted display where supported
- Approval limits and periodic allowance review
- A defined process for moving assets after a suspicious signature
Bitcoin-only cold storage
- A Bitcoin-focused signer and a watch-only transaction coordinator
- Tested PSBT or equivalent signing workflow
- Recovery records that preserve the required wallet policy and derivation information
- Geographically separated recovery without unnecessary online copies
- Regular small recovery and signing drills
Material family or organizational holdings
- Distributed signing authority where the operational burden is justified
- Preserved wallet policy, descriptors and replacement procedures
- Named responsibilities and succession instructions
- Independent legal, tax and security review appropriate to the jurisdiction
- A migration plan that can be executed before quorum or institutional access is lost
Minimum acceptance test
- Initialize the device yourself using official software.
- Create recovery material offline.
- Verify a receiving address on the hardware-wallet screen.
- Send a small amount using the intended network.
- Run the manufacturer’s backup check or perform a controlled restore.
- Confirm the restored wallet produces the same known addresses.
- Test the normal signing path without relying on memory or undocumented steps.
- Record the backup standard, passphrase use, wallet policy and compatible recovery options.
- Separate the device, recovery material and any passphrase instructions.
- Explain the recovery process to the responsible future operator without exposing live secrets.
Incident-response order
When compromise is suspected, the order of operations matters:
- Protect remaining assets: stop signing and move funds to a fresh, verified wallet when the recovery secret may be exposed.
- Preserve evidence: save transaction IDs, domains, messages and device details without continuing to interact with the suspected attacker.
- Revoke or isolate: remove relevant approvals and stop using compromised software or accounts.
- Rebuild from trusted components: use official software, fresh recovery material and a documented process.
- Review the failed assumption: identify which control was missing or misunderstood before returning funds to the new setup.
Related research
- Hardware Wallet & Self-Custody Guide
- Best Hardware Wallets by Threat Model
- Can a Hardware Wallet Be Hacked?
- What Air-Gapped Hardware Wallets Actually Protect
- Hot Wallet vs Cold Wallet
- Move Crypto Off an Exchange Safely
- Seed Phrase vs Passphrase
- Multisig vs Passphrase
- What Happens If You Lose a Hardware Wallet?
- What If the Wallet Company Shuts Down?
Research-use note
This matrix is designed to separate a control from the claim that it solves every custody risk. Cryptophia Research evaluates a control by the failure it can reduce, the assumptions required for it to work, the residual risk that remains and the new complexity it introduces.
Readers, researchers and educators may link to this page as a threat-modeling reference. See How We Research for the evidence and editorial standards used by Cryptophia Research.
This framework is educational. It is not a security guarantee, legal advice or personalized financial advice.