Hardware Wallet Security Starts Before the Device Arrives

Two hardware-wallet customer-data incidents within days of each other exposed the same uncomfortable gap in cold-storage security. The devices themselves were not compromised, yet names, email addresses, phone numbers, shipping addresses and order information belonging to tens of thousands of customers ended up accessible to unauthorized parties.

The SafePal breach affected about 39,798 customers whose orders were placed between March 2025 and April 2026. Days earlier, Trezor disclosed that a breach at fulfillment partner ShipMonk exposed full contact and shipping information for 11,742 customers and more limited information for another 1,947. Neither incident exposed seed phrases or private keys.

That distinction is important, but it does not make the leaked information harmless. Buying a physical wallet can create a second security perimeter outside the device: databases connecting a real identity, contact details and delivery location with a purchase from a hardware-wallet company.

The Purchase Creates Its Own Attack Surface

A hardware wallet is designed to prevent private keys from being exposed through an internet-connected computer or phone. Shipping one is almost the opposite problem. A merchant and its logistics partners need enough information to move a physical product to a customer.

SafePal says its exposed records included names, emails, phone numbers, shipping addresses and purchase details. Trezor says ShipMonk held names, addresses, phone numbers, emails and order numbers because those fields were required for fulfillment.

This does not reveal how much cryptocurrency a customer owns, or even prove that every purchaser actively uses the device. It does, however, give scammers unusually useful targeting information. An attacker does not have to guess whether a recipient might recognize a hardware-wallet brand, and leaked order details can make a fake refund, firmware update, support message or delivery problem considerably more convincing.

SafePal already has evidence that this second stage is underway. The company says it has identified and taken down more than 30 fraudulent websites and phishing links associated with scam activity around the incident. It also says reports consistent with the problem began arriving in May, months before the root cause was publicly confirmed.

There is historical precedent for that progression. After Ledger’s 2020 e-commerce breach exposed roughly one million email addresses and more detailed information for an initially identified subset of 9,500 customers, the company later said the incident led to “aggressive phishing attacks” and that it had removed more than 170 phishing websites by December.

Retention Can Determine the Blast Radius

The sharper difference between the SafePal and Trezor incidents is not the hardware. It is how long customer data remained available.

Trezor requires completed-order information to be deleted after 90 days, including from fulfillment partners. Its privacy policy says names, addresses, phone numbers and emails used for fulfillment are removed after that period, while invoice information required for accounting is stored separately. Trezor said this policy limited how many records were available in ShipMonk’s systems when the breach occurred.

SafePal reached a similar policy after its incident. Its investigation found that a scheduled cleanup process had stopped working correctly between September 2025 and April 2026, leaving older records in the order system. SafePal says the failure did not cause the authorization flaw, but it explains why the exposed dataset stretched back to March 2025. The company has now reduced sensitive order-data retention to 90 days.

This is where data minimization becomes a security control rather than a general privacy preference. A vulnerability can determine whether an attacker gets into a system. Retention policy helps determine what is still there to steal once that happens.

Ledger adopted a related approach after its own 2020 breach. In 2022, the company said older e-commerce records containing names, addresses and phone numbers were being moved into a segregated environment with restricted access, while it reviewed third-party providers to reduce the personal information they could access and accelerate deletion or anonymization. Some records still had to be retained for accounting obligations, illustrating why “delete everything” is not always operationally or legally possible.

More Private Delivery Changes What a Breach Can Reveal

The logical extension is to reduce how much identifying data enters the fulfillment chain in the first place.

Trezor now recommends options such as an email address not tied to a user’s primary identity and, where practical, a P.O. box. More significantly, it plans an “Anonymous Delivery” system using locker pickup, neutral packaging, generic sender information and automatic deletion of shipping identifiers after delivery. The company says it is targeting an EU launch in September 2026 and a U.S. rollout by year-end.

These measures are not anonymity guarantees. Payment processors, couriers or pickup providers may still collect information under their own legal and operational requirements. Trezor itself notes, for example, that P.O. box providers may retain customer identification.

They can nevertheless break some of the most useful links in a breached merchant database. An alias email reduces the value of an exposed address for cross-service impersonation. A pickup point can keep a home address out of a hardware-wallet vendor’s fulfillment records. Short retention periods mean that even correctly collected data does not have to remain exposed indefinitely.

The SafePal and Trezor incidents do not establish that leaked customer addresses have caused physical attacks, and the documented immediate risk in both cases is phishing and impersonation. But they do establish something narrower: securing the private key does not secure the information generated while acquiring the device.

For hardware-wallet vendors, the relevant security boundary therefore extends beyond firmware, secure elements and recovery phrases. It includes checkout systems, order-tracking plug-ins, fulfillment contractors, shipping databases and, critically, the decision about when identifying data stops being useful enough to keep.