Cloud email and BEC risk are outpacing legacy security models

At a glance

What this is: This webinar summarises Forrester’s TEI findings on Abnormal Security and argues that cloud-native email security is displacing legacy approaches as BEC pressure rises.

Why it matters: It matters because email compromise now intersects with identity, access, and SOC workload decisions, forcing IAM and security teams to rethink how they govern cloud email and API-connected control planes.

By the numbers:

• SOC analyst hours spent on email security tasks dropped by 95% after deploying Abnormal Security.

👉 Watch Abnormal AI's webinar on Forrester's TEI study of BEC and cloud email security

Context

Business email compromise is no longer just a phishing problem. It is a control problem that sits at the intersection of identity, mailbox access, API permissions, and detection workflows, especially as organisations move to cloud email infrastructure and broader API-enabled security tooling.

The governance gap is that legacy email controls were designed for a slower, perimeter-shaped operating model. As email becomes more cloud-native and more connected through APIs, security teams need clearer ownership of mailbox access, delegated permissions, and the operational boundaries between email security and IAM.

Key questions

Q: How should security teams govern cloud-native email security in BEC-heavy environments?

A: They should govern it as part of identity and privileged access management, not as a standalone message-filtering problem. That means reviewing API scopes, delegated permissions, administrative ownership, and offboarding for every integration that can act on mailboxes. It also means testing for identity abuse patterns such as thread hijacking and impersonation, not only malicious content.

Q: Why do legacy email security controls struggle against modern BEC attacks?

A: Legacy controls were built to inspect message flow, but modern BEC often exploits trusted identity paths, delegated mailbox actions, and reply-chain abuse. Those behaviours can look legitimate at the message layer even when they are harmful. Teams need controls that understand mailbox behaviour and identity context, not only email content.

Q: When should organisations treat email security tools as privileged systems?

A: They should do that whenever the tool can read, move, quarantine, or auto-remediate messages through API access. At that point, the platform can affect business communications and must be governed like a high-trust identity. Ownership, review, and revocation discipline should match other privileged integrations.

Q: What signals show that cloud email security is reducing risk rather than just workload?

A: Look for faster containment of suspicious mail, fewer successful reply-chain fraud attempts, and tighter control over delegated access paths. Analyst time savings matter, but they are not enough on their own. A stronger signal is whether the organisation can prove who can act on mailboxes and why.

Background and context

Why cloud email changes the email security control plane

Cloud email moves enforcement away from a single perimeter device and into service integrations, mailbox APIs, and identity-backed policy decisions. That changes what defenders can observe and what attackers can abuse. In practice, BEC and mailbox compromise are less about one malicious message and more about trusted execution paths that let an attacker imitate or operate as a legitimate user. API-enabled email security, sometimes described as CAPES, shifts inspection and response into the cloud service layer, where it can see behaviour across mailboxes rather than only at the gateway.

Practical implication: map who can grant, revoke, and monitor mailbox-level API access before you rely on cloud-native email controls.

Why legacy email security struggles with modern BEC patterns

Legacy secure email gateways were built for a world where threats arrived through a narrower set of message flows. Modern BEC campaigns exploit identity trust, thread hijacking, impersonation, and delegated access patterns that do not always look malicious at the content layer. That means the control can miss the abuse even when the message itself appears normal. The problem is not that legacy tools see nothing. The problem is that they often see too little of the identity and behavioural context needed to stop the attack before business action is taken.

Practical implication: evaluate whether your email stack can detect identity abuse, not just malicious message content.

What API-based email security changes operationally

API-based email security can inspect mailboxes post-delivery, correlate user behaviour, and trigger remediation after a suspicious action is detected. That operational model is useful because many BEC incidents are only obvious once a message is opened, replied to, or used to redirect payments. The trade-off is governance: if API scopes, delegated permissions, or administrative access are overbroad, the security tool itself becomes another identity surface to manage. CAPES-style controls therefore need the same discipline applied to any privileged integration.

Practical implication: treat email security integrations as privileged identities and review their scopes, ownership, and offboarding controls.

NHI Mgmt Group analysis

Cloud email has turned BEC into an identity governance problem. The article's core signal is not just that attacks are increasing, but that the control surface has moved into mailbox identity, delegated access, and API-connected enforcement. That makes ownership, scope, and offboarding of email security integrations part of IAM and PAM governance, not a separate tooling concern. Practitioners should treat email trust paths as governed identities, not only as message filters.

Legacy email security is being outpaced by a control-plane shift. Gateway-era assumptions break when threat actors abuse cloud-native workflows, threaded conversations, and post-delivery mailbox actions that look legitimate in isolation. The important question is no longer whether a message is suspicious, but whether the platform can see the identity behaviour around that message. Security teams should re-evaluate which controls actually observe the act of trusted abuse.

API-enabled email security creates its own identity surface. Once security depends on cloud permissions and mailbox integrations, the email security layer itself needs lifecycle management, least privilege, and continuous access review. That is a broader programme issue: the tool designed to reduce email risk can expand privileged access if it is not governed like any other non-human identity. Practitioners should fold email security integrations into NHI oversight.

CAPES is a useful concept because it names the architectural shift. Cloud-native, API-enabled email security is not just a deployment choice. It represents a move from perimeter inspection to identity-backed, service-level enforcement, which changes how organisations should measure coverage, response speed, and administrative blast radius. Practitioners should use that lens when deciding whether a legacy stack is still fit for current BEC patterns.

Forrester-style economic validation matters because analyst ROI does not remove governance risk. Cost savings and analyst time reduction can justify change, but they do not answer the harder question of entitlement hygiene, delegated access ownership, or whether the control can withstand identity abuse at scale. Security leaders should separate efficiency evidence from control assurance before approving broad rollout.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why practitioners should pair cloud email controls with stronger lifecycle oversight, as shown in 52 NHI Breaches Analysis.

What this signals

Cloud-native email security is part of a wider NHI governance shift. As mailboxes, security services, and API-backed remediation become more tightly linked, teams should expect privileged integration review to move closer to standard IAM and PAM operating rhythms. The practical question is not whether the platform reduces workload, but whether it reduces exposed trust paths across the email control plane.

1.5 out of 10 organisations are highly confident in securing NHIs, compared with nearly 1 in 4 for human identities, according to The State of Non-Human Identity Security. That gap matters here because cloud email security depends on non-human access paths that many programmes still under-govern. Practitioners should assume email integrations are only as strong as the identity governance around them.

Email security teams should expect governance convergence. The more a platform can automate response through APIs, the more it resembles an identity control surface and the more it needs lifecycle review, entitlement scoping, and offboarding discipline. That is the direction the market is moving, and it favours programmes that can govern tools as identities rather than treat them as isolated appliances.

For practitioners

• Inventory mailbox and security API permissions Document which systems can read, move, quarantine, or remediate mail, and identify every delegated integration that can act on behalf of a user or administrator. Review those permissions on the same schedule as other privileged access.
• Classify email security integrations as privileged identities Assign ownership, business purpose, and offboarding steps for every API-backed email control. If an integration is no longer needed, revoke it with the same discipline used for service accounts and other high-trust access paths.
• Test for identity abuse, not only malicious content Build detection scenarios for thread hijacking, impersonation, reply-chain abuse, and suspicious mailbox actions after delivery. Measure whether the stack can spot legitimate-looking activity that still creates fraud risk.
• Fold email controls into IAM and PAM review cycles Include email security platforms in access recertification, change management, and separation-of-duties reviews. The point is to govern the control plane that protects email, not just the inbox itself.

Key takeaways

• Business email compromise is increasingly an identity and control-plane problem, not only a detection problem.
• The strongest evidence in the webinar is operational as well as financial, with $4 million in prevented losses and a 95% reduction in SOC analyst hours.
• Practitioners should govern email security integrations like privileged identities if they want cloud-native controls to stay inside their intended boundary.

Key terms

• Business Email Compromise: Business email compromise is a fraud pattern where an attacker abuses trusted email communications to redirect payments, impersonate an executive, or influence business decisions. The attack often relies on identity trust rather than malware, which is why mailbox governance and behavioural detection matter.
• Cloud-Native Email Security: Cloud-native email security is a control model that inspects, correlates, and remediates email using cloud service APIs rather than only perimeter gateways. It is effective when teams can govern the privileged integrations and mailbox-level permissions that make those actions possible.
• Delegated Mailbox Access: Delegated mailbox access is permission that lets one identity act on behalf of another identity for email operations such as reading, moving, or responding to messages. It is a high-trust capability because compromise or overreach can turn a security control into an abuse path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: The Total Economic Impact of Abnormal Security. Read the original.