Hardware Wallets: What They Actually Protect

Everything a hardware wallet promises reduces to one property: there exists a display you can trust that is not controlled by your computer. If that property fails, the device provides almost nothing, no matter how well the key is protected.

The attack it exists to stop

Address substitution is the most productive attack against ordinary users, because it needs no cryptography. Malware watches for a crypto address, replaces it at the moment of display or copy, and lets you authorise a payment to an address you believe is yours.

This is not theoretical. In documented cases against shipped hardware wallets, the receiving address was generated by code running on the host computer, which meant malware could substitute it before the user ever saw it. In at least one such case the attack required no administrative privileges — the wallet’s files sat in a user-writable directory with no integrity checking, so a very small script was sufficient. The substitution also regenerated the QR code, so both the text and the scannable code agreed with each other and disagreed with reality.

Blind signing

A related failure: when a device cannot parse what it is being asked to sign, it may present a hash rather than a human-readable summary. Approving that is signing a blank cheque — the trusted screen is present but has nothing meaningful to show. Where a device offers a “blind signing” toggle, leaving it off is the safe default, and needing it on is a signal that the operation deserves more scrutiny.

The corollary

If an attacker gains control of the display, the entire model collapses — not partially, but completely, because every check you perform routes through the thing they control. This is why the architecture questions in the Advanced section matter: which chip drives the screen, and what proves the code doing so is authentic, are not incidental engineering details. They are the security model.

Between the factory and your hands, a device passes through a supply chain you cannot observe. Supply-chain attacks are attractive because they arrive before every defence you would otherwise have: before your PIN, before your careful setup, before your first transaction.

What seals prove

Less than people assume. Holographic stickers are commercially available and reproducible. “Sealed” shrink wrap can be reapplied with a heat gun. Their real function is raising effort slightly and creating a story users can check — not providing a cryptographic guarantee.

Some vendors omit seals deliberately, arguing that cryptographic attestation makes them unnecessary. That is a coherent engineering position, and it shifts the entire burden onto attestation actually covering the whole device — a question examined in the Advanced section, where the answer has historically been “less than advertised”.

The channel almost nobody considers

Read the vendor’s returns policy. Many accept returns within a window provided the packaging appears unopened, and return those units to inventory. For a monitor or a graphics card, that is ordinary retail practice. For a device that exists to hold secrets, it means the unit you receive may have spent a fortnight in a stranger’s possession — and an attacker prepared to buy, modify, repackage, and return devices has a cheap, repeatable channel with a plausible payoff, since these products are bought disproportionately by people holding significant sums.

Ask what a vendor does with returned units. It is a question with a specific, checkable answer, and very few buyers ever ask it.

The robust response

You cannot verify provenance. You can make it not matter:

• Always generate the seed yourself after receipt. A pre-set phrase is the single clearest sign of compromise.
• Assume the device may be modified and keep the seed independent of it, so a suspect unit costs you a device rather than a balance.
• Use vendor-diverse multisig for meaningful sums, so that one compromised supply chain is insufficient.
• Buy devices at a different time and place from when you fund them, breaking the link between a delivery and a large deposit.

Updates fix real vulnerabilities — including the physical attacks described later in this guide. Refusing to update leaves you exposed to known issues. But updating is also the moment when new code is written to the device that holds your key, and it is the single most concentrated point of risk in normal operation.

There is a persistent pattern of users reporting losses shortly after an update. Multiple explanations fit — phishing timed to update announcements, fake update prompts, coincidence and reporting bias, and in some cases acknowledged bugs where devices reset to factory state during the update process. The point is not to assign blame. The point is that this is empirically the window in which things go wrong, so it deserves deliberate handling rather than a reflexive click.

Updating safely

1. Never update from a prompt that surprised you. Close it. Go to the vendor’s site yourself and confirm the release exists.
2. Wait. Unless the update fixes something actively exploited, let it sit for a week or two. Problems surface in community channels quickly.
3. Verify before installing. Check signatures and hashes on the companion software.
4. Confirm your backup first. Have the phrase in hand and confirm it is correct before you begin, because a mid-update failure may require a restore.
5. For large holdings, move funds first. Transfer to a different key, update, verify the device behaves correctly, then move back. Tedious, and it eliminates the entire class of risk.
6. Verify addresses again afterwards. Confirm the device derives the same addresses it did before.

What the PIN does

The PIN protects against someone who physically has your device and wants to use it casually. It is combined with escalating delays between attempts and, on most devices, a wipe after a set number of failures — which is safe precisely because you hold the seed elsewhere and can restore.

What the PIN does not do is protect the seed against an attacker with laboratory equipment. Against that threat, the relevant defences are the chip architecture and the passphrase, not the PIN.

The passphrase is widely misunderstood

The optional BIP39 passphrase — the “25th word” — is genuinely powerful and causes more accidental losses than almost any other feature, because two different purposes get presented as one.

Both uses are technically valid — any passphrase produces a distinct wallet. The problem is that the framing changes how carefully people treat it. A user who believes they are setting a device password does not back it up. A user who believes they are strengthening their seed does.

The rule that prevents all three: if you do not understand exactly what a feature does, do not enable it. If you do use a passphrase, treat it as a second secret with the same backup discipline as the seed itself — stored separately, so that one location never yields both. Full treatment in The 25th Word.

Since the seed is the asset, the medium holding it is the real security product in your setup. Evaluate it against threats that operate on a multi-decade timescale.

The labelling problem

A backup that announces itself defeats much of its own purpose. The card supplied with many devices is printed with the brand name and phrases like recovery seed in large type, sometimes alongside warnings not to share it — which conveniently informs anyone who finds it that they have found something worth taking.

The goal is a backup that looks like nothing. Approaches range from the improvised — words marked inconspicuously within an ordinary pocket dictionary or a language notebook, kept among similar items rather than in a safe — to purpose-built solutions that store words as index numbers or binary patterns rather than readable text. A thief who finds a metal card covered in dots has found an object with no obvious value; a thief who finds a card headed BITCOIN RECOVERY SEED has found instructions.

Multiple copies, separated

One backup is a single point of failure for the thing that cannot be replaced. Two or three copies in genuinely separate locations protect against fire, flood, and loss. The trade-off is that each copy is another place a thief can succeed — which is one of the clearest arguments for multisig, where no single recoverable location is sufficient.

An untested backup is a hypothesis. Most people discover a transcription error, an ambiguous character, or a forgotten passphrase at the worst possible moment.

The drill

1. Note your current receiving addresses.
2. Wipe the device completely.
3. Restore using only your physical backup — not memory, not a note on your phone. If you cannot complete the restore from the backup alone, it has failed, and you have learned that safely.
4. Confirm the addresses match and the balance appears.
5. If you use a passphrase, verify the hidden wallet too.

Frequency and scope

• Immediately after setup, before funding
• Annually, and after any firmware change
• After any change to your backup, its location, or your passphrase
• At least once using a different vendor’s wallet — this proves your phrase is standard and that you are not dependent on one company continuing to exist

The central hardware design decision is which silicon holds the secret. The two options carry opposite trade-offs, and the industry has argued about it for a decade without converging.

The trade is not security versus insecurity

It is which adversary you are defending against. An SE is materially better against an attacker holding your device with laboratory equipment. An open MCU is better against the possibility of undisclosed behaviour in silicon you cannot inspect. Choosing one means accepting the other’s residual risk.

The industry reversal

This tension is not academic. One major vendor spent years explaining publicly that it had evaluated secure elements, found critical flaws in every one examined, and been dissatisfied with how chipmakers responded — some declining to fix known issues, others asking that findings not be disclosed. On that basis it built its products around general-purpose chips.

That same vendor now ships secure elements in its current models.

The reversal may reflect genuinely improved silicon, or a market that came to treat “has a Secure Element” as a purchasing requirement regardless of the engineering argument. Both readings are plausible. What matters for your evaluation is the underlying lesson: architectural positions that were presented as principled security conclusions can be revised for commercial reasons. Design your setup so that being wrong about any single vendor’s architecture is survivable.

Secure elements are built for smartcards. They are excellent at protecting secrets and poor at everything else — many cannot drive a display or speak USB at all, communicating only over a slow serial link.

This creates an engineering problem. A device needs a screen, buttons, and a USB connection, and the secure chip cannot provide them. The common solution is a second, ordinary microcontroller that handles the peripherals and relays messages to the secure element.

Where the security boundary really sits

The key never leaves the secure element, which is the property vendors advertise. But the screen and buttons are wired to the other chip — the one with no special protections. Everything you rely on to verify a transaction passes through the component that is easiest to compromise.

The intended fix is attestation: the secure element challenges the microcontroller to prove it is running authentic firmware, and refuses to cooperate otherwise. When this works, it is elegant. Confidence in it has been strong enough that vendors have argued tamper-evident packaging is unnecessary, and at least one publicly told users that buying from open marketplaces was acceptable because attestation would catch a modified device.

How that was broken

In 2018 a researcher demonstrated a complete bypass on a shipping device. The essential steps generalise beyond the specific product:

1. The attestation compared a compressed image of the microcontroller’s memory. Modified firmware could be crafted to produce a matching image while behaving differently.
2. With the microcontroller compromised, the attacker controlled the display and the buttons — and therefore controlled every warning the user would have relied on, including the alert that would have flagged a non-authentic interface.
3. The onboarding flow could then be altered so that seed generation ran with entropy forced to a fixed value, producing a phrase that looked ordinary and was entirely predictable to the attacker.
4. The secure element, satisfied by the forged attestation, cooperated normally throughout.

Compromise the display and you do not need to defeat the cryptography. You only need to change what the user is told.

Why this class of flaw is hard to close

The mitigations that followed were architectural patches rather than a redesign: restructured firmware to reduce the code an attacker could reuse, and timing constraints intended to prevent the microcontroller from performing extra work while responding. The researcher noted a structural difficulty — the secure element runs at a fraction of the microcontroller’s clock speed, so a slower verifier is attempting to constrain a faster prover over a slow link. Whether such a scheme can be made robust is a genuinely open question, not a settled one.

With physical possession, an attacker is no longer limited to the interfaces the designers intended. They can manipulate the conditions the chip operates under.

Fault injection

The most practical technique against unprotected microcontrollers is voltage or clock glitching: deliberately disturbing the power supply or clock at a precisely chosen instant so the processor misbehaves. A single skipped comparison — the one checking whether a memory region is readable — can be enough to expose protected memory for the fraction of a second needed to read it out.

This is not exotic. Security researchers have publicly demonstrated seed extraction from hardware wallets using glitching, on multiple models. The equipment is affordable and the technique is well documented. Vendors have responded with meaningful mitigations, and secure elements include hardware countermeasures against exactly this class of attack — which is the strongest argument in their favour.

Side channels

Even without inducing faults, a chip leaks information through power consumption, electromagnetic emission, and operation timing. Careful measurement across many operations can recover key material or PIN digits without ever bypassing a check. Countermeasures — constant-time code, masking, randomised execution — are standard in secure elements and frequently absent elsewhere.

What this means for you

One further note on how this research reaches the public. A demonstration of a new attack against a shipping device was, by one account, made private after the researchers received a bounty from the vendor. That arrangement is normal and largely healthy — it funds research and gives vendors time to patch. It also means the absence of public attack demonstrations is weak evidence of their absence. Assume that the published attacks are a subset of the known ones.

The device and the companion application exchange structured messages, commonly over USB. Two properties of that channel deserve scrutiny.

The channel usually does not authenticate the caller

In several designs the device responds to well-formed commands without establishing which application sent them. The user-approval step is the intended defence — nothing signs without a button press — and this is why the trusted display carries so much weight.

The consequence is visible in a documented incident where a counterfeit companion application, published to a browser extension store under a plausible name, sent a device an instruction to transfer funds to an attacker’s address, and the device processed the request as it would any other. The cryptography behaved correctly; the device simply had no way to know the request came from a hostile application, and the user approved what they were shown.

Semantics are harder than cryptography

The subtler failures are not in signing but in understanding what is being signed. The clearest published example concerns change outputs.

When you spend part of a UTXO, the remainder returns to an address your wallet controls. The device must verify that the change output really does belong to you. Researchers found that some devices would accept a transaction where the derivation path for the change output was simply left empty — and would not flag it. An attacker able to manipulate the transaction being presented could direct the change to their own address while the user saw and approved a small, legitimate-looking payment.

The user sees: pay a small amount to a known address. The transaction actually says: pay a small amount to a known address, and send everything else to an attacker. The same class of issue was found in devices from more than one manufacturer, and it resurfaced years after being fixed.

Signing correctly is not the same as understanding what you signed. Most modern attacks target the second problem.

Air-gapped signing

The strongest structural answer removes the electrical connection entirely. With air-gapped signing, unsigned transactions reach the device by QR code or removable media, and signatures return the same way. There is no USB session to hijack and no driver stack to exploit.

This does not solve the semantic problem — a device that misinterprets a transaction misinterprets it identically over QR — but it eliminates an entire category of connection-layer attack, and it forces the data crossing the boundary to be small enough to reason about.

A common and mistaken instinct is to buy several units of the same device and split holdings across them. It feels like diversification. It is not.

Four identical devices share identical firmware, identical silicon, an identical supply chain, and an identical vendor. A flaw in any of those affects all four simultaneously. You have multiplied the number of objects to protect without reducing the probability that a single discovery compromises everything — and you have created four opportunities for physical theft instead of one.

Splitting funds across identical devices divides your convenience and leaves your correlated risk exactly where it was.

What actually diversifies

Real diversification requires that the failure modes be independent, which means varying the things that could fail:

• Different manufacturers — so one vendor’s firmware bug, hostile update, or supply-chain compromise is insufficient
• Different chip architectures — so one silicon flaw does not apply to every key
• Different geography — so fire, flood, burglary, or seizure reaches only one
• Different entropy sources — so a weak generator affects one key rather than all
• Different backup media — so a single medium’s failure mode does not apply everywhere

The structure that makes this pay off is multisig. In a 2-of-3 across three manufacturers, an attacker must compromise two independent organisations, and you can lose any single device or location without losing access. This is the only arrangement in which a vendor being wrong is a recoverable event rather than a terminal one.

Collaborative custody

Services exist that hold one key in a multisig arrangement while you hold the others, providing recovery assistance without custody. The model is sound: the service cannot move funds alone, and you can recover without the service. Two things to verify before relying on one: that you genuinely can recover independently if the company disappears, and that you hold the descriptor yourself rather than depending on their software to reconstruct it.

Both split or strengthen a single key. They solve different problems and fail differently.

The considerations that decide it

Shamir is genuinely better for redundancy: a 2-of-3 share scheme survives losing a location, which a single seed does not. Its cost is portability. Support is narrower than BIP39, which reintroduces a dependency on particular implementations continuing to exist — precisely the dependency the seed phrase standard was created to remove.

Passphrases are universally supported and add real protection against seed compromise. Their cost is brittleness: there is no recovery, no redundancy, and no error tolerance. Nothing warns you that you have mistyped one — you simply arrive at a different, empty wallet.

Security work should end with an honest statement of what is left. Here is what remains for a well-run single-device setup, and what each item requires to address.

Reading the table

Two things stand out. First, multisig appears against more rows than anything else — it is the single highest-leverage structural change available, because it converts vendor trust from a requirement into a preference. Second, the last two rows are not solved by technology. The breach already happened when you bought the device, and your own error is best addressed by keeping the setup simple enough that you can operate it correctly under stress, years from now, possibly by someone who is not you.