What breaks when business email compromise is not controlled at the identity layer?

Why This Matters for Security Teams

business email compromise becomes much more damaging when identity is not treated as the control plane. A secure inbox does not guarantee a trustworthy sender, because attackers frequently abuse valid accounts, session theft, forwarding rules, and social engineering to make fraudulent requests look routine. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that authentication, authorization, and monitoring need to work together, not separately. For BEC, that means identity proof, transaction approval, and workflow validation must all be independently enforced.

The practical risk is not limited to lost funds. BEC often becomes a doorway to payroll diversion, vendor fraud, invoice redirection, data exfiltration, and later-stage account takeover. Once an attacker can act through a legitimate identity, many email security tools lose their value because the message itself is no longer the main signal. Identity controls also matter when attackers use AI-assisted lures, because the quality of the language no longer reveals the fraud as reliably as it once did. Current threat reporting, including Anthropic — first AI-orchestrated cyber espionage campaign report, reinforces how adversaries can scale believable interaction while relying on stolen or abused identity. In practice, many security teams encounter BEC only after finance has already approved a payment that looked legitimate in the inbox.

How It Works in Practice

Controlling BEC at the identity layer means verifying who is acting, not just what the email says. That usually starts with stronger authentication, conditional access, and continuous session risk checks, but it cannot stop there. Organisations need workflow controls that force independent validation for high-risk actions such as payment changes, bank detail updates, password resets, supplier onboarding, and payroll modifications. These checks should use a different channel or a separate approver path, because the compromised mailbox is part of the attack surface.

In mature environments, identity-layer BEC controls include:

• Phishing-resistant multifactor authentication for privileged and finance users.
• Mailbox rule monitoring for forwarding, delegation, and suspicious OAuth consent.
• Step-up verification for risky requests based on user, device, location, and transaction value.
• Separation of duties so the requester cannot also complete approval.
• Logging and alerting across IAM, email, and finance systems for rapid correlation.

This is where identity governance meets operational resilience. If a request reaches finance through a compromised account, the organisation still needs a way to challenge the request without using the same channel that may already be compromised. Security teams should also map this to account recovery and privileged access processes, because attackers often pivot from a spoofed vendor thread into administrative changes once trust is established. The most reliable guidance is to verify identity and intent out of band, then bind the approval to a specific transaction record rather than to a mailbox conversation. These controls tend to break down in highly outsourced finance environments because approvals are fragmented across shared mailboxes, ERP systems, and unmanaged mobile devices.

Common Variations and Edge Cases

Tighter approval control often increases operational friction, requiring organisations to balance fraud resistance against speed and user convenience. That tradeoff is real, especially in procurement, AP, and executive support workflows where delay itself can cause business pressure. Best practice is evolving, but there is no universal standard for how much friction is acceptable; the right threshold depends on transaction value, authority level, and historical risk.

Edge cases matter. A finance leader using a legitimate account from a new device may trigger the same alerts as an attacker, so teams need risk-based verification rather than rigid blocking. Shared mailboxes, third-party processors, and delegated assistants also complicate attribution, because the inbox holder is not always the effective decision-maker. For organisations handling regulated data or high-value payments, identity checks should align with broader control expectations in NIST controls and internal segregation-of-duties policies. The key is to avoid treating email as proof of authority. Where identity assurance is weak, even a perfect message can still be a fraudulent instruction.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted cloud identity is used for business email compromise?
• Who is accountable when compromised cloud identity is used for business email compromise?
• How should universities reduce business email compromise risk across mixed identity populations?
• How should healthcare teams respond when business email compromise affects identity workflows?