Business Email Compromise Prevention: A Practical Control Framework for Impersonation Fraud

Business email compromise caused approximately $3.047 billion in reported losses across 24,768 complaints to the FBI's Internet Crime Complaint Center in 2025. Those numbers reflect reports submitted to the FBI, not the full prevalence of the crime. They still make the central problem clear: a short message that appears to come from the right person can trigger a very expensive action.

The old mental model of BEC is an executive sending a badly written request for gift cards. That attack still exists, but it is only one version. A modern request can arrive inside a real supplier's compromised mailbox, continue an authentic invoice thread, pass SPF, DKIM, and DMARC, and use the supplier's normal writing style. The attacker may reinforce the request through Microsoft Teams, WhatsApp, a phone call, or a synthetic voice. Another campaign may begin with credential phishing, malicious OAuth consent, session theft, or a fraudulent help-desk reset, then remain quiet until a valuable transaction appears.

That is why BEC cannot be solved by asking employees to inspect messages more carefully. Email filtering, multifactor authentication, employee training, and payment approval all help, but each has failure modes. The durable objective is to prevent a persuasive communication from becoming authority to move money, change account details, reset an identity, or release sensitive data.

The governing principle is simple: verify the action, not the message. A familiar sender, valid email authentication, known voice, or convincing video may affect how suspicious a request seems. None should authorize a sensitive action by itself. Authorization must come from a trusted system, an independent verification path, and a recorded process that remains effective when one defensive layer fails.

An effective BEC prevention program therefore connects three control planes:

1. Technical controls protect identities, domains, mailboxes, endpoints, sessions, and cloud applications.

2. Verification workflows constrain high-risk business actions, including payments, vendor changes, payroll updates, help-desk resets, and data releases.

3. Training and reporting give people repeated practice executing those workflows under realistic pressure and provide a fast route to the teams that can act.

What You'll Learn

• How direct spoofing, compromised mailboxes, vendor email compromise, token theft, help-desk manipulation, and multi-channel impersonation create different BEC paths.

• Which identity, email, mailbox, endpoint, and monitoring controls reduce the chance that an attacker reaches a trusted communication channel.

• How to build independent verification workflows for bank-detail changes, payments, payroll, executive requests, account recovery, and sensitive-data release.

• How to train high-risk roles to follow the process under pressure and measure reporting and verification behavior rather than completion alone.

• Which controls to prioritize in the first 30, 60, and 90 days, and how to respond quickly when money or an account has already been compromised.

Why BEC Still Works When the Email Looks Legitimate

Business email compromise is targeted impersonation fraud. The attacker uses or imitates a trusted business identity to induce an unauthorized action. The desired outcome may be a wire transfer, altered supplier bank details, payroll diversion, gift-card purchase, release of employee tax records, disclosure of customer data, or an identity reset that enables a later intrusion.

The term “email” can obscure how the attack now works. In its 2026 M-Trends report, Mandiant said highly interactive voice phishing accounted for 11% of the initial infection vectors observed in its 2025 investigations. That is an incident-response dataset, not a measurement of all fraud. It nevertheless shows why current phishing attack paths extend well beyond the inbox.

Several attack paths can produce the same fraudulent request:

• Direct spoofing: The attacker forges the visible From address or abuses a domain with weak email-authentication policy.

• Lookalike domains: The attacker registers a confusingly similar domain, sometimes with an added word, transposed character, or Unicode lookalike.

• Email account takeover: Stolen credentials, a relayed MFA code, a stolen session, malware, or an account-recovery weakness gives the attacker access to a real mailbox.

• Vendor email compromise: The attacker compromises a supplier, law firm, broker, or other partner, observes legitimate conversations, and changes payment instructions at the right moment.

• Mailbox manipulation: Hidden inbox rules, external forwarding, delegated access, or automated deletion helps the attacker monitor and control a conversation.

• OAuth and token abuse: A malicious application grant or stolen session can provide mailbox access without a fresh interactive login.

• Help-desk manipulation: The attacker persuades support staff to reset credentials, change MFA, or register a new device.

• Multi-channel reinforcement: A fraudulent email is backed by a call, collaboration message, or video meeting that appears to confirm the request.

These paths defeat different controls. DMARC may block unauthorized use of your exact domain, but it does not invalidate mail from a supplier's compromised account. An email filter may recognize a newly registered lookalike but see nothing malicious in a message sent from a legitimate tenant. MFA can stop a password-only takeover, but a real-time phishing proxy may relay a one-time code or capture a session after the user authenticates. Phishing-resistant MFA can make that relay much harder, yet it cannot stop an authorized employee from sending money after receiving a convincing request.

The attacker exploits ordinary work conditions. Accounts-payable staff process repeated requests under deadlines. Executive assistants are expected to respond quickly. Help desks are measured on restoring access. Procurement teams routinely handle changes. A request framed as urgent, confidential, or commercially sensitive can make a policy exception seem like good service.

A typical vendor email compromise illustrates the full chain. An attacker gains access to a supplier's mailbox and creates a rule that hides selected replies. They study invoice schedules, names, signatures, and normal phrasing. Shortly before a payment, they continue the real thread and announce a bank change. If the customer asks for confirmation by replying, the attacker confirms. If the customer calls the new number in the email, an accomplice answers. Once the transfer reaches the first beneficiary account, the money may move rapidly through additional accounts.

Every message in that sequence can look internally consistent. The defense succeeds only when the customer obtains the supplier's trusted contact details from a separate system, follows a bank-change workflow, records the verification, applies dual control, and holds the first payment long enough to review anomalies.

The difference is fundamental. Email authentication asks whether a domain was used in an authorized way. Identity authentication asks whether an account or authenticator was valid. Transaction authorization asks whether the organization should perform this action under these conditions. BEC prevention requires all three, but the last question determines whether the fraud produces a loss.

Build BEC Prevention Around Independent Control Layers

A resilient program assumes that individual controls will sometimes fail. The design goal is graceful failure: a spoofed message may reach an inbox, an account may be compromised, or an employee may believe a caller, but a separate control still prevents the requested action or exposes it quickly.

Three types of control should be deliberately combined:

• Preventive controls reduce the chance that the attacker can impersonate a trusted identity or reach the target.

• Detective controls reveal unusual sender, identity, mailbox, payment, or user behavior in time for investigation.

• Transaction controls prevent a communication from becoming a completed high-risk action without independent authorization.

Independence matters more than the number of clicks. If one employee creates a payment and another approves it based on the same compromised email thread, the organization has two participants but only one source of trust. If a supplier's new phone number comes from the message that changed the bank account, the callback is not independent. If a help-desk agent sends a confirmation to an email account that the caller has already taken over, the second channel does not add meaningful assurance.

For each high-risk action, ask five questions:

1. Which system is the authoritative record?

2. Who is allowed to request, verify, approve, and execute the action?

3. Which verification channel remains trustworthy if the request channel is compromised?

4. What evidence must be retained?

5. Which conditions trigger a hold, escalation, or refusal?

Those answers turn “be careful” into an auditable control.

Technical Controls That Reduce BEC Entry and Account Takeover

Technical controls remove common impersonation paths, make account takeover harder, and provide signals that finance and security teams need. They cannot authorize a legitimate business transaction. Rank them according to the authority attached to each identity and system as well as the number of users.

Deploy phishing-resistant authentication where fraud begins

Start with accounts that can create, influence, or conceal high-risk actions: finance, accounts payable, treasury, payroll, procurement, vendor management, executives and their assistants, IT administrators, help-desk staff, shared invoicing mailboxes, and external accounts with access to payment or procurement portals.

NIST SP 800-63B-4 defines phishing resistance in terms of an authentication protocol preventing disclosure of secrets and valid authenticator outputs to an impostor verifier without relying on user vigilance. FIDO2/WebAuthn authenticators provide verifier-name binding. A security key or passkey produces a cryptographic response for the legitimate service domain, not an attacker's imitation.

That mechanism differs from manually entered codes. SMS codes, time-based one-time passwords, and other OTPs can improve security substantially compared with passwords alone, but an attacker can ask the victim for the code and relay it. Ordinary push approval can be abused through fatigue or a convincing call. NIST therefore does not treat manual entry of an authenticator output as phishing-resistant.

The target state should include:

• FIDO2/WebAuthn security keys or passkeys for high-risk and privileged users.

• Two separately stored authenticators for critical roles so loss of one does not force a weak emergency recovery.

• Step-up authentication for beneficiary changes, payment release, mailbox delegation, new OAuth grants, and sensitive administrative actions.

• Conditional access based on managed device state, user risk, application, network, and role.

• Separate administrative accounts that are not used for everyday email.

• Disabled legacy authentication and basic protocols.

CISA recommends planning a move to FIDO/WebAuthn. Where that cannot happen immediately, number matching is a stronger interim choice than simple push approval. The migration should be explicit. Tracking only whether “MFA is enabled” hides important differences among methods and makes a poor long-term risk objective.

Harden enrollment, recovery, and help-desk resets

Strong authentication is only as strong as its enrollment and recovery paths. An attacker who cannot phish a security key may call the help desk, claim to have lost every device, and ask for a weaker method to be enrolled.

High-risk recovery should require more than caller ID, an employee number, a manager's name, or answers derived from public information. Depending on the environment, controls can include:

• Approval through an already enrolled trusted device or authenticator.

• A separate manager or security approval that the help-desk agent cannot provide.

• A cooling-off period before a new authenticator can perform privileged actions.

• Immediate notification through previously registered channels.

• A recorded ticket containing the evidence, approver, reason, time, and devices affected.

• Forced revocation of existing sessions and refresh tokens after a reset.

• Enhanced review when the caller is traveling, demands secrecy, reports every device lost, or pressures the agent to bypass policy.

Recovery events should be treated as security-relevant transactions. Alert on new authentication methods, device registration, password reset, disabled MFA, changed recovery details, and privileged role changes. Send notifications to channels established before the event, not only to the account being recovered.

Configure SPF, DKIM, and DMARC without overstating them

Email authentication removes a large and preventable class of direct spoofing. NIST SP 800-177 Rev. 1 covers the roles of SPF, DKIM, DMARC, and related technologies in improving trust in email.

• SPF identifies servers authorized to send for an envelope domain.

• DKIM applies a cryptographic signature associated with a signing domain.

• DMARC checks alignment between the visible From domain and SPF or DKIM, then publishes handling and reporting policy.

Deploy these controls across primary domains, subdomains, marketing systems, transactional services, and parked domains. Begin with an inventory of legitimate senders and DMARC reporting. Correct alignment problems, move through controlled quarantine, and work toward p=reject where operationally safe. Configure non-sending domains so they cannot be used plausibly for mail.

Deployment requires care. Third-party senders, forwarding, mailing lists, and SPF's DNS lookup limit can produce failures. Moving directly to rejection without discovering legitimate mail can disrupt business. ARC may preserve authentication information through trusted intermediaries, while MTA-STS and TLS reporting improve transport protection. These are supporting mechanisms, not proof that the person behind a message is trustworthy.

DMARC does not prevent:

• A lookalike domain controlled and correctly authenticated by an attacker.

• A compromised mailbox at your company or a supplier.

• Fraud from a legitimate consumer-mail account.

• Display-name deception where the actual address is different.

• Impersonation by phone, messaging, collaboration tools, or video.

• An authorized employee acting on a fraudulent instruction.

Use DMARC to stop unauthorized use of your domains. Do not treat it as a general “BEC protected” label.

Detect impersonation and suspicious requests

Inbound controls should evaluate relationships and business context, not just known malicious files and URLs. BEC messages are often short, low volume, and free of payloads. Useful signals include:

• Executive, employee, and supplier display-name impersonation.

• Reply-To and From mismatches.

• Typographical, homoglyph, and newly registered domains.

• First-time correspondence or an unusual sender-recipient relationship.

• Changes in timing, geography, device, sending infrastructure, or writing pattern.

• Bank-account, beneficiary, payroll, contact-detail, or gift-card language.

• Urgency, secrecy, authority, and requests to switch channels.

• QR codes, image-based text, password-protected files, and links to legitimate file-sharing or form services.

• Missing participants, altered headers, or other thread anomalies.

• An unusual invoice amount, currency, receiving country, or payment schedule.

External-sender banners can help, but they should not become the primary decision rule. Users quickly habituate to banners, and vendor compromise arrives from an external sender that may be genuinely familiar. Behavioral detection also produces false positives. High-impact messages need explainable review and a rapid way for analysts and business owners to resolve uncertainty.

Harden mailboxes, OAuth, and SaaS

Mailbox takeover becomes more durable when the attacker can monitor mail, hide replies, or retain access after a password change. Baseline controls should include:

• Block external automatic forwarding by default and tightly control exceptions.

• Alert on new forwarding destinations, hidden or suspicious inbox rules, and rules that delete or move finance/security messages.

• Review Send As, Send on Behalf, delegates, shared-mailbox membership, and mailbox application access.

• Restrict user OAuth consent to approved publishers and reviewed permission sets.

• Alert on new grants with mail, file, directory, or offline-access permissions.

• Monitor unusual mailbox searches, bulk message access, exports, and legacy-protocol use.

• Retain identity, mailbox, OAuth, endpoint, and payment logs long enough to reconstruct an incident.

• Correlate a risky sign-in or identity reset with mailbox changes and financial activity.

A password reset is not complete containment. Microsoft's compromised-account guidance emphasizes disabling access where appropriate, revoking sessions, and reviewing forwarding, inbox rules, and delegated access. Investigators should also inspect registered authentication methods, devices, OAuth applications, refresh tokens, and endpoint evidence.

Protect endpoints, browsers, mobile devices, and domains

Credential and session theft can begin with an infostealer, malicious browser extension, unpatched device, or unmanaged browser. Apply endpoint detection, rapid patching, application control, extension governance, managed browsers, and isolation for risky links according to user risk. Protect administrative and finance workstations more aggressively than general-purpose endpoints where practical.

Mobile coverage matters. QR phishing deliberately moves a user from a managed desktop to a phone where the destination may be harder to inspect and enterprise controls may be weaker. Employees need a straightforward way to report suspicious QR codes, texts, and mobile email, not only desktop messages.

Monitor for confusingly similar domains, newly issued certificates, cloned login pages, and misuse of company or executive brands. Defensive registration can protect a small set of highly likely variants, but no organization can register every permutation. Monitoring, takedown procedures, inbound analysis, and transaction verification must carry the rest of the load.

Make logs actionable

Logging is useful only when someone owns the signal and can act before the money moves. Define response playbooks for high-value combinations such as:

• New MFA method followed by a finance-mailbox login.

• New external forwarding rule plus deletion of replies.

• OAuth consent followed by unusual mailbox searches.

• Risky sign-in followed by a vendor-master change.

• Password reset followed by a new beneficiary or payment release.

• First-time supplier domain plus changed bank instructions.

Route technical alerts to security, but also connect them to finance and business operations. A SOC analyst may not know that a payment is scheduled for the same afternoon. Conversely, accounts payable may see an unusual bank change but have no visibility into a recent identity reset. High-risk correlation should bridge those systems.

Verification Workflows That Stop Fraudulent Actions

“Call to verify” becomes a real control only after the organization specifies where the trusted number comes from, who may call, what must be confirmed, how the evidence is recorded, which approvals are required, and what happens when verification fails. Without those details, staff will improvise under pressure, and the attacker will shape the process.

Establish trusted contact data before a request arrives

Independent verification depends on contact data established outside the request. For a supplier, that could be a verified phone number and named contact stored in the vendor master. For an employee, it could be an authenticated HR portal and a previously registered contact method. For an executive, it could be an approved directory and escalation chain. For IT, it could be a trusted device and documented manager relationship in the identity or service-management system.

The system of record should have a named owner, access restrictions, change history, and periodic recertification. If any employee can change the phone number used to verify bank-detail changes, the verification control can be modified by the same person who initiates the risky action. Separate maintenance of trusted contact data from use of that data where risk justifies it.

Do not source contact details from:

• The email or attachment requesting the change.

• A website or portal linked from that message.

• A reply in the same thread.

• Caller ID, which can be spoofed.

• A new collaboration account introduced during the request.

• Search results without validating that the result belongs to the expected entity.

When no trusted contact exists, pause the transaction. Re-establish the relationship through procurement, the contract owner, previous records, or another independently known party, regardless of the request's urgency.

Verify bank-account and vendor-master changes

A request to change a beneficiary or supplier bank account should enter a controlled workflow, not remain an email task. A defensible process includes the following steps:

1. Capture the request. Create a case in the ERP, procurement, or service-management system. Preserve the original communication and identify the affected supplier and pending payments.

2. Check authority. Confirm that the named requester is authorized to submit changes for that supplier. Authority must come from an existing record or contract, not only the message.

3. Initiate an independent callback. A trained employee calls a previously validated number. The employee, not the requester, initiates the call.

4. Perform meaningful read-back. Confirm the existing relationship, change request, new account information, effective date, and reason. Do not ask only, “Did you request a change?”

5. Record evidence. Document who called, who answered, which trusted number was used, what was confirmed, when it occurred, and any anomalies.

6. Require independent approval. A second authorized person reviews the evidence and change. The approver should not rely solely on the original email.

7. Apply a risk-based hold. Delay activation or the first payment where business conditions permit, particularly for high values, new countries, unusual currencies, or a change close to the payment date.

8. Notify through old and new channels. Send confirmation to the existing trusted contact and, where appropriate, the newly verified contact. Unexpected objections can surface before payment.

9. Escalate failed verification. A wrong number, unavailable contact, inconsistent answer, or pressure to bypass the process is an investigation trigger, not an administrative inconvenience.

The FinCEN advisory on email compromise fraud recommends multi-faceted transaction verification and identifies anomalies such as a beneficiary with no payment history or a payment inconsistent with previous activity. Although the advisory's historical loss figures are dated, its process logic remains useful.

Consider a supplier mailbox that has been compromised. The attacker sends a legitimate-looking change inside the real invoice thread. DMARC passes. A staff member replies and receives a convincing answer. Under an email-only process, the change succeeds. Under the controlled process, the request creates a case, the callback number comes from the pre-existing vendor master, the real supplier denies the change, the payment is held, and security receives the fraudulent thread for investigation. The process does not require accounts payable to prove how the mailbox was compromised. It only requires staff to follow a control that does not trust the mailbox.

Separate payment creation, approval, and release

Payment controls should prevent one identity, device, or session from creating and completing a high-risk transfer. Depending on organizational size and transaction risk, separate:

• Creation or modification of a supplier record.

• Entry of a beneficiary or bank account.

• Preparation of a payment batch.

• Approval of the payment.

• Release in the bank portal.

• Reconciliation after settlement.

Use named accounts rather than shared credentials. Align ERP roles and bank entitlements with job duties. Require reauthentication for sensitive actions and use phishing-resistant methods for users who can release funds. Review entitlements after role changes and departures. Do not let an administrator quietly grant themselves both preparation and release privileges without a separate approval and alert.

Thresholds can reduce operational burden, but attackers adapt to them. Monitor split invoices, repeated amounts just below a limit, rapid beneficiary creation followed by payment, and changes made by a user who does not normally manage that supplier. Consider risk factors together rather than relying on amount alone. A small first payment may be a test before a larger transfer.

Reconciliation closes the loop. Daily review of released payments, rejected transactions, beneficiary changes, and callbacks can surface fraud while recall is still possible. The reviewer should have access to the supporting case and verification evidence, not only a total.

Protect payroll and employee-record changes

Payroll diversion uses the same trust problem on a different system. An attacker impersonates an employee and asks HR or payroll to change direct-deposit information. The request may come from a lookalike account or the employee's real mailbox.

Prefer authenticated employee self-service with strong authentication, alerts, and audit history. If manual changes are allowed, verify through a previously registered channel and notify the employee through the old channel when the change is submitted and completed. Consider a hold or enhanced review when the request arrives shortly before payroll, changes both contact and bank details, or follows an account recovery event.

Apply similar controls to tax documents, benefits, address changes, and sensitive employee data. A message from a familiar executive should not authorize bulk release of W-2s or identity records. Use data classification, minimum-necessary access, and a documented approval path.

Control executive and confidential requests

Executive impersonation works partly because staff believe seniority can override process. Leadership must explicitly remove that ambiguity. Executives should state, in policy and in practice, that they will not ask employees to bypass payment, procurement, identity, or data-release controls because a matter is urgent or confidential.

Executive assistants, chiefs of staff, finance leaders, and legal teams need a clear escalation path. They should be empowered to pause a request without career risk. Confidentiality can limit who is informed, but it should not eliminate independent authorization.

Code words may help in narrow circumstances, but they are fragile. They can be shared, overheard, stored in compromised messages, or reused. A code word should never replace an authenticated workflow, dual control, or a callback to a known contact. A familiar voice or face is also weak evidence because recordings, social media, and synthetic media can support impersonation. Verify the action through the approved process, regardless of how convincing the person appears.

Secure help-desk resets and device enrollment

Help-desk staff control a path into every other workflow. Recovery and new-device enrollment should use the same principles as payment changes: known records, independent authorization, evidence, separation of duties, and alerts.

For sensitive users, require verification through an enrolled device or authenticator plus a separate approval. If the user claims all authenticators are unavailable, escalate to a higher-assurance process rather than dropping to knowledge questions. Consider temporary restricted access and a cooling period before the recovered account can change payment data, add delegates, create OAuth grants, or perform privileged administration.

After a reset:

• Revoke existing sessions and refresh tokens.

• Review registered devices and authenticators.

• Notify the user and manager through previously established channels.

• Monitor the account for unusual mailbox, SaaS, and administrative behavior.

• Link the recovery event to downstream risk engines where possible.

Recovery must remain usable while preventing an attacker from turning urgency and an empathetic support interaction into a bypass of phishing-resistant login.

Verify sensitive-data release and legal requests

BEC is often described as wire fraud, but attackers also request contracts, customer lists, employee records, tax forms, credentials, or privileged legal information. Define which data classes require independent approval and which channels are permitted for transfer.

The verifier should confirm both identity and authority. A real employee may not be authorized to request the full dataset. Limit disclosure to the minimum necessary, use an approved transfer mechanism, and involve privacy, legal, or security teams when the request carries regulatory, contractual, or privilege implications. Do not send sensitive records to a new personal address because the requester claims the corporate system is unavailable.

Design exception handling before emergencies

An undocumented exception process guarantees improvised exceptions. Define:

• Who can approve an exception.

• Which controls can never be waived.

• Which compensating controls are required.

• How long the exception lasts.

• What evidence and business reason must be recorded.

• Who reviews the exception afterward.

For example, if a time-critical payment cannot wait through the normal hold, the compensating process might require direct voice confirmation with two known supplier contacts, treasury leadership approval, bank fraud-team notification, and immediate post-release reconciliation. “The CEO said it was urgent” is not an exception process.

Train People to Execute the Workflow Under Pressure

Role-based training against AI phishing should make safe behavior familiar enough that employees can perform it when a request looks normal, a deadline is close, and the apparent requester is powerful. Perfect deception detection is an unrealistic objective.

A peer-reviewed scoping review of phishing-training research found wide variation in methods and outcomes. It concluded that annualized programs are unlikely to provide sustained protection and that active engagement, repeated practice, and process-based feedback improve results. The evidence does not justify a claim that training catches every attack. It supports designing training around repeated behavior rather than a yearly information transfer.

Train by role and authority

Generic awareness establishes common language, but high-risk roles need scenarios tied to the actions they can perform:

• Finance, accounts payable, and treasury: beneficiary changes, invoice fraud, unusual payment requests, threshold manipulation, and escalation to the bank.

• Procurement and vendor management: trusted contact maintenance, onboarding, bank-change verification, contract-owner coordination, and supplier compromise.

• Payroll and HR: direct-deposit changes, tax-document requests, executive requests for employee data, and authenticated self-service.

• Executives and assistants: authority-based pressure, confidential requests, voice/video impersonation, and leadership behavior that reinforces non-waivable controls.

• Help desk and identity teams: lost-device pretexts, MFA reset, new-device enrollment, SIM-swap claims, and post-recovery containment.

• Legal and data owners: privileged or regulated data requests, new transfer destinations, and minimum-necessary disclosure.

• Security operations: user-report triage, identity-mailbox correlation, finance escalation, and preservation of evidence.

Train managers too. A procedure fails when an employee pauses a suspicious payment but a manager orders them to process it to meet a deadline.

Simulate real attack chains

Simulations should reflect the control environment and roles being tested. A multi-vector simulation program can cover useful BEC exercises such as:

• A supplier bank-change request inside an existing-looking thread.

• An executive request for an urgent payment followed by a phone call.

• A payroll change from a compromised employee account.

• A fake IT-support call that asks the target to approve MFA or visit a login page.

• A malicious OAuth-consent request framed as a document collaboration.

• A help-desk caller who claims to have lost every device while traveling.

• A data request that uses confidentiality to discourage verification.

• A hybrid email-plus-voice scenario that tests whether the employee follows the same workflow across channels.

The exercise should have an approved learning objective, a safe payload, privacy safeguards, and a defined end condition. Avoid humiliation, surprise scenarios involving personal trauma, and tests that reward trickery more than learning. Coordinate with HR, legal, and employee representatives where appropriate.

Give immediate, process-based feedback

Feedback should explain the correct action in that organization's environment. “You should have noticed the domain” is incomplete. The domain might be genuine in the next attack.

Better feedback says:

1. This request changed a supplier bank account.

2. The approved procedure requires opening a case and calling the number already stored in the vendor master.

3. Replying to the thread or calling a number in the email does not provide independent verification.

4. The report button or named escalation channel alerts security and finance.

That turns a missed cue into procedural learning. Repeat practice over time and vary the channel, difficulty, and pretext while keeping the expected behavior stable.

Make reporting fast and psychologically safe

Employees need an obvious way to report suspicious email, voice, collaboration, and mobile requests. A one-click or one-step path is preferable to asking users to forward a message, locate a mailbox, and explain technical details. Acknowledge reports and tell employees what happens next.

Reporting after a click, credential entry, or disclosure is especially important. If people expect punishment, they may wait, delete evidence, or hope nothing happens. Early reporting can enable session revocation, payment holds, recipient warnings, and bank intervention. Treat a fast post-error report as valuable security behavior.

The response team must be able to handle the volume. Define triage priorities, preserve headers and attachments, correlate the report with identity and mailbox telemetry, and route payment-related reports to finance immediately.

Calibrate difficulty and measure behavior

Raw click rate is not a stable measure of human risk when exercises differ. A highly personalized request to a finance employee cannot be compared fairly with a generic password-expiry message sent to another group. The NIST Phish Scale gives training teams a method for considering detection difficulty based on observable cues and alignment with the target's context.

Measure security awareness training effectiveness through outcomes tied to the program's purpose:

• Reporting rate and time to report.

• Percentage of high-risk changes that follow the approved verification procedure.

• Percentage of verification cases with complete evidence.

• Frequency and type of attempted policy bypass.

• Repeat behavior after feedback.

• Time for security and finance to act on a report.

• Percentage of identity resets followed by required session revocation and review.

• Results of tabletop and control-path testing.

• Losses, near misses, stopped payments, and recovery actions, interpreted carefully because event counts may be low.

Completion rate is an administrative metric. Click rate is one simulation outcome. Neither alone demonstrates that the organization can stop impersonation fraud.

Assign Ownership and Roll Out the Highest-Value Controls First

BEC crosses organizational boundaries, so no single team can own the entire outcome. Security and identity teams manage authentication, conditional access, telemetry, and containment. Messaging teams manage domain authentication and mail controls. Finance and treasury own payment authority and bank relationships. Procurement and vendor management own supplier records. HR and payroll own employee changes. The help desk owns recovery execution. Legal, privacy, and insurance functions guide obligations and response. Internal audit tests whether the process works as designed.

An executive sponsor should resolve conflicts between speed and control. The policy must name high-risk actions and non-waivable controls. It should also require leaders to support employees who pause suspicious requests.

After 90 days, mature the system by integrating identity and payment risk, expanding supplier security requirements, automating holds on high-risk combinations, validating logging retention, testing recovery paths, and reviewing entitlements and trusted contacts on a schedule. Repeat exercises when systems, payment processes, vendors, or executive roles change.

Create an operating cadence so the program does not decay after the initial rollout. A quarterly BEC control review should bring security, finance, procurement, payroll, and IT support together. Review near misses, reported requests, beneficiary changes, identity-recovery events, unusual mailbox activity, policy exceptions, and the time taken to contain incidents. The purpose is to find gaps between systems. A finance team may have followed its callback procedure while using a trusted number that had not been recertified. Security may have detected a risky sign-in but failed to connect it to a payment scheduled that day.

Supplier governance belongs in this cadence. Contracts and onboarding procedures can require suppliers to maintain named payment contacts, report mailbox compromise quickly, use strong authentication, and accept independent verification of banking changes. These requirements do not transfer responsibility for your own payment controls. They reduce ambiguity and make joint response faster. Segment suppliers by transaction value, data access, geographic risk, and operational criticality so the most consequential relationships receive deeper verification and more frequent recertification.

Use a small scorecard that connects control operation to business outcomes. Useful measures include the percentage of priority accounts protected with phishing-resistant authentication, DMARC enforcement coverage across sending and non-sending domains, the percentage of high-risk changes with complete verification evidence, the number of unauthorized forwarding or OAuth events investigated within the target time, median user-reporting time, and the percentage of BEC exercises that reach finance and security through the correct route. Pair rates with absolute counts and context. A rise in reports may indicate more attacks, better reporting, or both.

Internal audit or another independent assurance function should periodically sample real transactions and recovery cases. Test whether the recorded callback used the approved contact, whether approvers reviewed evidence, whether exceptions expired, and whether sessions were revoked after identity recovery. Tabletop exercises test what people say they will do. Transaction sampling tests what the organization actually did.

The roadmap should be risk based. A small company may not be able to separate every duty across different departments, but it can still require two people for bank changes, use trusted callbacks, strengthen email authentication, protect finance accounts with FIDO, and establish a direct bank escalation path. Compensating controls should be explicit, documented, and reviewed.

Respond in Minutes When a BEC Payment or Account Compromise Occurs

When a fraudulent payment may have been sent, financial action and technical containment should begin in parallel.

1. Contact the financial institution immediately. Use the established fraud contact, request a recall or freeze, and provide the beneficiary, amount, time, transaction identifiers, and reason for suspected fraud.

2. Report through the appropriate law-enforcement path. In the United States, submit a report to FBI IC3 and follow established local or federal contacts. Other jurisdictions have their own reporting routes.

3. Preserve evidence. Retain the original messages, headers, attachments, call details, payment records, account logs, and timeline. Do not rely only on screenshots.

4. Contain affected identities. Disable or restrict accounts as appropriate, revoke sessions and refresh tokens, reset credentials, review authentication methods and devices, and remove unauthorized OAuth grants.

5. Inspect the mailbox and connected systems. Review forwarding, inbox rules, deleted items, delegates, searches, exports, sign-ins, and endpoint telemetry. Determine whether the attacker contacted customers or suppliers.

6. Warn affected counterparties through trusted channels. A compromised mailbox may be used to continue the fraud against others.

7. Escalate internally. Involve finance, security, legal, privacy, insurance, communications, and leadership according to facts, contracts, jurisdiction, and the response plan.

The FBI reported that its Financial Fraud Kill Chain was used in about 3,900 incidents involving $1.164 billion in attempted theft in 2025 and helped freeze approximately $679 million. That 58% ratio is an aggregate program result, not a promised recovery rate. It does show why minutes and hours matter.

After containment, identify the control failures and repair the process. Update simulations and tabletop exercises so the exact exception path, technical gap, or escalation delay is tested again.

Brightside AI: AI-powered spearphishing and BEC training platform

Technical and financial controls depend on people executing them correctly when a request feels plausible. Brightside AI provides the training, simulation, and reporting-practice layer for that part of a BEC prevention program.

Brightside supports email phishing simulations that include business email compromise and AI-powered spearphishing scenarios. Employee profile information can come from supported directory and HR integrations or be entered by an administrator. AI uses that information to select and personalize prebuilt templates that have been created with AI assistance and human review. This allows the exercise to reflect a person's role, company, and likely tools without generating an uncontrolled message from scratch during campaign setup.

That approach can support role-specific BEC exercises. A finance employee can receive a realistic supplier or executive-payment request. Payroll can practice handling a direct-deposit change. An executive assistant can face an authority-and-secrecy pretext. A help-desk employee can be tested on an identity reset. The expected behavior should match the organization's approved workflow, such as opening a case, using a trusted callback record, refusing an exception, or reporting the request.

Email is only one channel. Brightside also supports AI-powered vishing simulations and hybrid scenarios that combine a live voice call with a trackable phishing email. Administrators can design the caller persona, objective, opening, tactics, and targeted information, then preview the call before launch. Hybrid exercises are useful for BEC because attackers often use a second channel to make the first request feel confirmed.

Interactive courses cover spearphishing, vishing, deepfake awareness, and related security topics. When an employee fails a simulation by completing the defined attack goal before reporting it, follow-up training can be triggered automatically. Program teams can review outcomes such as delivered, opened, clicked, credentials entered, and reported, helping them distinguish risky interaction from successful reporting.

The Report Phishing add-on closes part of the practice-to-response loop for Gmail and Google Workspace. Employees can report a selected message from the Gmail side panel. Brightside distinguishes its own training simulations from real reported messages. A reported simulation is credited as a catch, while a real report is routed to the security team with the original message and full headers. The add-on uses least-privilege access to the single email the employee chooses to report.

Brightside sits alongside the controls described in this guide. It provides realistic, repeatable practice across email and voice, reinforces the approved response after mistakes, and makes reporting behavior measurable. Its scope does not include inbound email filtering, identity protection, payment authorization, or real-time employee monitoring.