Trezor Customer Data Exposed in ShipMonk Breach: What Happened and What Customers Need to Know

Trezor has disclosed a data breach involving ShipMonk, one of its third-party shipping and fulfillment providers. The incident exposed personal information associated with a subset of customers who ordered Trezor products through the company’s online store.

The incident is important for a reason that goes beyond the number of records involved. The compromised information includes names, email addresses, phone numbers and, for the majority of affected customers, physical shipping addresses. In the context of cryptocurrency hardware wallets, that combination of information creates a particularly useful dataset for targeted social engineering.

Trezor says its own systems were not compromised and that the hardware wallets themselves remain secure. There is currently no evidence in the company’s disclosure that attackers obtained wallet recovery seeds, private keys, cryptocurrency balances or access to Trezor devices.

The breach instead occurred at the fulfillment layer of the supply chain.

According to Trezor, ShipMonk notified the company on August 10 that an unauthorized party had gained access to systems containing customer data. The investigation is still ongoing, and Trezor has not publicly disclosed the initial access vector, exploited vulnerability, compromised account, malware, or other technical mechanism that allowed the unauthorized access.

That distinction matters. It is possible to explain the technical exposure and the security implications of the incident from the information currently available. It would not be accurate, however, to invent an attack chain that Trezor or ShipMonk have not confirmed.

What happened in the ShipMonk breach?

Trezor uses third-party fulfillment providers to store and ship physical products to customers. That means information entered during an online purchase does not necessarily remain inside Trezor’s own infrastructure.

A simplified version of the order flow looks like this:

Customer → Trezor eShop → fulfillment data transfer → ShipMonk → carrier → customer

Once an order is handed to a fulfillment provider, that provider needs enough information to identify the package and arrange delivery. Trezor says ShipMonk therefore held information including the customer’s name, email address, phone number, shipping address and order information.

On August 10, ShipMonk informed Trezor that an unauthorized party had accessed systems containing customer data.

Trezor subsequently determined that customer information associated with affected orders had been exposed. The company says 11,742 customers experienced full exposure, consisting of their name, email address, phone number and shipping address. A further 1,947 customers had partial exposure, consisting of their name, city and email address.

That puts the currently disclosed affected population at approximately 13,689 customers. Trezor says affected customers were contacted directly by email from help@trezor.io.

The affected countries identified by Trezor are the United States, United Kingdom, Sweden, Colombia, Brazil, Italy and Portugal. Trezor’s customer notification describes the relevant orders as those received within the 90 days before August 8, 2026, although the company has separately warned that the precise timeframe for the 1,947 partially exposed records is still being verified.

There is therefore one important qualification to the 90-day explanation: Trezor has said that the partial-exposure group may include older orders, and that it is still working with ShipMonk to establish the exact timeframe.

What information was exposed?

The distinction between the two exposure categories is significant.

For the 11,742 customers classified as having full exposure, Trezor says the compromised information includes:

• Full name
• Email address
• Phone number
• Shipping address

Trezor also says order information was held by ShipMonk as part of the fulfillment process. The company’s customer notification specifically refers to the order number as information that was exposed.

The 1,947 customers in the partial-exposure category were identified as having their name, city and email address exposed, rather than the complete shipping address.

There is no indication in Trezor’s current disclosure that the breach exposed cryptocurrency wallet recovery seeds, private keys, PINs, passphrases, Trezor Suite credentials or the cryptographic secrets stored on Trezor devices.

A shipping database is fundamentally different from a wallet-key database. ShipMonk needs information about where a physical package should go. It does not need a customer’s wallet seed to perform that function.

Trezor itself was not breached

Trezor has explicitly stated that its own systems were not compromised. This means the incident should not be described as a compromise of Trezor’s wallet infrastructure or as a direct compromise of Trezor hardware.

A typical ecommerce transaction involves several independent systems. The retailer processes the order, a fulfillment provider receives the information necessary to prepare the shipment, a carrier receives delivery information, and various operational systems may process tracking information.

Every additional organization that receives personal information creates another place where that information must be protected. In security terms, this is a third-party data exposure rather than a compromise of the cryptographic security model of the hardware wallet.

That does not make the breach insignificant. It changes the nature of the risk. The security of a hardware wallet can remain intact while the privacy surrounding ownership of that hardware wallet is damaged.

The technical attack path is not yet known

One of the easiest mistakes to make when reporting a breach is to fill gaps in an incident investigation with assumptions.

At the time of Trezor’s disclosure, the company has said only that ShipMonk experienced unauthorized access to systems containing customer information. The investigation is ongoing.

There is no confirmed public information establishing whether the attacker entered through a stolen employee credential, a compromised API credential, an application vulnerability, a cloud configuration problem, a third-party integration, malware, session theft or another mechanism.

Consequently, claims that this was caused by a specific vulnerability or a particular form of attack would currently be speculation. What can be established is the data path.

Trezor’s ecommerce environment had to provide ShipMonk with fulfillment information. ShipMonk then stored or processed that information in systems used to fulfill customer orders. An unauthorized party gained access to a ShipMonk environment containing that information. The attacker was consequently able to access customer records that had crossed the Trezor-to-fulfillment trust boundary.

From a security architecture perspective, the breach demonstrates why an organization’s attack surface does not end at its own domain, applications or cloud accounts. The data itself becomes part of the attack surface wherever it is replicated.

Why the 90-day retention policy mattered

One of the more significant details in Trezor’s disclosure is its data-retention policy. Trezor says it deletes or anonymizes customer data related to an ecommerce purchase after 90 days. The company says it also negotiated the same retention requirement with fulfillment partners.

The practical security benefit is straightforward.If a database contains ten years of customer records, compromising that database potentially exposes ten years of historical information. If the same system retains only the information necessary for current fulfillment, the amount of historical data available to an attacker is smaller.

This is the principle of data minimization applied to incident impact. It does not prevent an intrusion. It limits what an attacker can take when an intrusion occurs.

Trezor says the policy is intended to cover the operational lifetime of an order, including delivery, returns, refunds and replacements. After that period, the company says there is no operational reason to retain the customer’s shipping address or phone number.

The result in this case is that the disclosed exposure was substantially narrower than it could have been if old fulfillment records had remained indefinitely.

There is, however, an important caveat. Trezor is still verifying the history of the 1,947 partially exposed records, so the 90-day explanation should not be interpreted as a guarantee that every affected record originated inside exactly the same window.

Why this is particularly sensitive for hardware-wallet customers

A leaked email address by itself is a common consequence of a data breach. A leaked name and address combination is more useful to an attacker. A leaked name, address, phone number and email address associated with the purchase of a cryptocurrency hardware wallet can be considerably more useful for targeted social engineering.

The attacker does not need to break the cryptography protecting a Trezor device. Instead, the attacker can attempt to manipulate the person who owns it. Imagine an attacker already knows a customer’s name, phone number and delivery address. They may also know that the person ordered a physical product from Trezor. That information can be used to make subsequent communications appear legitimate.

An email can be designed to resemble a Trezor security notification. A phone call can reference a genuine delivery or purchase. A letter can contain real identifying information. A fraudulent website can be presented as a wallet-security portal.

The purpose of such an attack would not necessarily be to steal the leaked information again. It would be to use the leaked information as context for a second attack. This is the main security consequence Trezor is warning customers about.

The most dangerous phishing scenario is a fake wallet recovery request

A hardware wallet does not require Trezor to know a customer’s recovery seed.

That seed is the critical secret used to recover the wallet and control its assets. Anyone who obtains it may be able to recreate the wallet and move funds.

Consequently, a legitimate support representative should never need a customer to enter a recovery seed into a website or send it through email, messaging applications or a telephone call.

This is where the ShipMonk incident could become dangerous.

An attacker possessing a customer’s real name and shipping details can construct a much more convincing phishing message than an attacker starting with nothing but an email address.

For example, a criminal could claim that a customer’s Trezor device requires a security verification because of a supposed shipping or account problem. The message could direct the victim to a counterfeit website and request the recovery seed.

The technical sophistication required to steal the cryptocurrency in such a scenario is actually low. The attacker does not have to defeat the cryptographic protections of the hardware wallet. They only need to convince the owner to disclose the secret.

That is why Trezor’s warning to never enter a wallet backup on a website is the most important practical advice following the incident.

What customers should do now

Customers who received a notification from Trezor should treat their personal information as potentially available to attackers.

The most important step is to become suspicious of unsolicited messages that appear to be connected to Trezor, cryptocurrency exchanges, wallet security, shipping problems or account verification.

Do not use links supplied in unexpected messages to access Trezor services. Instead, navigate independently to the official Trezor website or use the normal Trezor Suite application.

Most importantly, never disclose a wallet recovery seed.

A recovery seed should not be entered into a website because someone sent a security alert. It should not be sent to Trezor support. It should not be photographed and uploaded for verification. It should not be provided to someone claiming to be a security investigator.

Customers should also be cautious about phone calls. A phone number appearing to belong to Trezor, a delivery company or another recognizable organization does not prove that the caller is legitimate.

The same applies to physical mail. Since shipping addresses were among the exposed information, attackers can potentially use postal communications as another social-engineering channel.

A useful rule is simple: the more specific a message is about your real order, the more carefully you should verify it rather than trusting it.

How affected customers can verify the notification

Trezor says affected customers have been contacted separately by email from help@trezor.io.

The company has also stated that customers who did not receive that notification are not affected according to its current assessment.

Customers should nevertheless avoid using the links inside an unexpected email to investigate the incident. If there is uncertainty, they should independently visit Trezor’s official website and contact the company’s support team through its normal support channels.

Trezor’s public blog is the appropriate place to follow subsequent updates as the investigation develops. Trezor security and incident updates

Orders from Amazon are a separate case

Trezor has also clarified that orders placed through its official Amazon stores were fulfilled by a different partner and are not part of this particular incident.

The currently disclosed incident concerns orders placed through the Trezor Shop and fulfilled by ShipMonk.

That distinction is useful because customers should not assume that every Trezor purchase, regardless of sales channel, was necessarily processed through the affected fulfillment provider.

What Trezor and ShipMonk still need to establish

The investigation is not finished. The most important unanswered technical questions concern the initial access and the scope of the compromise.

A complete post-incident investigation should establish how the unauthorized party obtained access, which ShipMonk systems and accounts were involved, how long unauthorized access existed, what authentication mechanisms were bypassed or abused, which datasets were accessed or exported, and whether the attacker obtained persistent access.

It should also establish whether the exposed information was merely viewed or actually exfiltrated, although from a defensive standpoint affected customers should assume the information may have been copied.

Other important questions include whether the incident was limited to Trezor-related records, whether other merchants using the same ShipMonk environment were affected, whether any API credentials or integration tokens were exposed, and whether the attacker was able to move laterally into other systems.

None of those questions should be answered with assumptions at this stage.

Trezor has said it is working directly with ShipMonk to establish exactly what happened and which information was accessed. ShipMonk has said it secured the affected systems and hardened its security following the incident, according to Trezor’s disclosure.

The technical details should become clearer as the investigation progresses.

The bigger security lesson

The Trezor incident is not a story about a hardware wallet being cryptographically broken. It is a story about what happens when sensitive customer information leaves the system that originally collected it.

For Trezor customers, the distinction is reassuring in one respect. There is no indication in the company’s current disclosure that wallet seeds, private keys or the cryptographic security of Trezor devices were compromised.

But the exposed personal information still matters. A name, email address, phone number and physical address can provide an attacker with enough context to build a convincing impersonation campaign. When the victim is known to have purchased a cryptocurrency hardware wallet, that social-engineering context becomes more valuable.

The incident also demonstrates why retention limits matter. Trezor’s 90-day deletion or anonymization policy did not stop the breach, but it reduced the amount of historical customer information available in the affected fulfillment environment. That is precisely what data minimization is supposed to accomplish: reduce the consequences when preventive controls fail.

For customers, the practical response is not to panic or replace a functioning hardware wallet simply because a shipping database was breached. The immediate priority is to protect the secret that actually controls the wallet and to assume that personalized phishing attempts may become more convincing.

For organizations, the lesson is broader. A third-party provider holding customer information is part of the effective security boundary, whether or not that provider operates under the company’s own domain.

In this case, the hardware wallet remained outside the compromise. The customer record did not.

That is the part of the incident that matters most.

Sources and reporting basis

This report is based primarily on Trezor’s August 2026 customer disclosure and subsequent clarification concerning the affected records, with ShipMonk’s published security documentation used for background on its security and compliance posture. Trezor’s current disclosure does not identify the initial intrusion technique, vulnerability or compromised account, so this article deliberately does not speculate about an attack vector. ShipMonk publicly states that its platform is SOC 2 Type II compliant and that its controls are independently assessed.