Verified Platforms
Quick Links
Where to Stay Secure
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Non-custodial describes where your keys live. It says nothing about where you live.
The device does what it advertises. It generates a seed offline, holds it there, and never hands it to a website. But the box had to reach you, which means somebody printed a label carrying your name, your phone number and your front door, gave that label to a courier, and kept a copy for the returns window. Three days apart in August 2026, two hardware wallet companies emailed more than 53,000 customers about the copy. Each incident is a crypto wallet data breach in which no seed was touched and no device was opened.
This walkthrough follows Ava, who reads systems for their structure rather than their marketing, and Nina, who bought her first hardware wallet eleven months into her first brokerage account and has been careful with it since. Ava takes it in two passes: the mechanics of who ends up holding what when you buy a physical device, then the two disclosures that tested those mechanics in public.
Nina starts where the product page left her.
"I chose the non-custodial option," she says. "That was the entire point. Nobody is holding anything of mine."
Ava does not correct the sentence. She splits it.
"Custody of what?" she asks. "The word only does work once you finish that question."
Two separate things went through that checkout, and they have almost nothing to do with each other. The first is control of the coins: who can sign a transaction and move value. A hardware wallet answers that in your favour and keeps answering it, because the key is generated on the device and stays there, and no website can talk it into leaving. That is key custody, and the entire product exists to win it. If you want the part underneath, the randomness behind key generation is where that question gets settled.
The second is knowledge of you. Your name, your phone number, the street the parcel went to, and the fact that a crypto purchase happened at all. That is data custody, and it was never on the device. It sat in a checkout form.
"So the device is not the thing that leaked," Nina says.
"The device cannot leak that. It never had it."
Nina's threat model is organised entirely around the seed, the way a careful buyer's threat model usually is. Write the words on paper, keep them off every screen, never type them into anything that asks. All of it is correct, and all of it covers exactly one asset.
The seed has a threat model. The address never got one.
"How many companies have my address, then?" Nina asks. She is thinking of one.
Ava counts differently. Her count starts with the vendor's own store, which holds the order record because it took the payment and owes you a device. A payment processor holds a card and usually a billing address. Then the parcel has to be picked, packed and moved, and that is rarely the same company: a fulfilment provider holds what a parcel needs in order to arrive, which is a name, an email address, an order number, a phone number and a shipping address. Four fields and a door, sitting in a warehouse system you were never told the name of.
That is three companies, and the fourth is the one worth pausing on.
A fulfilment provider does not read raw order tables by hand. It runs software on top of them: support tooling, business intelligence, an analytics dashboard with a live connection to the database. Every one of those is another company, another codebase, another login. You chose the vendor. The vendor chose the shipper. The shipper chose the dashboard.
"I read the vendor's privacy policy," Nina says.
"That policy governs the vendor. Which is one of four."
Nothing here is exotic, and it is not unique to crypto hardware. It is what buying a physical object means. You may already recognise the shape from a third-party vendor compromising the frontend, where the contract was fine and the path to it was not. This is the same lesson one layer over, in a warehouse instead of a browser: you did diligence on one company, and your address ended up under the diligence of four.
Ava puts the next question ahead of any breach.
How big a leak gets is decided long before an attacker arrives. What sits in the database on the bad day is not a security outcome, it is a retention setting, and there are two common ways to enforce one.
The first is contractual. A vendor writes a deletion window into the agreement and requires its partner to erase or anonymize order data a fixed number of days after delivery. That window can be short, because the useful life of an order record is short: delivery, returns, a refund or a replacement, and then it is dead weight. Its failure mode is that enforcement is paperwork. You cannot audit it from outside, and it holds only as long as the partner performs.
The second is automated. A job runs on a schedule and deletes records older than the cutoff. The failure mode there is silence. Nobody's order fails when a cleanup job stops. No support ticket gets filed. A job that deletes nothing produces the same output as a job that had nothing to delete.
"So nobody emails you when it breaks," Nina says.
"Nobody outside the company can see it break at all. Which is why the question to put to a vendor is not whether it deletes your order, but when."
Neither failure announces itself. A contract holds only while the partner performs, and you learn which way it went afterwards. A schedule holds only while the job runs, and in the meantime the database quietly grows past the size anyone intended.
A deletion policy is a bet on a process, not a promise about the past.
Now the names. Nina has been waiting for them since the first paragraph.
Trezor published on 13 August. Its fulfilment provider, ShipMonk, had been breached through a critical SQL injection zero-day in Metabase, the analytics software ShipMonk ran on top of its order data. That flaw hit other Metabase customers too, including Framework and Tally, which is what a shared layer looks like when it fails. The notification chain ran through the supply chain in the same direction the data did: Metabase told ShipMonk on 6 August, ShipMonk told Trezor on 10 August, Trezor told customers on 13 August. Of 13,689 affected customers, 11,742 had a name, email address, phone number and shipping address exposed, and 1,947 had a name, city and email address exposed. Deliveries between 10 May and 8 August 2026, across seven countries: the United States, the United Kingdom, Sweden, Colombia, Brazil, Italy and Portugal.
Nina reads the country list twice. She works in São Paulo.
Trezor's own disclosure names the control from the previous section: "we require our partners to delete or anonymize order data 90 days after delivery." A three-month exposure window is what that clause looks like when it holds.
SafePal published on 16 August. Its cause was an authorization flaw in a third-party order-tracking plug-in on its store, which under some conditions let one buyer pull up another buyer's shipment details. Names, email addresses, shipping addresses, phone numbers and purchase information for 39,798 customers. Seed phrases, private keys, passwords, bank account information, payment card numbers and government-issued identification numbers were not exposed. During the investigation the company also found a separate configuration error that had stopped its data-cleanup processes between September 2025 and April 2026, which is why the exposed window runs from 2 March 2025 to 11 April 2026. Thirteen months of orders that a working cleanup job would have thinned down.
"Put them side by side," Nina says.
| SafePal | Trezor | |
|---|---|---|
| What leaked | Name, email, shipping address, phone, purchase information | Name, email, phone, shipping address (11,742 people); name, city, email (1,947) |
| Orders exposed | 2 Mar 2025 to 11 Apr 2026, about 13 months | 10 May to 8 Aug 2026, about 3 months |
| Retention control | Automated cleanup, stopped by a configuration error from Sep 2025 to Apr 2026 | Contractual: partners delete or anonymize order data 90 days after delivery |
| Earliest signal to customer notice | Early May report to 16 Aug email | 10 Aug notice from the provider to 13 Aug disclosure |
The two windows differ by a factor of four, and neither attacker had anything to do with that. Both took what was in front of them. What was in front of them had been decided months earlier, by a clause in one case and a scheduled job in the other.
Both clocks are worth reading slowly, because they measure different things. Trezor's three days start from the moment a partner told it there had been unauthorized access. SafePal's start from a customer phishing report in early May that the company treated as an isolated case; the authorization flaw itself surfaced in July, during a full review and rebuild of the order-processing system, and customers were notified on 16 August with an email headed "[Important] Your SafePal Order Information Has Been Affected." One company was handed a named incident by a vendor. The other had to infer one from a symptom.
A clock only starts once somebody names the problem.
A careful buyer already follows a set of tests. Does the email use your real name. Does it reference an order that exists. Does the caller know what you bought. Is the greeting generic, is the domain slightly wrong, is the tracking number invented.
Every one of those tests measures a single variable: how much the sender knows. They work because a stranger guessing at you gets the details wrong.
Nina sees it before Ava says it. "The leak is the answers."
Name, order number, phone number, address, and at SafePal the purchase information as well. There is even a difference in grade between the two incidents. Trezor stated that "the contents of the parcel were not exposed in this breach," so that caller can know a parcel arrived and not much more. The SafePal data includes what was bought, so that caller can open with your device model. Both are enough to sound real. One is enough to sound like support.
A sharper version of the problem is already live. BleepingComputer reported that the stolen SafePal data was listed for sale on a cybercrime forum, with the seller offering an order ID and shipping country as proof the data is authentic, and noted that it has not independently verified that the seller holds it. SafePal's own tool for checking whether you were affected asks a customer for an order number and a shipping country. The same two fields authenticate the seller's claim and a customer's query. A page that asks you for both cannot be told apart from the real one by looking at what it asks.
SafePal says it has taken down more than 30 fraudulent websites and phishing links tied to the incident, which is a fair measure of how quickly that gap gets filled. An attack lands by wearing something you already trust, which is exactly the trick behind malware arriving inside tools you installed on purpose. And the leaked list has a second, blunter use, because it also records which homes took delivery of a device built to hold money. That risk is real, and it is not the thing arriving in your inbox this month.
"So what still works?" Nina asks.
A red-flag test grades the attacker. The rule that survives grades the channel instead.
Nothing inbound gets authenticated. Not an email, not an SMS, not a phone call, not a DM, no matter how much it appears to know about you. Verification only runs in the other direction: you type the vendor's address yourself, you use the number from your own order confirmation, you open the app you installed. Same for the courier, whose delivery problems never require a seed phrase, a PIN or a wallet connection. If an inbound contact asks for one, the request is the answer.
The reason a direction rule survives is that it assumes nothing about the other side's information. Its only input is who started the conversation. An attacker holding your complete order history still cannot change who dialled.
There is a second half, and Ava is blunt about it. Stop confirming things. A caller reciting your order is not proving who they are, they are collecting the last field they are missing, and "Is this Nina, at the address ending in 214?" is a question rather than a credential. Silence costs you a slightly awkward call. Confirmation costs you the one detail that made the next call convincing.
Then the question from the retention section becomes portable. Before your next order, ask who ends up holding the label and for how long, exactly as you would run the checks that come before you deposit anywhere. That set of checks happens before money moves. This one happens after the box arrives.
Nina revises the sentence she started with.
"I thought non-custodial meant nobody had anything of mine. It meant nobody had my keys. Somebody had my door the whole time."
The device kept its promise in both incidents, and the exposure lived in the paperwork wrapped around it. Paperwork has a clock, and someone else sets it. When Nina buys her next device the first question is not which model, it is which companies end up holding the label, and how many days each of them is allowed to keep it. Her keys are a secret she can protect on her own. Her address is a record she can only ask about.
Before your next order, run the inventory: every company holding your name because you bought crypto hardware, and the deletion window each of them publishes. Twenty minutes, no device required, and it is the one layer of your threat model that no firmware update can reach. Then put the rest of the hour into the risk that lives in a position instead of a parcel, on a free Kodex account with a $5,000 paper balance across crypto, tokenized stocks and metals.
