Legacy email gateways miss modern phishing and data exfiltration

At a glance

What this is: A European manufacturer used a Proofpoint proof of concept to show that a legacy secure email gateway was missing threats and failing to expose risky outbound email behavior.

Why it matters: For IAM, PAM, and identity governance teams, the lesson is that email security now intersects with identity-led data loss, user behaviour, and cloud access patterns, not just inbound phishing defence.

By the numbers:

• 17 minutes
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, making poorly scoped access 4.5x more likely to lead to a security incident.

👉 Read Proofpoint’s analysis of modern email protection behind Microsoft 365

Context

Email security failures now show up as both inbound compromise and outbound leakage. In this case, the problem was not just whether phishing reached inboxes, but whether the security stack could detect malicious delivery patterns and risky user behaviour inside Microsoft 365. That makes the issue relevant to identity governance because email accounts remain a high-trust access channel for people, service flows, and business processes.

The manufacturer’s starting point is increasingly typical: a legacy secure email gateway in front of Microsoft 365, manual cleanup after suspicious messages arrive, and limited visibility into what users send out of the organisation. What changed here was the proof that a cloud-native, API-based model could expose gaps that the perimeter model left hidden.

Key questions

Q: What fails when email security still depends on a legacy gateway in Microsoft 365?

A: A legacy gateway can miss threats that only become obvious after delivery, such as impersonation, delayed links, and no-payload BEC. When that happens, security teams shift from prevention to mailbox cleanup, which increases exposure time and weakens confidence in the control stack.

Q: Why do phishing attacks remain effective even with secure email gateways?

A: Because gateways inspect messages, not human decisions or downstream identity behaviour. Attackers exploit urgency, trusted brands, and business context, then move from the email channel into login, consent, or session abuse. A filter can reduce volume, but it cannot fully eliminate user interaction with a convincing lure.

Q: How do security teams know whether email DLP is finding real exposure?

A: They should look for user behaviours that indicate data leaving normal boundaries, such as sensitive files sent to personal accounts or unapproved external mailboxes. A useful program tracks those events over time and shows whether policy changes actually reduce them.

Q: Who is accountable when risky email behaviour persists despite detection tools?

A: Accountability sits with the teams that own email governance, data protection, and identity policy, because the control failure is usually a mismatch between approved access and real user behaviour. Frameworks such as NIST CSF and NIST SP 800-53 expect organisations to validate that controls are working in practice, not just installed.

Technical breakdown

Why secure email gateways miss modern phishing

Traditional secure email gateways are strongest when threats are easy to classify before delivery. Modern phishing often avoids that model by using benign-looking URLs, delayed activation, HTML wrappers, impersonation, and business email compromise that contains no malware payload at all. That means the control is forced to judge content with incomplete signals. Once email lands in the mailbox, the attacker is already inside the user’s trust boundary, and response becomes a cleanup exercise instead of a prevention exercise.

Practical implication: teams should test whether their email controls still rely on pre-delivery reputation and static indicators alone.

How API-based email protection changes the control point

API-based email protection works after mail reaches the cloud email platform, which allows the security layer to inspect, quarantine, or remove messages already delivered to users. That changes the operational model from perimeter screening to mailbox-level enforcement. It also lets defenders act on suspicious messages retroactively, which matters when attackers use lures that become malicious after delivery. In Microsoft 365 environments, this reduces dependence on mail flow redesign and makes post-delivery response a first-class control.

Practical implication: evaluate whether your architecture supports mailbox-level remediation without changing MX routing.

Why outbound email DLP belongs in the same control plane

Outbound data protection matters because email is not only an attack vector, it is also an exfiltration path. Adaptive email DLP monitors what leaves the organisation and can surface behaviours such as sending sensitive files to personal accounts, external partners, or unsanctioned mailboxes. That visibility is a governance issue as much as a data security issue, because it reveals where policy, user behaviour, and actual data handling diverge. In practice, inbound and outbound controls need to be treated as one workflow, not separate problems.

Practical implication: add outbound DLP to the same review cycle as phishing detection and incident response.

Threat narrative

Attacker objective: The attacker aims to convert trusted email access into credential theft, business email compromise, or sensitive data exposure.

1. Entry occurs through socially engineered emails, impersonation, delayed-detonation links, or other messages designed to reach the mailbox without triggering classic gateway filters.
2. Escalation happens when the user clicks, replies, or shares data, giving the attacker a trusted communication channel and a foothold inside the Microsoft 365 environment.
3. Impact is inbox compromise, manual cleanup, and potential data exfiltration through risky outbound email or document sharing.

NHI Mgmt Group analysis

Perimeter email filtering is no longer enough: the control model assumed the dangerous message could be identified before delivery, but modern phishing often becomes dangerous only after it lands. That creates a governance gap between detection and user exposure, especially in Microsoft 365 where email is deeply embedded in daily work. Practitioners should treat post-delivery remediation as a core requirement, not an optional add-on.

Email security is now a data security problem, not only a threat problem: the discovery of employees emailing sensitive documents to personal accounts shows how outbound leakage can sit hidden behind a healthy-looking inbox dashboard. This is the same structural issue seen in many identity-led environments, where the account is trusted but the behaviour is not. The named concept here is the mailbox trust gap, where access to a legitimate mailbox masks risky or noncompliant use of that access.

Legacy stack confidence is often a reporting illusion: when a secure email gateway presents completion status while hundreds of threats still land daily, the issue is not just missed detections but false operational reassurance. Security leaders should question whether their controls are measuring inbox hygiene or real threat interruption. The practitioner conclusion is to validate control efficacy against live traffic, not dashboard completeness.

Cloud-native email controls fit the way attackers operate now: the relevant architectural shift is from protecting the mail perimeter to governing activity inside the productivity platform. That does not remove the need for broader identity governance, but it does mean email security, user behaviour, and data leakage are increasingly one control problem. Teams should align email protection with identity-aware data governance rather than treat it as a standalone gateway decision.

What this signals

Mailbox trust gap: email programmes increasingly fail at the boundary between legitimate access and illegitimate use, which is why the control conversation has moved from inbox filtering to behaviour and data flow. For practitioners, the signal is clear: if you cannot see what leaves the tenant as well as what enters it, you do not have full email security.

The practical next step is to align email controls with broader identity and data governance, including mailbox-level response, outbound policy review, and user behaviour monitoring. That is where the environment starts to resemble modern identity governance rather than a static security gateway.

Teams that run Microsoft 365 should treat this as a test of control validity, not a product comparison exercise. The right question is whether the current stack can prove it reduces exposure in live traffic, using evidence that stands up in incident review and board reporting.

For practitioners

• Test post-delivery remediation against live mailbox traffic Run a controlled evaluation that measures whether suspicious emails can be removed after delivery inside Microsoft 365, not just blocked at the perimeter. Compare the outcome to your current secure email gateway and document how many threats require manual cleanup.
• Measure outbound data exposure in the email channel Review how often users send sensitive documents to personal accounts, external addresses, or unsanctioned mailboxes. Treat those findings as a governance signal, because they reveal where policy and actual behaviour diverge.
• Validate phishing detection with real attack patterns Test delayed URLs, HTML redirect files, supplier impersonation, and no-payload BEC messages rather than relying on malware samples alone. Use the results to decide whether your current SEG still matches the threat mix your users face.
• Unify email security and data loss reviews Bring phishing response, mailbox investigation, and outbound DLP into one operating review so the team sees both inbound compromise and outbound leakage together. That makes it easier to spot when a healthy-looking inbox is still exposing information.
• Document mail-flow change tolerance before migration If the current design depends on rerouting inbound mail or changing MX records, record the operational risk and downtime tolerance before selecting a replacement. API-based protection is often evaluated precisely because it avoids that disruption.

Key takeaways

• Legacy email gateways can create a false sense of control when they miss modern phishing and business email compromise.
• Outbound email behaviour matters as much as inbound threat delivery because personal-account sharing can expose sensitive data without a malware event.
• Modern email security should be judged on mailbox-level remediation, outbound visibility, and operational proof, not on perimeter detection claims.

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.
• Post-delivery remediation: Security action taken after a message has already reached a mailbox or application. It can delete, quarantine, or flag content, but it becomes less effective when the same message has already been copied into downstream systems outside the control boundary.
• Data Loss Prevention: Data loss prevention is the set of controls used to detect, block, and report sensitive data moving in ways the organisation does not allow. In practice, DLP must account for endpoints, email, cloud apps, APIs, and user behaviour, or it will miss the paths where real exposure happens.
• 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.

What's in the full article

Proofpoint's full article covers the operational detail this post intentionally leaves for the source:

• How the Proofpoint Core Email Protection API was evaluated behind Microsoft 365 without changing mail flow
• What the Adaptive Email DLP findings showed about employees sending sensitive documents to personal accounts
• How the team used live threat removal, policy tuning, and mailbox investigation during the proof of concept
• Why the migration was considered operationally easier than a disruptive MX-record redesign

👉 The full Proofpoint article covers the proof-of-concept findings, outbound DLP discovery, and the operational switch from a legacy SEG.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls that underpin modern identity programmes. It is suitable for practitioners who need a stronger foundation for identity-led security decisions across people, workloads, and automated systems.