How can organisations reduce BEC risk without slowing legitimate work?

Why This Matters for Security Teams

Business email compromise works because it targets trust, not malware. Attackers pressure finance, procurement, and executives into approving payments, changing bank details, or releasing sensitive data through channels that look routine. If every request gets the same friction, teams either slow the business down or create workarounds. The practical challenge is to add verification where money, privilege, or reputation is at stake without turning ordinary operations into a queue. Guidance in the NIST Cybersecurity Framework 2.0 supports risk-based controls, and NHIMG research shows how often identity weaknesses are already present in real environments. In the Ultimate Guide to NHIs, 79% of organisations reported secrets leaks, with 77% of those incidents causing tangible damage. In practice, many security teams encounter BEC only after a payment or account change has already been approved under pressure, rather than through intentional testing of the approval path.

How It Works in Practice

The most effective pattern is to make verification proportional to risk. Routine work should stay fast, while high-impact actions trigger stronger checks based on transaction value, destination, urgency, requester history, and channel anomalies. This is not about rejecting every unusual request. It is about making it harder to fake a trusted workflow when the consequence is financial loss. The Top 10 NHI Issues and the 2024 ESG Report: Managing Non-Human Identities both reinforce a simple lesson: excessive trust and weak governance create avoidable exposure. In BEC prevention, that usually means layered validation rather than blanket controls.

• Require out-of-band confirmation for bank-detail changes, large payments, and gift card or wire requests.
• Use step-up approval for exceptions, such as urgent requests outside normal hours or requests involving new recipients.
• Separate request initiation from approval, so one compromised inbox cannot complete the full workflow.
• Log and review high-risk approvals for patterns such as repeated urgency, domain lookalikes, or unusual device locations.
• Preserve low-friction paths for low-risk work so users do not route around controls.

This approach aligns with the direction of current guidance: evaluate the context of the request, not just the identity of the requester. It also reflects the broader principle in the NIST Cybersecurity Framework 2.0 that protective measures should be risk-informed and adaptable. Teams often pair that with playbooks for invoice fraud, payroll redirection, and executive impersonation, because those workflows fail differently. These controls tend to break down when approvals rely on a single mailbox, a single approver, or a shared exception path because attackers only need one convincing message to bypass the rest.

Common Variations and Edge Cases

Tighter verification often increases operational overhead, requiring organisations to balance fraud prevention against speed, staffing, and user experience. That tradeoff is real, especially in finance teams that process high volumes of legitimate exceptions. Best practice is evolving, but one point is clear: controls should scale with exposure, not with annoyance. A low-value internal reimbursement does not need the same friction as a first-time vendor bank change, and a payroll correction deserves different treatment from a routine invoice.

Two edge cases matter most. First, executive requests can bypass normal skepticism because staff assume authority equals legitimacy. Second, attacker campaigns often chain email compromise with callback spoofing, invoice tampering, or supplier impersonation, which means a single control is rarely enough. Organisations should document which actions always require extra verification and which only trigger it when risk indicators stack up. Where there is no universal standard for this yet, current guidance suggests using clear thresholds, pre-approved escalation paths, and separation of duties that is difficult to override casually. The NHI lesson is relevant here: when access paths become too broad or too reusable, attackers exploit the process, not just the account.

Related resources from NHI Mgmt Group

• How can organisations reduce production access risk without slowing incident response?
• How can organisations reduce shadow AI risk without slowing adoption?
• How can organisations reduce third-party identity risk without slowing operations?
• How can organisations reduce jailbreak risk without slowing AI adoption?