These attacks succeed because they exploit trust at the identity and communication layers. BEC can trick employees into approving transfers or sharing sensitive data, while synthetic identities blend real and fake attributes to bypass weak checks. When organisations rely on isolated controls, attackers can move from impersonation to financial loss, account abuse, and longer term trust erosion.
Why these attacks are so damaging to trust and payment workflows
business email compromise and synthetic identity fraud are high-risk because they target the points where organisations decide whom to trust. BEC abuses familiar names, internal language, and timing to get legitimate people to authorise payments or release information. Synthetic identities are harder to detect because they are built to look consistent across onboarding and account opening checks, which makes them useful for fraud, mule activity, and repeat abuse. CISA’s current guidance on cyber threats and advisories shows how often real-world campaigns blend deception with operational pressure, which is exactly why these attacks succeed when teams rely on one control in isolation.
These attacks also create compounding harm. A single successful impersonation can lead to immediate financial loss, but it can also undermine vendor trust, disrupt approvals, and force expensive investigations into whether a request, account, or customer record is genuine. In practice, many security teams encounter the damage only after a payment has been redirected or an account has already been opened under false pretences, rather than through intentional prevention.
How the risk develops across email, onboarding, and fraud controls
The core risk is not just the fraud attempt itself, but the gap between controls that were designed separately. Email controls may catch obvious spoofing, yet BEC often uses compromised mailboxes, lookalike domains, or conversational manipulation that passes technical filters. Identity proofing controls may verify documents or data points, yet synthetic identities are built to satisfy those checks while remaining difficult to tie back to a real, accountable person. That means the organisation may see each signal as acceptable in isolation, even though the combined pattern is unsafe.
For BEC, the critical failure is usually a weak approval path: a message appears to come from a trusted executive, supplier, or internal function, and the recipient is pressured to act quickly. For synthetic identity fraud, the failure is usually an incomplete assurance chain: onboarding checks confirm enough attributes to open an account, but not enough to establish durable identity legitimacy or detect coordinated reuse. If a team only watches for one style of abuse, the attacker simply shifts to another part of the workflow.
- Email security reduces obvious spoofing, but it does not by itself verify the intent behind a request.
- Identity proofing reduces false enrolment, but it does not guarantee that the applicant is economically or operationally trustworthy.
- Fraud review reduces some losses, but it must be tuned for patterns of repetition, mule behaviour, and account chaining.
Where these attacks are most damaging is at scale, because the same weakness can be reused across many transactions, applicants, or business units before the pattern is recognised.
Common variations and edge cases that change the response
Tighter verification often increases friction, so organisations have to balance speed against the cost of a mistaken trust decision. That trade-off matters because BEC and synthetic identity attacks do not always look like classic malware or account takeover.
Some BEC cases begin with no mailbox compromise at all, only business process abuse and social engineering. Others involve a compromised vendor account, which makes the request appear consistent with prior correspondence. Synthetic identity attacks also vary: some are used to open credit or service accounts, while others are designed to build credibility over time before a larger fraud event. Guidance is not uniform across sectors, because financial services, e-commerce, and general enterprise environments face different proofing and approval expectations.
Organisations should be cautious about treating every high-trust request the same way. A request that changes payment destination, bank details, or beneficiary identity should be handled differently from an ordinary workflow update. Likewise, an identity proofing failure should not be interpreted only as a front-end onboarding issue if the same synthetic record can later be used for fraud, abuse, or account recovery. The answer breaks down when teams rely on static checks without monitoring how trust is reused after the first decision.
Risk and Threat Considerations
These attacks create material exposure because they exploit trust decisions that are both operationally important and difficult to reverse. BEC is attractive to adversaries because it can convert a single deceptive message into payment diversion, data disclosure, or authorisation abuse without needing technical exploitation. Synthetic identity fraud creates similar exposure by turning weak assurance into a reusable fraudulent persona that can move through onboarding, credit, or account creation workflows.
Failure mechanism: The failure usually appears when organisations split email trust, identity proofing, and transaction approval into separate controls that do not challenge one another. Attackers abuse compromised mailboxes, lookalike domains, social engineering, or fabricated attribute combinations to pass each checkpoint independently.
Impact: The result can include financial loss, unauthorised account creation, fraudulent transactions, dispute costs, customer distrust, and increased review burden across finance, fraud, and security teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Controls approval and lifecycle handling for accounts used in fraud and impersonation paths. |
| Recommendation — Enforce account approval and review steps for high-risk changes to reduce BEC and synthetic identity abuse. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | Addresses trust decisions around who can act, approve, or obtain access. |
| ID.RA-5 — Threats, Vulnerabilities and Controls Identified | Supports recognising deception-driven fraud patterns and weak control assumptions. | |
| Recommendation — Strengthen identity and access checks for payment and onboarding workflows. Map fraud and impersonation patterns to risk registers and adjust control coverage. | ||
| MITRE ATT&CK | T1566 — Phishing | BEC commonly uses deceptive messages and social engineering to induce action. |
| Recommendation — Hunt for phishing and impersonation indicators in mail and approval workflows. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Relevant to synthetic identity risk where proofing strength affects enrolment trust. |
| Recommendation — Use stronger identity proofing where account creation or recovery carries fraud exposure. | ||
Practitioner Guidance
What to prioritise: Focus first on the requests and identity events that can directly move money, change beneficiary details, or create durable account access. Those are the highest-consequence points where a single failure has the broadest impact.
What to verify: Verify that approval paths require an independent check when a request is unusual, urgent, or high-value, and that onboarding decisions are reviewed against patterns of attribute inconsistency, reuse, or repeated enrolment signals. The key judgment is whether the control confirms legitimacy or merely confirms completion.
Practitioner takeaway: Treat BEC and synthetic identity as trust-capture problems, not just fraud events, because the real failure is usually the organisation’s willingness to accept a plausible story as sufficient evidence.
Related resources from NHI Mgmt Group
- Why does phishing against cloud accounts create such a high-risk access problem for organisations?
- Why do email platforms create such high identity risk during active exploitation?
- Why do synthetic identities and identity theft create such high risk in new account origination?
- Why do identity attacks create broader business and operational risk than many organisations expect?