Why do phishing and BEC remain identity risks even when email controls are in place?

Why This Matters for Security Teams

Phishing and business email compromise persist because the control problem is broader than inbox filtering. Even strong spam detection, sandboxing, and DMARC tuning do not stop an attacker from convincing a person to approve a payment, disclose a one-time code, reset a password, or grant delegated access. That makes email a trust-exploitation problem as much as a content-security problem. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity, detection, and response as connected outcomes rather than separate tools.

The practical risk is that the initial compromise often lands in a place security tooling does not fully own: user judgment, help desk workflows, finance approvals, or SaaS consent screens. Attackers exploit urgency, impersonation, and business context to turn a single message into token theft, mailbox rules, invoice redirection, or lateral movement into cloud identity systems. In practice, many security teams encounter the fraud only after the recipient has already authenticated the attacker, rather than through intentional prevention.

How It Works in Practice

Phishing and BEC succeed when the attacker can use a believable message to trigger an identity action. That action may be a password reset, MFA approval, OAuth consent grant, mailbox forwarding rule, or a reply that authorises a financial change. Email controls reduce volume and improve inspection, but they rarely prove that a request is legitimate. That is why current guidance suggests pairing message security with identity verification, transaction verification, and privilege controls.

Operationally, defenders should treat email as one signal in a broader control chain:

• Harden mailbox authentication with SPF, DKIM, and DMARC, but monitor failures and lookalike domains as an active attack surface.
• Require out-of-band verification for payments, banking detail changes, password resets, and delegate access requests.
• Reduce standing privilege so a compromised mailbox cannot easily create forwarding rules, add delegates, or approve high-risk SaaS consents.
• Correlate email events with identity telemetry, such as impossible travel, risky sign-ins, MFA resets, and new device enrollment.

Alignment with NIST SP 800-53 Rev 5 Security and Privacy Controls is especially relevant because it connects access control, audit logging, incident response, and authentication safeguards into one implementable set of outcomes. For organisations using cloud collaboration suites, the same logic applies to consent governance and mailbox rule monitoring. These controls tend to break down in high-velocity finance and executive-support environments because attackers exploit exception handling, informal approvals, and overloaded service desks.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance fraud resistance against executive convenience and operational speed. That tradeoff is real, especially where assistants, treasury teams, and external counsel legitimately move sensitive requests through email.

Best practice is evolving for several edge cases. For example, not every phishing campaign aims for immediate credential theft; some aim to harvest replies, then build enough context for a later invoice scam or vendor impersonation. In other cases, a mailbox compromise is secondary to session theft after the user approves a malicious prompt or re-authenticates on a convincing fake page. There is no universal standard for perfectly detecting these social-engineering chains from email signals alone.

The identity bridge matters here. When email abuse leads to password resets, MFA changes, delegated mailbox access, or OAuth app approvals, the incident becomes an IAM and NHI governance issue, not just a messaging problem. That is why detection should include abnormal consent grants, privileged mailbox actions, and service desk reset patterns, not only malicious content scoring. Security teams should also review whether approval workflows are tied to the right human identity, because a compromised assistant account can become a proxy for the executive it supports.

Related resources from NHI Mgmt Group

• How do security teams prioritise phishing controls across email, identity, and SaaS?
• Why do healthcare organisations remain vulnerable even with email security tools in place?
• Why do phishing attacks remain effective even with secure email gateways?
• Why do socially engineered attacks remain effective even when email filtering is in place?