A Governance Perspective on Custody Risk: When Key Generation Fails

On July 30, 2026, an attacker began exploiting a firmware flaw in certain Coldcard hardware wallets, sweeping funds from over a thousand single-signature wallets. As of the most recent analysis, the total stands at over 1,100 BTC — approximately $70 million — with the figure still being refined as the investigation continues.

Coinkite, the maker of Coldcard, has published a full technical breakdown of the root cause, affected models, and remediation steps — see Sources below for the complete disclosure. In short: certain firmware versions were silently using a much weaker source of randomness than intended, instead of the device's hardware generator — leaving affected seeds with roughly a third of the randomness a Bitcoin wallet is supposed to have, low enough, in principle, for an attacker to reconstruct a private key without ever touching the device. Coinkite hasn't confirmed this is what caused this specific sweep, though the timing and pattern point strongly in that direction.

One detail stands out on its own: Coinkite says it has to assume an attacker used AI tooling to find the flaw in its own open-source code — after its own AI-assisted review, weeks earlier, had missed it. Both attackers and defenders now have the same review tools; here, those tools helped the attacker first. It's a reminder that 'the code is public and reviewable' is not, on its own, a security guarantee.

Owners using affected firmware can't simply patch and move on. Updating the firmware doesn't repair a seed that was already generated under the flaw — the weakness lives in the seed itself, not the device holding it. The practical fix is to generate an entirely new wallet on safe firmware and migrate funds there. The same logic applies to multisig setups: a wallet isn't protected just because one of its keys is safe, if enough of the other signing keys came from affected devices to still meet the spending threshold on their own. Coinkite's advisory walks through the exact steps and edge cases.

What this means for custody architecture

It would be a mistake to read this incident as a story about one product being flawed. The more useful reading is structural: the failure occurred at the very first step of the custody lifecycle, key generation, and nothing downstream could compensate for it. A seed generated with insufficient entropy is not made safer by good backup hygiene, careful firmware updates, or offline storage. If the randomness underlying a key is predictable, the key itself was never truly private, regardless of where it was kept.

Key generation is only as trustworthy as its weakest, least-reviewed component — as the AI-assisted discovery of the Coldcard flaw showed. The failure mode points to what a different architecture needs to get right: a software fallback silently standing in for a hardware random number generator, with no one checking which one actually ran.

Certified Hardware Security Modules are built to avoid exactly that failure mode at the source: they draw randomness from a physical noise source — a hardware true random number generator, continuously self-tested — rather than a software-derived substitute waiting to be triggered by a misconfiguration.

In Bitpanda Enterprise Custody, key material is generated and protected within this kind of certified HSM infrastructure, operated as part of a managed environment subject to independent certification and audit, rather than a single consumer device running a fixed firmware stack whose review depends on who happens to look, and when.

It would be inaccurate to claim this makes every layer immune to a comparable bug: a policy or approval layer implemented in software carries the same category of risk as any other code, and could in principle contain an analogous defect. What is structurally different is the entropy source itself — a physical process rather than a software substitute — which is precisely where the Coldcard flaw occurred.

A single key, however it was generated, is a single point of failure for authorization as much as for generation. The blockchain cannot distinguish a legitimate signer from an attacker holding a reconstructed key.

This is where internal processes, not just cryptography, become a security control in its own right.

Bitpanda Enterprise Custody is built around role-based access and quorum-based approval: a defined number of authorised users must approve a sensitive action — a transaction, a policy change, a change to user roles — before it can proceed, and if that quorum is not reached, the action does not go through. Depending on how an organization configures its account, this can support segregation of duties and maker-checker controls, so that the person who initiates a transaction is not the same person who can approve it.

Transaction-level policies can add further constraints on top of quorum, such as restricting transfers to a pre-approved address book, or requiring additional manual approval above a given value threshold that the organization itself defines.

Detection matters as much as prevention. The reported transfer took place inside a short window across over a thousand wallets — the kind of pattern continuous transaction monitoring is designed to flag. A self-managed hardware wallet has no equivalent unless the owner builds one. Bitpanda Enterprise Custody includes 24/7 monitoring and continuous alerting as part of its operating model.

None of this amounts to a claim that managed custody eliminates risk, or that certified infrastructure is immune to the same category of failure. HSMs and other managed key-management components are themselves complex systems with their own firmware, supply chains, and disclosed vulnerabilities over the years; certification and audit reduce the likelihood and blast radius of a flaw; they do not guarantee its absence. Architecture determines what happens after a flaw is found: whether it can be identified, contained, and remediated in a coordinated way, or whether each affected party has to discover the problem, assess their own exposure, and migrate their own funds individually.

Looking ahead

This incident also points to a broader requirement for institutional custody: the ability to adapt as cryptographic standards and implementations change, not just to respond to today's known risks.

A managed environment is, in principle, better positioned to coordinate a response — a new firmware fix, a compromised algorithm, a required key migration — across an institution's entire holdings than an individual hardware wallet owner managing devices one at a time.

More immediately, this incident is a reminder that continuous monitoring, audit logging, and a documented incident-response process are not administrative overhead — they are what determines whether an institution learns about a problem from its provider or from a headline.

Self-managed hardware wallets vs. managed institutional custody

Closing observations

While Coldcard is a reputable and broadly utilised hardware solution, this episode should not be interpreted as a blanket indictment of hardware-based security. Instead, it serves as a structural reminder that offline storage represents only a single component within a multi-layered defense strategy.

The consequences of failures during the initial stage of the custody lifecycle, specifically entropy generation, are permanent and cannot be mitigated by downstream measures. For institutional actors, the critical inquiry in due diligence remains the same: the goal is not to seek a system where flaws are impossible, but to identify a custody architecture designed for resilience and containment when a vulnerability inevitably surfaces.

Institutions reassessing their own custody architecture in light of this incident are welcome to reach out to the Bitpanda Enterprise team for a walkthrough of how these controls are structured.

Sources

• Coinkite, Mk3 Security Advisory
• Coinkite, Technical Deep Dive into the Entropy Issue
• COLDCARD Documentation, Upgrade Firmware
• Block Engineering Blog, Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware