Why
The question "which hardware wallet" is usually answered with a brand, and a brand is the wrong unit. One word stands in for at least four independent supply chains — the silicon and firmware that generate the seed, the application that constructs and signs a transaction for a specific chain, the cryptographic construction that turns a key and a message into a signature, and the logistics that put the box in your hands. Each is built by different people, audited on a different schedule, and fails in a way the other three cannot detect.
One month made that concrete, which is why the criteria below are worth writing down now rather than after a purchase. Coldcard's defect was in the entropy source: a 2021 build-configuration error routed seed generation to a software PRNG instead of the STM32 hardware RNG, leaving roughly 40 bits of effective entropy on Mk2/Mk3 devices, and at least 1,719 BTC across more than 5,200 addresses was swept once someone noticed. Trezor's incident was in logistics: its fulfilment partner ShipMonk was breached and 13,689 customer records were exposed, with no key touched — the asset stolen was a verified roster of people known to hold hardware wallets, complete with delivery addresses. And on 2026-08-25 Ledger patched a critical flaw in its Ethereum application, the layer between the chain's encoding rules and the device's screen. Three manufacturers, three layers, one month, and no overlap between the failures.
That pattern kills the criterion most buyers actually use. "The vendor with no incidents" is not an observable property — it is the absence of a disclosure, which is also exactly what a vendor that does not look, or does not tell, produces. What can be observed is the shape of a disclosure: how long between discovery and patch, whether the root cause is named specifically enough to be checked, whether the affected build range is stated, whether the fix appears in a changelog you can read. Buy the manufacturer whose incident you can read end to end, because the alternative is buying silence and calling it a clean record.
The fourth layer is the one worth staring at, precisely because it did not appear in the month's news. A signature scheme fails without an event: if the same nonce is ever reused across two signatures, the private key falls out by arithmetic, and nothing on the device, the chain or the balance looks unusual until the funds are gone. RFC 6979 exists to remove that failure mode by deriving the nonce deterministically from the key and the message rather than from a random source — which matters most on exactly the devices whose randomness you cannot inspect. A layer that has been quiet for a decade is not evidence that it is sound; for this layer, quiet is what failure looks like.
And there is now a fifth criterion that did not exist a few years ago. The post-quantum deposit-contract draft in irreversible-switch-design is one instance of a broader move: signature schemes are being prepared for replacement, and the technique is to strip out hardcoded assumptions about the scheme rather than to teach systems a new one. A device bought today will outlive the algorithm it ships with. So the question "can this device receive a new signature algorithm as firmware, or is the curve fixed in hardware?" is not a hypothetical — it is the criterion with the longest half-life on the list, and almost nobody asks it at the point of sale.
How it works
One word, four vendors
| Layer | What it actually is | What its failure looks like | Evidence to demand before buying |
|---|---|---|---|
| Entropy | Silicon RNG plus the firmware path that reaches it | Keys that were never yours — and no symptom until a sweep | An end-to-end audit of the entropy path, naming the RNG; support for user-supplied (dice) entropy |
| Application | The per-chain app that decodes a transaction and renders it on screen | You approve something other than what the screen showed | Date and scope of the last independent audit of that chain's app, not of the device |
| Signing | The construction turning key + message into a signature | Nothing. A reused nonce leaks the key by arithmetic | RFC 6979 or hedged determinism, stated in documentation and confirmed by the two-signature test below |
| Logistics | Fulfilment partner, carrier, order database | No key touched — a targeting list of known holders, with addresses | Named fulfilment partners, purchase without an account where possible, and the full text of the last disclosure |
The four columns are not ranked. They are independent, which is the entire point: an audit of the application says nothing about the RNG, and a flawless RNG does not stop a fulfilment partner from selling your address to a wrench.
The two tests you can run yourself
Sign the same message twice and compare the bytes. Under RFC 6979 the nonce is a deterministic function of the private key and the message, so two signatures over identical input are byte-identical. If they differ, that is not automatically a defect — hedged determinism deliberately mixes in fresh randomness, and it is safer than pure determinism against fault attacks. What the test buys is the right follow-up question: if they differ, which of the two is it? A vendor that cannot answer that in one sentence has told you something.
Supply your own entropy if the device allows it. Rolling dice into the seed does not require trusting the manufacturer's RNG; it requires trusting only that the device mixes your input in rather than discarding it — a far smaller claim, and one the Coldcard defect shows is worth reducing to. The device that refuses user entropy is asking for trust it has no way to let you verify.
Why "no incidents" is the wrong filter
The three failures this month came from three of the four layers and none of them overlapped, so a clean record in one layer is not evidence about the others. Worse, the record itself is not a measurement. An incident count is a disclosure count, and disclosure is a behaviour of the vendor rather than a property of the device.
What a disclosure does reveal, if you read the whole thing rather than the headline, is four things worth scoring: time from discovery to patch, specificity of root cause ("a build-configuration error routed seed generation to a software PRNG" is checkable; "a security issue" is not), whether the affected range is stated, and whether the fix is traceable in public source or a changelog. A vendor that scores well on those has demonstrated the only capability that generalises to the next incident — because there will be one.
The criterion with the longest half-life
irreversible-switch-design reads a draft EIP that prepares the deposit contract for a signature-scheme replacement, and the technique there is instructive here: it works by removing the contract's hardcoded opinion about the old scheme rather than by teaching it the new one. Hardware has the same distinction in a harder form. A device whose curve arithmetic lives in a secure element's fixed instruction set cannot be given a new scheme by firmware; a device that implements signing in updatable firmware can, at some cost in side-channel exposure.
That is a real trade rather than an obvious answer, which is why it belongs on the table as a question rather than as a rule: the device that cannot be updated is also the device that cannot be updated against you. But given that a scheme replacement is now visibly being designed for, a buyer who never asks the question has made the choice by default.
The conclusion that follows from independence
If the four layers are independent across vendors and correlated inside one, then the strongest available control is not a better single device — it is a multisig whose signers come from different manufacturers. A quorum of two devices from one brand shares an entropy path, an app codebase, a signing implementation and a fulfilment partner; a quorum spanning two brands shares none of them. This is the same argument as third-party-blast-radius turned toward hardware: the question is never whether a vendor is trustworthy, it is how far the damage reaches when one turns out not to be.