.svg){kind=small}
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.
How to Assess your Microsoft 365 Tenant Before Making Security Changes
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.
Which Microsoft 365 Licensing do you Need to Harden your Tenant?
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.
Why Identity is the Most Targeted Attack Surface in Microsoft 365
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.
Build your MFA and Conditional Access Policy Stack
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:
- All users (baseline MFA requirement)
- Admin accounts (requiring phishing-resistant MFA specifically)
- Azure management and device enrollment actions
- Legacy authentication blocking
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.
Review and Upgrade your Authentication Methods
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 Passkeys: Device-bound or hardware key (YubiKey, Windows Hello for Business, Microsoft Authenticator in passkey mode)
- Microsoft Authenticator app (push notification with number matching enabled)
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.
What Email Authentication Settings does Microsoft 365 Require to Block Phishing?
Email is the primary attack vector for BEC. Before configuring any Defender for Office 365 policies, make sure your domain authentication is in order.
SPF, DKIM, and DMARC
These three protocols work as a layered stack, and all three need to be configured correctly:
- SPF tells receiving mail servers which sources are authorized to send on behalf of your domain
- DKIM adds a cryptographic signature to outbound mail that verifies it was not altered in transit
- DMARC ties SPF and DKIM together, tells receiving servers what to do when either check fails, and generates reports so you can see what is being sent as your domain
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.
Most organizations assume their email authentication is configured correctly. In reality, small misconfigurations in SPF, DKIM, or DMARC are one of the most common reasons spoofing attacks succeed.
Run a quick scan below to see how your domain is configured.
If your results show gaps or misalignment, it is worth validating how your email configurationis set up before it becomes an entry point for attacks
Defender for Office 365 Policies
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
- Anti-spoofing detection
- Safe Links for time-of-click URL scanning
- Safe Attachments for sandbox detonation of email attachments
- Mail tips that alert users when an email comes from an external or unrecognized address
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.
How to Control Enterprise Application Permission in your Microsoft 365 Tenant
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.
Why Dormant Microsoft 365 Accounts are a Direct Path for Threat Actors
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.
Understanding AiTM Token Theft and Why MFA Alone is Not Enough
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:
1. Require Phishing-Resistant MFA (FIDO2)
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.
2. Require a Known or Compliant Device
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.
How to Phase your Microsoft 365 Security Controls for Minimum Disruption
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:
Phase 1: Immediate, Lower disruption
- Run a tenant assessment
- Confirm licensing (Business Premium minimum)
- Enable and enforce MFA for all users via Conditional Access or Security Defaults
- Block legacy authentication
- Configure SPF, DKIM, and DMARC to quarantine or reject
- Enable Defender for Office 365 policies
- Restrict enterprise app consent to admins only
- Disable or delete dormant user accounts and stale devices
Phase 2: Planned rollout, higher disruption
- Migrate privileged accounts to FIDO2 passkeys
- Deploy Intune for device management
- Enforce compliant or managed device requirements via Conditional Access
- Implement Privileged Identity Management (PIM) for admin roles
- Expand FIDO2 to high-risk user groups (finance, executives)
Phase 3: Ongoing governance
- Review enterprise apps and OAuth permissions regularly
- Monitor DMARC reports and update SPF as sending sources change
- Audit Conditional Access policies for exclusion drift
- Review risky sign-in alerts from Entra ID Protection
What Stops Most BEC Attacks in Microsoft 365 is Already in your Tenant
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.
Explore the Full Series:
