Supply chain, long cons, and the vendor you cannot avoid trusting

At some point in every self-custody setup there is a thing you did not make and cannot inspect. A chip whose contents you take on faith. Firmware you did not compile. A parcel that spent four days out of your sight. You can push that boundary back a long way, and this guide is about how far — but the honest starting point is that it never reaches zero.

Three quite different problems get filed under "supply chain", and they call for different answers. Confusing them is how people end up buying tamper-evident stickers and calling it a threat model.

1Three problems wearing one name

• Interception. Someone touched the device between the factory and your hands — a swapped unit, a counterfeit, a pre-loaded recovery sheet. An outsider, acting once, against one parcel.
• The long con. Nobody intercepted anything, because the person you needed to worry about was inside from the beginning. They spent years being genuinely useful, and then spent the trust.
• Plain vendor risk. No attacker at all. A company folds, a product line is dropped, a design trade-off you never knew you accepted turns out to matter. Most of what actually goes wrong lives here.

A tamper seal answers the first problem, weakly. It has nothing to say about the other two.

2The parcel

Holographic seals and shrink wrap are worth something, but much less than their theatre suggests: they are manufactured goods like anything else, and an attacker who can source a device can usually source the packaging. Treat an intact seal as mildly reassuring and a broken one as disqualifying, and do not build anything on top of that.

The defence that actually works is procedural, and it is short: never accept a secret the device did not make while you were watching. The counterfeit that has taken the most money is not a sophisticated implant — it is a device shipped with a recovery sheet already filled in, and a card in the box explaining that this is your wallet. It is not. It is the attacker’s wallet, and everything you send to it is a gift.

• A device that arrives with words already written on the recovery card is compromised. There is no benign version of this.
• Being asked to re-type words the device has just shown you is the normal backup check, and both COLDCARD and Trezor document it. The danger is a phrase that existed before you initialised the device — printed on a card, already loaded when it arrived, or read out to you by someone claiming to be support.
• Anyone who contacts you claiming your device needs its phrase re-entered for a firmware issue is running the same scam without the hardware.

Beyond that: buy direct from the manufacturer rather than a marketplace where the listing and the fulfilment are different companies, initialise the device yourself, check the firmware version and its signature against the vendor’s published value, and generate a fresh wallet before anything of value goes near it. Counterfeit units convincing enough to fool a casual look have been found in the wild, with the real microcontroller replaced — which is exactly why the check that matters is behavioural rather than visual.

3The long con

This is the hard one, and it is not hypothetical.

In March 2024 an engineer investigating why ssh logins on a test machine had become about half a second slower found a backdoor inside xz, a compression library that ships in nearly every Linux distribution. It had been introduced by an account that had been contributing to the project for roughly two years — fixing real bugs, doing real work, eventually becoming a co-maintainer and gaining the right to cut releases. The malicious code was not in the source anyone reads; it was assembled from files that looked like test fixtures. It was found by accident, by someone chasing a performance oddity that had nothing to do with security.

Bitcoin has its own version. In 2018 the maintainer of a widely used JavaScript library, tired of supporting it for free, handed it to a volunteer who had been helpfully contributing for some time. The volunteer added a new dependency, and that dependency carried a payload aimed specifically at the build of a particular bitcoin wallet, targeting users’ keys. It reached an enormous number of machines before anyone noticed, because everything about the handover looked exactly like the open-source maintenance everyone wants more of.

Notice what defeats every heuristic you would normally reach for. A long commit history, real contributions, an established name, code in front of everyone — those are not evidence against this attack, they are the attack’s method. Reputation is accrued in public precisely so it can be spent once.

4What reproducible builds prove

A reproducible build means anyone can compile the published source and get a binary identical to the one the vendor shipped, byte for byte. That is a real and valuable property, and a device whose firmware is reproducible is meaningfully better than one whose is not.

Be precise about what it rules out, though. Reproducibility proves the binary matches the source. It says nothing about whether the source is honest. The xz backdoor was in the project’s own repository, put there by someone entitled to put things there — a reproducible build would have faithfully reproduced it.

5Signatures, and where the chain ends

Verifying a release signature before you flash it defeats a substituted download: a file altered in transit or on a mirror will not verify against the vendor’s key. Do it. Most vendors document the exact command, and the ones that do not are telling you something.

But follow the chain to its end and you arrive at a key you got from somewhere, most likely the same website that served the firmware. The usual answers help without closing it: fetch the key over a different network, check it against a copy published somewhere the vendor does not control, and note that a key you have been verifying against for three years is a better bet than one you fetched five minutes ago. A signature proves the vendor signed it. It cannot prove the vendor should have.

6The one answer that survives a dishonest vendor

Every defence above assumes the vendor is honest and asks whether someone else interfered. Only one common arrangement drops that assumption: multisig across different manufacturers.

In a 2-of-3 where the three keys live on devices from three vendors, running three independent firmware codebases, a single compromised device cannot move funds. It cannot even do it quietly — it needs a second signature from a device that shares none of its code. That is a structural answer rather than a procedural one, which is why it is the only thing on this page that keeps working when the vendor themselves is the problem.

It is not free, and the costs are the familiar ones: three devices to buy, three backups to store and test, a descriptor to keep alongside them, and considerably more ways to lock yourself out by accident. A 2-of-3 protects you from one dishonest vendor and from one lost key. It also gives you three chances to lose the plot.

How a 2-of-3 multisig actually works

7Trade-offs you are choosing whether you notice or not

• Secure element or open silicon. A secure element resists someone who has your device on a bench, which is a real and common threat. It has also, historically, been a chip you cannot audit — the design is behind an NDA and you are trusting a certification rather than reading anything. That is no longer quite the binary it was: Tropic Square's TROPIC01, shipping in the Trezor Safe 7 alongside a conventional certified element, publishes its design and datasheet for independent review. One example is not a trend, and the rest of the market still works the old way, but the trade is worth re-checking rather than assumed. What that resistance is made of is worth understanding before weighing it.
• Closed or open firmware. Open firmware can be read and, at its best, reproduced. Closed firmware cannot, and you are trusting a process you can only see the outputs of. Neither answers the malicious-maintainer case on its own.
• Standards or convenience. A device that stores a standard BIP39 phrase on a standard derivation path can be recovered on completely different hardware years from now. Anything proprietary makes the vendor’s continued existence part of your backup plan.
• How much the vendor knows about you. Customer databases leak; one hardware wallet company’s did, and its customers received phishing and physical threats for years afterwards. Where a device is bought, and under what name, is part of this decision.

Why being identified as a holder is its own risk

8What to actually do

• Buy direct from the manufacturer, and prefer vendors who publish reproducible builds and signed releases.
• Initialise every device yourself. Never accept a pre-filled recovery sheet, and never re-enter an existing phrase because someone asked you to.
• Verify firmware signatures before flashing, and keep the vendor key you have been checking against rather than re-fetching it each time.
• Confirm receive addresses on the device’s own screen, not on the computer driving it.
• Prefer standard BIP39 and standard derivation paths, so recovery never depends on one company still existing.
• For amounts that would genuinely hurt to lose, spread the trust across vendors with multisig rather than deepening it with one.

The short version

The parcel problem is real but tractable: buy direct, initialise it yourself, and never accept a secret you did not watch being made. The vendor-risk problem is mostly solved by standards, so that no company’s survival is load-bearing. The long con is the one with no procedural fix, because it defeats reputation, code review and reproducible builds alike — and the only answer to it is not to let any single vendor be sufficient.

The 2024 xz backdoor is documented as CVE-2024-3094; the 2018 npm incident is documented in the event-stream maintainers’ own thread . Device-specific verification steps come from each vendor’s published documentation.