Trezor
A shipping list that says who owns a hardware wallet, and where to find it.
What happened?
Trezor disclosed on August 13 that attackers stole data on nearly 14,000 customers after compromising ShipMonk, its shipping and logistics provider. In early September the company revised the figure sharply upward to 81,000 affected individuals.
ShipMonk received extortion emails from the ShinyHunters extortion gang. Trezor itself was not breached. Its hardware, firmware and wallet infrastructure were not involved, which matters technically and helps the affected customers very little.
What data was actually inside?
Shipping and customer information: names, delivery addresses, email addresses, phone numbers and order records. No wallet seeds, private keys or funds, because Trezor never holds those by design.
The sensitivity here is not in any single field. It is in what the list means. A hardware wallet is bought by people who hold cryptocurrency and intend to secure it themselves. A shipping manifest for that product is a filtered list of probable crypto holders with verified home addresses, which is a far more valuable document than the sum of its fields.
Who gets hurt and how?
Customers whose threat model was specifically physical. Self-custody exists to remove the exchange as a point of failure, and the accepted trade is that the holder becomes responsible for their own security.
Crypto holders have been targeted with home invasion and coercion, and a name plus address plus proof of purchase is the input that makes such targeting possible. The exposure cannot be remediated by rotating anything. An address is not a credential.
What did they think they were doing right?
Outsourcing fulfilment is ordinary and sensible. A wallet manufacturer should not be running a warehouse, and ShipMonk is a legitimate provider used across ecommerce.
The assumption that failed is that shipping data is low sensitivity. For most products it is. For this product the customer list is the sensitive asset, arguably more so than anything in the device, and it was handed to a third party under terms written for generic ecommerce risk.
What did they not know about their own data?
The revision from 14,000 to 81,000 is the finding. That is not a small correction. It is a near sixfold increase, which means the initial scope was established before anyone knew what the provider actually held.
That gap sits at a vendor boundary, which is where it usually sits. Trezor could enumerate its own systems. What it could not do was state, on August 13, how many of its customers appeared in a partner's records and in which datasets, so the first number was an estimate presented as a count.
Every organization that ships a sensitive product has the same unanswered question about its logistics provider, and most will answer it the same way: after the provider is breached, in public, twice.
If you use cloud storage, do you know what sensitive data lives in your buckets and blobs? Or would you find out the same way they did?
Not sure where to start? How to find sensitive data across your estate
What does attribution look like the morning after?
ShinyHunters sent extortion emails to ShipMonk. Trezor has not attributed the attack on its own behalf, which is consistent with it being a downstream victim rather than the target.
This is the second entry in this series where ShinyHunters reached a large customer set through a third party rather than through the brand itself. Contractor, vendor, provider: the pattern is the perimeter somebody else is responsible for.
What would have changed the outcome?
Not giving the fulfilment provider more than a label needs. Name and address are required to ship a box. Email, phone and full order history are not, and each additional field expanded what ShipMonk's breach meant for Trezor's customers.
Second, knowing before the vendor does. The only reason the count went from 14,000 to 81,000 is that Trezor could not independently answer what its partner held about its customers. A supplier inventory that records which fields go where, maintained before an incident, turns a six week revision into a same day statement.
Trezor found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.
Want to understand the process first? Read our guide to sensitive data discovery .