BleepingComputer reported on September 11, 2026 that Trezor customers were targeted by phishing emails after a security incident at Brevo, the third-party marketing platform Trezor used for newsletter campaigns. Trezor said the campaign reached roughly 347,000 newsletter email addresses, about 2,500 recipients clicked the link before it was disabled, and no Trezor wallet, product, or account system was touched.
That last detail matters. The practical lesson is not only about crypto wallets. It is about trusted sender infrastructure. Many businesses allow outside platforms to send newsletters, invoices, appointment reminders, password notices, support updates, or customer alerts from a company domain. If that provider is breached or an account boundary fails, the email may look legitimate because it travels through systems customers already trust.
The risk lives in delegated trust
Brevo's own incident write-up said an attacker exploited a flaw involving SAML single sign-on scoping, gained access to 138 client accounts, used 6 accounts to send phishing emails, and exported contacts from 43 accounts. Brevo said the route was closed, sessions were reset, and a permanent fix was being deployed to limit SSO access to the organization that owns the SSO configuration.
For business owners, the important question is simple: who else can send email as your company, and what would happen if that access were misused?
An email marketing platform, ticketing system, payment tool, scheduling app, CRM, or customer-notification service may all have some form of sender authority. That authority is useful, but it should not be invisible. It needs ownership, limits, monitoring, and a fast shutoff path.
What owners should ask the provider
- Which platforms can send email from our domain? Ask for an inventory of marketing, billing, support, scheduling, and alerting tools with sender permissions.
- What contact data does each platform store? Email-only lists are different from lists that include names, phone numbers, addresses, account details, or service history.
- How is administrator access scoped? SSO, shared admin roles, delegated access, and reseller portals should be limited to the correct organization and reviewed regularly.
- Who can disable sending in an emergency? A business should know whether its IT provider, internal admin, or vendor support team can quickly suspend campaigns, revoke keys, or remove DNS records.
- How would customers be warned? If a trusted sender is abused, customer communication cannot wait for a committee meeting and a perfect press release.
Do not stop at SPF, DKIM, and DMARC
Email authentication is still important, but this type of incident shows its limits. Brevo noted that phishing messages sent through legitimate infrastructure could pass usual authentication checks. SPF, DKIM, and DMARC help prove that a message came through an authorized path. They do not prove that the authorized path was used for a legitimate purpose.
That means businesses need both technical controls and operational controls. The technical side includes sender records, access reviews, MFA, least-privilege admin roles, logging, and account separation. The operational side includes vendor due diligence, incident contacts, customer-warning templates, and a decision about which customer lists belong in which systems.
A practical next step
Use this story as a reason to review delegated email access before there is a live incident. Ask your IT provider or internal team for a plain-language map of every service that can send as your company, the data each service holds, who administers it, and how quickly it can be disabled.
The goal is not to avoid every SaaS email tool. Most businesses need them. The goal is to make sure trusted email is treated like a business system with real authority, not just another marketing checkbox. Once a platform can speak in your company's name, it deserves a seat in the vendor risk review.
Sources and further reading
