Trezor’s disclosure that another 67,000 U.S. customers were affected by the ShipMonk breach significantly changes the understanding of the incident. The newly identified records relate to orders placed between November 2019 and August 2021 and include names, email addresses, phone numbers, shipping addresses and order numbers. These customers are in addition to the 13,689 customers disclosed in August, bringing the known exposure to more than 80,000 people. Trezor says its own systems were not compromised, its hardware wallets remain secure and private keys or wallet backups were not exposed. The more troubling issue is that these historical records were apparently still present in ShipMonk’s systems despite Trezor repeatedly receiving written assurances that the data had been deleted. 

That distinction makes this more than a conventional third-party breach. The security failure is not only that an attacker gained unauthorized access to a logistics provider. It is that information which was supposed to have ceased to exist was still available to steal. Trezor’s privacy model has long emphasized reducing exposure by anonymizing order data after a limited retention period, with its current privacy policy stating that customer order information is anonymized no later than three months after the sale to the fullest possible extent. Trezor also says it had contractually required fulfillment partners to follow similar deletion practices. If historical customer information from 2019 through 2021 remained accessible years later, then the control failed at the exact point where data minimization is supposed to provide protection.

This is an important lesson because data deletion is frequently treated as an administrative or privacy exercise rather than a cybersecurity control. In reality, deleting information that is no longer required is one of the strongest forms of breach prevention available. Encryption can fail if keys are compromised. Access controls can fail if credentials are stolen. Monitoring may fail to detect an attacker. But information that has genuinely been destroyed cannot subsequently be exfiltrated. Organizations therefore need to view retention limits as attack-surface reduction, not merely as compliance language buried somewhere in a data-processing agreement.

The hardware-wallet context makes the exposure particularly sensitive. The leaked information does not directly allow an attacker to move cryptocurrency because wallet private keys and recovery backups were not part of the breach. However, the combination of a customer’s identity, phone number, email address, physical shipping address and evidence that the person purchased a hardware wallet creates a highly valuable targeting dataset. Criminals no longer need to guess whether someone owns cryptocurrency. The order information can provide a strong indication that the person deliberately acquired a device designed to secure digital assets.

That makes targeted phishing substantially more convincing. An attacker can impersonate Trezor support and reference the victim’s real name, address or purchase details while claiming that the device requires an urgent firmware update, wallet verification or recovery procedure. The objective would typically be to persuade the victim to reveal their wallet backup, enter recovery words into a malicious website or install fraudulent software. Trezor has specifically warned affected customers to expect fake emails, phone calls and fraudulent letters and has reiterated that users should never provide their wallet backup to anyone.

The inclusion of physical addresses creates another category of risk that is more serious for cryptocurrency users than for many conventional consumer-data breaches. Knowledge that a particular individual owns a hardware wallet can potentially create physical-security concerns because the attacker may infer that valuable digital assets are stored under that person’s control. Trezor itself warned affected customers about potential physical security risks, which is an unusually important acknowledgement in a breach notification.

This is not an entirely theoretical concern. The cryptocurrency industry has already seen how leaks of hardware-wallet customer information can create years of downstream abuse. Following the earlier Ledger data breach, customers reported receiving highly targeted phishing campaigns, fraudulent hardware-wallet replacements, scam phone calls and even physical mail designed to convince victims to surrender their recovery information. The lesson is that identity data associated with cryptocurrency ownership can remain useful to criminals long after the original breach disappears from the news cycle.

The ShipMonk incident therefore raises an important vendor-governance question: how does an organization verify that a third party has actually deleted customer information? Written contractual confirmation is useful from a legal perspective, but it is not technical evidence. A provider can certify that information has been deleted while copies remain in backups, archives, analytics systems, disaster-recovery environments or other storage locations. If those secondary datasets are later compromised, the organization discovers that the promised retention policy was never fully implemented.

Organizations handling sensitive information should therefore distinguish between contractual deletion and verifiable deletion. Vendor agreements should define which systems contain customer data, how backups are handled, when deleted information ages out of backup media, whether derived copies are retained and how deletion can be independently verified. For higher-risk datasets, periodic audits or technical attestations may be justified rather than relying entirely on a vendor email stating that deletion has occurred.

Backup retention is particularly relevant. Security teams frequently discover after incidents that old information survives inside backup systems long after it has been removed from production databases. This creates a difficult but manageable problem. Some backup architectures are deliberately immutable, meaning individual records cannot simply be removed from every historical snapshot. In those cases, organizations need clearly defined backup expiration periods and controls preventing old backups from being restored or accessed casually. A nominal 90-day data-retention policy has limited value if full copies of the same information remain in backups for five years.

The incident also shows why third-party risk cannot be delegated away merely because the primary company does not operate the breached infrastructure. From the customer’s perspective, they bought a Trezor product and supplied their address to receive it. They generally do not make an independent risk decision about the logistics platform operating behind the checkout process. Trezor may not have been technically responsible for the ShipMonk intrusion, but customers reasonably expect Trezor to ensure that vendors receiving their information follow the same privacy and retention commitments Trezor makes to them.

This is an important distinction for all enterprises using fulfillment, CRM, marketing, cloud or support providers. Every third party receiving customer information expands the organization’s effective data perimeter. A company can maintain excellent internal security while still suffering customer exposure because one downstream service retains unnecessary copies. Third-party cybersecurity therefore needs to address both how well the vendor protects information and whether the vendor needs to retain the information in the first place.

The breach also demonstrates why data maps need to include former vendors and historical relationships. The newly affected records came from Trezor’s earlier cooperation with ShipMonk between 2019 and 2021. Organizations often concentrate vendor-risk management on current suppliers while assuming that terminating a contract also ends the associated data exposure. That assumption is unsafe unless deletion is independently confirmed and retention periods are monitored. Former service providers can remain part of an organization’s attack surface for years if they continue holding historical customer information.

For security teams, the most useful question is therefore not simply “Which vendors currently process our data?” but “Which vendors have ever received our sensitive data, and can we prove they no longer possess it?” That second question is considerably harder, which may explain why it is asked less frequently despite being the more interesting one.

Trezor’s response also deserves some credit for explicitly distinguishing the wallet-security impact from the privacy impact. The company has stated that affected customers’ devices remain secure and that the breach did not expose wallet backups or private keys. That is important because users receiving a breach notification may otherwise believe they need to move funds immediately or enter their recovery phrase somewhere to “secure” the wallet, precisely the kind of behaviour criminals are likely to encourage.

Affected users should therefore avoid making security decisions based on unsolicited messages claiming to relate to the incident. Firmware and software updates should be obtained only through official Trezor channels, and a wallet backup should never be entered into a website, disclosed over the phone or provided to someone claiming to be support staff. Any message that demonstrates knowledge of a real Trezor purchase should still be treated as potentially malicious because that knowledge is now part of the compromised dataset.

For organizations, the broader lesson extends far beyond cryptocurrency. Data minimization is one of the few security controls that permanently reduces breach impact. Every unnecessary record retained today is another record that may appear in tomorrow’s incident report.

The most important failure in the Trezor-ShipMonk incident may therefore not be the attacker’s ability to access ShipMonk.  It may be the fact that the attacker was able to steal information that everyone believed had already been deleted. A retention policy written into a contract does not reduce risk. Only actual deletion does.

Hardware wallet manufacturer Trezor on Friday disclosed that another 67,000 customers from the U.S. have been impacted in a breach at its shipping provider ShipMonk. The exposed information includes customer names, email addresses, phone numbers, shipping addresses, and order numbers between November 2019 and August 2021. The breach does not affect the security of the company's hardware wallets

Source: Trezor Says ShipMonk Breach Exposed 67,000 U.S. Customers' Data It Said Was Deleted via The Hacker News — published 05 Sep 2026.