Business email compromise succeeds when attackers combine social engineering with session persistence, OAuth consent abuse, or push fatigue against MFA. Strong controls can still fail if the attack never needs the password alone. In practice, identity assurance depends on limiting app permissions, reducing user approval paths, and watching for abnormal authentication and consent patterns.
Why Strong Identity Controls Still Miss the Real Attack Path
Cloud email security is only as strong as the assumptions behind it. BEC attacks often avoid password theft entirely, so MFA, SSO, and conditional access can all be working as designed while the attacker still gains usable access through consent grants, token replay, or an approved session that looks legitimate.
The practical failure is not usually “identity control absent,” but “identity control scoped too narrowly.” If the control stack verifies a login event but does not sufficiently constrain what a signed-in user, app, or session can do afterward, the attacker can operate inside the trust boundary without ever needing a fresh password challenge.
That is why cloud email environments need stronger control over app permissions, mailbox delegation, session duration, and consent workflows. The issue is not just authentication strength, but the size of the post-authentication attack surface and how much authority a single user approval can silently unlock.
- Ultimate Guide to NHIs is useful here because it frames the broader problem as governance of access-bearing identities, not just login events.
- Top 10 NHI Issues helps connect excessive permissions, visibility gaps, and lifecycle failure to the kind of authority BEC operators exploit after initial access.
- CSA Cloud Controls Matrix gives a broader cloud-control lens for IAM, auditability, and third-party exposure in hosted email environments.
Why Consent Abuse and Session Persistence Beat “Stronger MFA”
Many BEC campaigns succeed because they attack the approval layer, not the password layer. OAuth consent abuse can grant application access without a traditional login event, while session persistence lets a stolen or coerced session remain useful even after the user changes a password or completes MFA again.
Push fatigue attacks exploit the human side of MFA by turning repeated prompts into an acceptance event. Once the user approves one request, the attacker may not need to repeat the same path if the session, refresh token, or delegated permission already provides durable access to mail, contacts, or rules management.
This is why abnormal consent patterns, impossible travel, unfamiliar app grants, mailbox rule creation, and new forwarding destinations matter so much. Those signals often reveal the abuse path earlier than password-reset telemetry, especially when the original authentication event appears clean.
- Storm-2949 Azure Breach is a good example of social engineering turning one identity event into wider tenant compromise.
- Dropbox Sign breach illustrates how API tokens and service-side access can outlive a single user login decision.
- CISA cyber threat advisories provide current adversary tradecraft and campaign context for credential, consent, and session abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | BEC often persists through tokens, consent, and delegated access. |
| NHI-04 — Authorization and Privilege Management | Mailbox and app permissions determine the blast radius after login. | |
| NHI-07 — Lifecycle and Offboarding | Stale grants and sessions let attackers retain access after compromise. | |
| Recommendation — Minimise standing credentials and rotate access-bearing secrets aggressively. Restrict delegated access and enforce least privilege on mail and apps. Revoke stale tokens, grants, and sessions as part of lifecycle control. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Cloud email BEC exploits gaps between authentication and post-login access. |
| Recommendation — Constrain authentication, consent, and access paths to reduce trust abuse. | ||
| CIS Controls v8 | 5 — Account Management | User and app accounts need governed lifecycle and access review. |
| 6 — Access Control Management | Least privilege and approval controls reduce BEC blast radius. | |
| 8 — Audit Log Management | Consent abuse and mailbox rule changes require strong logging and review. | |
| Recommendation — Inventory and review accounts, delegated access, and privileged permissions regularly. Enforce least privilege and limit application consent to approved use cases. Collect and alert on consent grants, forwarding rules, and anomalous sessions. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to Address Risks and Opportunities | Email BEC risk from AI-assisted social engineering and automation needs formal governance. |
| Recommendation — Assess and govern email abuse scenarios as part of organisational AI risk management. | ||
| NIST AI RMF | GOVERN — Govern | Email BEC resilience depends on defined accountability for identity and consent risks. |
| Recommendation — Assign ownership for consent, session, and mailbox abuse controls. | ||
Practitioner Guidance
What to verify: Confirm whether your email stack logs and reviews OAuth grants, mailbox delegation changes, forwarding rule creation, and token-driven access separately from interactive sign-ins. If you only monitor authentication success and failure, you will miss the most common BEC persistence layer.
What to prioritise: Tighten app consent, admin consent, and session lifetime controls before investing in another authentication prompt. The highest leverage is usually reducing what an approved session can do, because that shrinks the blast radius after the attacker gets past the first control.
Common mistake: Treating MFA strength as the end state. For cloud email, the harder problem is governing delegated access and user-approved permissions so that a single compromised approval does not become durable mailbox control.
Practitioner takeaway: BEC keeps bypassing strong identity controls because attackers increasingly target the trust that follows login, not the login itself.
Related resources from NHI Mgmt Group
- Why do identity attacks with normal-looking activity still bypass traditional controls in cloud and SaaS environments?
- Why do legacy MFA and conditional access controls still fail to stop business email compromise in cloud environments?
- Who is accountable when a trusted cloud identity is used for business email compromise?
- Who is accountable when compromised cloud identity is used for business email compromise?
