How should organisations protect Microsoft 365 users against business email compromise across the full attack chain?

Stopping BEC at Multiple Failure Points in Microsoft 365

business email compromise is rarely a single-control problem. In Microsoft 365, the attacker path often combines credential theft, mailbox access, message rule abuse, impersonation, and payment or data-exfiltration fraud. That means the practical question is not whether email filtering works, but whether the organisation can prevent takeover, detect abuse quickly, and keep one compromised mailbox from becoming a broader fraud event. MITRE ATT&CK Enterprise Matrix is useful here because BEC usually maps to a chain of account access, persistence, and social engineering behaviours rather than a single exploit.

Security teams also need to remember that BEC often succeeds without malware, which makes gateway-only thinking ineffective. In practice, many organisations discover the problem only after an attacker has already created forwarding rules, impersonated a supplier, or used a trusted mailbox to steer a payment workflow.

How Microsoft 365 Controls Disrupt the Attack Chain

The most effective defence is layered around the points where BEC campaigns commonly progress. First, reduce initial access risk with strong authentication, conditional access, and phishing-resistant sign-in for privileged and high-value users. Second, harden mailbox and message controls so the attacker cannot quietly persist after login. Third, improve detection across identity, email, and endpoint telemetry so suspicious behaviour is visible before a fraudulent request is actioned. Fourth, make response fast enough to contain a compromised user before the attacker can pivot into finance, HR, or executive impersonation.

In Microsoft 365, that usually means combining native protections rather than relying on one product to do everything. Mail flow rules, anti-phishing policies, impersonation protection, mailbox auditing, suspicious inbox-rule alerts, session revocation, and sign-in risk monitoring each address a different stage of the chain. Identity protection matters because many BEC cases start with stolen credentials, token abuse, or consent abuse, then move to mailbox persistence and targeted social engineering. Endpoint telemetry matters because users often receive the lure, click the link, or approve the session from a managed device that can reveal the event sequence. Where the organisation has higher fraud exposure, payment verification and out-of-band approval processes should be treated as control dependencies, not optional process hygiene.

A useful operating rule is to assume that one control failure will not stay isolated. If an attacker can read mail but not send, they may still harvest context for later impersonation. If they can send but not persist, they may still win with a short-lived urgent request. If they can persist in a mailbox, they can often exploit trust already established with suppliers or executives. This is why coordinated detection and containment matters as much as prevention. The guidance breaks down when organisations treat BEC as a mailbox-only problem and ignore identity, finance workflow, and user-verification controls.

Where BEC Defences Usually Fail in Practice

Tighter mailbox control often increases administrative overhead, requiring organisations to balance user convenience against the risk of high-trust account abuse.

One common edge case is delegated access or shared mailboxes. These can be legitimate, but they also create ambiguity about who actually authored or approved a message. Another is executive protection: impersonation rules may catch obvious lookalike addresses, yet a compromised real account can be harder to distinguish from normal business activity. A third is hybrid identity or legacy authentication. Where older protocols remain enabled, attackers can bypass the strongest mailbox hygiene by using the weakest sign-in path. Industry guidance agrees that legacy authentication and broad mailbox delegation are recurring weaknesses, but there is less consensus on how much user friction is acceptable for high-risk personas.

Organisations should also distinguish between low-confidence alerts and evidence of active compromise. A suspicious external sender warning is not the same as a mailbox rule that silently forwards messages outside the tenant. The latter is a stronger sign of persistence and should trigger containment, not just user awareness messaging. When finance fraud is the likely downstream harm, the right decision is often to prioritise transaction verification over further email tuning. If the question is whether a control should be automated, the answer is usually yes for detection and containment, but no for high-value payment approval decisions.

Practitioner Guidance

What to prioritise: Protect the users whose mailbox access has the highest fraud value first. Executives, finance approvers, payroll staff, legal teams, and IT admins usually justify stricter sign-in, message, and session controls than general users because their compromise creates disproportionate downstream trust.

What to verify: Confirm that the organisation can see the full compromise path, not just the phish. That means validating sign-in logs, mailbox audit events, inbox-rule changes, forwarding configuration, and message tracing together so investigators can distinguish a noisy alert from a real takeover.

Decision rule: Treat any mailbox rule, forwarding change, or suspicious login on a high-risk account as a containment event when it aligns with urgency, payment diversion, or supplier impersonation. In those cases, response should move faster than user awareness or awareness training can help.

Practitioner takeaway: BEC defence works best when teams design for trust abuse across identity, mailbox, and business process layers, because stopping the email is not enough if the attacker can still shape the decision.

Related resources from NHI Mgmt Group

• How should organisations defend against business email compromise when attackers use real conversations?
• How can organisations govern DLP when users work across Microsoft 365 and AI tools?
• Why do organisations need more than email recall to protect sensitive information in Microsoft 365?
• How should organisations reduce Microsoft 365 license waste without disrupting users?