Your Keys, Their Database: Trezor’s Shipping Breach
A hardware wallet protects a secret. The company delivering it still has to account for the personal information left behind.

Keeping your own keys does not erase the delivery address you supplied to buy the device.
On September 4, 2026, Trezor said the breach at its shipping partner, ShipMonk, affected approximately 67,000 additional US customers who ordered between November 2019 and August 2021. Names, email addresses, phone numbers, shipping addresses and order numbers were exposed, the company said. It maintains that its systems and devices were not compromised. Trezor’s updated advisory.
That distinction matters. This is not evidence that someone defeated a hardware wallet’s protection of private keys. It is a reminder that the person using one can remain exposed through a supplier’s records. A secure device and a serious privacy failure can coexist.
The disclosure grew backwards
The initial August 13 account concerned 13,689 customers. BleepingComputer’s reporting at the time also drew on customer-notification emails sent by ShipMonk. BleepingComputer’s original report.
An August 14 correction acknowledged that some partially exposed records involved older orders. September’s update widened that historical exposure substantially. Yet, when reviewed on September 6, the advisory’s older FAQ still described a recent-order limit and deletion of older data. That wording no longer describes the full scope disclosed. The advisory and retained FAQ.
How the disclosure expanded
Three disclosure dates. One shipping-provider incident.
-
13 August 2026 — 13,689 customers initially disclosed. 11,742 with full exposure; 1,947 with partial exposure.
-
14 August 2026 — Older orders acknowledged. Trezor clarified that the 1,947 partially exposed customers included older orders. This was not a new group of 1,947.
-
4 September 2026 — Approximately 67,000 additional US customers. Orders from November 2019 to August 2021; names, emails, phone numbers, shipping addresses and order numbers exposed.
Company-reported scope, not independently audited by Gazette. Dates mark public disclosures, not separate breaches. September’s number is additional and approximate.
Source: Trezor’s advisory and dated updates. Checked 6 September 2026.
The question is no longer only how an intruder got in. It is why records from years earlier were available to take.
Trezor says it repeatedly obtained written confirmation that ShipMonk had deleted the data. In a separate response to Protos, it said the earlier cooperation period had apparently been overlooked when the original breach scope was established, and that it was arranging another audit. Protos’s follow-up reporting.
A deletion promise needs evidence
Trezor’s current privacy summary says delivery data should be deleted from its own and its fulfilment partner’s systems after 90 days, with exceptions for unresolved order issues. It separately describes ten-year invoice retention in an encrypted environment and longer retention by payment providers. Those are distinct record categories, not a promise that every trace of a purchase disappears after three months. Trezor’s privacy summary.
That current summary is not proof of the exact historical contract or how either company implemented it. Gazette has not reviewed the deletion confirmations, a completed audit, or ShipMonk’s explanation of the historical retention.
The evidence worth asking for is concrete: which records and systems did the deletion checks cover, and how was completion verified? Did the checks extend to exported copies and backups? An assurance that a process exists is different from a check that the process removed the intended data. These are reporting questions, not claims that any particular backup or export caused this incident.
Outsourcing delivery may be necessary for a business serving customers across borders. It does not make the resulting dependency irrelevant to the buyer. Customers choose a wallet company; they have much less visibility into the databases used to get a parcel to their door.
The standard should be proportionate and testable: collect what delivery requires, identify where it goes, distinguish records that must remain from those that should not, and verify the promised deletion. A privacy policy is a commitment to that work, not evidence that the work was completed.
Protect the person, not only the device
A purchase record does not prove that someone currently owns bitcoin, much less establish a balance. But it can give an impersonator enough context to make an approach feel familiar. Knowing an order number is not proof that the caller is legitimate.
Trezor’s security guidance warns about unsolicited messages and requests to reveal a wallet backup, also called a recovery seed. The practical rule is straightforward: do not share those words or enter them into a website prompted by a message. Reach support independently through the official site, rather than a link or telephone number supplied by the sender. Trezor’s phishing guidance, official support.
Those precautions do not return an exposed address to privacy. Nor should the burden of recognising every convincing scam become an excuse to stop examining the supplier’s data practices.
Self-custody remains useful because it removes a custodian’s permission from spending your bitcoin. It does not remove every company from your life. For a business selling tools for individual sovereignty, protecting the customer’s information belongs in the security story, alongside protecting the customer’s keys.