If your security plan assumes the hardware in your hands is the hardware the manufacturer shipped, you don’t have a security plan.
Ledger has confirmed that unauthorized hardware implants were found in some of its devices sold by CryptoBilis, a reseller operating in Southeast Asia. Those implants captured seed phrases as they were displayed on screen during wallet setup, then transmitted them over a cellular connection. More than $86 million in cryptocurrency was drained from hundreds of wallets. Ledger says its software and internal systems were not altered, which points squarely at a physical supply chain attack. The company is working with authorities to identify who did it and has asked CryptoBilis to stop selling its wallets.
I build bots and automation systems for a living, so my first reaction wasn’t about crypto at all. It was about every assumption I’ve quietly made about the machines my code runs on.
Why this attack is so uncomfortable
Most of us reason about security as a stack of software problems. Dependency audits, signed releases, reproducible builds, key rotation, least privilege. Those are real defenses and they work against real attackers. But every one of them sits on top of a foundation we treat as given: the physical device is what it claims to be.
This implant didn’t need to break signature verification. It didn’t need a zero-day in the firmware. It didn’t need to touch Ledger’s build pipeline or push a malicious update. It just read the screen, which is exactly where a hardware wallet is supposed to show you your recovery phrase, because showing it on an offline screen is the entire security story. The attack targeted the one step the design treats as trusted.
Then it used a cellular radio. Not Bluetooth, not Wi-Fi, nothing that needs pairing or a nearby laptop or a compromised host machine. A device sold as air-gapped had its own quiet uplink. No network logs on your side. No firewall rule to write. Nothing to notice.
The lesson for anyone shipping hardware-adjacent bots
A lot of what I write ends up on hardware I didn’t manufacture. Raspberry Pis for home automation agents. Mini PCs running inference locally. USB security keys gating deploy access. Industrial sensors feeding data pipelines. Most of it bought from whichever reseller had stock and shipped fast.
That purchasing habit is the vulnerability. The software side of my threat model is reasonably careful; the procurement side is basically vibes. I’ve never once opened a device to check whether the board matched the reference photos.
A few things I’m changing, and I’d suggest you consider them too:
- Buy security-critical hardware directly from the manufacturer or an authorized channel you can verify, not whichever marketplace listing is cheapest.
- Treat a secret displayed on any screen as a secret that has left your control. If your bot’s recovery flow prints an API key or a mnemonic to a display, assume something could be reading it.
- Assume “offline” is a claim, not a property. Devices with their own radios can exfiltrate without your network ever seeing it. Physical RF monitoring is one of the few ways to catch that, and almost nobody does it.
- Design so that a single compromised device is survivable. Multisig for anything holding value, split credentials for anything holding access, and limits on what one key can do by itself.
- Check weight, seals, and board photos on arrival. Low effort, occasionally decisive.
Architecture beats vigilance
The honest problem with supply chain attacks is that you probably can’t detect them. I’m not going to pretend that careful inspection would have caught a small implant inside a sealed consumer device. Most of us lack the tools, the reference hardware, and the patience.
Which means the answer isn’t better inspection. It’s architecture that doesn’t collapse when one component turns out to be hostile. In bot design terms: no single node should hold enough authority to cause unrecoverable damage. The agent that can read your database shouldn’t be the agent that can drop it. The key that signs transactions shouldn’t be sufficient on its own. The device that generates a secret shouldn’t be the only thing standing between you and total loss.
That’s more work up front. It’s also the only approach that holds up when your assumptions about the hardware turn out to be wrong.
What I’d actually do tomorrow
Inventory the hardware your systems depend on and write down where each piece came from. Not the brand, the actual purchase path. For anything in that list that guards money, credentials, or production access, ask whether a compromised unit would be survivable or catastrophic. Fix the catastrophic ones first, by splitting authority rather than by trusting harder.
Ledger’s software held up here. The physical path to the customer didn’t. That gap is where this kind of attack lives, and it’s the part of our stack most of us have never looked at.
🕒 Published: