Business email compromise, usually shortened to BEC, has been the largest reported category of cybercrime loss tracked by the FBI's Internet Crime Complaint Center for years running, ahead of ransomware and ahead of credential theft. It's also one of the least technically sophisticated attacks in active use. There's often no malware, no zero-day, no cracked cipher. The entire attack lives in the gap between "this email looks legitimate" and "this email is legitimate," and that gap is wider than most encryption marketing wants to admit.
Two different attacks that look identical to the victim
BEC comes in two forms, and the distinction matters for defense. The first is account takeover: an attacker phishes credentials or steals a session token, logs into the real mailbox, and sends from it directly. Every authentication signal a recipient could check passes, because it genuinely is that account sending that mail. SPF passes. DKIM passes. DMARC alignment passes. The message is, by every protocol-level measure, authentic.
The second is domain impersonation: the attacker registers a lookalike domain (rn instead of m, a swapped TLD, an extra hyphen) and sends from there, often after quietly monitoring a real email thread for weeks to learn the tone, the vendor names, and the amounts already in flight. No account is compromised. The forgery is in the domain, not the mailbox.
Both produce the same result in an inbox: a message that reads as coming from someone the recipient already trusts, asking for something time-sensitive and financial.
Why DMARC enforcement helps with only one of the two
SPF, DKIM, and DMARC exist to answer one question: did this message actually originate from a server the domain owner authorized? When DMARC is enforced at p=reject, and not left at the far more common p=none monitoring mode, it closes the domain impersonation vector almost completely. A lookalike domain sending unauthenticated mail gets rejected outright, or at minimum flagged before it lands.
DKIM and DMARC prove which mail server sent a message and that its headers weren't altered in transit. They say nothing about who was sitting at the keyboard, or whose credentials that keyboard belonged to. Account takeover BEC passes every one of these checks, because the check was never designed to answer that question.
That's the ceiling on authentication-layer defenses. A message from a genuinely compromised mailbox is, cryptographically, indistinguishable from a message the legitimate owner typed. Some of the same weaknesses that make forwarded and mailing-list mail hard to authenticate cleanly, covered in our piece on DKIM replay, apply here too: the signature travels with the message regardless of who currently controls the account attached to it.
The four patterns that account for most losses
| Pattern | Mechanism | Typical ask |
|---|---|---|
| Executive fraud | Compromised or spoofed executive mailbox, often timed to travel or a known meeting | Urgent wire transfer, gift cards, secrecy requested |
| Vendor invoice redirect | Compromised vendor mailbox monitoring a real, ongoing invoice thread | "Our bank changed, use this account for the next payment" |
| Attorney impersonation | Spoofed or compromised law firm domain, timed around a real closing | Wire the closing or escrow funds to a new account |
| Payroll diversion | Compromised employee or HR mailbox | Change direct-deposit routing details before the next pay cycle |
Notice the common thread across all four: none of them require the attacker to break anything cryptographic. They require patience, plausible timing, and a payment process with no independent verification step.
What actually stops it
The controls that work aren't primarily cryptographic. They're process controls that assume any single email, however authentic it looks, can be wrong.
- Out-of-band verification for any payment-detail change. Call a phone number pulled from an existing record, never one supplied in the email itself, before honoring a new account number.
- Dual control on wire transfers above a threshold. No single approver, regardless of seniority or urgency framing, should be able to release funds alone.
- DMARC enforcement at
p=reject, with SPF and DKIM properly aligned. This closes the impersonation half of the problem outright and is table stakes even though it doesn't touch account takeover. - Message signing for finance-sensitive internal communication. A PGP or S/MIME signature tied to a specific private key gives a recipient something to check beyond "does this look right": did this message verify against the key I already have for this person.
- Training staff to recognize the pattern, not the sender. Urgency, secrecy, and a payment-detail change are the three-signal cluster that matters, independent of whose name is on the message.
That last point is the one most training programs get backwards. Teaching people to scrutinize sender names and domains helps with impersonation, but account takeover BEC comes from an address that is, in every visible respect, correct. The signal that actually generalizes across both attack types is the shape of the request itself.
The session-token wrinkle that makes MFA less of a backstop than it used to be
A common assumption is that multi-factor authentication closes the account-takeover half of this problem outright. It closes the credential-phishing version of it. It does much less against the adversary-in-the-middle phishing kits now common in BEC campaigns, which proxy a real login flow in real time and capture the session token issued after MFA succeeds, rather than trying to capture a reusable password. The victim completes a normal-looking login, MFA prompt included, and the attacker walks away with a live session cookie that bypasses the need to re-authenticate at all. We've covered the mechanics of this pattern in more depth in our piece on adversary-in-the-middle phishing, and it's worth understanding specifically in a BEC context: a stolen session token is functionally indistinguishable, to the mail server, from the account owner simply staying logged in.
This is part of why the process controls matter more than any single authentication upgrade. Phishing-resistant hardware keys (FIDO2/WebAuthn) close the adversary-in-the-middle gap in a way that OTP-based MFA doesn't, and they're worth adopting for exactly that reason. But a determined BEC operation only needs one compromised mailbox to run the executive-fraud or vendor-redirect pattern, and the defense that actually catches it is a human process that treats every payment-detail change as unverified until confirmed through a separate channel, regardless of how the request arrived or how authentic the account looked.
Where a signed, encrypted channel helps and where it doesn't
End-to-end encryption was never built to solve BEC, and it's worth being direct about that rather than implying otherwise. Encryption protects a message's contents from anyone who doesn't hold a key. It does nothing to verify who's sitting at the sender's keyboard, and a compromised account can send an encrypted message just as convincingly as a plaintext one.
What a PGP-signed message adds is narrower and more specific: cryptographic proof that a message was signed with a particular private key, which is a stronger claim than "this domain's DKIM record checked out." If that private key lives somewhere an attacker who merely phished a web login can't reach, a forged executive request stops verifying, even from a compromised mail account, unless the attacker also has the signing key. That's a real, if partial, improvement over authentication headers alone. It's not a replacement for callback verification and dual control on money movement, and no vendor, us included, should suggest otherwise.