What is worth comparing on a hardware wallet

Every hardware wallet comparison leads with the number of supported assets, because it is a large number that is easy to put in a table. It is close to the least important thing on the page.

Why no product is named here

Two reasons, and the first is about us.

This source contains an exchange referral arrangement that is not yet registered, disclosed at the top of every page. Adding device affiliate links on top of that would create another financial interest in the answer to a question readers are asking precisely because they want a disinterested one. We would rather verify the existing entry and avoid adding another relationship.

The second reason is that product recommendations decay. Firmware changes, models are discontinued, vendors are acquired, and a comparison written today describes a market that will not exist in two years. A framework for evaluating devices survives that; a list of devices does not.

So this page tells you what to compare. Comparing specific devices is then a job with an obvious right source: the vendors' own documentation, read with the questions below in hand.

One — the recovery mechanism

This is the column that decides most outcomes, and it is usually a footnote.

The device will fail eventually. It will be lost, damaged, discontinued or simply left in a drawer for five years. What determines whether that is an inconvenience or a catastrophe is entirely the recovery arrangement, and this is where the meaningful differences between products live.

Three questions:

• Is the recovery material a standard format? A widely-implemented standard means a replacement device from a different vendor can restore your holdings. A proprietary scheme means you are dependent on that vendor continuing to exist and continuing to supply devices. The relevant standards are public specifications, so the answer is checkable rather than something you take on trust.
• Can it be restored without the vendor? Ask what happens if the company is gone. If the honest answer involves their servers, their app or their support, that is a dependency the marketing did not mention.
• What is the backup medium, and how does it fail? Paper burns and is thrown out during house moves. Metal plates survive both. Digital copies fail in the way that has cost people the most: photographed for convenience, synced to a cloud account, and now exposed to anyone who compromises that account.

An honest weighting: the recovery arrangement matters more than every other column on this page combined, because it is where the losses actually happen. Most self-custody failures are not attacks. They are backups that turned out not to be backups.

Two — what you can verify on the device itself

The security argument for a hardware wallet is that the key never leaves it. That argument depends on one thing working: the device having its own screen and its own buttons.

If you can only see transaction details on a computer screen, malware on that computer can show you one destination while the device signs another. The screen exists so that the thing you approve and the thing you approve on are the same object.

So the comparison question is not "does it have a screen" but how much can you actually read on it. Specifically: does it display the full destination address or a truncated version; does it show amounts and fees in a form you can check; and for contract interactions, does it show anything meaningful about what you are authorising or only an opaque blob.

That last one separates devices considerably. A device that can only tell you "you are signing something" is protecting the key while leaving the decision unprotected, and the decision is what modern attacks target.

The corollary is a habit, not a feature: the screen only helps if you read it. Checking the first and last several characters of an address on the device, every time, is the entire defence against a class of malware that swaps addresses silently. It takes three seconds and people skip it.

Three — firmware provenance

You are trusting software you cannot see running on hardware you cannot inspect. What can be compared is how much of that trust the vendor has made checkable.

Is the firmware source public? Public source does not mean anyone has reviewed it, and it is regularly oversold on that basis. What it does mean is that review is possible, and that the vendor has accepted the constraint of operating in the open.

Can you verify that the firmware on your device is the firmware that was published? This is a different question from whether the source is public, and it is the one that connects the published code to the object in your hand. Vendors that support reproducible builds have made this checkable.

How are updates delivered and authenticated, and what happens if one fails partway through? Anything with a slow, verified, recoverable update process is preferable to something that updates silently.

Finally, whether the device uses a secure element is worth knowing without being decisive. It raises the cost of physical extraction attacks. It is also usually the least open component, which is a genuine trade-off between two things you want rather than a feature with no downside.

Four — the supply chain

The realistic attack on an individual is not a laboratory attack on a chip. It is a device that was tampered with before it reached you.

Which makes purchasing part of the comparison, and it is the part where people make an avoidable mistake by buying through a marketplace listing to save a little money or a few days.

Two things to look for. First, whether the vendor sells direct and what their guidance on authorised resellers is. Second, and more useful, whether the device can prove its own authenticity when you first set it up, through a cryptographic attestation rather than a sticker. Tamper-evident packaging has been convincingly faked; an attestation check performed by the device is a stronger signal.

The absolute rule, independent of any product: a device that arrives with a recovery phrase already written down is compromised. There is no legitimate reason for this to happen. A genuine device generates its recovery material during your setup, and nobody else has ever seen it. Any pre-supplied phrase, in any packaging, with any explanation, means someone else has a copy of your keys.

Five — asset support, which comes last for a reason

The number that leads every spec sheet belongs at the bottom, for a simple reason: it is a question about your holdings, not about the device, and most people hold a handful of assets that essentially everything supports.

The version of this question that has consequences is narrower. Does it support the specific chains you use, including the layer-two networks if you use them? Does support mean signing transfers only, or does it extend to the contract interactions you actually perform? And is the software you will use daily to talk to the device something you find tolerable, since that interface is what you will experience rather than the hardware?

Support for a thousand assets you will never hold is a large number in a table. It is not information about your situation.

Which attack you are actually buying protection from

Before comparing anything, it is worth being precise about what a hardware wallet removes, because the answer is narrower than the category's reputation suggests and it determines whether any of the columns above matter to you.

What it removes is key extraction from a general-purpose computer. Your private key never exists on a machine that runs a browser, opens attachments and installs software. Malware on that machine can see what you are doing and cannot sign anything, because signing happens on a device that does one thing and has no way to be persuaded to do another.

That is a real and significant category. It is also, for most individuals, not the category that empties accounts.

The losses that actually happen fall into two groups, and a hardware wallet addresses neither. The first is backup failure — the recovery phrase that was discarded, photographed, or split and half-lost. The device is irrelevant to this; the backup is the whole exposure. The second is authorising something you did not understand, where the device performs its job perfectly and signs exactly what you approved.

This is why the two columns weighted most heavily on this page are the recovery arrangement and what you can read on the device screen. They map to the two things that actually go wrong. Supported assets, secure element design and firmware provenance are real considerations that matter at the margin; they are not where the money goes.

Stated plainly: buying a device and keeping a poor backup makes you less safe than the arrangement you had before, because it adds an object that can be lost while creating a confidence that was not earned.

Two arrangements that change the comparison

Both of these are features on many devices, both are frequently recommended, and both are more dangerous than the material describing them tends to admit.

An additional passphrase. Most devices support extending the recovery phrase with a word or sentence of your choosing, producing an entirely separate set of accounts. Someone who obtains your recovery phrase without the passphrase finds a wallet that works and is empty, which is a genuinely useful property against physical coercion and against a discovered backup.

The danger is symmetrical and severe. The passphrase is not stored anywhere and cannot be recovered, and there is no error message for getting it wrong — a mistyped passphrase silently opens a different, empty wallet, which looks exactly like your funds having disappeared. Every character, including whitespace and capitalisation, is part of the secret. This turns one thing you must not lose into two, and it has cost people their holdings more often than it has protected them.

Multiple signatures. An arrangement requiring several keys to authorise a transaction removes the single point of failure entirely: no one device, and no one backup, can lose the funds. For a large long-term holding this is the structurally correct answer, and it is also the answer to the inheritance problem, since keys can be distributed to different people and places.

The cost is operational complexity that does not go away. Every key needs its own backup, the configuration itself has to be recorded to reconstruct the arrangement, and routine transactions require coordinating multiple devices. It is a real answer for a real problem and it is not a beginner's setup.

If you are comparing devices, whether they support these arrangements cleanly — and how well their documentation explains the failure modes rather than the benefits — is a reasonable proxy for how seriously the vendor takes the part of the job that is not marketing.

The setup, which is where it goes wrong

More holdings are lost during the first hour with a device than in every attack on hardware wallets combined. The sequence that avoids it is short.

1. Verify authenticity before anything else. Run whatever attestation check the vendor provides, from software you obtained by typing their domain rather than by searching for it.
2. Let the device generate the recovery material itself. If any phrase arrives pre-written in the packaging, the device is compromised and there is no exception to this.
3. Write the phrase down on something durable, away from a camera. Not photographed, not typed, not stored in a password manager that syncs. The medium should survive water and fire, because the two ways paper backups die are floods and house moves.
4. Verify the backup by restoring from it. This is the step everyone skips and the only one that proves the backup works. Wipe the device and restore it from what you wrote down, before there is anything on it worth losing.
5. Send a small amount, then send it back. A round trip confirms both directions work and gives you the habit of reading the address on the device screen, which is the habit that matters afterwards.

The fourth item is the one worth insisting on. A backup that has never been tested is a belief about a backup, and the moment you discover the difference is the moment it is too late to do anything about it.

Treat firmware and setup as separate checks

A firmware update changes code that interprets what the device displays and signs. Use the vendor's official application reached from a domain or publisher entry you verified, read the release note and confirm that the device reports the expected model before approving. A message delivered through email, support chat or a search advertisement is not an update channel.

An update should not require you to type the recovery phrase into a computer or phone. If an application asks for it, stop. The phrase is used on the device itself during a genuine recovery, not supplied to desktop software as proof of ownership. Keep the backup available before updating, but do not create a new digital copy for convenience.

After an update, verify the receive address on the device display and use a small transfer before moving a consequential amount. That test checks the whole path: the companion application, the device display, the network selected and your ability to recognise the result. It is more informative than treating a successful progress bar as proof that every dependency still works.

Initial setup needs the same separation. Generate the recovery material on the device, confirm the backup as instructed and reset a test setup before relying on it for a real balance. A sealed box or genuine application can reduce supply-chain risk, but only a recovery rehearsal demonstrates that the backup you made can restore control.

Before you buy anything

The prior question is whether a hardware wallet is the right answer for you at all, and it frequently is not. For a balance you trade weekly, the friction will lead you to defeat the security of the arrangement within a month — or worse, to leave the device unused while telling yourself the holdings are protected.

The failure modes on both sides of that decision, including the self-custody ones most coverage leaves in a footnote, are set out in full elsewhere on this site. If you want the short version, five questions will place you without naming a product either.

And if the answer is yes: buy from the vendor, verify the attestation, use a standard recovery format, store the backup on something that survives water and fire, and read the address on the device screen every single time. That list is worth more than any comparison of models.