Hardware wallets: Understanding the risks of self-custody

Self-custody is often described as the endpoint of bitcoin security: move coins off an exchange, onto a hardware wallet, and the risk of a third party losing your funds effectively disappears. That framing is correct as far as it goes. It is also incomplete, and a 2026 incident involving one of the most trusted hardware wallet brands on the market is a clear illustration of why.

What a hardware wallet actually does

A hardware wallet generates and stores private keys on a device with no persistent internet connection, so the keys never touch a computer or phone that could be compromised remotely. Transactions are signed on the device itself and only the signed transaction, not the key, ever leaves it. That design eliminates an entire category of attack: remote hacking, exchange insolvency, and custodial mismanagement. Popular models in 2026 include Bitcoin-only, fully open-source devices built for air-gapped operation, alongside more broadly compatible devices that work across third-party wallet software.

The signing process itself is the part that makes this work in practice, and it is worth understanding rather than taking on faith. When a user wants to send bitcoin, the transaction details are constructed on a connected computer or phone, but the actual cryptographic signature that authorizes spending the funds is created entirely inside the hardware wallet, using the private key that never leaves the device. The connected computer sends the unsigned transaction to the hardware wallet, the wallet displays the transaction details on its own screen for the user to verify, the user physically confirms it on the device, and only the resulting signature, mathematically tied to that specific transaction and useless for anything else, gets sent back out. Even if the connected computer is fully compromised by malware, an attacker controlling it can see what the user is doing and potentially trick them into approving a malicious transaction, but cannot extract the private key itself, because the key was never present on the compromised machine in the first place.

Seed backups: the part people get right

The private key itself is derived from a seed phrase, typically 12 or 24 words, generated when the device is first set up. Losing that phrase means losing access to the funds permanently if the device is also lost or destroyed; exposing it to anyone else means they can drain the wallet regardless of whether they ever touch the physical device. The standard practice by 2026 is to stamp, engrave or etch the seed words into metal plates rather than writing them on paper, so the backup survives fire, flood and general corrosion. This part of the self-custody model is well understood and, when followed, genuinely effective against the risks it targets.

The gap that a firmware bug exposed

What metal backups and air-gapped signing do not protect against is a flaw in how the seed itself was generated in the first place. Generating a secure seed depends on entropy, genuinely unpredictable randomness, fed into the key-generation algorithm. A proper hardware random-number generator draws that randomness from a physical source, electrical noise or some other unpredictable process inside the chip, that no outside party can observe or predict. If that hardware source is bypassed or fails silently, and the device falls back to a software-based generator that follows a deterministic, reproducible pattern instead, the resulting seed looks exactly like any other seed to the user, twelve or twenty-four ordinary words, but is drawn from a vastly smaller and, to an attacker who understands the pattern, effectively guessable set of possibilities. That is the specific failure mode a firmware bug can introduce, and it is invisible to the user at every step of an otherwise correct self-custody process.

In August 2026, hardware wallet maker Coinkite disclosed that a firmware bug affecting its Coldcard devices (present in versions shipped from March 2021 onward) meant the device sometimes skipped its hardware-based random-number generator when creating a wallet seed, falling back instead to a generator that was deterministic and, for an attacker who understood the pattern, reconstructable. Newer models running unpatched firmware generated seeds with around 72 bits of entropy instead of the 128 bits the design called for, a difference that makes an exhaustive search dramatically more tractable for a well-resourced attacker.

The result: attackers drained roughly 1,367 BTC, worth about $89 million, from thousands of addresses across several waves between July 30 and early August 2026. None of the affected users did anything wrong by the standard self-custody checklist. Their seeds were generated offline, on a dedicated device, and backed up correctly. The seed itself was simply not random enough to be secure, and no amount of careful storage afterward could fix that.

What this changes for a self-custody checklist

The practical lesson is not that self-custody is unsafe, but that it has a supply-chain dependency most holders never think to check: the firmware that generated the seed in the first place. A responsible self-custody practice in 2026 includes confirming a device’s firmware version against the manufacturer’s published security advisories, applying updates before generating any new seed, and treating a seed generated under a firmware version later found to be flawed as compromised: meaning funds need to move to a freshly generated seed on patched software, not just have the firmware updated after the fact. Self-custody removes counterparty risk. It does not remove the need to verify the tools doing the custody.

Reducing single points of failure further

For holdings large enough to justify the added complexity, multisignature setups address a related but distinct risk: what happens if one seed, one device, or one backup location is compromised, lost, or coerced out of its owner, regardless of how well that seed was generated. A multisig wallet requires signatures from more than one independent key to authorize a transaction, commonly configured so that any two of three separately stored keys, or three of five, are sufficient. That structure means a single point of failure, a stolen device, a burgled safe, a firmware flaw affecting one specific hardware model, is no longer enough on its own to move funds, since an attacker would need to compromise multiple independent keys, ideally generated on different hardware from different manufacturers and stored in different physical locations, to succeed. The tradeoff is operational complexity: more devices to maintain, more backups to manage, and a genuine risk of self-inflicted lockout if too many of the required keys become inaccessible at once. That tradeoff is why multisig tends to make sense for larger holdings or shared custody arrangements rather than as a default recommendation for every bitcoin holder, but it is the most direct answer available to the exact class of problem the Coldcard incident illustrated: a single device, however carefully backed up, is still a single point of failure if something about it was flawed from the start.