Summary
- Brevo suffered an incident affecting customer accounts, including Trezor's marketing environment.
- An unauthorised actor used the service to send messages from affected customer accounts.
- The incident is separate from Trezor's recent ShipMonk breach and exposes a different third-party dependency.
Hardware-wallet maker Trezor has disclosed a second unrelated supplier security incident, after an attacker abused access at email provider Brevo to send messages through customer accounts including Trezor’s.
Trezor said Brevo informed customers of an incident on 9 September affecting 120 accounts. An unauthorised actor was able to use the provider’s environment to send emails from some customer accounts. Trezor said its own systems and hardware-wallet products were not compromised.
The event follows a separate breach involving logistics provider ShipMonk, which exposed customer order information and ultimately affected more than 80,000 Trezor customers after older retained records were discovered. Cyber Insider previously reported that the ShipMonk incident expanded because data that should have been deleted remained in the supplier’s systems.
The Brevo incident is materially different. Rather than exposing fulfilment records, it affected a communications provider trusted to send legitimate messages in Trezor’s name. That creates a particularly awkward risk for a company whose customers are routinely targeted with phishing intended to steal cryptocurrency wallet recovery information.
Trusted messaging infrastructure is attractive because successful abuse can bypass one of the cues recipients use to identify scams. A malicious message arriving through an organisation’s normal email service may carry the expected sender details and infrastructure even though the content was not authorised by the organisation itself.
For crypto-related businesses, the consequences can be amplified. Attackers do not need to compromise the underlying wallet hardware if they can persuade customers to disclose recovery phrases, credentials, or other sensitive information through social engineering. A supplier breach can therefore create a route to customer loss without touching the product’s security architecture.
The two Trezor incidents also demonstrate how third-party risk fragments across different business functions. Logistics companies hold names, addresses, telephone numbers, and order histories because they need them to ship products. Marketing providers hold contact lists and sending privileges because they need them to communicate with customers. Neither dependency is part of the hardware wallet itself, yet both can create security exposure around the customer relationship.
That distinction is increasingly relevant under European regulatory regimes that expect organisations to understand important suppliers rather than treat outsourcing as a transfer of responsibility. NIS2, DORA, privacy law, and sector-specific requirements approach third-party risk differently, but each reflects the broader principle that external service providers can become part of an organisation’s operational and security perimeter.
Supplier reviews also face practical limits. Organisations can assess contracts, controls, retention policies, and certifications, but they rarely have complete visibility into a provider’s day-to-day security. That makes incident response and the containment of downstream impact as important as pre-contract assurance.
Trezor’s experience is particularly illustrative because the two incidents occurred close together while involving different suppliers, different data, and different attack paths. There is no evidence that the events are connected.
The common factor is dependency: customer trust and operations extend through external platforms that can expose the organisation even when its own core systems remain intact. Trezor can accurately say that its wallet technology was not compromised, while still facing a security problem created through the services surrounding that technology.
