Trezor expands ShipMonk breach notice to older orders

The shipping-data breach grew beyond the first notice

Trezor expanded its ShipMonk breach notice to include older US shipping records. It now reports 80,689 affected customers, with contact and delivery information exposed. Trezor says its own systems and devices were unaffected. That is the vendor’s assessment, not independent verification of each customer’s situation.

Why the retention policy matters to the story

Trezor’s published logistics privacy explanation says completed order and delivery records are ordinarily deleted after 90 days, with exceptions for unresolved order issues. It separately describes longer retention for invoice and payment-related records. Those categories should not be collapsed into a claim that every piece of information disappears on the same day.

The deletion assurance did not match the findings

Trezor says ShipMonk had confirmed deletion of the older records. The September update showed that those records remained.

An illustrative exposure assessment

Imagine a customer whose notice lists a name, phone number and delivery address. Those details could make an invented delivery problem sound convincing. A caller might know enough to refer to a real purchase without being authorised to help with the wallet. The fact that the caller knows the order should therefore be treated as context, not as proof of identity.

A different customer may have received a notice describing a smaller set of exposed fields. Their first task is to read the actual notice rather than assume that every record contained every category. A useful personal record would note which fields the company says were involved and the date of the notification. There is no need to add wallet secrets or unrelated financial information to that record.

These are hypothetical examples of how contact data can affect the credibility of an approach. They do not establish that either customer has been contacted by an attacker, that a physical threat has occurred or that funds have been taken. Keeping those outcomes distinct helps a person respond to evidence rather than to the most alarming possible scenario.

Verify a message without using its proposed route

Suppose a letter or call claims that a device must be replaced and asks the recipient to follow a special recovery procedure. The practical check is whether the same instruction appears through an official route the recipient opens independently. A phone number printed in the suspicious message is part of the message’s claim; calling it does not independently verify that claim.

A person seeking clarification can contact the company through its known support page and refer to the notification or order reference. They can describe the request they received without sending recovery words. This creates a useful separation between reporting a suspicious approach and complying with it.

For a household, it may help to agree that unexpected wallet-related calls are not handled on the spot. The recipient can take a note and verify later through the established channel. That is an editorial response plan for potentially convincing contact attempts, not a claim that Trezor announced a mandatory new procedure for all owners.

Read the historical correction accurately

The older-order update changes the scope of the original story. It would be misleading to repeat only the initial recent-order window and leave an older purchaser with the impression that their purchase date automatically excludes them. At the same time, a broad date range is not a substitute for the individual notification and the company’s investigation.

Our reading is that the central issue is the exposure and retention of shipping information. The article should not turn that into an unsupported claim that a hardware wallet’s signing mechanism failed. The useful next step for an affected reader is to understand the categories in their notice, recognise that an informed caller may still be untrusted and use an independently chosen support route for questions. That keeps the response tied to the data actually reported as exposed.

For anyone comparing old and new notices, recording the date beside each scope statement prevents an earlier, narrower description from being mistaken for the final account of the incident.