Major events create a flood of legitimate messages, urgent exceptions, and unfamiliar process changes, which lowers employee suspicion and raises the chance of approval errors. Attackers use that noise to imitate executives, vendors, and service providers. Even valid sender addresses do not guarantee safety, because compromised accounts can still send convincing fraudulent requests.
Why major events make BEC more persuasive
business email compromise works better when the organisation is already expecting unusual requests, high-volume communication, and fast decisions. Major business events create exactly that environment. Procurement, finance, legal, HR, and executive assistants are more likely to see messages that look urgent, routine, and legitimate, so the attacker’s request blends into the day’s normal operating noise.
That context matters because BEC rarely depends on technical sophistication alone. It depends on social timing, process pressure, and the receiver’s willingness to treat an exception as part of the event. A request that would look suspicious in an ordinary week can seem acceptable during a merger, earnings cycle, holiday period, board meeting, or vendor transition, especially when staff are already handling exception-heavy workflows.
Major events also change the attacker’s camouflage options. They can impersonate known executives, counsel, suppliers, payment partners, or event-related service providers, and they can reference real internal activities to make the message feel anchored in the moment. Even when the sender address looks valid, that can still be misleading if the account or mailbox has been compromised and is now being used to send convincing fraudulent instructions.
What changes in the approval process during event-driven noise
During major events, normal review patterns often weaken in predictable ways. Approvers may be travelling, delegating more often, working across time zones, or operating under compressed deadlines. That increases the chance that a request is approved because it feels expected, not because the underlying payment, change, or data request was independently verified.
The practical problem is not only message volume, but process drift. Teams start bypassing verification steps they would normally use, such as call-back confirmation, second-person review, or validation against a known workflow. Once those controls are treated as slow rather than necessary, BEC becomes much easier because the attacker needs only one rushed approval path to succeed.
Event-driven change also creates believable pretexts. New vendors, temporary accounts, project codes, invoice templates, and exception workflows give attackers more room to mimic the language of the business. A well-timed fraudulent request can look like a routine adjustment rather than an intrusion, which is why BEC campaigns often succeed by exploiting business realism, not just email spoofing.
Why valid addresses and familiar names are not enough
One of the most dangerous assumptions in BEC is that a familiar sender means a safe request. A legitimate address can belong to a compromised account, a hijacked mailbox, or an internal user whose credentials were stolen earlier. Once that account is abused, the attacker inherits the trust already attached to the identity and can continue the conversation inside an existing thread.
That is why defenders should think in terms of request legitimacy, not sender legitimacy. Verification needs to cover the instruction itself, the payment destination, the business context, and the approval route. If any of those elements changed unexpectedly during a major event, the message deserves extra scrutiny even when it appears to come from a known person or partner.
For broader background on how real-world fraud and compromise cases evolve, see The 52 NHI Breaches Report, which includes examples of credential abuse, lateral movement, and account compromise patterns that also support email-enabled fraud. Event-driven impersonation can escalate quickly, as shown in Arup deepfake fraud 2024, where executive impersonation helped drive a large payment loss.
Risk and Threat Considerations
Major events do more than increase message volume. They raise the probability that a fraudulent request will be treated as a business exception, and that shift creates a direct path to payment diversion, data disclosure, or account abuse. The threat is strongest when the organisation expects urgency, temporary process changes, or executive involvement.
Failure mechanism: Attackers exploit event-driven urgency and familiarity to bypass normal verification, often by abusing compromised accounts, trusted vendors, or realistic internal context.
Impact: The result can be fraudulent transfer approvals, exposure of sensitive information, or a foothold for further compromise through a trusted communication channel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | BEC often begins with deceptive email delivery and social engineering. |
| T1078 — Valid Accounts | BEC frequently abuses compromised legitimate mailboxes or accounts. | |
| Recommendation — Map suspicious mail to phishing tradecraft and tighten detection for impersonation and lure content. Hunt for use of valid accounts in suspicious approval and payment workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | BEC risk rises when account compromise or mailbox abuse is not tightly controlled. |
| CIS-14 — Security Awareness and Skills Training | BEC exploits urgency, impersonation, and exception pressure on staff. | |
| Recommendation — Restrict and review account access paths that can be abused for fraudulent requests. Train staff to verify high-value requests through a separate trusted channel. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Request validation depends on strong identity and access controls around communication channels. |
| Recommendation — Enforce strong identity checks for email and approval workflows before authorizing transfers. | ||
Practitioner Guidance
What to verify: Treat event-related payment changes, bank detail updates, and exception approvals as high-risk until a separate channel confirms the request, the amount, and the destination. If the request references a real event, verify the business need independently rather than relying on the message thread.
Decision rule: If a request arrives during a major event and asks for urgency, secrecy, or process bypass, assume elevated BEC risk and require an out-of-band approval step before any action is taken.
Practitioner takeaway: BEC becomes more effective during major events because the business itself becomes noisier and less predictable, so the safest control is to verify the transaction path, not the apparent legitimacy of the sender.
Related resources from NHI Mgmt Group
- Why do business email compromise attacks create so much risk during bank account changes?
- Why are vendor email compromise attacks so effective in large enterprises?
- Why do business email compromise attacks succeed even in well-run organisations?
- Why do business email compromise attacks work so well in retail?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
