Beyond Cold Storage: What the Coldcard Incident Reveals About Wallet Security

From Suspicious Transactions to a Vendor Advisory

On Jul 30, 2026, a group of Bitcoin addresses that had been dormant for years began making unusual transfers. Initial findings associated the affected addresses with Coldcard hardware wallet users. Coinkite, the Canadian Bitcoin security company that makes Coldcard, published a security advisory the same day and confirmed that seeds generated by certain firmware versions did not have the intended level of randomness. On Aug 1, 2026, Coinkite updated the advisory and clarified that Mk2, Mk3, Mk4, Mk5 and Q devices could be affected, depending on the firmware used when the seed was created.

The incident quickly drew attention across the crypto and security communities. Hardware wallets have long been regarded as one of the safer options for holding digital assets over extended periods, and Coldcard had earned a strong reputation among Bitcoin users for its offline design and security-focused features. Because the weakness arose before funds were ever deposited, the discussion shifted from whether a device was connected to the internet to whether the wallet’s seed-generation process could be trusted.

On Aug 5, 2026, TRM Labs, a blockchain analytics and investigations firm, published an on-chain tracing report. Citing preliminary estimates from Galaxy Research, the research arm of digital-asset financial services company Galaxy, TRM Labs said the suspected theft occurred in at least four waves. Approximately 1,816 BTC moved from more than 5,200 addresses, worth about US$116 million at the time. TRM Labs cautioned that the figures could change because the funds were still moving and some users might discover losses later. As of the report’s publication, there was not enough evidence to attribute the activity to a specific group.

Taken together, the information disclosed so far supports a working theory: insufficient randomness during seed generation sharply reduced the number of seeds the affected devices were likely to produce. An attacker could then brute-force candidate seeds, derive their addresses and compare them with public blockchain data. Once a matching seed was found, the attacker could derive the corresponding private keys, sign transactions and transfer the funds. A weakness introduced at generation cannot be repaired simply by keeping the device offline afterward.

From Randomness to Private Keys: Where the Coldcard Failure Occurred

To see why a random-number flaw could put funds at risk, it helps to follow the path from a wallet’s first random input to the keys that control its assets.

Randomness → mnemonic phrase → wallet seed → private keys → public keys and addresses

When a wallet is created, the device first generates random data. Entropy describes how difficult it is to predict the data. Under Bitcoin Improvement Proposal 39, commonly known as BIP39, a typical 12-word mnemonic begins with 128 bits of entropy. When the randomness is generated correctly, the number of possible outputs is far too large to search exhaustively with practical computing resources.

The device converts the random data into a mnemonic phrase that is easier to record and back up. The mnemonic, together with an optional passphrase, is then processed into a wallet seed. That seed can derive many private keys and addresses, making it the starting point for the wallet as a whole.

Private keys are used to sign transactions. Each private key can generate a corresponding public key and address, which can be shared to receive funds. Anyone who obtains the relevant private key can authorize transfers from the associated address.

Coldcard’s failure occurred at the first step, the generation of randomness. According to a technical analysis by Block, the financial technology company behind Square, Cash App and Bitkey, a codebase migration in March 2021 changed the random-number call path used for seed generation. In practice, the firmware invoked MicroPython’s deterministic Yasmarang software fallback instead of the intended STM32 hardware random-number generator. If the starting state of a deterministic generator can be reconstructed, its later outputs can also be reproduced.

A configuration detail allowed the problem to escape detection during the build. The relevant macro was defined as zero, which was intended to disable the fallback, but the dependency checked only whether the macro existed and did not test whether its value was nonzero. The firmware therefore built successfully, and the device still produced a correctly formatted mnemonic, even though the expected hardware randomness was missing.

In a later technical note, Coinkite said that, under the current attack hypothesis, the effective search space for affected Mk2 and Mk3 devices was about 40 bits. Mk4, Q and Mk5 devices added some entropy from a secure element, resulting in an estimated search space of roughly 72 bits. Both were below the intended 128-bit security target.

The theoretical number of combinations allowed by BIP39 did not change. The problem was that affected devices may have produced seeds from only a much smaller subset of those combinations. If Coinkite’s estimates are correct, an attacker would need to test roughly 2^40 or 2^72 candidates instead of a space associated with 2^128 possibilities. The smaller the search space, the less computing power, time and money a brute-force search requires.

Researchers have therefore proposed that an attacker generated candidate seeds locally, derived their addresses and compared them with addresses and balances visible on the Bitcoin blockchain. A match would provide the seed needed to derive the private keys, sign transactions and move the funds.

What can be confirmed is that some Coldcard firmware used a flawed random-number call path that reduced the security strength of seed generation. The attacker’s tools, computing resources and end-to-end process have not been disclosed, so the proposed attack path remains an inference drawn from firmware analysis and on-chain evidence.

Cregis Analysis: What the Coldcard Incident Actually Shows

One Firmware Failure Does Not Invalidate Cold Storage

The Coldcard incident concerns seed generation in specific firmware versions. It does not show that hardware wallets as a category are unsafe or that cold storage has ceased to be useful. Offline isolation still reduces exposure to malware, remote compromise and leakage from connected devices. What it protects is key material after generation; it cannot establish that the original generation process was sound.

Nor does the incident prove that a wallet supported by a professional provider is automatically safer than individual self-custody. Engineering teams, independent review and ongoing maintenance can add meaningful safeguards, but the outcome still depends on implementation, the scope of verification and the quality of incident response.

From Cregis’ perspective, the incident highlights four points:

Offline storage reduces network exposure, but it cannot supply the randomness that was missing when a seed was created.
A valid mnemonic, a functioning device and correct code in a repository do not prove that production firmware reached the intended random-number source. Dependencies, build settings and the complete execution path must also be verified.
Wallet security spans key generation, use, backup, recovery and migration. A serious weakness at any point can erode the protection provided elsewhere.
Firmware updates can repair future seed generation, but they cannot strengthen seeds and addresses already created by the affected process.

“The Coldcard incident does not support a broad conclusion that hardware wallets are unsafe or that cold storage has failed. The more important point is that asset security cannot be assessed by storage method alone. A wallet system is like a barrel: its capacity is determined by its shortest stave. Weaknesses in randomness and private-key generation, firmware maintenance, access controls, backup and recovery, or incident response can all reduce the protection that offline storage is intended to provide.

No single security setup can address every risk. Individuals and organizations should choose a practical and effective combination of safeguards based on the value of the assets they hold, how those assets are used and the nature of their operations. They should also verify the full security process, assess whether the team behind the product can maintain it over time, and confirm that a clear, workable migration plan is available if a risk emerges.”

Shawn Yan, Founder of Cregis

Affected and Uncertain Users Should Prioritize Migration

Coinkite’s advisory calls for seeds created by affected firmware to be replaced. Users who cannot establish the device model, firmware version or additional entropy used when their seed was generated should assess migration as a priority, even if they have not seen any suspicious activity.

Use Coinkite’s official channels to verify the device model, firmware branch and version used to create the seed. Ignore unsolicited messages offering a wallet “security audit.”
Install the fixed firmware for the relevant model and release branch, or use another wallet that has been independently evaluated, then generate an entirely new seed. Importing the old mnemonic into a new device does not remove the original weakness.
Back up the new seed offline, verify the wallet fingerprint and receiving address, and make a small test transfer before moving the remaining balance.
After migration, update payment instructions, stop receiving funds at the old addresses and continue monitoring them for unexpected activity.

Coinkite’s current advisory lists the fixed versions as 4.2.0 or later for Mk2 and Mk3, 5.6.0 or later for standard Mk4 and Mk5 devices, 1.5.0Q or later for standard Q devices, and 6.6.0X or 6.6.0QX or later for the Edge line. Standard and Edge are separate firmware tracks, so users should install the release that matches both their device and branch.

Coinkite says a seed is not affected by this random-number issue alone if, at creation, the user added at least 50 fair, independent and private physical dice rolls that were neither recorded nor exposed. A strong, unique BIP39 passphrase stored separately from the mnemonic adds an independent layer of protection, but it does not repair an affected seed. Unless the dice-roll condition is met, the official recommendation remains to replace the seed and migrate the assets.

Migration also creates an opportunity for secondary attacks. BleepingComputer, citing research by Proofpoint, reported that attackers had impersonated Coldcard and used a supposed “security audit” to trick users into installing remote-access software. Firmware, advisories and migration instructions should be obtained directly from Coinkite. Users should never enter a mnemonic into a website, online form or unverified application.

What to Verify When Evaluating a Wallet

The same questions apply beyond Coldcard. Users can ask wallet vendors and infrastructure providers to explain their randomness sources, key-generation process, audit coverage for production releases, verification of the complete execution path and emergency migration procedures.

A code audit is useful evidence, but every audit is bounded by a particular version, scope and point in time. A broader review should cover the following:

Key generation. Identify the sources of randomness, the implementation the production release actually invokes and how hardware entropy or multiple sources are combined. Determine whether a complete private key ever exists in one environment, and what happens if a device or component fails.
Audit scope and production equivalence. Public source code, independent code review, penetration testing and hardware evaluation answer different questions. Reproducible Builds can help third parties check whether distributed firmware corresponds to published source. Reviews should also cover dependencies, build configuration, module boundaries and runtime behavior.
Protection across the full workflow. Hardware wallets should be assessed for secure-element design, firmware signing, tamper resistance, supply-chain controls, backup and recovery. Software and mobile wallets can also be reviewed against the OWASP Mobile Application Security Verification Standard for local data storage, authentication, network communication and platform interaction.
Maintenance and incident response. NIST’s Secure Software Development Framework treats security as a lifecycle practice. Users should review release history, vulnerability disclosure channels, patching, user notification, technical postmortems and emergency migration procedures.

For individual users, a practical starting point is to review published audits, source-code availability, firmware history and the vendor’s record of responding to security issues. Backup and recovery procedures should also be tested periodically.

Organizations and holders of high-value assets should commission an independent assessment that reflects their operating model. They should separate duties, define transaction policies, monitor for anomalies and rehearse backup recovery and emergency migration. A prospective provider should be able to explain its threat model, key-generation process, audit scope and approach to legacy risk.

The Hardest Problem Is Risk Already Embedded in Deployed Wallets

As a digital-asset infrastructure provider, Cregis is also watching how vendors address risk that already exists across their installed base. Based on public information, Coinkite has released fixed firmware, halted shipments and dealt with inventory that still carried affected firmware. It has continued to publish technical information and migration guidance, and has directly helped some users move their assets.

Those actions cannot recover losses that have already occurred. The industry still needs to examine how responsibility for vulnerabilities should be assigned, what protection users should receive and what obligations apply when a self-custody product fails. Even so, Coinkite’s response deserves recognition. Its work extended beyond correcting the code to identifying exposure, notifying users and supporting migration, giving potentially affected users a clearer path to act.

The harder problem is the wallet population left behind by older releases. New firmware can improve seed generation from that point forward, but it cannot change seeds already created by the affected process. Eliminating that risk still requires users to create a new wallet and move their assets.

This is the main warning for the industry. The longer a flaw in the generation process remains undetected or unresolved, the more likely it is to become an operational legacy problem involving version identification, user outreach, migration coordination and questions of responsibility. As the installed base grows and users become more dispersed, notification, support and migration become more costly. Some exposure may remain for years in wallets that have not been migrated.

Wallet manufacturers and infrastructure providers should verify the full path from randomness sources and dependencies through build configuration and key generation before release. After deployment, they need traceable version and validation records, along with clear procedures for disclosure, user notification and emergency migration. Finding and resolving known weaknesses early is the best way to prevent a technical defect from becoming a larger body of legacy risk.

Cold storage remains valuable, but long-term asset security covers the full process of generating, using, backing up, recovering and migrating keys. That is the clearest lesson the Coldcard incident leaves for the wallet industry.