Who is accountable for reducing BEC risk when attackers target Microsoft 365 users?

Accountability for BEC Risk in Microsoft 365

Business email compromise in Microsoft 365 is not owned by a single team because the exposure spans identity, messaging, endpoint, and financial workflows. Security may set the control baseline, identity may enforce authentication and session protections, and messaging or collaboration teams may tune mail controls. Business leadership still matters because the real harm is fraudulent payment, approval abuse, and operational disruption, not just suspicious email.

For that reason, accountability should be treated as shared but not vague. If no one owns the end-to-end risk, the usual failure is that each team assumes another group is covering the user, the mailbox, or the payment process. The question is not who "handles email" but who is responsible for reducing the business impact of account takeover and impersonation in a cloud productivity environment. In practice, many security teams encounter BEC accountability gaps only after a payment diversion or mailbox takeover has already exposed the split between technical control ownership and business risk ownership.

MITRE ATT&CK Enterprise Matrix is useful here because BEC often follows well-understood credential access, mailbox abuse, and phishing-adjacent techniques rather than a single isolated control failure.

How Microsoft 365 BEC Risk Gets Owned Across Teams

In practice, BEC accountability works best when teams own different layers of the same risk chain. Security owns prevention and detection standards, such as phishing-resistant authentication targets, alerting, and incident triage. Identity owns the account security posture, including strong authentication, conditional access decisions, legacy authentication removal, and privileged access boundaries. Messaging or collaboration owners manage mail flow protections, impersonation controls, external sender handling, and tenant configuration.

That separation matters because Microsoft 365 BEC rarely begins with a single broken setting. Attackers usually rely on a combination of weak authentication, over-trusted inbox rules, risky forwarding, weak approval processes, and users who can be manipulated into changing payment instructions. If the environment allows attackers to authenticate, read mail, hide activity, or act as a trusted internal sender, the risk becomes a business process issue as much as a technical one.

Accountability also extends beyond IT. Finance and operations leaders should own the business controls that prevent fraudulent payment or vendor-bank detail changes from being approved on email alone. That means documented approval paths, out-of-band verification, and clear escalation rules for suspicious requests. When leadership treats BEC as "an email security problem," the control gap usually appears where mail security ends and money movement begins.

• Security sets the minimum control baseline and response thresholds.
• Identity hardens user and admin access conditions.
• Messaging teams reduce impersonation and mailbox abuse paths.
• Business owners control payment verification and exception handling.

Microsoft 365 BEC ownership becomes weakest when control decisions are fragmented across tenants, business units, or outsourced help desks, because attackers need only one weak approval or recovery path to turn a mailbox compromise into fraud.

Where BEC Ownership Breaks Down and What Changes at Scale

Tighter email and identity controls often increase operational friction, so organisations must balance fraud reduction against support burden and user pushback. That trade-off becomes more visible at scale, where exceptions, shared mailboxes, service accounts, and delegated access can create hidden trust paths that normal user controls do not cover.

One common edge case is responsibility for shared mailboxes, executive assistants, and delegated approvals. These accounts often sit between technical ownership and business authority, which makes them easy to under-govern. Another is third-party or partner-driven payment workflows, where a compromised external mailbox can still trigger internal action if staff rely on email content alone. In those cases, the accountable owner is usually the business process owner, with security and identity providing guardrails rather than sole control.

There is also a governance distinction between reducing exposure and absorbing residual risk. Teams can harden accounts, monitor logins, and block suspicious mail patterns, but they cannot fully remove the human trust problem that BEC exploits. The practical answer is therefore shared accountability with explicit executive sponsorship, because the decision to tolerate some residual fraud risk is a business decision, not a mail-filter tuning choice. The answer breaks down when organisations expect one control owner to absorb all technical and financial consequences of a cross-functional fraud path.

Risk and Threat Considerations

Microsoft 365 BEC is material because it combines identity compromise, trust abuse, and financial manipulation. The attacker does not need broad access if they can authenticate as a user, redirect messages, or impersonate an internal sender long enough to influence a payment or approval decision.

Failure mechanism: The risk materialises when weak authentication, mailbox abuse, forwarding rules, or approval shortcuts let an attacker intercept or mimic trusted business communication and then exploit that trust to change payment instructions or obtain sensitive data.

Impact: The likely consequence is fraudulent transfer, invoice diversion, compromised internal correspondence, or wider account takeover exposure if the mailbox becomes a pivot point for further access.

Practitioner Guidance

What to prioritise: Treat BEC accountability as a business-risk ownership problem, not a helpdesk or mail-filter issue. The named owner should be able to answer who approves controls, who investigates suspicious activity, and who accepts residual fraud risk when controls do not fully stop a phishing or impersonation attempt.

What to verify: Confirm that the organisation has one accountable business owner for payment-risk decisions, plus clear technical owners for identity and messaging controls. If those roles cannot name their boundaries and escalation points, the control model is probably relying on informal coordination rather than durable governance.

What good looks like: Security can detect and contain suspicious mailbox activity, identity can reduce account takeover likelihood, and finance or operations can independently verify high-risk requests outside email. The strongest signal is not perfect prevention but a process that still resists fraud after an attacker reaches a user inbox.

Practitioner takeaway: BEC in Microsoft 365 is best reduced when technical teams own controls and business leaders own the fraud consequence, because the weakest point is usually not the mailbox itself but the approval path that trusts it.

Related resources from NHI Mgmt Group

• Why do campaigns that use Cloudflare turnstiles and rotating malicious domains create more risk for Microsoft 365 users?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?