Can assets still be stolen from a hardware wallet built with an intact, genuine chip, running official firmware, and capable of passing the manufacturer’s Genuine Check?
The recent Ledger security incident exposed precisely this seemingly impossible risk.
According to Ledger’s subsequent investigation, attackers had installed an additional malicious electronic module inside the affected devices. The implant could intercept the recovery phrase displayed on the screen and transmit it to the attackers over a cellular network.
In other words, the original Secure Element was never compromised. Yet the moment the recovery phrase first appeared on the screen, it could already have fallen into the attacker’s hands.
And this was not the only recent security incident worth examining.
Since September, incidents ranging from the exploitation of a vulnerability in a third-party security product used by Bitget, to the compromise of Trezor’s email provider Brevo, and a security incident affecting part of MetaMask’s infrastructure have delivered the same warning: as crypto products grow more complex, security can no longer be reduced to protecting private keys and preventing smart contract vulnerabilities.
Risks hidden in device distribution, third-party services, internal permissions, and user communications can be just as attractive to attackers.
1. Ledger Sounds a New Alarm for Supply Chain Security
Let us first unpack what happened to Ledger.
When purchasing a hardware wallet, users generally worry about two things: receiving a counterfeit device or getting one that someone has already initialized.
Historically, one of the most common scams involved malicious intermediaries generating a recovery phrase in advance, printing it on a scratch card, and placing it back inside the package, hoping an inexperienced user would deposit funds without realizing the danger.
The scam was serious, but the defensive logic was straightforward: buy through official channels, inspect the device’s status, let the device generate a new recovery phrase in front of you, and never use a recovery phrase supplied in the box.
The recent Ledger attack was considerably more sophisticated.
Attackers installed an additional electronic module inside the casing, equipped with a microcontroller, an eSIM, and cellular connectivity. When users initialize a hardware wallet for the first time, they must read the recovery phrase from its screen and write it down.
The malicious implant did not interfere with the process that generated the phrase. It simply monitored the display and transmitted the phrase elsewhere.
That is why saying “the private key was never extracted directly from the Secure Element” does not necessarily mean the wallet’s recovery information remained secure.
More troublingly, a tampered device may still pass Ledger's official Genuine Check without the added hardware being detected. Genuine Check primarily verifies the identity of the Secure Element and the authenticity of its firmware. The check cannot detect unauthorized physical modifications such as spying implants when the original Secure Element remains intact.
The incident therefore exposed a serious but often overlooked form of supply chain risk: hardware-wallet security depends not only on the chip and firmware, but also on the device’s entire journey from the manufacturer to the user.
A device may pass through regional distributors, third-party warehouses, logistics providers, and retailers. Any party with physical access to it may become another risk point that needs to be assessed.
The broader lesson is clear: a genuine device can still be physically modified after leaving the manufacturer's control
2. From Trezor to Bitget: How Attackers Bypass the Strongest Defenses
Once the Ledger incident is understood, the recent security events affecting Bitget and Trezor reveal a remarkably similar pattern. Instead of attacking the strongest defenses head-on, the attackers entered through third-party services at the perimeter.
Consider Trezor first.
In early September, some Trezor users received an email titled “Critical Security Alert: STM32 Entropy Vulnerability,” claiming that their hardware wallets contained a serious vulnerability and required immediate action.
Such a message could easily alarm users. Few people would remain calm after receiving a warning about a critical flaw in the hardware wallet protecting their assets.
The attackers exploited Brevo, the third-party email marketing platform used by Trezor, allowing malicious content to reach users through legitimate email infrastructure.
According to Brevo’s incident report, the attacker exploited an authorization-boundary flaw in its single sign-on system and gained unauthorized access to 138 customer accounts. Some of these accounts were used to send phishing emails or export contact data.
Trezor subsequently confirmed that 347,149 marketing email addresses had been exported. The phishing message attempted to persuade users to download a malicious application and enter their recovery phrase.
There is no evidence that Trezor’s hardware wallets or private-key protection systems were compromised. What the attacker initially obtained was user information and the ability to misuse an official communication channel.
For an ordinary recipient, however, that made the attack more difficult to identify. The message could arrive from a familiar official domain and pass normal email authentication checks, while its content had already been replaced with phishing instructions.
If a user then entered their recovery phrase, a breach involving a third-party email provider could escalate into an actual loss of assets.
Now consider Bitget.
On September 24, unauthorized asset transfers occurred from some of Bitget’s hot and warm wallets. The final confirmed amount involved was approximately $388 million.
According to Bitget’s published investigation, the attacker exploited a vulnerability in a third-party security product to obtain high-level internal credentials. Those credentials were then used to access wallet-related backend systems, forge withdrawal instructions, and bypass existing risk controls, allowing fraudulent transfers to enter the normal execution process.
Bitget stated that no private keys were compromised and that its cold wallets were unaffected.
At first glance, this may sound contradictory. If the private keys were not stolen, how could the funds still be transferred?
The answer lies in how custodial exchanges operate.
When a user requests a withdrawal, an employee does not manually retrieve a private key and sign every transaction. The request moves through a complete internal workflow that includes account verification, risk review, transaction generation, and wallet signing.
It is similar to a bank vault. Even if the vault key is protected with extreme care, someone who can impersonate a highly privileged employee and submit a forged transfer instruction that appears to have passed approval may still cause funds to be sent out incorrectly.
The Bitget incident demonstrated how a failure in upstream access control and instruction validation could compromise the systems responsible for executing fund transfers.
“No private keys were leaked” and “funds cannot be transferred without authorization” are therefore two different security claims.
The infrastructure security incident disclosed by MetaMask in late September illustrated another dimension of operational risk.
As a precaution, MetaMask began exiting some affected staking validators. In its October 1 update, the company said it had found no indication that MetaMask wallets or customer funds had been affected. It also emphasized that its staking operations were non-custodial and that it did not manage withdrawal keys on behalf of customers.
That does not mean an infrastructure incident can have no other consequences. Non-custodial architecture primarily addresses asset control; it does not automatically eliminate the operational risks of external infrastructure.
When these incidents are viewed together, the pattern becomes clear.
- Ledger exposed the risk of physical tampering during hardware distribution, potentially leading to recovery-phrase theft.
- Trezor and Brevo demonstrated the risk of user data exposure and the misuse of an official communication channel, which does not mean the wallet itself was compromised.
- Bitget showed how a vulnerability in a third-party product could propagate into highly privileged internal systems and directly affect the execution of fund transfers.
- MetaMask reminded us that asset control and operational risks associated with services are not the same thing.
Crypto products today are no longer isolated islands.
Wallets rely on external RPC nodes to read blockchain data and aggregation services to retrieve market information. Exchanges depend on third-party security monitoring, KYC providers, and risk-control components. Beyond these sit node operators, cloud providers, customer-support platforms, and email systems such as Brevo.
These services improve efficiency and user experience. But every new external dependency also introduces another trust relationship that must be managed:
What can the third party access? How much authority does it have? If it is compromised, can the resulting risk propagate into other critical systems?
3. How Should Products and Users Respond?
With third-party dependencies becoming more complex and interconnected, it would be unrealistic—and commercially impractical—to expect every product team to return to a model that uses no external services whatsoever.
The real test of security architecture is whether it can minimize every potential attack surface.
Why, for example, should a SaaS provider used only to send marketing emails retain a complete database of user contact details indefinitely? Why should a third-party security monitoring tool be able to reach a core production environment without independent, multilayer authorization? Sensitive actions involving the movement of funds must never rely on implicit trust between internal systems. They require strict permission isolation and independent cross-checks.
These principles are commonly known as least privilege and separation of duties.
An email platform should possess only the permissions necessary to send emails. A security monitoring tool should not be able to initiate asset transfers. A large withdrawal should not be approved solely because a single internal system submitted an instruction.
The Ledger incident further demonstrates that hardware-wallet manufacturers must extend security management into the physical distribution process.
From manufacturing and warehousing to logistics and reseller delivery, manufacturers need traceable procedures, methods for detecting abnormal disassembly or device substitution, and the ability to identify affected batches and users when something goes wrong.
For a hardware device designed to protect private keys, delivery is not merely a channel-management issue. It is part of the security architecture itself.
Ordinary users cannot audit a wallet’s software supply chain or investigate every warehouse and logistics provider that handles a hardware wallet.
But that does not mean users can only accept these risks passively. Several habits can meaningfully reduce exposure.
First, minimize unnecessary intermediaries when purchasing a hardware wallet.
Whenever possible, order through the manufacturer’s official website and choose direct fulfillment from the manufacturer or an official warehouse. This generally reduces the opportunities for third parties to access, open, modify, or replace the device after it leaves the manufacturer’s control.
From a risk-management perspective, the more independent parties that physically handle a device, the more trust assumptions the user must accept. After receiving the device, users should still inspect the packaging and casing for irregularities, verify it using official software, and follow the correct initialization procedure.
Second, reconsider what it means for a message to be “official.”
The Trezor incident showed that even when an email is sent through infrastructure legitimately used by the company, the links and instructions inside it are not automatically safe.
Messages involving wallet upgrades, account freezes, asset migrations, or vulnerability fixes should be treated with particular caution. Instead of clicking a link inside the message, open the official website from a saved address or use the official app already installed on your device to verify the information independently.
Users of non-custodial wallets such as imToken should likewise rely on official channels. Downloads should be obtained through token.im, while unusual messages should be verified through official entry points such as “Support and Feedback” within the app.
No matter whether someone claims to represent customer support or a security team—or presents a highly technical explanation of a vulnerability—they should never be given a recovery phrase or private key.
Finally, users need to distinguish between different types of security incidents and their actual impact.
An exposed email address primarily means that the user may face more targeted phishing attempts in the future. Clicking a suspicious link requires determining whether any malicious file was downloaded or executed. If a user has entered their recovery phrase into a suspicious website or application, they should treat the wallet as compromised and act immediately.
If a suspicious transaction or approval has been signed, the user must examine the specific onchain action and determine whether an ongoing contract-approval risk remains.
For failures involving third-party services or infrastructure, users should refer to official disclosures and determine whether the incident affects their assets, service availability, or earnings.
Hearing about a “wallet security incident” does not automatically mean that private keys have been compromised. Nor should users move assets to an unfamiliar address merely because they received an urgent security notice.
In many cases, attackers are not trying to defeat the strongest technical defense themselves. They are trying to frighten users into completing the final step on their behalf.
Further reading: “Can AI “Challenge” Cryptography? Web3 Must Prepare Early—but Migration Must Not Be Rushed.”
Final Thoughts
For years, one of the crypto industry’s most repeated principles has been: “Not your keys, not your coins.”
That principle remains important. Control of the private keys determines whether users can truly control their own assets.
But as wallets, exchanges, and onchain financial products mature, we must recognize that private-key protection is only one part of the broader security system.
A genuine hardware wallet can still be physically modified during distribution. A message genuinely sent through an official email system can still be exploited by an attacker. A third-party tool originally introduced to improve security may even become an entry point into a core asset-management system.
These incidents do not mean that we should stop trusting every wallet and external service. On the contrary, they show that the industry must extend security beyond individual products to cover the entire lifecycle of supply chains, permission management, user communications, and incident response.
A mature crypto security architecture must do more than prevent private keys from being exposed.
Even when an external component fails, the system should contain the risk before it crosses the final boundary protecting the user’s assets.