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

Accountability usually sits across security, identity, and messaging teams, with business leaders sharing responsibility for user risk. Security teams must enforce controls and monitoring, identity teams must harden authentication and access, and operations teams must support response workflows. Executive ownership matters because BEC is a business disruption and financial fraud risk, not just an email problem.

Why This Matters for Security Teams

Business email compromise is not just a mail-flow problem. When attackers target Microsoft 365 users, they usually exploit identity, session trust, and business process gaps at the same time. Security teams may own the technical controls, but identity, messaging, finance, and operations all influence whether a phish becomes a payment fraud event. The practical issue is accountability: someone must own detection, containment, and user-risk reduction end to end.

NHI Management Group’s research on the Microsoft Midnight Blizzard breach shows how identity compromise can cascade into broader enterprise exposure, even when the initial entry point is not a classic malware event. That is why current guidance aligns BEC defense with identity hardening, conditional access, message authentication, and response playbooks, not with awareness training alone. The control question is broader than email security and narrower than general cyber risk management.

Practitioners should also pay attention to the speed of attacker action once credentials are exposed, as shown in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where exposed credentials were targeted within minutes. In practice, many security teams encounter BEC only after a payment request has already been approved, rather than through intentional detection of identity abuse.

How It Works in Practice

Accountability for reducing BEC risk should be split by function, but not diffused by ambiguity. Security operations owns detection, alert triage, and incident response. Identity teams own MFA strength, token protection, conditional access, and risky sign-in controls. Messaging or email operations own mail authentication, tenant hardening, and anti-phishing policy tuning. Business leadership owns process enforcement for payment approvals, vendor changes, and user-risk acceptance.

The operational model should connect those owners through measurable controls. For Microsoft 365, that usually means blocking legacy authentication, enforcing phishing-resistant MFA where feasible, monitoring impossible travel and token anomalies, hardening mailbox forwarding rules, and validating sender domains through SPF, DKIM, and DMARC. NIST’s Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both support this kind of shared-control design, because identity assurance, logging, and response are all required for effective risk reduction.

For teams building a more mature program, the question is not whether users can be fooled, but how quickly suspicious messages and sign-ins are correlated before money moves. That makes escalation paths as important as prevention. Use playbooks that require finance verification for payment change requests, and route suspicious account activity to identity and SOC teams together. The practical lesson in NHIMG’s 52 NHI Breaches Analysis is that weak credential governance tends to create incident chains, not isolated events. These controls tend to break down when mailbox rules, delegated access, and business approval workflows are managed in separate teams because no one owns the full fraud path.

Common Variations and Edge Cases

Tighter control often increases friction for legitimate business email and payment workflows, requiring organisations to balance fraud reduction against speed, usability, and executive exceptions. That tradeoff is real, especially in environments with heavy external correspondence, M&A activity, or distributed finance operations.

There is no universal standard for BEC ownership in every organisation, but current guidance suggests the most effective model is a shared accountability structure with one executive sponsor. In smaller environments, IT may temporarily own more of the control stack. In larger enterprises, responsibility often spans SOC, IAM, messaging, finance, and legal. The key is that one function must be explicitly accountable for the program outcome, not just the controls.

Edge cases matter. Highly delegated mailboxes, shared mailboxes, and executive assistants create higher approval risk because attackers can exploit trusted relationships instead of brute-forcing authentication. Similarly, tenant-to-tenant collaboration, third-party forwarding, and OAuth consent abuse can bypass simple phishing controls. The CISA cyber threat advisories and the MITRE ATT&CK Enterprise Matrix both reinforce that BEC is often a multi-step identity and social-engineering attack, not a single malicious email. For that reason, accountability should include business process owners, because security controls alone cannot stop a fraudulent transfer that has already been approved.

Related resources from NHI Mgmt Group

• Who is accountable for reducing product security risk in identity and governance platforms?
• Who is accountable when Microsoft 365 access reviews are not completed on time or evidence is missing?
• Who is accountable for reducing exposure risk between security assessments?
• Who should be accountable for cybersecurity policy review and vendor risk oversight?