When risk goes out the door and comes back through the window. The Coldcard case and the bitcoin stolen without a hack

For years the rule was "not your keys, not your coins". The Coldcard case shows that your own keys are not enough: if the device generating them fails to produce randomness, the key is guessable even though it was never exposed. And it is a flaw no update can repair.

What actually happened

On 30 July 2026 Coinkite published a security advisory concerning its Coldcard hardware wallets. It was not an intrusion: nobody broke into the devices, and calling it a "hack" is misleading. The problem is a flaw in entropy generation introduced with firmware 4.0.1 in March 2021: the randomness a seed is built from was not being produced as intended.

Affected are Mk2 and Mk3 on firmware 4.0.1 through 4.1.9, Mk4 and Mk5 before 5.6.0, and Q before 1.5.0Q. For Mk4, Mk5 and Q the advisory quantifies it: seeds contain "approximately 72 bits of entropy rather than the expected 128 bits". Independent technical coverage attributes the flaw to an internal library which, instead of the microcontroller's hardware RNG, used a software generator seeded from the serial number, the internal clock and button presses, with Mk3 entropy estimated at around 40 bits: plausible reconstructions consistent with the facts, but the official advisory neither confirms them nor names the library.

The difference between 128, 72 and 40 bits is not academic. At 40 bits an attacker with ordinary resources enumerates the key space; at 72 bits the effort is expensive but not impossible; at 128 bits it is out of reach. On 30 July roughly 594 BTC — about $38 million at the time — were swept from around 500 single-signature addresses in under half an hour, and the total reported over the following days rose to approximately 1,367 BTC across more than 4,500 addresses. Many had been dormant for years: a sign the attacker had pre-computed a large set of vulnerable keys and was running a systematic drain rather than reacting to live movements.

The flaw no patch repairs

Coinkite shipped corrective firmware the next day, with a warning that is the technical heart of the matter: updating the firmware does not repair a seed that has already been generated. You must create a new seed on fixed firmware and move the funds.

This category of defect deserves to be isolated, because it does not behave like the others. When a bug produces a persistent secret, fixing the bug does not undo the damage: the weak key has existed for five years, it is already written on a sheet of paper in a safe, and the attack came afterwards. It is the same temporal structure as harvest now, decrypt later: the moment of compromise and the moment of exploitation are years apart, and in between the victim gets no signal at all. In systems that generate long-lived secrets, time works against whoever holds them.

Not your keys: your generator

"Not your keys, not your coins" describes custody and says nothing about generation. It is a formula that solves one problem — exchange counterparty risk — and conceals another: self-custody does not remove trust, it moves it. From the custodian to the firmware vendor, that is, to a place the user can verify far less and where no contractual remedy exists. Nobody buying the device was in a position to know that the hardware RNG was not being used.

What is interesting for security practitioners is that this verification is a solved problemoutside the consumer world. Entropy sources are validated, and the standards have existed for years: NIST SP 800-90B for estimating and testing sources, the German BSI's AIS-31, FIPS 140-3 certification for cryptographic modules. The question "who validated your generator, and by which method?" is routine in a tender for an HSM, and absent when buying a device that protects six-figure sums.

It is worth extending the question beyond cryptocurrency, because the same class of defect hits keys every company generates continuously: SSH keys, TLS certificates, JWT signing secrets. Weak randomness leaves no trace in the logs, fails no functional test and triggers no alert: the system works perfectly, its keys are simply predictable. It is the same phenomenon that makes passwords generated by a language model unreliable — optimised for plausibility, not for randomness.

The dice that saved some people

One detail of the advisory refutes the fatalistic reading that users could do nothing. Coldcard lets you add physical dice rolls to seed generation, and the device "hashed the device-generated seed together with every dice roll entered": anyone who used 50 or more rolls had at least 128 bits of entropy from human input alone, regardless of the firmware flaw. Those seeds were not attackable.

That is defence in depth demonstrated by the facts, not in theory: a second entropy source independent of the first held when the first was silently broken. It works as a general design principle — when a control can fail without signalling, redundancy is not zeal, it is the only available defence.

The real question: self-custody or third-party custodian?

This is where the discussion stops being technical and becomes risk management. Cryptographic implementations are fragile, operational mistakes are common, and the reasonable conclusion is not to pick a slogan: it is to run a risk assessmentand compare the two scenarios. Because they cannot be ranked on a "more secure / less secure" scale: they are risk profiles made of different events.

Self-custody. The dominant scenarios are operational error — a mistranscribed seed, a single backup, a backup in one physical place, a forgotten passphrase — the vendor defect we have just seen, physical coercion, and the event almost nobody plans for: the death or incapacity of the key holder, leaving funds unreachable for the heirs. The impact is total and irreversible, there is no appeal, and above all the risk is not transferable: no policy covers your transcription error, and nobody compensates you for your own mistake.

Third-party custody. The scenarios are custodian insolvency, insider fraud, a breach of its systems, seizure or censorship, jurisdictional risk. The impact can be just as total, but a remedy and a transfer do exist — both partial, and it pays to know exactly where they stop.

The most useful conclusion is also the least ideological: third-party custody is not more secure, it is more governable. It converts a technical risk, dependent on rare cryptographic and operational competence, into counterparty risk — the risk category any organisation already knows how to handle: vendor due diligence, contractual requirements, liability clauses, insurance, monitoring. These are the supplier relationship controls in ISO 27001 Annex A (A.5.19–A.5.22), applied to this vendor as to any other. For a company that is often the decisive argument. For an individual with solid cryptographic skills, tested backup procedures and a written succession plan, the assessment may legitimately flip: the point is not the answer, it is having made the comparison.

Which guarantees to demand from a custodian

If the choice is transfer, verify that the risk genuinely transfers. In the European Union the reference is the MiCA regulation, which governs custody of crypto-assets on behalf of clients. The minimum checklist:

Authorisation, checked in the registers — the custodian must be a provider authorised under Article 59 MiCA, and this is verified in the authorities' public lists, not on the "compliance" page of its website.
Legal, not merely accounting, segregation — Article 75(7) requires crypto-assets held in custody to be "legally segregated from the crypto-asset service provider's estate in the interest of the clients". This protection decides whether, in an insolvency, you own assets or queue up as one creditor among many.
The liability clause, read for its limits — Article 75(8) makes the custodian liable for the loss of crypto-assets or means of access "as a result of an incident that is attributable to them", with liability "capped at the market value of the crypto-asset that was lost, at the time the loss occurred". Two limits to keep in mind: compensation is anchored to the value at the time of the loss, so subsequent appreciation stays with you; and it covers only incidents attributable to the custodian, not a problem inherent to the ledger's operation or an event beyond its reasonable control.
The insurance policy, in detail — the existence of cover says little. What matters is the sub-limit for cold storage versus hot wallets, any exclusion of employee dishonesty (one of the more likely scenarios), and who the insured party is: a policy benefiting the custodian is not a policy benefiting you.
Attestations with a readable scope — an ISO 27001 certificate is worth what its scope and Statement of Applicability say; a SOC 2 counts if it is Type II, meaning it has an observation period, and it must be read for its exceptions. A logo on a website is not an attestation.
Proof of reserves and an exit route — independent, periodic attestation that the assets exist, and a documented exit procedure: how you recover the funds, how long it takes, and what happens if the custodian ceases trading.

The third model is interesting, not decisive

Between the two extremes lies distribution: multisig schemes using devices from different manufacturers, or collaborative custody where one key sits with a provider. It is the same logic as the dice — do not trust a single source — and it diversifies both vendor-defect risk and counterparty risk. But it is not the solution, and this deserves to be said plainly: it adds complexity, and complexity is itself a risk factor.

Every control you add introduces a new way to fail. In a quorum scheme the new ways amount to being unable to reach the required number of signatures: a signer who is unreachable, in dispute or deceased, a key lost beyond the tolerance threshold, a manufacturer that has left the market, and the most underestimated case — losing the wallet descriptor, without which the keys alone reconstruct nothing. On top of that, the signing procedure is more involved, and involved procedures are executed badly more often.

In the classic security vocabulary, multisig converts confidentiality risk into availability risk: it makes it much harder for someone to take your funds, and easier for you to be unable to reach them. It is a trade, not a reduction — and it should be chosen knowing which of the two risks you are better equipped to manage, and after testing the recovery procedures before you need them.

Risk is not eliminated

That is the lesson the Coldcard case delivers to people who own no bitcoin at all. Every option here trades one risk profile for another: self-custody removes counterparty risk and hands you a non-transferable technical risk; a custodian removes the technical risk and hands you a partially covered counterparty risk; multisig reduces both and hands you an availability risk.

There is no risk-free box, which is why "where should I keep my bitcoin" has no universal answer. The right question is a different one, and it holds equally for a personal holding and for a company treasury: which residual risk am I willing to keep, did I choose it deliberately, and have I written it down anywhere? A risk that is chosen and documented is a governance decision. The same risk left unassessed is merely a hope.