Security

The Coldcard incident is still unfolding but the lesson is already clear

Over the past few days, the Coldcard failure has moved from an alarming report about a cluster of drained wallets to a much broader custody event.

The Coldcard incident is still unfolding but the lesson is already clear
Photo by FlyD / Unsplash

From isolated reports to a custody event

Over the past few days, the Coldcard failure has moved from an alarming report about a cluster of drained wallets to a much broader custody event.

The immediate facts are still being refined, including the number of wallets affected and the total losses. The central mechanism is now clearer: seeds generated by some Coldcard firmware versions drew on far less entropy than users had reason to expect. A seed phrase can look like a normal 12- or 24-word Bitcoin backup while remaining vulnerable if the process that created it sampled from a much smaller space of possibilities.

That is why this incident is more serious than a conventional device hack. Nobody needed to access a user’s Coldcard, break its air gap, obtain a backup, or persuade its owner to sign a transaction. If the seed itself was predictable enough to reconstruct, the attacker could derive the relevant private keys and sweep funds directly. The hardware wallet could remain untouched in a drawer or a safe while the Bitcoin moved on-chain.

What we know so far

Coinkite’s advisory identifies the affected Mk3 firmware range and acknowledges that seeds generated on earlier Mk4, Mk5, and Q firmware may also have had materially less entropy than expected. Its technical account describes roughly 40 bits of effective entropy for affected Mk3 seeds and around 72 bits for the newer devices. Independent analysis has raised more severe questions about some older configurations. The exact forensic account will matter but users should not wait for a final consensus before acting. A seed generated under the affected conditions must be treated as potentially exposed.

The crucial practical distinction is between fixing the device and fixing the wallet. Firmware updates matter because they change how new seeds are generated. They do not repair a seed that has already been created, backed up, used to derive addresses, and potentially enumerated by an attacker. Moving that same seed to another device changes nothing. The Bitcoin must be moved to a genuinely new wallet, created from fresh entropy.

I highly recommend reading the Amboss entropy explainer.

For some diverse perspectives on the attack, see my summaries of these three podcast episodes that came out within the last day and a half:

AI Security and Bitcoin Governance
On August 5, 2026, BTC Sessions Bitcast convened Ben, Nathan, Joey, and Brandon to argue that AI-assisted attacks and vulnerability discovery are pressuring Bitcoin’s custody, service, and governance layers at once.
Bitcoin Custody and Security Assurance
On August 4, 2026, Galaxy Grid featured a panel examining a reported Coldcard key-generation failure and the thefts linked to vulnerable Bitcoin wallets.
Bitcoin Self-Custody and Verification
On August 5, 2026, The Bitcoin Nova featured Josh (Secure Sovereign) arguing that the Coldcard incident exposed a gap between Bitcoin’s self-custody ideals and its actual systems of verification.

What affected users can do

For affected users, the priority is migration, not reassurance. First confirm the applicable device and firmware history against Coinkite’s advisory. Then create a new wallet from a source of entropy that is not dependent on the compromised generation path. Physical dice entropy, correctly collected and incorporated, offers one route. A new signer or a multisignature arrangement with independently generated keys offers another. A strong, independently generated BIP-39 passphrase may provide a temporary layer of protection but it should not become an excuse to leave funds indefinitely on a seed whose provenance is now in doubt. Test the recovery and signing process before transferring a larger balance.

The limits of passive self-custody

The incident has also exposed a weaker idea that has become common in Bitcoin custody: that buying a respected device and storing its seed carefully completes the task. It does not. Self-custody transfers responsibility for a chain of decisions – entropy generation, backup design, recovery testing, transaction verification, software updates, and eventual migration – to the holder. A device can reduce some risks while quietly concentrating others.

That does not mean self-custody has failed, or that the answer is to return automatically to custodians. It means that passive self-custody is not a stable category. A static setup becomes brittle when its assumptions change. The attack on Coldcard users was possible precisely because a property many users had delegated to the device – the quality of the original randomness – could not be confirmed merely by looking at a valid-looking seed phrase or a functioning wallet.

AI changes the pressure

AI adds pressure to this problem. It can accelerate code review, pattern matching, wallet clustering, seed-space search, and the operational coordination of attacks. The relevant response is not to treat AI as a mystical new adversary. It is to assume that weaknesses once protected by obscurity, inconvenience, or limited attacker attention will be found and exploited more quickly. Custody arrangements need to be designed for that environment.

The Coldcard event will leave a difficult legacy because the failure occurred in a product associated with careful, sovereignty-oriented Bitcoin practice. But that is exactly why it is worth taking seriously; the lesson is not that users should abandon self-custody. It is that self-custody is an active governance practice. It requires verification, redundancy, and a willingness to revisit arrangements that once seemed settled.

For users with potentially affected Coldcard-generated seeds, the immediate rule is simple: update the device for future use but migrate the Bitcoin to a newly generated wallet asap. The old seed is the risk.

Further reading: Coinkite’s security advisory, Coinkite’s technical backgrounder, and my earlier notes on the initial 40-bit failure, AI security pressure, passive self-custody, and passive verification.