How to Prevent Business Email Compromise

By Navid Sobbi, Founder and CEO, NSI Global

Executive Summary

Business email compromise succeeds when a fraudulent instruction can pass through a legitimate business process without independent verification. Email filtering matters, but it is not the decisive control. The decisive control is whether one email — even one sent from a genuine account — can change payment details, release funds, disclose sensitive information or override an established approval path.

The Australian Signals Directorate’s Annual Cyber Threat Report 2024–25 identifies email compromise with no financial loss and BEC fraud with financial loss as the two most frequently self-reported cybercrime threats for Australian businesses, at 19 per cent and 15 per cent respectively. Those figures describe reports made to ReportCyber; they are not estimates of the proportion of all Australian businesses affected.

An effective BEC prevention programme therefore combines seven control domains:

1. Transaction governance: define which instructions may never be accepted through email alone.
2. Independent verification: confirm new payees and changes to payment details through a trusted channel.
3. Segregation of duties: separate the ability to change supplier records from the authority to release funds.
4. Identity security: use phishing-resistant multi-factor authentication for high-risk and privileged accounts.
5. Domain and email protection: implement SPF, DKIM and DMARC, understanding what each control can and cannot stop.
6. Mailbox and cloud monitoring: detect suspicious rules, forwarding, access, consent and administrative changes.
7. Incident readiness: make bank escalation, account containment, evidence preservation and reporting executable within minutes.

The governing principle is simple: email may initiate a request, but it should never be sufficient authority to complete a high-risk transaction.

Purpose and Scope

This white paper is intended for boards, executives, finance leaders, procurement teams, legal departments, risk managers and cyber security personnel. It focuses on preventing payment redirection, supplier impersonation, executive impersonation and the misuse of compromised business mailboxes.

It does not repeat the technical investigation methodology required after an incident. That subject is addressed through NSI Global’s ransomware and BEC incident response capability. This paper instead defines the governance, process and technical controls that reduce the probability that a deceptive message becomes an authorised business action.

1. Understand the Two Main BEC Pathways

BEC is sometimes described as a non-technical scam. That description is incomplete. Some attacks depend entirely on impersonation; others begin with a genuine account compromise. The defensive model must account for both.

1.1 Impersonation Without Account Compromise

An attacker may register a lookalike domain, manipulate a display name or send a message that appears to come from an executive, supplier, customer or adviser. The criminal does not need access to the organisation’s systems if the request is plausible and the recipient accepts email as sufficient proof of identity.

Typical requests include changing supplier bank details, making an urgent confidential payment, purchasing gift cards, releasing payroll or tax information, or providing documents that enable a later fraud.

1.2 Misuse of a Genuine Mailbox

An attacker may obtain valid credentials through phishing, information-stealing malware, password reuse or another form of account compromise. Once inside, the attacker can observe real correspondence, learn transaction timing and send from an address the recipient already trusts. Malicious forwarding rules, inbox rules, delegated access or third-party application permissions may be used to retain visibility or conceal replies.

The distinction has an important control consequence. SPF, DKIM and DMARC can reduce exact-domain spoofing, but they will not stop a message sent from a genuinely compromised account. Staff awareness may detect a crude lookalike domain, but it can fail when an attacker enters an authentic conversation at the expected payment point.

2. The Attack Exploits a Business Process, Not Just an Inbox

A BEC attempt becomes a loss only when the organisation’s process converts the message into action. The attacker is looking for a path in which trust, urgency or hierarchy can substitute for verification.

This is why a prevention programme built only around phishing simulation is incomplete. Training may reduce the probability that a person trusts the message, but transaction design determines whether that trust can move money.

3. The Seven-Control Framework

3.1 Establish Transaction Governance

The organisation should identify the workflows in which an email could cause material harm. At a minimum, this includes supplier onboarding, changes to bank details, payment release, payroll changes, refunds, acquisition-related transfers, confidential data disclosure and changes to account recovery information.

For each workflow, management should define:

1. Which roles can request, verify, approve and release the action
2. Which communication channels are accepted for each step
3. The transaction or risk thresholds that require enhanced approval
4. The evidence that must be retained to show verification occurred
5. Who may approve an exception and how that exception is recorded
6. The process for urgent requests when the normal approver is unavailable

The policy must apply to executives as well as employees. A control that can be waived by a senior person’s email is not a control; it is a preference.

3.2 Require Independent Verification of Payment Changes

Any new payee or change to existing payment details should be verified outside the email thread. The verifier should contact the supplier or authorised person using a telephone number, portal or contact record obtained before the change request — not contact information contained in the message or altered invoice.

The Australian Government’s Scamwatch guidance specifically recommends checking changes to payee information and contacting the business by phone using a number sourced independently.

A defensible procedure should require the verifier to record:

1. The identity and role of the person contacted
2. The trusted source used for the contact details
3. The date, time and result of the verification
4. The old and new payment details or other material change
5. The names of the requestor, verifier and approver

For higher-risk payments, organisations may add a risk-based hold period, a second confirmation or bank-provided payee-verification control where available. Those measures support — but do not replace — independent verification.

3.3 Separate Supplier-Master Changes From Payment Release

Two approvals are useful only when they represent independent decisions. If one person can amend the supplier master record and approve the resulting payment, the organisation has preserved the appearance of control while leaving the decisive pathway open.

At minimum:

1. Supplier or payee changes should be performed by an authorised role that cannot release the associated payment alone.
2. The approver should see the verification record, not merely an updated account in the finance system.
3. Emergency or executive-directed payments should remain subject to the same independent verification requirement.
4. Overrides should generate an alert and be reviewed by someone outside the transaction chain.
5. Dormant suppliers, unusual first payments and material deviations from established patterns should receive enhanced scrutiny.

The same principle applies to smaller organisations. Where headcount does not permit fully separate teams, use two identifiable people, a trusted external accountant or another documented compensating control. The control objective is independence, not bureaucracy.

3.4 Use Phishing-Resistant Identity Controls

MFA materially improves account security, but not all methods provide the same resistance to phishing and session theft. ASD’s current guidance on implementing multi-factor authentication recommends phishing-resistant MFA for online services, systems and data repositories.

For BEC risk, organisations should prioritise:

1. Finance, payroll, procurement and executive accounts
2. Email, identity-provider and remote-access administrator accounts
3. Shared mailboxes and service accounts with payment or sensitive-data exposure
4. Accounts able to reset credentials, alter MFA methods or create forwarding and transport rules

Where supported, passkeys, FIDO2 security keys or other phishing-resistant methods should be preferred over SMS or voice-based codes. Legacy authentication that can bypass MFA should be disabled. Administrative accounts should be separate from ordinary email use, and changes to authentication methods should generate alerts.

MFA is a critical account-security control, not a complete BEC control. It cannot stop lookalike-domain impersonation, misuse of an already authenticated session or an employee who voluntarily approves a fraudulent transaction.

3.5 Protect the Domain and Authenticate Email

SPF, DKIM and DMARC work together, but they do different jobs:

ASD’s Information Security Manual email guidance recommends SPF, DKIM and DMARC controls and specifies DMARC rejection for messages that fail the required checks.

Deployment should be managed. Organisations commonly begin with DMARC reporting to discover legitimate senders, then move to quarantine and rejection after authorised mail streams have been validated. All active and parked domains should be considered. Domain registration, renewal and DNS administration should be protected with strong access controls and change monitoring.

These controls reduce exact-domain impersonation and improve visibility. They do not justify treating a successfully authenticated email as proof that a payment instruction is genuine.

3.6 Monitor Mailboxes and Cloud Identity Activity

Prevention should be paired with detection. The monitoring design should reflect the organisation’s email platform, licence, configuration, risk profile and available log retention.

Relevant events may include:

1. New or changed inbox, forwarding and mail-flow rules
2. External forwarding or delegation added to a mailbox
3. Unusual sign-in locations, devices, applications or times
4. New MFA methods, recovery details or privileged-role assignments
5. Suspicious third-party application consent or OAuth grants
6. High-risk administrative actions and changes to audit settings
7. Unexpected message deletion, movement or access patterns
8. Supplier-master changes followed by rapid or unusual payments

Alerts need an owner, an investigation path and an escalation threshold. Generating an alert that no one reviews is not an effective control. Log availability and retention should be tested before an incident, because platform defaults and subscription entitlements may not support the period the organisation assumes.

3.7 Train and Exercise the Business Process

Generic annual phishing training is not enough for people who authorise payments or alter supplier records. High-risk personnel should rehearse the exact situations an attacker will exploit: a CEO asking for secrecy, a supplier changing bank details at the end of a real email chain, a lawyer requesting funds before settlement, or a senior employee asking that normal controls be bypassed.

Training should establish that:

1. Verification is expected, not disrespectful.
2. Urgency and confidentiality do not override payment controls.
3. Staff may pause a transaction without adverse consequence when identity or authority is uncertain.
4. The trusted contact method must be independent of the request.
5. Suspicious messages and near misses are reported immediately.
6. Executives will support employees who enforce the control against them.

Exercises should test finance, procurement, cyber security, legal, communications and executive decision-making together. The objective is to discover where the process fails under pressure before a real attacker does.

4. A Tiered Control Baseline

The required sophistication will vary, but the underlying control objectives do not.

An SME does not need to replicate a large enterprise security stack. It does need to prevent one person, one mailbox and one urgent request from controlling an irreversible payment.

5. A 90-Day Implementation Roadmap

Days 1–30: Close the Direct Payment Path

1. Prohibit acceptance of new payees and changed bank details by email alone.
2. Establish a trusted supplier-contact register and an evidence field for verification.
3. Define transaction thresholds, approval roles and exception authority.
4. Enable MFA on email and administrative accounts; prioritise high-risk users for phishing-resistant methods.
5. Review current forwarding, inbox and mail-flow rules for unauthorised settings.
6. Confirm the bank’s fraud escalation number and internal incident contacts.

Days 31–60: Strengthen Identity, Domain and Monitoring Controls

1. Validate SPF and DKIM across authorised sending services.
2. Analyse DMARC reports and progress towards quarantine or rejection without disrupting legitimate mail.
3. Disable legacy authentication and separate privileged accounts from routine email use.
4. Configure alerts for forwarding, suspicious sign-ins, authentication changes, delegated access and risky application consent.
5. Review log coverage and retention against the time required to discover and investigate an incident.
6. Test segregation between supplier-master changes, approval and payment release.

Days 61–90: Exercise and Measure the System

1. Run a realistic payment-redirection exercise involving finance, procurement, executives and cyber security.
2. Test whether staff use independently sourced contact details under time pressure.
3. Verify that alerts reach a named owner and produce an auditable response.
4. Rehearse bank notification, account containment, legal escalation and evidence preservation.
5. Communicate the verification protocol to key suppliers and professional advisers.
6. Report control coverage, exceptions and remediation actions to executive management or the board risk committee.

6. What to Do if a BEC Attempt Succeeds

Speed matters, but an improvised response can create a second problem. If funds have been transferred or an account may be compromised:

1. Contact the financial institution immediately using its official number and request urgent fraud escalation, recall or transaction intervention. ASD’s BEC recovery guidance makes bank contact the first step when funds have been sent.
2. Contact the genuine supplier, customer or executive through a trusted channel to stop further payments and establish which communications are authentic.
3. Secure the affected identity by revoking sessions, changing credentials, reviewing authentication and recovery methods, and removing unauthorised access under a documented response plan.
4. Preserve the available record including original messages and headers, invoice versions, account rules, forwarding settings, relevant audit logs, payment records and a chronology of response actions.
5. Assess legal, privacy, contractual, insurance and regulatory obligations. A mailbox compromise involving personal information may require an assessment under the Notifiable Data Breaches scheme; the conclusion depends on the facts and applicable law.
6. Report the incident through ReportCyber and follow law-enforcement or sector-specific reporting pathways that apply.
7. Use a trusted communication channel for the response team. Do not coordinate the investigation through a mailbox that may remain accessible to the attacker.

NSI Global’s digital forensic services can support authorised investigation and evidence preservation where account compromise is suspected. The investigative scope — including cloud logs, mailbox configuration, messages and relevant endpoints — should be defined separately from the prevention programme.

7. Governance and Performance Measures

Boards and executives do not need a list of every email-security setting. They do need evidence that the transaction and identity controls are operating.

Useful measures include:

1. Percentage of new payees and payment-detail changes with documented independent verification
2. Number and value of transactions processed under an exception or override
3. Percentage of high-risk and privileged accounts using phishing-resistant MFA
4. Coverage of SPF, DKIM and enforced DMARC across active and parked domains
5. Number of unauthorised forwarding, delegation or application-consent events detected
6. Time from suspicious activity to account containment
7. Time from fraudulent payment discovery to bank notification
8. Availability and tested retention of the logs required for investigation
9. Results of payment-redirection exercises and completion of corrective actions

Metrics should be interpreted together. A low number of reported suspicious emails may indicate low attack volume; it may also indicate that staff do not recognise or report them. A high MFA coverage figure says little if administrators or legacy protocols remain exempt.

Questions the Board Should Ask

1. Can any employee or executive change payment details by email alone?
2. How are trusted supplier contact details established and protected from unauthorised change?
3. Who can alter supplier records, and can the same person release the payment?
4. Which email, finance and administrative accounts are not yet protected by phishing-resistant MFA?
5. Is DMARC enforced across every domain the organisation owns, including parked domains?
6. Who reviews alerts for forwarding rules, new application consent and unusual access?
7. How long are the relevant logs retained, and has retrieval been tested?
8. What is the exact first-hour procedure if a payment is misdirected?
9. When was the complete process last exercised under realistic conditions?

Conclusion

BEC is not prevented by asking employees to look more carefully at email. Skilled attackers can use a genuine mailbox, a familiar invoice and the expected timing of a real transaction. The organisation must assume that a convincing message will eventually reach the right person.

The durable defence is to design the surrounding process so that the message cannot act alone. Independent verification, segregated authority, phishing-resistant identity controls, domain protection, monitored cloud activity and a rehearsed response turn BEC from an individual judgement problem into a governed business risk.

NSI Global can assess the technical and procedural controls surrounding email, identity and incident response through its cyber security consultation services. Where an incident is already suspected, the priority changes to protecting funds, containing access and preserving the available evidence.

For a confidential discussion, contact NSI Global.

Frequently Asked Questions

Does MFA Stop Business Email Compromise?

MFA makes account takeover more difficult, particularly when phishing-resistant methods are used. It does not stop lookalike-domain impersonation, misuse of an already authenticated session or a fraudulent instruction that an employee voluntarily approves. MFA must sit beside transaction verification and monitoring.

Does DMARC Stop Business Email Compromise?

DMARC reduces the misuse of an organisation’s exact domain when the message fails the required alignment and authentication checks. It does not stop lookalike domains or messages sent from a genuine compromised account. It is an important domain control, not a complete BEC solution.

Is a Two-Person Payment Approval Sufficient?

Not necessarily. If both approvers rely on the same fraudulent email, the second approval may simply repeat the first error. At least one person should independently verify the payee or change through a trusted channel, and the ability to alter supplier records should be separated from payment release wherever practicable.

Should a Compromised Mailbox Be Deleted or Rebuilt Immediately?

The account should be contained promptly, but destructive action should be coordinated. Relevant logs, messages, rules, configuration and response actions may be needed to determine scope and meet legal, privacy, insurance or regulatory requirements. Preserve what can be captured safely, record the changes made and use a separate trusted channel to coordinate the response.

Sources and Further Reading

Research for this paper prioritised current Australian Government guidance and primary regulatory material available at the research cut-off. Platform capabilities, licence entitlements and regulatory requirements should be revalidated when the paper is updated or applied to a specific organisation.

1. ASD Annual Cyber Threat Report 2024–25
2. ASD: Preventing business email compromise
3. ASD Information Security Manual: Guidelines for email
4. ASD: Implementing multi-factor authentication
5. Scamwatch: Business email compromise scams
6. OAIC: Responding to data breaches — four key steps