How to Stop Vendor Impersonation Email Fraud

A finance clerk opens her inbox on a Tuesday morning. There’s an email from a vendor she’s been paying for three years. Same signature block, same friendly tone, same request format she’s seen a hundred times. New banking details attached, effective next invoice. She updates the record, files the email, and moves on.

Nothing looks wrong. That’s exactly the problem.

If you’re trying to work out how to stop vendor impersonation email fraud in your business, the uncomfortable starting point is this: the email your clerk received didn’t need to be clever. It needed to be expected. And the defenses most companies rely on, filters and MFA and awareness training, are all pointed at cleverness.

Why vendor impersonation exploits trust, not technology

Microsoft’s own security team puts it plainly: roughly 90% of phishing attacks involve social engineering rather than a technical exploit. The attacker isn’t beating your mail server. They’re beating the assumption underneath it.

Vendor impersonation is the cleanest example I know. The attacker doesn’t have to earn trust, because you already extended it, three years ago, when you onboarded that vendor. Every invoice since then has reinforced the pattern. When a message arrives that matches the pattern, it slides through the human filter for the same reason it slides through the technical one: it looks like the thing you were expecting.

Here’s the thing… the email doesn’t have to be sophisticated. It has to be routine. Routine is the disguise.

Why the usual defenses keep missing it

I get asked a lot why “we have MFA and a good spam filter” isn’t enough. It’s a fair question, and the honest answer is that each of those tools is doing a real job, just not this one.

Spam filters look for badness in the message. A vendor impersonation email often has none. No sketchy links, no malware, sometimes not even a spoofed sender, because the attacker is sending from a real mailbox they’ve taken over.

MFA is supposed to keep that from happening. It mostly does. But phishing-as-a-service kits are eroding the margin: one recent kit bypassed MFA at 258 organizations and harvested more than 5,000 Microsoft 365 credentials through adversary-in-the-middle token theft. That means the fraudulent email can literally come from the vendor’s actual account. No spoofing, no lookalike domain, no header oddity to flag. It’s them, except it isn’t.

And it’s not just vendors. Attackers are calling help desks and impersonating executives to steal tokens and reset MFA, targeting exactly the people who approve payments.

Awareness training is the last line, and it assumes the user will feel suspicion. Vendor impersonation is engineered to feel routine. You can’t train someone to be suspicious of the ordinary without breaking the workflow entirely.

I say this as someone who ran into it directly. I was brought into a roughly 20-person homebuilder after an ACH fraud had already succeeded, and while I was still getting my bearings, a lookalike domain contributed to an attempted six-figure transfer. The users weren’t careless. The environment had been quietly compromised, the attackers understood the payment rhythm, and the emails looked like the emails those employees saw every week. Filters weren’t going to catch that. Training wasn’t going to catch that. The only thing that broke the chain was changing how money moved.

How to stop vendor impersonation email fraud with workflow controls

So the real question shifts. Not “how do we detect the fake email,” but “what would have to be true for a fake email to still fail?” That’s a workflow question, not a technology question.

A few things I’ve found consistently hold up:

Treat banking-detail changes as an out-of-band process. Never validated by replying to the email. If the request came in over email, the confirmation has to happen somewhere else. If the attacker owns the inbox, replying just confirms the fraud with the attacker.

Callback verification, using a phone number from your vendor record, not the one in the email signature. This sounds obvious until you watch how often the “urgent” framing pushes people to grab the closest number.

Dual approval for wire transfers and for any change to payment instructions. Two humans, not one human plus a rubber stamp.

A documented vendor-change workflow that treats urgency as a yellow flag rather than a shortcut. Every real BEC email I’ve seen has a reason you need to move fast. Real vendors, in my experience, are usually fine waiting a day.

And this one gets underrated: give finance staff explicit permission to pause a payment without justifying the pause. If your clerk has to build a case before she’s allowed to be cautious, she won’t be cautious. She’ll be efficient, which is what she’s rewarded for.

Building approval chains that assume compromise

The mental shift that changes everything is designing your approval chain as if one of the channels is already compromised. Because sometimes it is, and you won’t know until after.

That means separating the person who requests a change from the person who confirms it. Different humans, different logins, different awareness of the request.

It means the confirmation travels over a different medium than the request. Email in, phone out. Portal in, email out. Anything but the same channel closing on itself.

It means logging vendor-detail changes as their own category of risk and reviewing them periodically, the same way you’d review admin role grants. This is one of the behaviors I ended up baking into the monitoring I built after that homebuilder engagement, because I kept running into the same pattern: nobody was watching the small changes that preceded the big transfers.

And it means designing so that no single compromised inbox, theirs or yours, is enough to move money. If a working attack requires two independent things to fail, you’ve bought yourself the margin that training and filters can’t.

The question underneath

Here’s what I keep coming back to. The instinct in most organizations is to ask, “can our people spot a fake?” It’s the wrong question, because eventually someone won’t, and the fake is engineered specifically to be unspottable.

The better question is quieter and a little harder to sit with: does our process still work when everyone involved genuinely believes the email is real?

If the answer is no, no amount of training closes the gap. If the answer is yes, most of the sophisticated attacks stop being sophisticated. They just become emails that didn’t go anywhere.

I’m still working out where the edges of that principle are, but I’ve yet to find a vendor impersonation case where it wasn’t the thing that would have changed the outcome.