BEC exploits trust, not only technology
Business email compromise (BEC), including executive-impersonation scenarios, makes a request look as if it came from a leader, supplier, or trusted partner. The message may ask for a wire transfer, a bank-detail change, a document, or temporary access.
The attack works because the request feels plausible and urgent. The attacker does not necessarily need to decrypt a vault or guess a password: the goal is to influence the person who can authorize the action.
Three common scenarios
- The executive who is “travelling.” Finance receives a request to complete a confidential transaction quickly, with a warning not to call.
- The supplier whose bank details changed. A real invoice is copied into a credible conversation, then the account details are replaced.
- The lookalike account or domain. A compromised mailbox or near-identical address makes the exchange appear routine.
These scenarios can be combined. An initial reconnaissance message identifies roles, signatures, and habits; the financial request follows with the right vocabulary and timing.
Why passwords are not enough
A strong password protects an account. It cannot, by itself, determine whether a payment request is legitimate. The risk then moves to email, leadership accounts, accounting tools, and secrets shared across several people.
Critical access therefore needs several barriers:
- Unique secrets. Finance or administration accounts should not reuse passwords from other services. Use a secure password generator and keep secrets in a controlled vault.
- Out-of-band verification. For a new bank account, unusual payment, or urgent request, call a number already on file or use a separate internal channel.
- Separation of duties. The person receiving the request should not be the only person approving and executing the payment.
- Limited access. Finance, procurement, HR, and leadership accounts should have only the permissions they need, with regular access reviews.
This is the same principle behind secure team password sharing: sharing a secret does not mean copying it into email, a spreadsheet, or an untraceable chat.
A short checklist for teams
Before approving a sensitive request, ask four questions:
- Who is asking? The displayed address and familiar tone do not authenticate a person.
- What changed? A new bank account, beneficiary, account, or document deserves verification.
- What is the second channel? Confirm through contact details already on file, never through the message itself.
- Who checks it? A second person reviews and approves the operation according to the procedure.
For finance and procurement, keep evidence of that verification. For HR, apply the same caution to requests for documents or personal data. For leadership, make it explicit that urgency never justifies bypassing the control.
After a mistake: contain, understand, rotate secrets
If a fraudulent request was followed, immediately contact the bank and responsible people, preserve the messages, and review forwarding rules or active sessions on the affected account. Do not delete material that may help the investigation.
Then change exposed secrets, including any that were reused elsewhere. Rotation should happen in an encrypted vault and according to a known procedure, not inside a rushed chat thread. Finally, turn the incident into an operational rule: which requests trigger a call, who approves, and where is the evidence kept?
BEC points to a simple rule: the identity displayed in a message is not proof of identity. Security depends on an organization that can slow the request at the right moment, keep secrets under control, and verify through an independent path.
