A hardware wallet ("HW") is a small dedicated computer whose only job is to sign transactions with a private key that never leaves the device. The market leaders — Ledger, Trezor, Coldcard, GridPlus — have spent a decade hardening this single problem. At 301-tier sizes you should be using at least one. This lesson covers what hardware wallets actually protect against, what they don't, and which design choices matter when you pick yours.
The threat model HW solves
When you sign a transaction on a desktop or phone wallet, the private key spends a few microseconds in RAM at signing time. Any malware on that device that can read process memory can capture it. Even a perfectly-clean OS is a wide attack surface: browser exploits, malicious extensions, supply-chain attacks on libraries you transitively use.
A hardware wallet moves the key into a separate physical device. The private key never appears on the computer it's plugged into. The computer sends a candidate transaction, the HW displays it on its own screen, you press a button on the device to authorise, the HW returns a signed transaction. The malware on your computer can see what you wanted to sign, but it cannot forge the signature without your physical button press.
This is the whole magic. It's not cryptographic genius — it's an air gap reduced to a USB cable.
The threat model HW does NOT solve
1. Blind signing. If you don't read the HW screen before pressing the button, all you've done is move "I trust my computer" to "I trust my computer's recommended transaction." Malware can substitute the destination address in the request the computer sends. The HW screen will show the malicious address; you have to actually read it, character by character, against a value you separately know to be correct.
The XRPL address format makes this less terrible than Ethereum's (the first and last 4 characters of an r-address are recognisable), but it still requires the discipline to look.
2. Supply-chain attacks. A used HW bought from eBay can be pre-tampered to leak signed transactions. Buy from the vendor directly. Verify the tamper seal. If the device was open-in-box when you got it, return it.
3. Firmware compromise. Every HW vendor has had firmware bugs. Ledger had a key-leak path in 2018; Trezor had a glitch attack in 2019; Coldcard had a brick bug in 2022. Keep firmware updated, but read the changelog for each update first — never blind-install over the air for high-value keys.
4. Coercion. Same caveat as multisig. The HW does not refuse a transaction you authorised under threat. A separate "duress PIN" (which some HWs support) shows a decoy wallet, but a sophisticated attacker knows about that feature.
Choosing your hardware
Three criteria that matter, in order of importance:
1. Vendor diversity. If you're using a multisig and all five keys are on Ledger devices, a Ledger firmware compromise nukes everything. Split between vendors: 2 Ledgers + 2 Trezors + 1 Coldcard is more resilient than 5 of any one.
2. Display size and supply-chain hardware. A device with a tiny screen that can't fit the full destination address is a device that trains you to skip verification. A device with a secure-element chip (e.g. the Ledger SE) is harder to physically attack than a generic microcontroller. Look at the device's screen before you buy and confirm it shows full r-addresses without scrolling.
3. Open-firmware option. For your most-trusted device (the one that holds the longest-term cold storage), consider one with open-source firmware (Trezor, Coldcard). Open firmware is auditable; closed firmware requires trust in the vendor's release process. Both are usable; the open option is the higher-discipline choice.
The setup hygiene checklist
- Generate the seed on the device, not on a computer. Any HW you buy must let you create the wallet on-device. Never type a seed phrase into a computer that's connected to the internet, ever, for any reason.
- Verify the seed on a fresh restore. After you've written the seed down, wipe the device and restore from your written copy. If it doesn't restore to the same addresses, your written copy is wrong. Many losses come from a seed that was almost correct.
- Store the seed apart from the device. A HW + its seed phrase together is a single point of failure. Apart they are two.
- Test a small transaction first. Send €5 to and from the HW before you load it up. This catches "wrong derivation path" mistakes that would otherwise lose the entire balance.
The HW is not your entire security story — it's one layer in a 301-tier stack that also includes multisig, social recovery, and the annual drill. Treat it that way and it works. Treat it as a magic bullet and you'll eventually hit a case it doesn't cover.