Hardware Wallet Security: What Actually Protects Your Keys

A hardware wallet protects your keys through four independent layers: a chip that will not surrender the secret it stores, code you can inspect, a signing channel that limits what can reach the device, and a supply chain that can prove the device is the one the vendor shipped. Each layer stops a different attack. None of them stops you from approving a malicious transaction yourself.

That last sentence is the part most buying guides leave out, and it is the reason this article is organised by threat rather than by product. Once you know which layer blocks which attack, a specification sheet stops being a list of features and becomes a list of answers to questions you can actually ask.

What is a hardware wallet actually protecting against?

Five things can separate you from your coins, and they are not equally likely:

• Key extraction by software. Malware on your computer or phone reads the private key out of memory or off disk. This is the attack a hardware wallet was invented to end, and against which it is close to absolute: the key is generated on the device and never leaves it.
• A transaction you approve without understanding it. The key stays safe; the funds leave anyway, because you signed something whose meaning was hidden from you. This is now the dominant way people lose money, and hardware helps only to the degree that it can show you what you are signing.
• Physical possession of the device. Someone has the hardware and wants the secret out of it. This is what the secure element and the PIN are for.
• A compromised device before it reaches you. Interception in transit, a tampered unit sold through a marketplace, or counterfeit hardware. This is a supply-chain problem, and it is solved with attestation, not with stickers.
• Loss of your own backup. No attacker involved. Statistically this is where a great deal of Bitcoin has gone, and no chip in the world addresses it — that job belongs to your recovery phrase and how you store it.

A device can be excellent against the first and third while doing nothing for the second and fifth. Ranking wallets on a single "security" score obscures exactly that, which is why our hardware wallet ranking scores five separate criteria instead.

Layer one: what does a secure element actually certify?

A secure element is a chip built to resist physical attack: probing, glitching the power supply, timing analysis, decapsulation under a microscope. It holds the key material and performs the signature internally, so the secret never appears on a bus a physical attacker could listen to.

Vendors advertise this with a Common Criteria certification, usually written as EAL5+ or EAL6+. Common Criteria — the international standard ISO/IEC 15408 — defines seven Evaluation Assurance Levels, EAL1 through EAL7, as packages of assurance requirements applied to a product under evaluation. The number describes how rigorously the thing was examined, from functional testing at the low end to formally verified design at the top.

Three things follow from that definition, and all three are routinely lost in marketing copy:

• The level measures the depth of the evaluation, not the strength of the product. EAL6+ does not mean "twice as secure as EAL5+". It means more of the design was examined, more formally, by an accredited laboratory.
• The certificate belongs to a specific target of evaluation. In almost every case that target is the chip, and sometimes the chip running a particular firmware version — not the wallet as a whole. A certified chip in a device whose firmware is unexamined is a certified component, not a certified wallet.
• A "+" means augmentation. The vendor's evaluation added requirements beyond the base package. What was added is in the certification report, which is where a claim becomes checkable.

The practical test is therefore not "does it have a secure element" but "which chip, at which level, and does the vendor name it?" A named chip model can be looked up against the certification register. An unnamed "bank-grade certified chip" cannot be looked up at all, and we score it as the disclosure it is not.

As published on each vendor's own product pages, read 24 July 2026. Specifications change; the vendor page is the authority, and every claim above is linked from the review it came from.

Note the last row. Blockstream's design uses no dedicated secure element at all, splitting the secret between the device and an encrypted oracle instead. That is not a failure to include a chip; it is a different answer to the same question, and a rubric that simply awards points for "has secure element" would score it wrongly. Multi-chip designs raise the same problem in the opposite direction: two or three independent elements distribute trust so that compromising one is not enough, which is a genuinely different property from a single higher-rated chip.

The PIN is part of this layer, not a separate one

A chip that resists physical attack would be worth little if an attacker could simply try every PIN. What makes a short PIN adequate is that the secure element itself enforces the attempt policy: it rate-limits guesses, typically with a delay that grows after each failure, and wipes the secret entirely after a set number of wrong entries. Because that counter lives inside the same tamper-resistant boundary as the key, it cannot be reset by power-cycling the device or by re-flashing firmware from outside.

Two consequences worth internalising. A wiped device is not a lost wallet — your recovery phrase restores it, which is another reason the phrase is the thing that actually needs protecting. And a longer PIN buys much less than people assume once a wipe threshold exists; the threshold, not the entropy, is doing the work.

Layer two: how much of the code can you actually check?

"Open source" in this category means at least four different things, and the gap between them is where most of the marketing happens.

1. A public repository. You can read the code. This says nothing about your right to use, modify or fork it — that is the licence, and code published with no licence file reserves every right by default.
2. A recognised open-source licence. Now the rights are granted explicitly. Still says nothing about whether the published code is the code on your device.
3. Reproducible builds. Anyone can compile the published source and get a binary that matches, byte for byte, the firmware the vendor signs and ships. This is the property that turns "you can read the code" into "you can verify the device runs it".
4. Open hardware. Schematics and board design published as well, so the physical device can be audited rather than only its software.

Only the third of these actually closes the loop between what is published and what is executing. Among the devices we rank, Coldcard publishes reproducible firmware builds, BitBox publishes fully open firmware, Keystone publishes both hardware and software, and Blockstream's Jade is open end to end. Ledger's secure-element firmware is not open, which is a deliberate trade: the certification regime that produces an EAL6+ chip is built around controlled disclosure, and vendors generally cannot have both.

Verifying a reproducible build is less exotic than it sounds, and it is worth doing once so that you know what the claim means. In outline: fetch the source at the tag matching the firmware version, build it inside the container image the vendor publishes for exactly this purpose, then compare the resulting hash with the hash of the signed release. If the two match, nothing can have been inserted into the shipped binary that is absent from the public source. If the build environment is undocumented or the hashes are not published, the claim is not testable, and it should be read as "the source is visible" rather than "the firmware is verified".

That trade-off is real and it has no universally correct answer. It is, however, a question you should answer deliberately: would you rather be able to inspect the code, or have an accredited laboratory attest to a design you cannot see? Anyone who tells you those are the same thing is selling something.

Layer three: how does a transaction reach the device?

The signing channel determines what an attacker on your computer can attempt. Broadly there are three:

• USB. A live data connection to a general-purpose computer. Convenient, and the attack surface that firmware must defend against.
• Bluetooth or NFC. Wireless convenience; the same logical exposure as USB plus a radio interface. Devices that offer it generally still require physical confirmation on the device itself.
• Air-gapped transfer via QR codes or microSD. No electrical connection ever exists between the signing device and the networked computer. Unsigned transaction goes in as an image or a file, signed transaction comes back the same way.

An air gap removes a whole category of attack — anything that requires talking to the device — at the cost of a slower workflow. Keystone signs by QR and microSD; Coldcard supports microSD, QR and NFC; Jade supports fully air-gapped transactions including firmware updates. Ledger and Trezor use a connected model, with confirmation on the device.

But the channel is only half of it. The other half is what the screen can tell you before you approve. Confirming a Bitcoin payment means checking an address and an amount, which a small display handles fine. Confirming a contract interaction means understanding a call to a contract that may be requesting an unlimited spending allowance on a token you hold. A device that can only show you an opaque hash is asking you to sign blind, and blind signing is precisely how the second threat on our list — approving something you did not understand — succeeds against people who did everything else right.

This is why display size and structured transaction decoding belong in a security assessment rather than a comfort one, and why a device used mainly for DeFi has different requirements from one holding long-term savings.

Layer four: how do you know the device is genuine?

The supply-chain question is whether the unit in your hands is the one the vendor built. Tamper-evident packaging is the weakest answer available: holographic seals are reproducible, and a sealed box proves only that a box was sealed.

The meaningful mechanism is cryptographic attestation. The secure element holds a key installed at manufacture; the vendor's software challenges the device to prove possession of it, and a device that fails the check is not one you should use. Where the firmware is reproducible, you can go further and verify that the running version corresponds to published source.

Two habits do more here than any specification: buy directly from the vendor rather than a marketplace reseller, and initialise the device yourself. A wallet that arrives with a recovery phrase already written down is not a wallet, it is a trap — the phrase is known to whoever wrote it.

What none of these layers protect you from

Being explicit about the boundary matters more than another paragraph of reassurance:

• Signing a malicious transaction. The device protects the key, not your judgement. Verification habits and transaction decoding are the mitigation, and we treat them as part of operational hygiene rather than a hardware feature.
• Coercion. A device that requires a PIN protects against a thief, not against someone standing next to you. Passphrase-protected hidden accounts exist for this scenario and carry their own failure mode: forget the passphrase and the funds are gone with no recovery path.
• Losing the backup. The recovery phrase is the wallet. The device is a convenient way to use it.
• Your own inheritance planning. Perfect key security with no succession plan is a guaranteed loss on a long enough timeline.

How we weigh this when we rank

Our hardware wallet ranking scores five criteria at equal weight: price and value, secure element, open source, air-gap and verification, and asset coverage. Each maps to a layer above, and each is scored from what the vendor publishes on its own pages, with the date we read them recorded on the review. Where a vendor states a count of chips but not their models, or a certification level but not the target of evaluation, we score the disclosure that exists rather than assume the rest. The full rubric is set out in our ratings methodology.

What we cannot verify

Three limits, stated plainly. First, we do not open devices or perform laboratory attacks; every physical-security claim here traces to a vendor publication or a certification scheme, not to our own testing. Second, certification registers list evaluated chips and firmware versions, and a vendor shipping a different revision than the one evaluated would not be visible to us from published material. Third, reproducible builds prove that source matches binary; they do not prove the source is free of flaws, and no audit or certificate available today makes that claim either.

Anyone promising certainty on those three points is overstating what is knowable. The honest position is that a hardware wallet moves a very large class of attacks off the table and leaves a smaller, sharper class — the ones that run through you rather than around you.

Sources

• Common Criteria for Information Technology Security Evaluation, Part 5: Pre-defined packages of security requirements (CC:2022 Revision 1) — commoncriteriaportal.org, read 27 July 2026
• ISO/IEC 15408-5, Information security — Evaluation criteria for IT security — iso.org, read 27 July 2026
• Device specifications as published by each vendor and cited individually on the reviews linked above, read 24 July 2026