How Hardware Wallets Work — and the One Failure Mode Nobody Checks

Most explanations of hardware wallets stop at the reassuring part: the key never leaves the device. That is true, and it is not the whole chain. In July 2026 a well-regarded vendor disclosed that on affected units the key had been weak from the moment it was created — and a key that is guessable does not care how well it is stored.

This page walks the whole chain, in order, and shows where it can break.

What the device is for

Your bitcoin does not live in a wallet. It lives on a public ledger, and what determines whether you can move it is possession of a private key — a very large number that produces valid signatures for transactions spending from your addresses.

A key stored on a laptop is a file on a machine that also runs a browser. Malware that reads that file has your money, and no confirmation dialog stands in its way.

A hardware wallet changes the physics of that. The key is generated on the device and stored there. To spend, your computer builds an unsigned transaction and sends it to the device. The device shows you the details on its own screen, you approve on its own buttons, it signs internally, and it returns the signed transaction. The key itself never crosses the cable.

Two properties do the work. Isolation: the secret exists in one place, and that place has no browser. Independent display: you confirm the amount and destination on a screen the compromised computer does not control, so malware cannot show you one address while sending to another.

Both properties are real, and both begin from an assumption we are about to examine.

Where the key comes from

At setup, the device generates a random number. Everything else is derived from it, deterministically.

That number is your entropy, and the standard sizes are 128 bits or 256 bits. Under BIP-39, the device appends a short checksum, chops the result into eleven-bit chunks, and maps each chunk to a word from a fixed 2,048-word list. 128 bits gives you 12 words; 256 bits gives you 24.

The words are not the key. They are a way of writing down the number, chosen because humans copy words more reliably than hex.

From that number, BIP-32 derives a tree of keys — one master key, and from it an unlimited number of child keys, each reproducible from the same seed. This is why restoring twelve words on a new device recovers every address you ever used. It is also why the entropy is load-bearing in a way nothing else is: it is the single input to every key you will ever hold.

Why 128 bits, and what happens when you have fewer

128 bits means roughly 3.4 followed by 38 zeros of possible values. No amount of computing power in existence searches that. It is not a matter of expensive; it is a matter of physically impossible.

The scale is not intuitive, because bits are exponents. Every bit removed halves the search. Dropping from 128 bits to 72 does not make the search 56 units easier — it makes it 2 to the power of 56 times easier, which is roughly 72 quadrillion times. A search that could never be attempted becomes a search that a well-resourced attacker can run.

And here is the property that makes weak entropy so dangerous: the attacker does not need to target you. They generate candidate seeds from the reduced space, derive the addresses each would produce, and check the public ledger for balances. The ledger is public by design. It is a sweep across everyone at once, and it needs no access to your device, your computer, or your network.

What went wrong in 2026

On 30 July 2026, Coinkite published a warning about seed generation on its Coldcard devices.

In the vendor's own description: "a build and link integration error meant that setting did not have the intended effect, and libNgU's rng_get() symbol resolved to MicroPython's default Yasmarang implementation instead."

Translated: the device was supposed to draw randomness from a dedicated hardware generator. Because of how the firmware was linked, that call silently resolved to the general-purpose pseudo-random generator built into the scripting runtime. A software PRNG produces numbers that look random and are, with knowledge of its internal state, reproducible.

The defect was introduced in a library migration in March 2021 and went unnoticed for over five years.

Affected versions, as published by the vendor:

• Mk2 and Mk3 — firmware 4.0.1 through 4.1.9
• Mk4 and Mk5 — before 5.6.0 (Edge before 6.6.0X)
• Q — before 1.5.0Q (Edge before 6.6.0QX)

On Mk4, Mk5 and Q, seeds carried about 72 bits of entropy instead of 128. On Mk2 and Mk3, seeds were inadequate outright — unless the user had supplied at least 50 independent private dice rolls during setup.

Read that last clause again, because it is the practical lesson of the whole episode. The users who had taken the trouble to roll dice were fine. The mechanism that saved them was the one that did not depend on the vendor's build system being correct.

The vendor has not published a figure for funds lost. Numbers circulating in coverage come from third-party analytics firms, and we are not treating them as confirmed.

The sentence people keep getting wrong

Updating the firmware does not repair an affected seed.

Patching restores correct generation for seeds created afterwards. A seed already derived from a weak number remains derived from a weak number. There is no operation that adds entropy to an existing seed retroactively.

If you hold an affected device, the sequence is: update firmware, create a new wallet, and move the funds to it. Do not restore the old seed onto the updated firmware. The seed is the problem; the device was only where it happened.

This generalises beyond one vendor. Any time a disclosure concerns key generation rather than key storage or transaction handling, assume existing keys are permanently affected and plan a migration. Storage bugs are fixed by patching. Generation bugs are fixed by starting over.

How to not depend on a vendor's RNG

Three approaches, in increasing order of effort.

Supply your own dice entropy at setup. Most serious devices accept dice rolls and mix them into — or use them in place of — the internal source. A standard six-sided die yields about 2.58 bits per roll, so roughly 50 rolls covers 128 bits. This is the option that saved the affected Mk3 users, and it is the highest-value hour you will spend on your own security.

Verify a known test vector. Some devices let you enter a fixed seed and check that it derives the published addresses. This confirms the derivation path is correct. It does not test the random source, since you supplied the number — so it is a useful check for a different failure, not this one.

Split trust across vendors. For meaningful sums, a multi-signature setup requiring keys from devices by two different manufacturers means a defect in one vendor's firmware does not compromise the wallet. This is real work to set up and to maintain, and it introduces its own failure mode: a multi-sig you cannot recover under stress is a worse outcome than a single key you can. Do it deliberately, or not at all.

The other things that go wrong

Entropy is the deepest failure, not the most common one. In practice, most losses come from the rest of the chain.

Supply chain. A device bought from a marketplace reseller may arrive pre-initialised with someone else's seed, sometimes with a "your recovery words" card already in the box. A genuine device generates its seed in front of you at first setup and never ships with words printed. Buy direct from the manufacturer. If a device arrives already set up, treat it as compromised.

The seed backup. Written on paper, in one place, in a home. Fire and water beat cryptography every time. Metal backups exist for this reason.

Photographing the seed. A phone photo of a recovery card lands in cloud storage within seconds, and cloud storage is a credential-theft target. This is one of the most common total losses there is.

Approving without reading. The device's independent screen only helps if you look at it. Malware that swaps a destination address relies on you glancing at the first four characters and pressing confirm. Check the whole address, or at minimum the first and last several characters.

The staged-transaction class of bug. Worth knowing because it is subtle: in the same August 2026 disclosure run, Coinkite fixed an issue where a connected host could substitute a staged transaction after the user had reviewed it. That attacks the independent-display property directly — the premise that what you approve is what gets signed. It was fixed, and it is the reason to keep firmware current even when no dramatic warning is attached.

Passphrase confusion. An optional passphrase on top of the seed creates a genuinely separate wallet. Forget it and the funds are unreachable even with all the words. It is a strong feature and a common cause of self-inflicted loss.

Should you still use one?

Yes.

The comparison that matters is not hardware wallet against perfect security. It is hardware wallet against a key on an internet-connected computer, which is attacked constantly and successfully. One vendor defect discovered and disclosed over five years does not change that arithmetic.

What it should change is the habit of treating any single component as beyond question. The right posture is the one that was already correct: supply your own entropy where you can, keep firmware current, buy direct, back up on metal, verify addresses on the device screen, and size your holdings to a setup you can actually recover.

And read vendor disclosure pages before you buy. A vendor that publishes a defect of this magnitude against its own product, in detail, with the exact symbol name that resolved wrongly, is behaving considerably better than one that has never published anything.

This page is informational and is not investment advice.

Sources

• Coinkite seed generation warning, 30 July 2026, updated 1 and 14 August — blog.coinkite.com
• Entropy technical backgrounder, 30 July 2026 — blog.coinkite.com
• Security update 5.6.1 and 1.5.1Q, 20 August 2026 — blog.coinkite.com
• Historical disclosures index — coinkite.com
• BIP-39, mnemonic code for generating deterministic keys — github.com/bitcoin/bips
• BIP-32, hierarchical deterministic wallets — github.com/bitcoin/bips