For a long time, “keep it offline” has been one of the most common pieces of advice given to anyone concerned about protecting digital assets.
It is sensible advice. A device that is not continuously connected to the internet is less exposed to malware, remote-access attacks, malicious browser extensions and many of the threats associated with everyday computers and mobile phones.
But the recent Coldcard incident is a reminder that offline security has limits.
What caught my attention was not simply the amount of Bitcoin reportedly stolen. It was the nature of the failure. The attackers did not need to break Bitcoin, compromise the blockchain or physically obtain the victims’ devices. The weakness reportedly existed in the process used to create some of the wallet seeds in the first place.
That changes the way we should look at the incident.
The Problem Started Before the Wallet Was Stored
A hardware wallet is often described as a secure place to keep private keys. That description is correct, but incomplete.
Before a private key can be protected, it must first be generated. The security of everything that follows depends on the quality of that initial process.
According to the technical analysis published by Block’s Bitcoin Engineering and Security teams, affected Coldcard firmware contained an integration error involving its random number generation process.
The device was intended to use a hardware source of cryptographically secure randomness. In the affected process, however, the firmware relied on a deterministic software fallback influenced by limited device information and timing values.
To a normal user, the resulting wallet would not necessarily appear unusual. It could generate addresses, receive Bitcoin and sign transactions exactly as expected. The underlying problem would remain invisible because the seed itself would look valid.
But valid does not always mean unpredictable.
If the values used to create a seed come from a smaller or more predictable set than intended, an attacker does not need to search the entire theoretical Bitcoin key space. The attacker only needs to recreate the smaller set of outputs that the weakened process could have produced.
That is a very different computational problem.
How an Offline Attack Becomes Possible
Bitcoin addresses are public. Anyone can view them on the blockchain, together with their transaction history and balances.
Private keys are supposed to remain secret and practically impossible to guess. However, if an attacker understands the weakness in a wallet’s seed-generation process, it may be possible to generate candidate seeds offline, derive the associated addresses and compare them with addresses already visible on the blockchain.
When a generated address matches a funded address, the attacker may also possess the private key needed to move those funds.
Nothing needs to be sent to the victim’s hardware wallet. No remote session is required, and the device does not need to be connected to the internet at the time of the theft.
This is why the air gap could not solve the problem. The air gap protected the device from certain external paths, but the weakness had already been introduced when the secret was created.
The Scale of the Incident
The first widely reported attack wave took place on 30 July 2026. Galaxy Research traced approximately 1,082 Bitcoin moving from 1,196 addresses during a period of only 41 minutes. The value was estimated at roughly $70 million at the time.
As researchers received further victim reports and identified additional activity on the blockchain, the estimated losses increased. In its 7 August report, Galaxy Research said tracked losses had reached close to $130 million as of 4 August and estimated that at least 15 separate attackers were exploiting the weakness.
These numbers should still be treated carefully. Blockchain analysis can identify transaction patterns and connections between addresses, but it cannot automatically prove how every wallet was created. Investigations may confirm additional cases, exclude others or revise the total again.
The financial impact is significant, but the wider lesson matters just as much.
Bitcoin Was Not Broken
It is important to be precise when describing an incident like this.
The available evidence does not suggest that Bitcoin’s blockchain was compromised or that its core cryptography was broken. The network continued to operate according to its rules.
Bitcoin verifies whether a transaction contains a valid signature. It cannot determine whether that signature was produced by the legitimate owner or by someone who managed to reconstruct the same private key.
From the blockchain’s point of view, possession of the correct private key is the authority to spend.
The failure therefore appears to have occurred in the wallet’s key-generation process, not in the Bitcoin protocol.
This distinction may sound technical, but it is essential. Calling every theft involving cryptocurrency a “blockchain hack” creates the wrong impression and prevents us from understanding where the security control actually failed.
What the Incident Says About Hardware Wallets
The Coldcard incident does not mean that hardware wallets are useless or that keeping signing devices offline is bad practice.
Hardware wallets continue to provide meaningful protection against many common threats. The mistake is treating a single security feature as if it were a complete security model.
A wallet may be air-gapped and still contain a firmware defect. It may use secure hardware while depending on an unsafe backup process. It may generate a strong private key while the user signs a manipulated transaction without checking the destination address.
Security rarely fails because one product has no protection at all. It often fails because a protection works against one class of attack while users assume it covers every other class as well.
An air gap limits connectivity. It does not independently verify the quality of the random number generator, the integrity of the firmware, the safety of the supply chain or the way the recovery phrase was created and stored.
Updating the Device Is Not the Same as Replacing the Seed
Coinkite has released corrected firmware for supported Coldcard models and published guidance for users who may be affected.
One point in that guidance deserves particular attention: installing updated firmware can correct future seed generation, but it cannot repair a seed that was already created using an affected process.
Randomness cannot be added retrospectively to an existing secret.
If an old seed is restored on a new or updated device, it remains the same seed. Any original weakness travels with it.
Where the manufacturer’s guidance indicates that a wallet is affected, the appropriate response may involve installing verified firmware, creating an entirely new seed and moving the assets to new addresses. Users should rely on Coldcard’s official security guidance and remain cautious of unsolicited messages offering “recovery assistance.”
Security incidents involving wallets almost always attract a second wave of criminals using fake support accounts, fraudulent migration tools and websites designed to steal recovery phrases.
No legitimate support representative should need a user’s seed phrase.
A Broader Lesson for Digital Asset Security
For me, the most important lesson from this incident is simple:
We spend a great deal of time discussing how to store secrets, but not enough time asking how those secrets were created.
A private key can be kept inside a secure element, placed in an offline device and stored in a physical vault. None of those measures can compensate for a key that was predictable at the moment of generation.
For individuals holding modest amounts, a reputable and correctly configured hardware wallet may still provide an appropriate level of protection.
For institutions and high-value holders, the security model should be broader. That may include independently generated keys, carefully designed multisignature arrangements, separate device vendors, geographically distributed backups, tested recovery procedures and a documented incident-response plan.
Even multisignature is not automatically safe. If every key is created using the same affected device, firmware and source of randomness, the arrangement may reproduce the same weakness several times instead of providing genuine independence.
The objective is not to add complexity for its own sake. It is to avoid allowing one hidden failure to compromise the entire system.
The Question We Should Ask
The traditional question in self-custody has been:
“Who controls the private key?”
After the Coldcard incident, that question is no longer enough.
We should also ask:
How was the key generated?
What source of entropy was used?
Was the generation path tested on the actual production device?
Could one firmware failure affect every key in the setup?
And what happens if the device or vendor is later found to be vulnerable?
Being offline remains valuable. But offline should never be confused with invulnerable.
In cybersecurity, the strength of a secret begins long before we decide where to store it. It begins at the moment that secret is created.
Disclaimer: This article is intended for cybersecurity awareness and educational purposes only. It does not constitute financial, investment or product advice. Technical findings and loss estimates may change as investigations continue.
Sources
