Secure email gateways are not enough for identity-based attacks

At a glance

What this is: This article argues that secure email gateways are useful front-line controls, but they do not stop identity-based abuse once an email account is already compromised.

Why it matters: IAM, IGA, and email security teams need to treat mailbox compromise as an identity problem, not just a filtering problem, because trusted accounts can bypass perimeter controls from inside cloud email.

Context

Secure email gateways sit in front of cloud email systems to inspect inbound and outbound messages before delivery. That model works for malicious content, spoofing, and obvious phishing, but it does not change the trust granted to an already authenticated user inside Microsoft 365 or Google Workspace.

The governance gap is lifecycle, not mail flow. If an account is compromised, overprivileged, or left active after a role change, attackers can send trusted messages and operate within the tenant even when the gateway does its job.

For identity programmes, the key question is not whether the gateway blocks bad email, but whether access reviews, offboarding, and role alignment prevent compromised identities from becoming an internal launch point.

Key questions

Q: What breaks when organisations rely only on legacy secure email gateways?

A: They miss attacks that do not depend on obvious malware or malicious links, such as BEC, spoofing and contextual manipulation. Gateway models are strongest at known bad content at the perimeter, but weaker at mailbox-level abuse, post-delivery threats and user-directed fraud. That leaves a large exposure window open.

Q: Why do compromised email accounts still create business email compromise risk?

A: Because once an attacker controls a valid mailbox, the messages often look legitimate to users and to some security tools. The attacker no longer needs to impersonate from outside the system. That is why account takeover, delegated access, and lifecycle gaps are the real drivers of business email compromise in cloud email environments.

Q: How should security teams govern mailbox access in cloud email platforms?

A: Use lifecycle governance for every mailbox, shared mailbox, and delegated access path. Recertify high-risk entitlements, remove inactive access, and tie offboarding to identity removal rather than leaving accounts available by default. That keeps email from becoming a durable internal trust channel after a role change or compromise.

Q: What signs show that email identity controls are not keeping pace?

A: Watch for stale shared mailboxes, persistent delegated send permissions, accounts that remain active after role change, and alerts that show unusual sending behaviour from trusted identities. Those signals usually mean the organisation is protecting the inbox but not the identity behind it.

Technical breakdown

Why secure email gateways stop at the message boundary

A secure email gateway filters mail before delivery, using sender reputation, content inspection, URL analysis, attachment sandboxing, and policy checks. That architecture is effective for blocking malicious messages at the perimeter, but it does not govern what happens after a user authenticates to the mailbox. Once delivery occurs, the gateway no longer decides whether the identity can send mail, access data, or act on behalf of the organisation. In cloud email, the mailbox is part of a broader identity plane, so message-layer inspection and account governance solve different problems.

Practical implication: treat gateway coverage as mail filtering, not as a substitute for identity control inside the tenant.

How compromised cloud email identities bypass perimeter inspection

When an attacker gains access to a Microsoft 365 or Google Workspace account, they can operate from inside the trusted boundary. That means internal sending, reply-chain abuse, and account takeover driven fraud no longer depend on getting a malicious message past the gateway. The email security problem shifts from pre-delivery detection to post-authentication abuse, where the organisation is trusting a live identity that now belongs to the attacker. In practice, this is why compromised accounts often produce business email compromise and internal impersonation even when the gateway is functioning correctly.

Practical implication: pair gateway controls with account-takeover detection, access governance, and high-risk identity monitoring.

Why identity governance changes the control model for email security

Identity governance adds the lifecycle and entitlement layer that gateways do not cover. Access reviews identify stale or overprivileged mailbox access, and offboarding removes accounts before they become durable attack paths. That matters because email is an identity service as much as a communications service: if the identity remains valid, the attacker can continue using legitimate infrastructure to send trusted messages, access shared mailboxes, or abuse delegated permissions. The control objective is no longer only to block bad mail, but to keep compromised or inactive identities from remaining usable.

Practical implication: enforce joiner-mover-leaver discipline and entitlement review for every mailbox, shared account, and delegated access path.

NHI Mgmt Group analysis

Email security is an identity governance problem once attackers get inside the tenant. Secure email gateways can reduce inbound phishing risk, but they cannot invalidate a compromised mailbox or revoke a trusted sender relationship already in use. That means the organisation’s real control boundary is the identity lifecycle, not the gateway queue. The practitioner conclusion is straightforward: mailbox abuse must be governed as an IAM and IGA failure, not only as a content-filtering event.

Gateway-only thinking creates a false sense of closure around BEC and impersonation risk. The article’s core tension is that the same control that blocks spam can still leave trusted identities fully exploitable after authentication. That is the control gap that matters in cloud email, where identity is the enforcement point for persistence, delegation, and internal trust. The practitioner conclusion is to measure email security by what remains possible after account compromise, not by inbox filtering rates alone.

Access reviews are the decisive control for overprivileged mailbox access, but only if they cover delegated and shared identities. The article correctly points to lifecycle management, yet the deeper issue is that identity sprawl in email systems creates durable abuse paths that perimeter tools never see. Shared mailboxes, service-linked accounts, and stale delegated permissions extend the attacker’s window even when a gateway is active. The practitioner conclusion is to govern every mailbox-adjacent entitlement as part of the identity estate.

Identity-based email abuse validates layered control design, not gateway replacement. This topic is not a verdict against secure email gateways. It is a reminder that the email stack has two distinct control planes: message inspection before delivery and identity governance after authentication. Organisations that collapse those planes into one tool choice will miss the attack path that starts with credential or account compromise and ends with trusted internal communication. The practitioner conclusion is to align security ownership across email, IAM, and IGA teams.

What this signals

Mailbox security has to be measured as an identity programme, not a perimeter programme. The practical test is whether a compromised account can still send trusted mail, inherit delegated rights, or remain active after a role change. That is where secure email gateways stop and lifecycle governance starts.

For IAM and IGA teams, the operational shift is to treat email identities like any other privileged access path. If entitlement review, offboarding, and delegation governance do not cover cloud mailboxes, the organisation is leaving a trusted internal channel open to account takeover abuse.

For practitioners

• Align email controls with identity lifecycle Map every mailbox, shared mailbox, and delegated access path to joiner-mover-leaver processes so stale identities are removed when roles change.
• Review overprivileged mailbox access Recertify who can send as, send on behalf of, or access sensitive mailboxes, and remove dormant entitlements that outlive the user’s role.
• Add post-authentication detection Complement gateway filtering with alerts for unusual sending patterns, impossible travel, delegated mailbox abuse, and account takeover indicators inside Microsoft 365 or Google Workspace.
• Govern shared and service-linked identities Treat shared mailboxes and service-linked accounts as governed identities with owners, review dates, and clear offboarding triggers rather than permanent utilities.

Key takeaways

• Secure email gateways reduce phishing exposure, but they do not solve the identity abuse that follows a mailbox compromise.
• The core evidence in the article is that cloud email tenants can still be abused from inside the trusted boundary after authentication.
• The control that changes the outcome is identity governance over mailbox lifecycle, delegated access, and overprivileged accounts.

Key terms

• Secure Email Gateway: A secure email gateway is a control layer that inspects email before it reaches users and can also inspect outbound mail. It filters malicious content, enforces policy, and reduces exposure to phishing, malware, and data leakage, but it does not replace identity governance or account monitoring.
• Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
• Email Identity Governance: Email identity governance is the discipline of managing who can assert trust on behalf of an organisation through domains, logos, and authentication policies. It connects branding choices to security controls, so inbox trust signals do not drift away from the underlying sender identity.

Deepen your knowledge

NHI governance, identity lifecycle, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.