Who is accountable when a BEC attack succeeds through a trusted mailbox?

Accountability sits across email security, identity governance, and the business process that approved the action. If the organisation allowed a payment or account change to proceed without secondary verification, the failure is not only technical. Teams need a defined owner for mailbox compromise response, workflow verification, and fraud escalation before the attack reaches completion.

Why This Matters for Security Teams

A trusted mailbox is often treated as a business control, not just a technical asset, which is why BEC succeeds when email compromise blends into normal approval chains. The real risk is not only message delivery, but the moment a finance, HR, or vendor workflow accepts a request as legitimate because it arrived from the “right” account. NHI Management Group’s 52 NHI Breaches Analysis shows how compromised identities can outlive perimeter assumptions, and CISA cyber threat advisories repeatedly stress that trusted channels are a common abuse point.

That matters because accountability cannot stop at the email team. Identity governance owns the conditions that let the mailbox be trusted, while the business owner owns the process that allowed a high-risk action to clear without challenge. If the approval path has no secondary verification, the attack outcome is shared, even if the initial compromise began in email. In practice, many security teams encounter the failure only after a payment is sent or an account is changed, rather than through intentional control testing.

How Accountability Should Be Assigned in Practice

The cleanest operating model separates compromise detection, workflow approval, and fraud response. Email security or SOC functions own mailbox investigation and containment. Identity teams own the trust model around the mailbox, including MFA strength, session revocation, conditional access, and privileged mailbox access. The business process owner owns the approval step that let the request proceed. This is where many organisations rely on implied trust instead of explicit verification.

For example, a vendor bank-detail change should not be approved solely because it came from an authenticated mailbox. The mailbox is an identity signal, but not proof of intent. Current guidance suggests pairing mailbox trust with transaction-specific verification, especially for payment, payroll, and legal changes. That can include out-of-band callbacks, dual approval, immutable audit logging, and short review windows for risky actions. If the environment uses shared mailboxes or delegated access, accountability should be even more explicit because access trails can become blurred.

• Email security confirms whether the mailbox was compromised and when the abuse started.
• Identity governance confirms whether the account should have been able to take the action at all.
• Business owners confirm whether the approval path required secondary verification.
• Fraud or finance controls decide whether the transaction can be reversed or blocked.

This aligns with the broader NHI lesson in Ultimate Guide to NHIs — Key Challenges and Risks: once an identity is trusted, downstream systems often inherit that trust automatically. Security teams should not wait for mailbox compromise alone; they should test the business process as the attacker would, using trusted identity to trigger a high-value action. These controls tend to break down when delegated mailbox access and manual approvals coexist in fast-moving finance operations because audit evidence is split across teams.

Where the Standard Answer Breaks Down

Tighter approval control often increases operational friction, requiring organisations to balance fraud resistance against business speed. That tradeoff is real in environments such as treasury, procurement, executive support, and customer service, where legitimate changes are time-sensitive and staff may resist extra verification.

There is no universal standard for exactly who “owns” a trusted-mailbox BEC failure, but best practice is evolving toward shared accountability with named control owners. If the mailbox is controlled by an enterprise platform team but the workflow lives in a business unit, both sides need documented response duties. One practical exception is external BPO or managed service environments, where responsibility should be contractually assigned and tested because internal escalation paths may not exist.

Security leaders should also treat mailbox trust as only one signal. A compromised account can still pass authentication while attacker behavior looks normal enough to bypass naive alerts. The Anthropic report on AI-orchestrated cyber espionage and MITRE ATLAS adversarial AI threat matrix both reinforce that threat actors increasingly chain identity abuse with workflow abuse. This is why accountability should be written into control design before the first fraudulent request lands.

Related resources from NHI Mgmt Group

• Who is accountable when a man-in-the-middle attack succeeds through weak authentication?
• Who is accountable when a prompt bombing attack succeeds?
• Who is accountable when a JWT token replay attack succeeds across services?
• Who is accountable when a supply chain compromise spreads through trusted credentials?