Your Defender Is On. So Why Is CEO Impersonation Still Working?

I have helped dozens of organizations secure their Microsoft 365 tenants.

And yet, one uncomfortable truth keeps showing up.

Executive impersonation attacks are still working. Even in tenants where Microsoft Defender is already enabled.

This is not a tooling problem. This is a configuration, licensing, and zero‑trust execution problem.

And the financial impact is very real.

Let’s ground this in facts, not fear.

Google and Facebook – Over $120M Lost
Finance teams received what looked like normal vendor invoices. The sender identity, domain, and language matched expectations.

Over time, more than $100M was wired out.

There was no malware. No exploited vulnerability. No breached servers.

Just trust abused at scale.

FACC AG – About €50M Lost
A single impersonated CEO email triggered fraudulent wire transfers tied to a “confidential acquisition.”

The request appeared legitimate. It referenced sensitive business context. It carried the authority of the CEO.

By the time the fraud was detected, tens of millions were gone. The incident ultimately resulted in the dismissal of senior leadership.

What they lacked was identity‑aware enforcement and least‑privilege trust.

The FBI continues to report business email compromise as one of the highest‑loss cybercrime categories globally, with annual losses consistently measured in the billions. Executive impersonation remains the most successful variant because it exploits authority, urgency, and implicit trust.

Here is what I see repeatedly during Microsoft 365 security assessments:

• Defender is licensed, but impersonation protection is not explicitly configured
• Anti‑phishing policies exist, but executives are not defined as high‑value targets
• Domain and user impersonation detection is enabled, but response is manual
• Security teams assume SPF, DKIM, and DMARC are enough - they are not

Impersonation emails often pass email authentication by design. That is exactly what makes them dangerous.

This is what aligning Defender with zero‑trust principles actually requires.

• Define protected users such as CEO, CFO, and board members
• Enable user and domain impersonation detection
• Apply strict actions like quarantine, not just tagging

This capability exists only in Microsoft Defender for Office 365 - not in basic Exchange protection.

• Automated investigation and remediation
• Alerts routed directly into SOC workflows
• Immediate quarantine and user notifications

This requires Defender for Office 365 Plan 2 or Microsoft 365 E5.

Without automation, response speed depends on human availability - and attackers know it.

Executives should not receive broader email trust just because they are executives.

• No implicit trust for “internal‑looking” emails
• Stronger enforcement for finance and authority‑based requests
• Regular review of impersonation insights in the Defender portal

Zero trust means authority does not equal exemption.

Let’s be very clear:

• Executive impersonation protection requires Microsoft Defender for Office 365
• Advanced automation and investigation require Plan 2 or E5
• E1, E3, F3, or Exchange‑only licensing is not sufficient for full protection

This is not an upsell. It is a design constraint.

Most executives believe impersonation attacks are an employee awareness problem.

They are not.

They are a trust boundary failure.

If your tenant allows an email that “looks right” to bypass enforcement simply because it references an executive, then zero trust is already broken.

And attackers know it.

If you want to know whether your Defender configuration would have stopped a real‑world CEO impersonation attack, the answer is usually uncomfortable.

I’m happy to help organizations validate that assumption before someone else does it for them.