Who should own BEC prevention when the attack spans email, IAM, and finance?

Ownership should be shared, but accountability must be explicit. Security teams own detection and control design, IAM owns identity verification steps, and finance or operations owns approval workflow enforcement. If no single team is responsible for the end-to-end request path, impersonation attacks will keep exploiting the gaps between functions.

Why This Matters for Security Teams

BEC prevention fails when teams treat email compromise, identity abuse, and payment approval as separate risks. Attackers do not respect org charts; they move from mailbox access to identity resets, then into finance workflows that look legitimate on paper. Guidance from the The 52 NHI breaches Report shows how often security breaks when secrets and access paths are handled in disconnected ways, and CISA advisories continue to show that compromise chains are usually operational, not isolated.

The practical question is ownership, but the real control problem is end-to-end accountability. If security owns detection, IAM owns verification, and finance owns approvals, each team can still assume another team caught the abnormal step. That creates a gap attackers exploit with spoofed inboxes, token theft, and altered payment instructions. In practice, many security teams encounter BEC only after a fraudulent transfer or vendor update has already crossed an internal handoff.

How It Works in Practice

Effective BEC prevention works as a cross-functional control path, not a single tool. Security should define the detection logic for suspicious message origin, impossible travel, mailbox rule abuse, and anomalous forwarding. IAM should enforce strong identity proofing, phishing-resistant authentication, and step-up checks for sensitive changes. Finance or operations should own the business approval workflow, including segregation of duties, dual confirmation, and callbacks to validated contact channels.

The strongest programs connect these steps with shared policy, not ad hoc escalation. For example, a payment change request can trigger identity re-verification, inbox risk review, and a finance hold until the request is confirmed through an out-of-band channel. This is where The 2024 Non-Human Identity Security Report is useful: 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, which shows how easily identity controls and business processes can drift into the same weak channel. That risk is amplified by current guidance from CISA cyber threat advisories, which repeatedly point to layered compromise rather than one-step attacks.

• Security owns detection engineering, alert triage, and evidence collection.
• IAM owns authentication, recovery controls, and identity verification for sensitive requests.
• Finance owns payment approval rules, vendor change validation, and exception handling.
• Leadership owns a named end-to-end process owner who can stop a transaction.

These controls tend to break down when approval and identity workflows are split across regional finance teams, outsourced service desks, or high-volume exception handling because no one sees the full request path.

Common Variations and Edge Cases

Tighter approval control often increases cycle time, so organisations have to balance fraud resistance against operational speed. That tradeoff is especially visible in payroll changes, urgent vendor updates, and executive requests, where business pressure can weaken standard verification. Current guidance suggests the answer is not to remove friction, but to apply it selectively where the loss impact is highest.

There is no universal standard for this yet, but mature programs usually separate low-risk routine payments from high-risk changes that require human confirmation and logged escalation. Shared mailboxes, delegated inboxes, and outsourced AP operations also need special handling because identity ownership can become unclear even when process ownership looks defined. The most resilient teams pair policy with immutable logging and periodic tests that trace a fake request from mailbox to payout.

For broader identity context, NHI governance lessons from Top 10 NHI Issues and the attack patterns summarized in LLMjacking: How Attackers Hijack AI Using Compromised NHIs reinforce the same lesson: identity abuse succeeds when one team believes another team owns the final check. In practice, that usually surfaces first during a payment exception, not during a formal control review.

Related resources from NHI Mgmt Group

• Who should own BEC risk across IAM and finance?
• Who should own identity risk when governance spans IAM, PAM, and security operations?
• What should security teams do when IAM governance spans human and machine identities?
• Who should own impersonation risk when it affects finance, help desk, and identity teams?