The average BEC attack costs organizations over $125,000. Most of them succeed not because defenses were bypassed, but because the right controls were never turned on in the first place.
If your Microsoft 365 tenant has never been through a formal hardening review, there is a good chance it has gaps that threat actors can and do exploit. Business email compromise (BEC) is the top reported cybercrime by dollar loss. The majority of successful attacks do not rely on advanced techniques. They rely on misconfigured tenants, missing authentication policies, and accounts that were never properly maintained.
The controls that stop the majority of BEC attacks are not complicated. They are just consistently skipped. Below is a breakdown of what those controls are and how to prioritize them.
Jumping straight into configuration changes without understanding your current state is a common mistake. You need to know where the gaps are before you can prioritize what to fix.
A good assessment covers your Entra ID policies, email configurations, user accounts, device enrollment status, Conditional Access rules, enterprise applications, and Secure Score. The goal is a prioritized list of changes ranked by security impact and operational disruption. Not all security changes carry the same weight, and not all of them can be deployed simultaneously without disrupting end users.
Work from highest impact to lowest, and schedule anything disruptive separately.
Before getting into specific controls, licensing matter. If your tenant is on Microsoft 365 Business Basic or Business Standard, you are missing many of the tools required for meaningful hardening.
Business Premium is the recommended starting point for most organizations (under 300 users). It includes Microsoft Defender for Business, Defender for Office 365 Plan 1, Intune, and critically, Microsoft Entra ID P1, which is required for Conditional Access policies. Without Entra ID P1, you are limited to Security Defaults. Security Defaults offer some protection, but no policy granularity.
If Conditional Access is not available in your current SKU, Security Defaults are better than better nothing. Once you move to Business Premium, you should be building proper policies.
The corporate firewall used to be where the battles were fought. That is no longer true. Today, identity is the security boundary that matters. Verizon's 2025 Data Breach Investigations Report found that 82% of breaches involve the human element, with stolen credentials as a leading factor. Yet, many organizations still lack basic identity hygiene like enforced MFA across all users.
MFA blocks the vast majority of credential-based attacks. That said, a single blanket MFA policy is not enough. It is also not how a properly hardened tenant is built.
A well-structured Conditional Access deployment should include separate policies for:
Admins can accidentally exclude themselves from a policy during configuration. Microsoft's Conditional Access UI makes that easier to do than most people realize. Stacking policies ensures admins are covered from multiple angles regardless.
Block legacy authentication completely. Protocols like IMAP and POP do not support modern authentication, which means Conditional Access cannot enforce MFA against them. Any active legacy auth path is a gap a threat actor can exploit.
Many tenants are still relying on SMS or email codes as MFA methods. These are not secure enough. SMS is vulnerable to SIM swapping. Email codes can be intercepted. Both can be bypassed through social engineering.
Not all authentication methods carry the same weight. When it comes to BEC resistance, the order matters.
FIDO2 is the strongest option available today. The authentication process happens through a second channel between the physical device and the tenant, not through the browser session. That is what makes it phishing-resistant in a way that traditional MFA is not. Microsoft began rolling out passkey profile support in 2025, which allows group-based FIDO2 configuration rather than a single tenant-wide setting.
Start by rolling FIDO2 out to admin accounts, finance, and executives. These are the account threat actors prioritize.
Email is the primary attack vector for BEC. Before configuring any Defender for Office 365 policies, make sure your domain authentication is in order.
These three protocols work as a layered stack, and all three need to be configured correctly:
For Microsoft 365, your SPF record should include include:spf.protection.outlook.com.
DKIM is not enabled by default for custom domains. You must publish CNAME records and enable it manually in the Microsoft Defender portal. Without that step, DMARC can only pass via SPF alignment, which is fragile when mail is forwarded or sent through third-party services.
DMARC policy matters. A DMARC record set to p=none adds visibility but no enforcement. Your goal is p=quarantine or p=reject. When DMARC is not set to quarantine or reject, Microsoft's own filtering has more trouble catching spoofed email from your domain. That makes it easier for attackers to impersonate you to your own users.
Before locking DMARC down, use a reporting tool such as EasyDMARC to identify every service sending email as your domain. Your Microsoft 365 environment, marketing platform, CRM, invoicing tool, and any other sending service all need to pass SPF and DKIM alignment first.
Once your domain authentication is solid, configure the Defender for Office 365 policies available in Business Premium. These include:
Anti-phishing policies with impersonation protection for your domain and key users
These settings do not configure themselves. Many tenants have Defender for Office 365 available through their license and have never touched the policy settings. Default is not hardened.
Once a threat actor has access to a user account, one of the first things they do is register an OAuth application under that account. This gives them persistent access to the tenant that does not appear in Entra ID sign-in logs the same way, making the compromise significantly harder to detect.
By default, users can consent to third-party applications on their own. That needs to change. Configure your tenant to require admin approval before any OAuth application is granted access. This prevents threat actors from establishing persistence and creates a visible alert when something unexpected tries to connect. An unusual app consent request is often one of the first indicators of a compromise account.
Also review your existing enterprise applications. Any OAuth app with broad mailbox or directory permissions that cannot be attributed to a known, approved service should be investigated.
This step is frequently skipped, and it consistently shows up as a problem in tenant assessments.
Departed employees whose accounts were never properly off boarded, old service accounts, and test accounts set up years ago all exist in tenants in large numbers. They are not enrolled in MFA. They are not monitored. Because they are inactive, no one notices when they are targeted.
If a threat actor finds a dormant account and initiates a password reset, sometimes they can gain access. When prompted to set up MFA for the first time, they will be the one completing that enrollment. At that point, they have a fully authenticated sessions with no one watching.
The standard off boarding process for departed users is to convert the mailbox to a shared mailbox and block sign-in. Service accounts, test accounts, and long-inactive accounts should be disabled or deleted.
The same applies to devices. Entra ID tracks every device that has ever registered or joined the tenant. Decommissioned hardware, test devices, and machines that have not been active in years all accumulate in the directory and distort your reporting. Clean them up.
Standard MFA stops credential theft. It does not stop token theft.
Token theft attacks, often called adversary-in-the-middle (AiTM) attacks, work by sitting between the user and Microsoft's login page using a reverse proxy. The user completes the login process including MFA, and the attacker intercepts the session token that gets issued afterward. That token is what allows your browser or email client to stay authenticated without re-prompting for credentials. When an attacker replays a stolen token, they appear as a fully authenticated user who has already passed MFA.
These attacks have become significantly more common over the last 12 to 18 months, driven largely by phishing-as-a-service kits like Evilginx and EvilProxy that have lowered the barrier to execution.
There are two primary controls that address this:
The FIDO2 authentication flow does not happen in the browser session. It happens through a separate channel between the physical device and the tenant. That is what makes it resistant to AiTM attacks. The token that gets issues is bound to the authenticated device in a way that makes replay significantly harder.
FIDO2 remains the recommended step for admin accounts, finance teams, and any user group that is seeing persistent targeting.
The second layer is Conditional Access policies that require the authenticating device to be known, managed, or compliant. When a threat actor tries to replay a stolen token from their own machine, Microsoft checks whether that device is registered and compliant and blocks access if it is not.
Compliant device enforcement requires Intune deployment and device enrollment, which is why this is typically a second-phase project. The security payoff is significant. A compliant device check validates that the device has BitLocker enabled, is current on patches, has antivirus running, and meets whatever additional baselines you define.
Requiring both FIDO2 and a compliant device simultaneously is the most hardened configuration available for standard Microsoft 365 tenants. It is the right move for organizations facing persistent attacks or for high-value accounts like global admins and finance leads.
Hardening a Microsoft 365 tenant is not a single project. It is a sequenced effort. The controls above are not all the same level of effort or disruption. Here is a reasonable phasing:
Run a tenant assessment
Migrate privileged accounts to FIDO2 passkeys
Review enterprise apps and OAuth permissions regularly
Securing Microsoft 365 against business email compromise is not about deploying the most advanced tools available. It is about making sure the foundational controls are actually configured. Most successful BEC attacks exploit tenants where MFA is inconsistent, email authentication is incomplete, or user accounts were never properly maintained. Getting those basics right narrows the attack surface dramatically before anything more complex is needed.
Want to know where your tenant stands? The Sourcepass MCOE runs structured Microsoft 365 hardening assessments to identify your highest-priority gaps and build a remediation plan that fits your environment. Reach out to our team to learn more.