Don't Trust the Company. Design So the Leak Doesn't Matter.

A hardware wallet can do its job perfectly and you can still end up with a security problem.

Not because the seed leaked.

Not because the firmware failed.

Because somebody leaked the customer database.

That is what makes the recent Trezor incidents interesting to me.

In August 2026, Trezor disclosed that ShipMonk, one of its fulfilment providers, had been breached. Names, emails, phone numbers and shipping addresses were exposed. The number later reached 80,689 affected customers after Trezor learned that older data, which it says should have been deleted, was still sitting in ShipMonk’s systems (https://trezor.io/blog/news/recent-customer-data-exposed-in-shipping-provider-incident).

Then in September, Brevo, Trezor’s newsletter provider, had a separate incident. Roughly 347,000 Trezor newsletter email addresses were affected, and an attacker used the access to send a fake Trezor security warning (https://trezor.io/blog/news/security-incident-at-brevo-our-third-party-email-provider).

The hardware wallet was not hacked in either case.

That is the point.

This is not a post about Trezor doing a bad job. I actually think Trezor is a useful example because it takes security and privacy seriously.

The problem sits one layer further out.

You can secure your own product. You cannot fully operate every company your business depends on.

The third-party problem has no clean answer

Modern companies outsource things because outsourcing often makes sense.

A hardware-wallet company is good at hardware wallets. It probably should not also become a warehouse-management company, newsletter platform, customer-support vendor, payment processor and logistics network.

Building all of that internally sounds more secure until you remember that you are asking a hardware company to build things outside its area of expertise.

That creates different risk, not necessarily less risk.

So companies use specialised providers. They negotiate contracts. They set retention rules. They ask for audits and certifications.

All useful. None of it changes the basic architecture.

If a courier needs your address, somebody eventually has to see the address.

If a newsletter platform needs to email you, it needs an address it can send to.

At some point the data is in somebody else’s system.

Trezor says it had written assurances that old ShipMonk data had been deleted. It later learned that it had not been.

That example changed the question for me.

Not only:

Can I trust this company?

But:

How much useful information do I want sitting there if that trust fails one day?

Hiding is not freedom

There is an easy way to take privacy too far.

Use a different identity for everything. Route every package through three intermediaries. Never talk about Bitcoin. Worry every time a company announces an incident.

At some point you have built yourself a prison and called it OPSEC. That is not what I want.

A good security setup should let you worry less.

If somebody learns that I am interested in Bitcoin, or even that I bought a hardware wallet, that information should not be enough to compromise anything important.

Privacy is still useful.

Buying a device that explicitly says “Bitcoin holder” is one of those situations where a little extra effort has a good payoff.

But secrecy should not be the thing holding the whole system together.

My mental model is:

Reduce the trail where it is easy, then design custody assuming some of the trail eventually leaks anyway.

That feels much closer to freedom.

The goal is not anonymity. It is breaking easy links.

A normal online order can contain your usual email, phone number, home address, payment details, residential IP address and an order for a Bitcoin-specific device.

Each piece is ordinary.

Together they make a useful record.

So I think about these purchases as a correlation problem.

I do not need to make every field anonymous. I want to avoid handing one company a clean map connecting all of them.

Start with the email

This is probably the cheapest improvement.

Instead of giving the merchant your main email address, create a unique alias for that company.

One example is Proton’s Hide-my-email aliases (https://proton.me/support/aliases-mail), available through Proton Pass and Proton Mail.

The merchant gets the alias. Messages still reach your inbox. If the alias later starts receiving phishing or spam, you know which identity escaped and you can disable it.

That is much better than one email address connecting a hardware-wallet purchase, social accounts, work history and every other service you have used for fifteen years.

One merchant, one alias.

No need to turn it into a project.

Remove the easy network signal

A VPN does not make me anonymous.

It does one narrower job here: the shop does not automatically receive my residential IP address.

If I then log into the same browser profile full of old cookies, give my home address and pay with my normal card, the VPN has not magically erased the rest of the trail.

This is why I prefer thinking in layers.

VPN. Clean browser session. Unique email. Only the information the order actually needs. None is impressive by itself, but together they reduce easy correlation.

The same applies to phone numbers. If a shop does not need one, I do not volunteer it.

If a number is required, a separate secondary number reduces linkage to the one I use across the rest of my life.

Delivery is the awkward one

A physical box has to go somewhere.

A pickup point, parcel locker, workplace, trusted person’s address, commercial mailbox or forwarding service can keep your home address out of the merchant’s customer database, depending on what is available and permitted where you live.

That does not mean nobody knows where you live.

The carrier or forwarding service may know exactly who you are.

But the data can be split.

The hardware-wallet merchant knows you bought a device.

The logistics provider knows where a parcel went.

Ideally, one database does not contain the complete story.

Trezor is moving in this direction itself. Its announced Anonymous Delivery model uses locker pickup, neutral packaging, generic sender details and reduced shipping identifiers (https://trezor.io/blog/news/recent-customer-data-exposed-in-shipping-provider-incident).

I like the direction because it changes the data flow instead of just promising to protect the same database harder.

Paying with Bitcoin is not automatically private

It is tempting to put “pay with Bitcoin” on the privacy checklist and move on.

Not so fast.

Bitcoin’s ledger is public. A payment can create another link if the coins you use are already connected to your identity.

So the useful principle is not:

Bitcoin payment = anonymous payment.

It is simpler:

Avoid creating unnecessary identifiers.

The merchant needs proof that the order was paid.

What payment method makes sense depends on the rest of your setup.

Sometimes the best Bitcoin device does not look like a Bitcoin device

This is one reason I like DIY projects such as SeedSigner.

A SeedSigner can be built from ordinary components: a Raspberry Pi Zero, display, camera and microSD card. The enclosure can be 3D printed.

SeedSigner itself points out that its component retailers are not Bitcoin-specific, which helps reduce the information trail associated with ordering a specialised wallet (https://seedsigner.com/seedsigner-independent-custody-guide/).

A Raspberry Pi is just a Raspberry Pi.

A camera module is just a camera module.

The transaction does not need to announce what you are building.

There is a tradeoff.

DIY removes convenience and creates new ways to make mistakes.

But you also learn how the thing works. You verify software. You test recovery. The black box gets smaller.

I would not turn everything into a DIY project. Sometimes the specialised product is simply better.

But this is a useful question to ask:

Does this actually need to be a Bitcoin-branded purchase?

The more important layer comes after delivery

All of this reduces exposure.

None of it should be your final defence.

Suppose a database containing your real name, home address and hardware-wallet purchase leaks tomorrow.

What changes?

If the answer is “my Bitcoin is now in immediate danger”, I would focus less on hiding the purchase and more on the custody design.

Knowing where someone lives should not reveal where the keys are.

Finding one device or one location should not be enough to collapse the setup.

Recovery should not depend on one company still existing.

I have written about these principles before, so I will not rebuild the custody article here.

The broader point is what matters:

Privacy lowers the chance of becoming an interesting target. Custody limits what a target can lose.

The first is valuable.

The second is what lets you sleep.

The tradeoff I want

I do not want to spend my life hiding.

I also do not want to hand every company a perfectly correlated identity when five minutes of effort can avoid it.

Those positions are not contradictory.

There is no perfect company that makes third-party risk disappear.

Building everything in-house creates its own security problems.

Outsourcing creates dependencies.

Certifications and contracts help, but they do not make incidents impossible or erase a copy that was never actually deleted.

So my approach is simpler.

Give companies less data when doing so is cheap.

Separate identities where correlation would be particularly useful.

Do not make specialised purchases more revealing than they need to be.

Then assume some information still leaks eventually and make sure the important system survives it.

I do not want security that requires me to remain invisible.

I want security that still works when I am not invisible.

What you can do

If you are just starting

For my next security-related purchase, this is what I do:

• I use a unique email alias
• I use a pickup point or another non-home delivery option when it’s practical
• I use a VPN and a clean browser session while ordering

Then I stop.

I do not turn a hardware-wallet order into a two-week intelligence operation.

The bigger win is making sure the Bitcoin itself is stored in a way I understand and have tested.

If you already think seriously about custody

I look at the information path around my setup, not only the keys.

I ask myself what a leaked merchant record would reveal.

I ask myself whether compromising one physical location would create a serious problem.

I ask myself which parts of the setup depend on information remaining secret rather than on the design remaining secure.

And for specialised hardware, I consider whether generic components or a DIY alternative can reduce the amount of Bitcoin-specific metadata I create.

The goal is not to disappear.

The goal is to make the leak boring.

Disclosure

No sponsorships or affiliate links.

Trezor is used here as a recent example of third-party risk, not as an argument against Trezor. Its own systems and devices were not reported compromised in the ShipMonk or Brevo incidents discussed above.

This article describes general principles and example patterns. My own custody locations, access paths and exact configuration are intentionally not described.