BEC keeps working because attackers exploit process trust, not malware. They imitate executives, suppliers, or finance staff, then use stolen email accounts, lookalike domains, or reply-chain manipulation to request payments, change bank details, or divert invoices. Out-of-band verification, payment call-back controls, and enforced approval steps reduce the chance that a single convincing message is enough.
Why BEC keeps working even when staff are alert
BEC succeeds because it targets workflow assumptions, not technical defenses alone. Attackers do not need to break encryption or install malware if they can persuade someone to treat a message as routine business. The attack only has to look plausible long enough for a payment, bank-detail change, or invoice diversion to happen.
That is why BEC remains effective across industries. The pressure comes from speed, authority and normality: the request sounds urgent, the sender looks familiar, and the action fits an everyday business process. Those three factors often matter more than the message's technical origin.
For practitioners, the real question is not whether email is “secure enough”, but whether the organisation has built enough friction around high-risk requests that a convincing impersonation is no longer sufficient on its own.
What makes the attack path so durable
Most BEC campaigns work by combining several weak signals into one believable story. A compromised mailbox, a lookalike domain, a reply-chain hijack, or a spoofed executive request can all be enough if the recipient sees only a fragment of the context. The attacker does not need perfect realism, only enough confidence to get the next step approved.
That durability is reinforced by business processes that assume email is a valid instruction channel. If finance teams can change payment details from an inbox thread alone, the control failure is procedural as much as technical. Top 10 Email Security Threats is a useful way to see how BEC sits alongside lookalike domains, thread hijacking and payment fraud rather than as a single isolated trick.
In practice, the same request can survive multiple checks because each check is narrow. One person may confirm the sender address, another may recognise the tone, and a third may only see a payment ticket. BEC exploits that fragmentation.
Which controls actually break the chain
Controls work best when they interrupt the business step, not just the message. Out-of-band verification, callback rules using known contact details, dual approval for bank-detail changes, and hold periods for first-time beneficiaries all reduce the chance that one message can trigger irreversible action.
Email authentication still matters, but only as one layer. If the organisation treats SPF, DKIM and DMARC as sufficient, it will miss mailbox takeover, compromised suppliers, and social engineering that uses legitimate accounts rather than fake ones. Email Identity and BEC Guide is the natural starting point for the control stack around impersonation, mailbox compromise and payment verification.
It also helps to treat bank-detail changes, urgent payment requests and invoice amendments as high-friction actions by default. The more a process can be completed entirely inside a single inbox thread, the more attractive it becomes to an attacker.
Risk and Threat Considerations
BEC is durable because it turns trusted communication into an attack surface. The main risk is not just fraudulent payment, but the organisational habit of accepting business urgency as a substitute for independent verification. Once that pattern is normal, even small compromises can produce large losses.
Failure mechanism: The attacker injects a believable request into an existing workflow, then relies on speed, hierarchy and fragmented review to bypass challenge. If the message is accepted as routine, the control failure happens before anyone asks whether the request is authentic.
Impact: Organisations can lose funds, expose supplier or payroll data, and trigger downstream disputes over approved transactions. A single accepted exception can also teach the attacker which people, processes and thresholds are easiest to reuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | BEC commonly starts with deceptive email and thread abuse. |
| Recommendation — Map BEC entry paths to phishing and hunt for deceptive email patterns. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised mailboxes and impersonated accounts are central to BEC. |
| Recommendation — Review privileged and finance-facing accounts for misuse and unnecessary access. | ||
| NIST CSF 2.0 | PR.AA-05 — User, Device, and Other Asset Authentication | BEC defenses depend on verifying the requester before authorising payment actions. |
| PR.DS-10 — Data and Assets are Protected from Unauthorized Access | BEC aims to divert money and sensitive business records through unauthorized requests. | |
| Recommendation — Require independent authentication before approving high-risk financial changes. Protect payment workflows with additional controls beyond inbox-based approval. | ||
Practitioner Guidance
What to verify: Verify that the teams handling payments, supplier changes and invoice approvals have a separate verification path that does not depend on the same mailbox thread. If the only control is “the email looked right”, the process is still exposed.
Decision rule: If a request changes money movement, payment destination or vendor identity, require an independent callback or second-channel confirmation before approval. Treat urgency, executive pressure and reply-chain continuity as risk signals, not as reasons to shorten the process.
What good looks like: The organisation can show that high-value payment actions are routinely delayed long enough for independent verification, and that exceptions are rare, logged and reviewable. A good BEC control environment makes the attacker spend more effort on process manipulation than the business spends on checking.
Practitioner takeaway: BEC keeps working where the business still trusts the inbox more than the workflow control, so the strongest defence is to make payment and bank-detail changes verifiable outside the email thread.
Related resources from NHI Mgmt Group
- Why do social engineering attacks keep working against modern IAM controls?
- Why do supply chain, OAuth phishing, and access token attacks keep working against mature organisations?
- Why do credential stuffing attacks keep working against rate limits?
- How should organisations keep access working when the identity provider is unreachable?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org