When a supplier gets compromised, the attackers rarely stay inside the supplier.
The pattern is consistent enough to plan for. Attackers break into a vendor, then impersonate that vendor and go after everyone who trusts it. EmailTooltester found fake Brevo login pages. Trezor users received a bogus security alert. In both cases the sequence was the same: compromise, impersonate, harvest credentials. I wrote about this on LinkedIn recently, and the response made it clear that agencies feel this most sharply.
Why agencies sit in the blast radius
An agency is a trust hub. Clients hand over platform access. You hold the sending domains, the ESP account, the CRM, the ad accounts. Your team shares logins because that is faster than provisioning per-seat access. Contractors come and go, sometimes without a clean offboarding step.
So when a vendor in that chain gets hit, the phishing email does not look random. It looks like a Brevo security notice. It looks like the tool your client actually uses. The target is not your firewall. The target is the account sitting behind it.
You may need to protect accounts you do not own
This is the uncomfortable part. Your security boundary is not your infrastructure. It is every account downstream from your vendors, including accounts that belong to clients, or to a freelancer who stopped working with you eight months ago, or to a platform your team half-uses because one campaign needed it.
Security responsibility does not always follow ownership. It follows exposure. If your work stops when that account is taken over, it is your problem regardless of whose name is on the billing.
Rotation and revocation are design decisions
Most teams treat credential rotation as something you do after an incident. That is the wrong time to discover that the platform does not support granular permissions, that three clients share the same admin login, or that nobody knows which email address the password reset goes to.
Better to treat revocation as a property of how you onboard. When you take on a new platform, note who can log in, how access is granted, and how quickly it can be pulled. When someone leaves a project, they leave the accounts too. Sounds obvious. It rarely happens without a process.
The questions worth asking
Four questions cover most of the gap. Who actually logs into this platform? Which clients or contractors have access right now, not at onboarding? Have those people been warned that this vendor is being impersonated? And can you rotate or revoke those credentials today, without a support ticket?
If the answer to the last one is no, you have a dependency you cannot control.
Search the dark room
There is an old story about a man looking for his lost key under a streetlamp. A crowd joins in. Someone asks where he lost it. "Inside the house," he says. "Then why are you searching out here?" "Because there is light here."
Breach response looks like this more often than anyone admits. We change passwords, check servers, review our own infrastructure, because that is the part we can see. Meanwhile the real exposure sits in a dark room nobody opened. The client's login. The shared credential. The API key nobody rotated. The account nobody remembered still had access.
The fix is not more tools. It is naming the accounts that exist outside your perimeter and treating them as yours to defend. Some of that work is unglamorous bookkeeping: an access inventory, an offboarding checklist, a rule that client logins live in a password manager with per-person entries instead of one shared note. On the technical side, authentication records for your own sending domains and basic inbox monitoring will catch some of the noise, but only for accounts and domains you can actually see.
Visibility first. Then the checklist. Then you can go back to finding the key in the house.