Secure Email Gateway vs ICES: Which Architecture Best Defends Against Phishing, Business Email Compromise, and AI Cyber Threats

Every organization moving email to the cloud eventually confronts the same infrastructure question: does inbound mail get inspected before it lands in an inbox, or after? That single design decision separates two dominant approaches to defending against phishing, business email compromise, and AI-generated social engineering. Choosing the wrong one leaves a measurable gap between what a security team believes is blocked and what actually reaches an employee.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, internet crime drove $20.877 billion in reported losses, a 26% jump over the prior year's $16.6 billion, and email remains the delivery mechanism cyberattackers return to most often. Comparing secure email gateway vs ICES architecture head to head is the starting point for closing that gap.

This guide covers:

• How a secure email gateway vs ICES platform differs in deployment, mail flow, and failure mode;
• What each architecture catches and what it structurally cannot see;
• Detection technologies behind signature-based filtering versus behavioral AI;
• Industry-specific and regulatory considerations for healthcare, financial services, and GDPR-bound organizations;
• Where cyber threat detection technology and a cybersecurity awareness training program intersect to close the human layer gap.

Knowing architecture difference will not stop a spear phishing email that reads exactly like a real colleague. Adaptive Security combines AI-powered simulations with real-time reporting so employees close the gap no gateway can close alone.

Take a self-guided tour

The Evolution of Email Security: From On-Premises Gateways to Cloud-Native Defense

Email security architecture changed because the location of email itself moved. When organizations migrated from on-premises Exchange servers to Microsoft 365 and Google Workspace, the SMTP-based inline inspection model that secure email gateways relied on lost its original justification. Email no longer passed through a corporate network perimeter where a gateway could intercept it before delivery.

Cloud email adoption reached near-universal levels within a few years of the shift, rendering the traditional perimeter-based security model a mismatch for where email actually lives today. That shift pushed the industry toward secure email gateway vs ICES comparisons as organizations reevaluated architecture built for a perimeter that no longer exists, moving toward Integrated Cloud Email Security (ICES), which inspects messages at rest inside the cloud platform rather than routing them through an external choke point.

From On-Premises to the Cloud: How Email Infrastructure Shifted

For two decades, email infrastructure followed a predictable pattern. An organization ran Microsoft Exchange Server on physical hardware inside a data center, and security teams positioned defenses at the network perimeter to inspect traffic before it reached user inboxes. This architecture made sense while email had a fixed physical location that security tools could guard.

That model began unraveling with the launch of large-scale cloud email platforms, and the migration accelerated sharply over the following decade. Microsoft has confirmed end-of-support timelines for on-premises Exchange Server, and cloud email adoption among large enterprises has become the operating default rather than the exception.

The shift was not merely a change of address. It altered the security equation because email no longer traversed a corporate network that security teams controlled. Messages moved directly between cloud provider infrastructure and end-user devices, often bypassing an on-premises security stack entirely. Perimeter-based defenses, designed to inspect SMTP traffic at a defined network boundary, suddenly had no traffic to inspect unless organizations deliberately rerouted mail through a gateway they still maintained. That rerouting introduced latency, created a single point of failure, and undermined the operational simplicity that made cloud email attractive.

Why Traditional Secure Email Gateway Architectures Emerged

Secure email gateways were a rational response to the infrastructure of their era. In the 2000s and early 2010s, email lived on corporate-owned servers behind a defined perimeter, and a secure email gateway slotted neatly into that architecture. It sat inline at the network edge, accepted inbound SMTP connections, filtered messages against known cyber threat signatures and reputation databases, and relayed clean mail to the internal Exchange server.

This inline SMTP model gave secure email gateways three advantages that made them dominant for over a decade. First, every message passed through the gateway before delivery. Second, the gateway operated independently of the mail server, so a compromise of Exchange did not automatically compromise the gateway. Third, the model created a natural logging and audit point that compliance teams relied on for e-discovery and regulatory reporting.

The limitation was architectural rather than functional. Secure email gateways were built for a world where email infrastructure had a fixed location behind a fixed perimeter. When that world dissolved, the model's dependence on rerouting traffic through an external appliance became a liability. Organizations that maintained gateways after migrating to Microsoft 365 often found cloud-native email forced through a legacy inspection pipeline that added latency, generated false positives from stale threat intelligence, and failed to detect cyberattacks exploiting cloud-platform features the gateway could not see. It only examined SMTP headers and message bodies, not platform-level API signals like login anomalies, mailbox rule changes, or suspicious OAuth grants.

The Cloud Email Migration Tipping Point

The tipping point arrived when cloud email adoption crossed from majority to near-universal, and the architectural mismatch between secure email gateways and cloud email became impossible to ignore. Three specific failure modes emerged repeatedly.

• Cloud-native cyberattack blindness: signature-based detection could not identify cyberattacks exploiting cloud-platform APIs, such as a cyberattacker using a compromised OAuth token to read a mailbox without sending a single malicious email;
• The MX record routing problem: forcing cloud email through an on-premises or hosted gateway required pointing MX records at the gateway instead of Microsoft or Google, creating a dependency chain where a gateway outage meant all mail stopped flowing;
• The speed problem: cloud-to-cloud delivery between two Microsoft 365 tenants takes milliseconds, while routing that same message through a third-party gateway added latency and a bottleneck the native architecture never had.

The visibility gap between what a gateway could inspect and what was actually happening inside the cloud platform became the central problem of the post-migration era. That gap is precisely what ICES was designed to address, replacing the inline SMTP model with API-based inspection that reads messages, attachment metadata, and behavioral signals directly from the cloud platform, restoring visibility without reintroducing the routing dependencies that made gateways problematic.

A gateway rebuilt for the cloud era still cannot see what happens after a message reaches the inbox. Adaptive Security's phishing simulation platform trains employees to catch what any perimeter architecture structurally misses.

Explore the platform

What is a Secure Email Gateway (SEG)?

A secure email gateway (SEG) is a dedicated email security appliance or cloud service that sits inline between the public internet and an organization's mail server, inspecting inbound and outbound messages before they reach the recipient. Acting as a proxy, a secure email gateway filters mail for spam, malware, phishing links, and malicious attachments using layered detection technologies, including signature-based analysis, URL reputation feeds, and attachment sandboxing.

Originally built for on-premises Microsoft Exchange environments, secure email gateways enforce policy at the network perimeter by redirecting SMTP traffic through a central inspection point, a model that introduces architectural rigidity and operational overhead when weighed against a secure email gateway vs ICES architecture built natively for the cloud.

How SEGs Work: SMTP-Based Mail Flow and Pre-Delivery Filtering

Secure email gateways function through inline inspection. When an organization deploys one, it reconfigures its DNS Mail Exchange (MX) records to point to the gateway's proxy server rather than directly to its own mail transfer agent. Every email addressed to the organization lands at the gateway first, where it is scanned and classified before being forwarded to the corporate mail server for delivery.

This architecture means the gateway sees and judges every message before a user sees it. The gateway terminates the SMTP connection from the sending server, performs its full security stack inspection, then initiates a new SMTP connection to relay only the clean messages through. Nothing enters or exits without the gateway's approval.

The pre-delivery model gives secure email gateways a decisive advantage: a malicious email can be blocked outright rather than pulled back after delivery. It also makes the gateway a critical single point of failure. If the gateway goes down, misclassifies a legitimate message as spam, or introduces excessive processing latency, every employee in the organization feels the impact immediately, and email simply stops flowing. That is the fundamental tradeoff baked into the inline architecture: total visibility in exchange for total dependency.

Core SEG Detection Technologies

Traditional secure email gateways rely on a stacked set of detection engines, each addressing a different cyber threat category, since no single engine is sufficient on its own.

• Signature-based detection compares every incoming message and attachment against a continuously updated database of known malware hashes, malicious file fingerprints, and spam patterns. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of any reported cybercrime category, which is precisely why signature freshness only addresses part of a gateway's real-world effectiveness. The gap between a new malware campaign launching and its signature propagating across every customer gateway is the window cyberattackers exploit.
• URL reputation filtering checks every embedded hyperlink against continuously updated threat intelligence feeds. If a URL appears on a blocklist, hosts a known exploit kit, or belongs to a domain registered within the last 24 hours, the gateway strips, rewrites, or blocks the link before delivery. The weakness is structural: a freshly registered domain used in a targeted spear phishing campaign has no reputation at all, making reputation-based blocking easy for a determined cyberattacker to bypass.
• Sandboxing addresses the detection gap that signature and reputation feeds leave open. When an attachment appears suspicious but matches no known malware signature, the gateway detonates the file inside an isolated environment and observes its behavior for signs of a command-and-control connection, registry modification, or other malicious activity. Sandboxing catches zero-day malware and novel payloads, but at a cost: detonation and behavioral analysis take 30 seconds to several minutes, delaying legitimate delivery for every recipient waiting on that message.

SEG Deployment Model: MX Record Changes, DNS Reconfiguration, and Inline Inspection

Deploying a secure email gateway is not a lightweight operational task. Every email must physically pass through the gateway, which means the organization's public DNS MX records must be updated to point to the gateway provider's proxy infrastructure instead of the company's own mail server. This DNS change is non-trivial: MX records carry Time to Live values that govern how long intermediate resolvers cache the previous routing path, so full propagation can take hours or even a full day. During that window, email may route inconsistently, some messages through the old path and some through the new.

Once redirected, the gateway terminates and inspects every SMTP connection, introducing an additional routing hop that adds measurable latency, typically a few seconds per message and significantly longer when sandboxing detonates suspicious attachments or the gateway operates under peak load. For time-sensitive communications such as transactional notifications or deal-closing contract exchanges, trading delivery speed for inspection is a genuine operational tradeoff.

The operational overhead extends well beyond initial deployment. Gateway appliances require ongoing patching, signature database updates, policy tuning, and capacity planning as mail volume grows, and false positives must be manually reviewed and whitelisted by administrators. TLS-encrypted messages require the gateway to act as a man-in-the-middle to inspect content, meaning the organization must manage, rotate, and protect the TLS certificates that make that inspection possible. Organizations that have migrated to cloud-native platforms often discover the inline model reintroduces the infrastructure complexity they moved to the cloud specifically to eliminate.

What is Integrated Cloud Email Security (ICES)?

Integrated Cloud Email Security (ICES) is a category of email protection that connects directly to cloud email platforms, specifically Microsoft 365 and Google Workspace, through API integration rather than sitting inline in the mail flow. Unlike a secure email gateway that reroutes all traffic through an external proxy, ICES analyzes messages after they land in user inboxes, using AI, machine learning, natural language processing, and behavioral analysis to detect cyber threats that signature-based systems miss.

The approach eliminates the need to change MX records, making deployment fast and operational overhead low. ICES was never designed to replace the native security of cloud email providers; it layers on top, catching the socially engineered cyberattacks that built-in defenses and legacy gateways routinely fail to stop. A secure email gateway vs ICES comparison ultimately comes down to where inspection happens and what that position enables.

How Gartner Defined the ICES Category

Gartner introduced the term Integrated Cloud Email Security in its Market Guide for Email Security, formally recognizing an architectural approach that emerged alongside mass migration to cloud email. The firm identified a distinct class of solutions that supplement, rather than replace, the native security capabilities of platforms like Microsoft 365 and Google Workspace by connecting through published APIs, a deliberate departure from the gateway model that had dominated enterprise email security for two decades.

Gartner's analysis captured a structural shift already underway. Organizations that had moved to cloud email found the gateway model increasingly misaligned with their architecture, since rerouting traffic to an external gateway introduced latency, created a single point of failure, and left internal-to-internal email, which never traverses a perimeter gateway, completely uninspected. ICES addressed all three problems by operating inside the cloud environment itself, and subsequent Gartner guidance has continued to track API-integrated supplemental security as a mainstream layer rather than an experimental one.

API-Based Architecture: How ICES Connects to Microsoft 365 and Google Workspace

ICES operates through a fundamentally different integration model than a gateway. The connection happens entirely through REST APIs: the Microsoft Graph API handles Microsoft 365 environments, and the Google Workspace APIs, including the Gmail API and Admin SDK, serve Google ecosystems. There is no MX record change, no mail flow rerouting, and no SMTP-level proxy between senders and recipients.

The authorization model uses OAuth 2.0 delegated permissions. An administrator grants the ICES platform scoped access to read mailbox contents, inspect message metadata, and perform post-delivery remediation actions such as quarantining or deleting malicious email. These permissions are granular: an ICES solution typically requests read and read-write mail scopes in Microsoft Graph, along with directory read permissions for user and group context, while Google Workspace grants equivalent access through domain-wide delegation restricted to specific OAuth clients. No credentials are stored by the ICES provider; authentication is token-based and revocable at any time from the cloud platform's admin console.

Because ICES does not sit in the mail path, delivery speed is unaffected. Messages arrive in inboxes at native speed, and the ICES platform analyzes them post-delivery, typically within seconds to minutes. This tradeoff, post-delivery analysis instead of pre-delivery blocking, is the defining characteristic of the ICES model and remains the central point of debate in any secure email gateway vs ICES evaluation.

The deployment timeline is where the API model most clearly diverges from the gateway approach. A full ICES deployment, from admin consent to active mailbox monitoring, takes minutes: an administrator authenticates, grants the required OAuth scopes, and the platform immediately begins analyzing mailboxes. No network configuration changes, DNS propagation delays, or mail flow testing are required. A gateway deployment, by contrast, typically involves MX record changes that can take days to propagate globally, firewall rule modifications, TLS certificate configuration, and extensive testing before cutover.

Core ICES Detection Technologies: AI, Machine Learning, NLP, and Behavioral Analysis

What makes ICES architecturally distinct is the API connection. What makes it effective is the detection engine running behind that connection.

• Behavioral baselines per user form the foundation, as an ICES platform ingests historical email data, communication frequency, typical contacts, sending patterns, attachment habits, and login locations, and builds a normal-behavior model for every individual in the organization;
• Natural language processing analyzes email content and tone at a semantic level rather than a keyword level, evaluating linguistic markers of social engineering including urgency framing, authority impersonation, and abnormal shifts in formality;
• Computer vision extends detection to image-based cyber threats that contain no scannable text, including QR code phishing, credential-harvesting login pages embedded as screenshots, and fake invoice images, a detection surface invisible to traditional gateways;
• Social graph analysis maps the organization's communication network, tracking who emails whom and how frequently, flagging anomalies such as a compromised vendor account emailing an employee it has never contacted before.

Together, these techniques create a detection model that does not rely on knowing what a cyber threat looks like in advance. It relies on knowing what normal looks like and flagging deviations. Signature databases that update on a fixed schedule fall behind cyberattackers using generative AI to produce novel phishing lures in seconds, which is why a behavioral model that updates continuously has become the architecture best positioned to keep pace.

Behavioral detection catches what signatures cannot see, but only if it reaches the inbox before an employee acts on it. Adaptive Security pairs continuous phishing simulations with real-time reporting to close that window.

Book a demo

Architectural Comparison: SEG vs ICES Email Security

The fundamental divide between a secure email gateway and Integrated Cloud Email Security is not primarily about which cyber threats each catches. It is about where each sits in the mail delivery path and what that position enables or forecloses. A gateway operates inline as an SMTP-based proxy, intercepting every message before it reaches the inbox by rerouting mail through DNS MX record changes, while ICES connects via native cloud APIs and analyzes email outside the mail flow entirely.

The gateway model enforces pre-delivery blocking, but a gateway outage stops mail delivery organization-wide. ICES deploys in minutes without touching DNS, inspects messages post-delivery, and fails open when the API connection is unavailable, meaning email continues flowing even if the security layer is temporarily offline. Neither architecture is superior across every dimension in a secure email gateway vs ICES assessment: gateways provide deterministic pre-delivery filtering that compliance-heavy environments value, while ICES trades that immediate block for deployment speed, operational simplicity, and visibility into communications gateways structurally cannot see.

API-Based vs. SMTP-Based: Deployment Speed, Mail Flow, and Failure Modes

Deploying a gateway begins with a DNS change that redirects inbound email through the appliance before it reaches the mail server. The organization updates MX records, validates TLS negotiation, configures connectors, and tests mail flow to confirm legitimate messages are not dropped. This process spans days or weeks and requires coordination across networking, IT, and security teams, and any misconfiguration produces delivery failures that users experience as missing email. Gateways generally require continual tuning to balance filtering accuracy against mail flow reliability, adding operational overhead that persists well past initial deployment.

ICES eliminates that entire surface area. It connects to Microsoft 365 or Google Workspace through native APIs, typically a two-click OAuth authorization, and begins analyzing messages immediately. No MX records change, no mail is rerouted, and no connector rules are created. Deployment is measured in minutes rather than weeks, and existing mail infrastructure remains untouched.

That difference carries directly into failure behavior. When a gateway goes offline, inbound mail queues on the sending server and eventually bounces; this fail-closed posture is the gateway's inherent architectural dependency risk. When an ICES API connection drops, protection pauses but business communication does not, since mail continues delivering as though the security layer were never present.

The mail flow distinction also affects active-incident response: a gateway that misclassifies a legitimate domain blocks every message from that sender before anyone sees them, and recovering those messages requires locating them in quarantine and releasing them manually. ICES, operating asynchronously, can flag and quarantine a malicious message without ever touching legitimate mail in the same flow, narrowing the blast radius of a false positive from an entire blocked sender to one specific removed message.

Pre-Delivery Blocking vs. Post-Delivery Remediation: The Timing Trade-Off

The most frequently cited advantage of the gateway architecture is also its most honest differentiator: the gateway inspects an email before the recipient does and can block it pre-delivery. If the gateway detects a known malicious attachment or a blocklisted URL, the message never reaches the inbox. This deterministic model has been the standard for email security for decades, and it remains the right fit for bulk phishing campaigns, known malware signatures, and policy violations where the indicators of compromise are static and well understood.

ICES operates on a different timeline. Messages are delivered to the inbox, analyzed by the platform's detection engine, and remediated after delivery if deemed malicious. The remediation window is measured in seconds: modern API-based platforms pull the message, run behavioral analysis incorporating sender-recipient relationship history and identity signals, then issue API calls to quarantine, delete, or move the message to junk. That behavioral depth produces higher-fidelity verdicts than content inspection alone can deliver.

The latency concern is real but narrow. In edge cases where an employee acts on a malicious email within the first few seconds of delivery, post-delivery remediation arrives too late, and that is the architecture's honest tradeoff: ICES accepts a brief exposure window in exchange for richer detection signals and operational simplicity. Organizations that require absolute pre-delivery blocking for every message, typically those in defense, critical infrastructure, or highly regulated environments with deterministic threat models, often find gateway architecture aligns better with their risk appetite. For most enterprises, the seconds-wide gap between delivery and remediation is a manageable risk weighed against the broader detection coverage ICES provides.

Internal Email Visibility: What Each Architecture can and Cannot See

Secure email gateways sit at the perimeter, giving a clear view of every message crossing the organizational boundary, inbound from external senders and outbound to external recipients. That position also creates a structural blind spot: internal-to-internal email never traverses the gateway. When one employee emails another within the same organization, the message routes entirely inside the mail platform, and the gateway never inspects it.

That blind spot matters because lateral phishing, where a cyberattacker compromises one account and uses it to phish colleagues inside the same organization, is one of the most dangerous forms of email-borne cyberattack. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 13% of all breaches, and compromised internal accounts are precisely the category a perimeter gateway is structurally unable to observe once the credential has already been used to log in. The recipient sees a message from a known internal sender, often with prior conversation history, and trust is immediate.

ICES, connecting directly to the cloud platform's API, sees every mailbox and every message regardless of direction, making internal communications as visible as external ones. This advantage extends beyond lateral phishing detection: ICES can identify patterns consistent with account takeover, such as a user suddenly sending dozens of messages in minutes or accessing mail from an anomalous geographic location, that a perimeter gateway would never observe.

ICES can also surface insider risk, where an employee moves data through internal email to a personal account. A gateway sees what crosses the border; ICES sees what happens inside it, and that internal visibility changes how an organization detects and responds to threats a perimeter-only defense was never positioned to catch.

Internal visibility only matters if the person receiving a suspicious internal message knows to question it. Adaptive Security trains employees to recognize account takeover and lateral phishing signals that architecture alone cannot flag for them.

Take a self-guided tour

Detection Capabilities Compared: What SEGs Catch and What They Miss

Secure email gateways and ICES platforms approach threat detection from different architectural positions. Gateways inspect email at the perimeter using signature matching, URL blocklists, and reputation scoring to filter known-bad traffic before it reaches the inbox, while ICES platforms operate inside the cloud email environment via API integration, applying behavioral baselining, natural language processing, and social graph analysis to detect anomalies that carry no malicious payload to flag.

Gateways excel at stopping bulk spam and known malware, the high-volume, low-creativity cyberattacks. ICES catches the targeted, text-only social engineering, business email compromise, and AI-generated phishing that bypass perimeter defenses without triggering a single rule. Both architectures have a place, but the cyber threat landscape has shifted so decisively toward payload-less, identity-deceptive cyberattacks that a gateway-only posture leaves organizations exposed to the cyberattacks causing the most financial damage today.

SEG Detection Strengths and Structural Weaknesses

Secure email gateways were built for a different era of email cyber threats. Their detection engine rests on three pillars: known malware signature matching, URL blocklists fed by threat intelligence feeds, and attachment sandboxing that detonates suspicious files in an isolated environment. Against bulk phishing campaigns with embedded payloads, mass spam operations, and email from domains with established poor reputations, gateways perform effectively.

The problem is that modern cyberattackers have systematically engineered around every one of these detection mechanisms. Business email compromise contains no malware, no malicious URL, and no suspicious attachment; it is pure text, a carefully worded request from what appears to be an executive asking finance to process an urgent wire transfer. Conversation hijacking takes this further: cyberattackers insert themselves into existing email threads using compromised accounts, building on legitimate context that makes the request indistinguishable from normal business communication. These cyberattacks bypass signature detection entirely because there is no signature to match.

Display name spoofing and lookalike domain cyberattacks exploit the gap between what gateways inspect and what employees actually see. An email from a lookalike domain one character off from a trusted brand can pass SPF and DKIM checks because the sending infrastructure itself is legitimate; the gateway sees authenticated email from a valid domain, while the employee sees a trusted brand. AI-generated phishing email produced by large language models has eliminated the grammatical errors and awkward phrasing that legacy filters once relied on as detection signals, making these messages payload-free and linguistically indistinguishable from legitimate correspondence.

According to IRONSCALES' analysis of phishing data across 1,921 organizations, secure email gateways miss an average of 67.5 phishing emails per 100 mailboxes every month, with vendor scams and credential theft accounting for more than 65% of missed cyber threats. That finding confirms secure email gateways fail most consistently against precisely the cyberattacks that cause the most damage, since a compromised account with a clean history and valid authentication renders the gateway's entire detection framework irrelevant.

ICES Detection Strengths: Behavioral Anomalies, Conversation Hijacking, and AI-Generated Cyber Threats

ICES platforms operate on a different detection philosophy. Rather than asking whether an email is known to be bad, the question that defines signature-based architectures, ICES asks whether an email deviates from normal, and that shift from reputation to behavior changes what gets caught.

Behavioral baselining powers this approach. ICES platforms establish a normal communication pattern for every user and relationship, including when a given executive typically sends email, what tone and vocabulary they use, and how frequently they request sensitive actions like wire transfers. When an email arrives matching an executive's display name but originating from an anomalous IP range or requesting an action at an unusual time, the system flags it even though the message has no malicious payload, passes all authentication checks, and came from a domain with a spotless reputation.

Natural language processing adds a second detection layer tuned specifically for text-only social engineering. NLP models analyze tone, urgency markers, and intent shifts within email bodies, so a message that opens with casual pleasantries and abruptly pivots to an urgent financial request, the classic business email compromise pattern, triggers anomaly scores even when every individual sentence appears benign. For AI-generated phishing, NLP models trained on the linguistic fingerprints of large language models can detect subtle structural patterns that distinguish machine-generated text from human-written business correspondence, even when the grammar is flawless.

Social graph analysis addresses the impersonation problem that reputation-based systems cannot solve. ICES maps the real communication relationships within an organization and across its supply chain, so when an email claims to be from a known vendor but originates from an address that has never previously communicated with the recipient, the graph flags the anomaly. Computer vision models add another layer, analyzing linked pages at render time to detect when a login page is a pixel-perfect replica of a legitimate service rendered as an image rather than HTML, a technique designed to evade URL-based defenses.

Detection Rate Data: Phishing Bypass Rates Compared

Vendor-neutral detection benchmarks confirm the gap between architectures. Native cloud provider defenses have improved meaningfully in recent years, but even strong built-in filtering still struggles most with the text-only social engineering and business email compromise that lack any technical indicator of compromise. According to the FBI's 2025 Internet Crime Report, cyber-enabled fraud accounted for almost 85% of all losses reported to the Internet Crime Complaint Center, totaling $17.7 billion, up from $13.7 billion the prior year, and business email compromise remains the persistent risk at the costly center of that total.

ICES platforms fill the detection gap that neither secure email gateways nor native cloud provider defenses close on their own. Where gateways stop known-bad cyber threats using signatures and reputation, ICES stops the unknown-bad: the AI-generated spear phishing email from a compromised vendor account that reads exactly like every other legitimate message in the thread. That is not a theoretical category. It is the majority of financially damaging email cyber threats reaching employee inboxes today.

A gateway stops what it already recognizes, but the costliest attacks carry no recognizable signature. Adaptive Security conditions employees to catch identity-deceptive attacks that gateways and ICES platforms miss.

Explore the platform

ICES Strengths and Limitations: What API-Based Security Delivers and Where it Falls Short

Choosing ICES means accepting a fundamentally different threat model. Pre-delivery blocking is exchanged for post-delivery behavioral detection that catches what gateways miss, but that exchange introduces an exposure window between delivery and remediation. Even a short gap between an email landing in an inbox and ICES removing it is enough for an employee to click a link, forward a credential request, or approve a fraudulent invoice.

Since Gartner's original market recognition of the category, ICES architecture has matured rapidly, but organizations that deploy it without understanding both halves of the secure email gateway vs ICES tradeoff can be caught off guard by limitations they did not plan for.

Key ICES Advantages

ICES deploys in minutes through native API connections to Microsoft 365 or Google Workspace, with no MX record changes, no mail-flow reconfiguration, and no appliance to rack. For organizations that have endured multi-week gateway migrations, coordinating DNS cutovers and troubleshooting delivery delays, the operational difference is stark. An API-based solution authenticates, begins scanning historical mailbox data to establish behavioral baselines, and starts detecting cyber threats within the same hour.

Post-delivery remediation is the signature operational capability. When a cyber threat is detected after delivery, security teams can typically remove it from every affected inbox with a single administrative action, though messages already synced to mobile clients or connected SaaS platforms may require additional remediation steps. Traditional gateways block before delivery but have no visibility into what has already landed; if a cyber threat bypasses the gateway, the gateway offers no further recourse. ICES also scans internal email traffic between employees, which gateways positioned at the perimeter never see, an internal-visibility advantage that matters because a compromised account sending lateral phishing messages inside the organization is invisible to the gateway.

Behavioral detection is where ICES separates itself most sharply from signature-based gateways. ICES solutions build a communication graph for each user, tracking who they email, at what cadence, and using what language patterns, then flag anomalies. An executive who has never emailed the accounts payable clerk suddenly requesting a wire transfer triggers a behavioral alert even though the message contains no malware, malicious link, or attachment. Business email compromise and social engineering cyberattacks that bypass gateways because they look structurally legitimate get caught by the behavioral models ICES architectures were built to run.

The administrative burden also shrinks considerably. There are no hardware appliances to patch, no mail-queue troubleshooting, and no TLS certificate renewals on gateway devices, since the ICES vendor handles detection logic, model updates, and platform maintenance. For lean security teams, eliminating appliance management frees analyst time for higher-value investigation work.

Key ICES Limitations

Post-delivery latency is the architectural constraint no ICES vendor can fully eliminate. An email arrives in the inbox, and moments later a notification appears on the recipient's phone. The ICES platform then authenticates via API, scans the message, runs behavioral models, and initiates removal if the message is malicious. Even fast solutions take roughly a minute under optimal conditions, and under load, during API throttling events, or when Microsoft or Google rate-limit requests, that window stretches to several minutes. During that gap, the email remains live and actionable.

The sync problem compounds the latency risk. Cloud email platforms sync to connected applications continuously, so a malicious email that lands in an inbox replicates to mobile devices, CRM platforms, EHR systems, and integrated SaaS tools within seconds. ICES can remove the email from the mailbox, but copies already synced to a phone's native mail app or a clinical system may persist, meaning the remediation scope is the mailbox layer rather than the broader SaaS ecosystem that already ingested the message.

API dependency creates a genuine architectural dependency risk. When Microsoft 365's Graph API experiences throttling or degradation, detection and remediation both stop, and the cloud email provider's API availability effectively becomes the email security layer's availability. There is no fail-open or fail-closed posture to configure; the ICES platform simply goes dark until the API recovers. Organizations with stringent uptime requirements must pressure-test this dependency against their own risk tolerance.

The OAuth permission surface is a legitimate concern that security-conscious teams must scrutinize. ICES solutions require broad OAuth permissions to function, typically read-write mail access and directory read scopes, and a compromised ICES vendor account or a malicious OAuth application impersonating the ICES connector becomes a privileged access pathway into every mailbox in the tenant.

Microsoft has documented a rise in OAuth consent phishing campaigns, in which cyberattackers trick users into granting permissions to malicious applications that then operate with legitimate access tokens inside the environment, underscoring why OAuth scope auditing belongs in every ICES procurement review.

Addressing ICES Concerns: What Security Teams Should Verify Before Deploying

Due diligence on an ICES provider should begin with specific contractual and technical verifications.

• Demand a documented remediation speed service-level agreement, measured from email delivery to detection and from detection to removal, and ask for the measurement methodology rather than only the marketing figure;
• Verify API failure mode behavior, including whether the platform queues requests and retries when the Microsoft Graph API throttles or errors, or whether detection stops entirely;
• Audit OAuth permission scoping, insisting on granular, documented justification for each scope the connector requests, and verify that read-only mail access is supported initially, with write permission scoped only to remediation actions;
• Evaluate whether the vendor processes email via streaming APIs rather than polling intervals, since streaming connections reduce the detection gap to single-digit seconds.

The fundamental tension in ICES architecture is that pre-delivery certainty is traded for post-delivery intelligence, and that trade is only rational when detection speed is fast enough to make the exposure window trivial. A platform that takes several minutes to detect and remove a phishing email is effectively running a multi-minute experiment on whether anyone in the organization will click.

For organizations evaluating whether ICES fits their risk profile, the answer lives in that exposure-window math. An organization where employees routinely act on email within seconds of receiving it, trading desks, executive offices, and accounts payable teams among them, carries higher exposure than one where response times average ten minutes or more. Mapping email interaction velocity against a vendor's remediation service-level agreement turns residual risk into something quantifiable rather than theoretical.

A remediation window measured in minutes is still a window a trained employee can close in seconds by reporting instead of clicking. Adaptive Security's phish triage tooling routes reported email straight into a security team's response workflow.

Take a self-guided tour

Industry-Specific and Regulatory Considerations for Email Security Architecture

The choice between a secure email gateway and an ICES platform is fundamentally a compliance decision, not purely an architectural one. Regulated industries face distinct requirements that make one approach measurably safer than the other, and selecting the wrong architecture can create audit exposure that no amount of policy documentation can offset. Healthcare organizations, financial services firms, and any organization bound by GDPR each weigh the secure email gateway vs ICES tradeoff differently depending on where their regulatory exposure concentrates.

According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of organizations report that board members receive regular cybersecurity updates, and board members in high-resilience organizations are far more likely to hold personal liability for a breach than those in low-resilience organizations, 30% compared to 9%. That liability gap is one reason email security architecture decisions increasingly reach board-level review rather than staying confined to IT.

Healthcare: HIPAA Compliance, EHR Integration, and Patient Data Protection

Healthcare organizations face a compliance challenge no other vertical confronts in quite the same way: email does not exist in isolation from the clinical record. When a physician emails patient data, lab results, or referral documents, that information often syncs directly into an electronic health record system. A phishing email containing a malicious link that lands in a clinician's inbox can, within seconds, compromise not just the mailbox but the entire clinical data environment.

The gateway architectural model exacerbates this risk in ways that are easy to overlook during procurement. Because a gateway sits inline with mail flow, it must receive, inspect, and forward every email before delivery, and cyberattackers design campaigns specifically to evade gateway-based detection. If a malicious email passes gateway inspection, it reaches the mailbox and can sync to the EHR before any secondary remediation occurs.

An ICES platform operates through API integration within the cloud tenant after delivery, enabling retroactive remediation that pulls messages from inboxes the moment a cyber threat is identified, even hours after initial delivery. For healthcare organizations where a single compromised email can trigger a breach notification affecting thousands of patient records, that post-delivery remediation capability is not a luxury.

HIPAA's Technical Safeguards, specifically the Transmission Security standard at 45 CFR § 164.312(e), require covered entities to implement measures guarding against unauthorized access to electronic protected health information during transmission, and proposed HHS updates add explicit requirements for encryption, multi-factor authentication, and network segmentation. Healthcare security leaders evaluating secure email gateway vs ICES architecture face one question that cuts through the feature matrices: if a cyber threat bypasses the email security control, how fast can it be pulled back? The gateway answer is never. The ICES answer is measured in seconds.

This distinction is not academic. According to research by Eric Perakslis, PhD, Chief Scientific and Digital Officer at the Duke Clinical Research Institute, published in the New England Journal of Medicine in 2022, the number of medical records stolen in the United States in 2021 exceeded the number of hospitalizations by 10%. When email effectively functions as part of the medical record, post-delivery threat remediation shifts from an IT function to a patient safety imperative.

Financial Services: PCI DSS, BEC Risks, and Regulatory Reporting

Financial services firms face two distinct email security pressures: protecting cardholder data under PCI DSS, and defending against business email compromise cyberattacks that target wire transfer and invoice approval processes. These two priorities pull in different architectural directions, and security leaders must understand the tension to make an informed choice.

PCI DSS Requirement 4.2 states that cardholder data must not be captured, transmitted, or stored via end-user messaging technologies such as email unless the transmission is end-to-end encrypted. A gateway that routes email through its own data centers for inspection introduces an additional processing point into the cardholder data environment, expanding PCI scope, since every server an email carrying payment data traverses becomes a compliance boundary that must be assessed and documented. An ICES platform that inspects email in place within the Microsoft 365 or Google Workspace tenant, without rerouting traffic, keeps the cardholder data environment boundary narrower and audit scope more manageable.

Business email compromise is where the architectural tradeoffs become hardest to resolve. A gateway can block known malicious senders and domains before an email reaches an employee, preventing a finance team member from ever seeing a fraudulent invoice or a spoofed wire-transfer request. According to the FBI's 2025 Internet Crime Report, business email compromise losses reached $3.046 billion across 24,768 reported incidents, averaging roughly $123,000 per case, virtually all routed through manager-level approvers rather than automated systems.

Modern business email compromise cyberattacks increasingly bypass signature-based detection entirely, using compromised legitimate accounts and AI-generated text that contains no malicious payload and no social engineering pattern a gateway rule can flag. In these cases, a gateway's pre-delivery advantage collapses because the email looks legitimate and passes through untouched.

The differentiating factor becomes what happens next: an ICES platform with behavioral anomaly detection can identify that an email from a known vendor is requesting payment to a new account number, flag it post-delivery, and remediate it across every mailbox before anyone acts on it. For financial services compliance teams, an architecture offering multiple detection opportunities, both pre- and post-delivery, reduces the probability of a reportable incident more than any single-point control.

GDPR, Cross-Border Data Flows, and Multi-Framework Alignment

For organizations operating in or serving the European Union, the secure email gateway vs ICES decision carries data sovereignty implications that most procurement teams overlook until an audit surfaces them. GDPR Article 5 requires personal data to be processed lawfully, fairly, and transparently, and Article 32 mandates technical and organizational measures appropriate to the risk. The architectural question is simple but consequential: where does email go for inspection?

A traditional gateway routes email through the vendor's data centers, often located in specific geographic regions, before delivering it to the recipient. If an employee in the European Union sends an email containing personal data and the gateway routes it through a data center outside the region for inspection, that constitutes a cross-border data transfer under GDPR, requiring coverage under an adequacy decision, standard contractual clauses, or binding corporate rules. An ICES platform that processes email in place within the organization's existing cloud tenant eliminates that transfer entirely, since the data never leaves the jurisdictional boundary.

This distinction becomes more consequential for organizations aligning with multiple frameworks simultaneously. NIST Cybersecurity Framework 2.0 emphasizes governance through its Govern function and supply chain risk management, both of which intersect directly with email security architecture, alongside Protect function controls covering identity management, authentication, and data security.

Organizations mapping email security controls to NIST CSF while also meeting GDPR and HIPAA obligations often find that ICES architecture simplifies the compliance narrative, since fewer data processing locations mean fewer controls to document, fewer transfer mechanisms to validate, and fewer failure points to explain during an assessment. For security leaders navigating multi-framework environments, the operating principle stays consistent: minimize data movement, and the compliance surface area shrinks with it.

A compliant architecture still depends on employees who can recognize a fraudulent wire request before it reaches an approver. Adaptive Security's risk monitoring surfaces the human-layer gaps that regulatory frameworks expect organizations to manage.

Explore the platform

Where Email Security and Cybersecurity Awareness Training Intersect

No email filter, whether a secure email gateway or an ICES platform, was designed to stop an employee from trusting a perfectly crafted message from someone they believe is a company executive. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed incidents involve a human element, a finding that has remained consistent because the root cause of these incidents is behavioral rather than purely technical. Email security technology and a cybersecurity awareness training program address different failure modes in the same attack chain, and treating them as substitutes rather than complements leaves a structural blind spot that cyberattackers have already learned to exploit.

Why no Email Filter Catches Everything: The Human Layer Gap

Every gateway and ICES architecture operates on detection logic, whether signature matching, reputation scoring, or behavioral anomaly analysis. That logic is effective against known malware, bulk phishing campaigns, and credential harvesting pages already catalogued in threat intelligence feeds, but it breaks down against zero-day cyberattacks with no existing signature, highly targeted spear phishing built from open-source research on specific employees, and AI-generated social engineering that reads like legitimate business correspondence.

Generative AI has accelerated that gap. According to Sumsub's 2025-2026 Identity Fraud Report, deepfake cyberattacks increased 2,100% globally, with sophisticated fraud, including deepfakes, synthetic identities, and telemetry tampering, surging 180% year over year. When a cyberattacker can prompt a large language model to produce a grammatically flawless, contextually appropriate email mimicking an executive's writing style, neither keyword filters nor reputation engines have a reliable detection surface to work with, because in structure and language, the message is functionally legitimate.

As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer in October 2020, compliance metrics do not tell the whole story and fail to measure whether a cybersecurity awareness training program produces sustained change in employee attitudes and behavior. That conclusion is precisely why the human layer gap persists even at well-resourced organizations.

According to the National Cybersecurity Alliance's 2025-2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 52% of employed participants reported receiving no training on the security or privacy risks of AI tools, despite 65% now using AI tools and 43% admitting to sharing sensitive work information with them. That gap concentrates risk precisely where visibility is lowest, and it is why an organization that invests heavily in ICES or gateway architecture without parallel investment in a cybersecurity awareness training program is betting that every cyber threat will present a machine-detectable signal, a bet that has already lost.

Architecture choice matters for the majority of cyber threats a gateway or ICES platform is designed to stop, but neither option changes the calculus on the smaller share that reach employees directly. What changes that calculus is whether the employee who receives the message has been trained to recognize it, and whether they have a one-click mechanism to report it.

How Phishing Simulation Complements Email Security Architecture

A phishing simulation program transforms the employee population from a passive attack surface into an active detection network. When an organization runs multi-channel phishing simulations, spanning email spear phishing, AI-cloned voice calls, SMS-based smishing, and deepfake video requests, it creates a continuous feedback loop that strengthens both technical and human defenses simultaneously.

The most operationally valuable output of that loop is the reporting signal. When an employee flags a suspicious email, that report feeds into the security team's threat intelligence pipeline. If the reported email turns out to be a real cyberattack that bypassed the gateway or ICES platform, the security team gains exactly the early-warning indicator no automated system provided. If it was a phishing simulation, the miss triggers targeted microlearning, a short, role-specific cybersecurity awareness training module delivered immediately, addressing the exact type of cyberattack the employee missed. This closed-loop model ensures every detection gap, technical or human, produces a corrective action.

Speed matters on both sides of that loop. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured breakout at just 27 seconds. A reporting culture that flags a suspicious message within minutes, rather than hours, is often the only control fast enough to matter against that kind of timeline. The reporting rate itself, the share of suspicious email employees flag rather than ignore, becomes a leading indicator of organizational resilience that no gateway or ICES dashboard provides on its own.

This feedback loop also strengthens the email security architecture itself. When reported phishing email is analyzed and classified through phish triage tooling, the resulting threat intelligence can be shared across the security stack, and patterns emerge: a specific impersonation technique, a recurring sender domain, or a repeated social engineering narrative. Those patterns inform future detection rules, making the technical controls incrementally better at catching what they previously missed, so the human layer and the technology layer improve together.

Building a Defense-in-Depth Strategy Across Technology and Human Risk

The modern email defense model works best as three concentric layers, each catching what the layer before it missed.

• The first layer, a secure email gateway or API-based ICES filtering, handles high-volume, known-bad traffic, including spam, malware attachments with established signatures, links to known phishing domains, and email from poor-reputation IP addresses; when configured correctly, this layer stops the large majority of malicious messages before an employee ever sees them;
• The second layer, behavioral AI and anomaly detection, catches cyber threats that look clean to signature-based filters but exhibit subtle irregularities, including newly registered domains that mimic legitimate senders and communication patterns that deviate from established baselines between specific correspondents;
• The third layer, employees equipped through an ongoing cybersecurity awareness training platform, is the only layer that catches the remainder: a spear phishing email indistinguishable from a genuine message, an AI-cloned voice call mimicking a manager, or a deepfake video request from a convincing executive. These cyberattacks carry no machine-detectable signal, so a trained employee who pauses, verifies through an out-of-band channel, and reports is the only remaining defense.

This three-layer model is not theoretical. Organizations that invest proportionally across all three layers, rather than disproportionately in any single one, consistently manage incident response more effectively than those that do not. A gateway or ICES deployment without trained employees leaves an organization exposed to the most damaging cyberattacks, while trained employees without technical filtering face unnecessary alert fatigue. Together, the three layers create a defense architecture where each compensates for the others' structural limitations, and no single failure cascades into a breach.

Three layers of defense only function if the third layer, employees, gets the same investment as the technology stack. Adaptive Security's cybersecurity awareness training program closes that gap with realistic, multi-channel phishing simulations.

Book a demo

See how Adaptive Security Closes the Gaps Secure Email Gateways and ICES Leave Open

Every phishing email that a secure email gateway or ICES platform misses represents a potential breach, whether a business email compromise, wire fraud attempt, a credential harvesting page, or an AI-generated spear phishing message with no detectable payload. Neither side of the secure email gateway vs ICES decision closes the human layer gap on its own, and organizations that treat architecture as the entire strategy are left exposed exactly where cyberattackers have concentrated their effort.

Adaptive Security closes that gap by pairing AI-powered phishing simulations, spanning email, voice, SMS, and deepfake video, with real-time reporting and phish triage that routes flagged messages straight into a security team's response workflow. Rather than treating employees as a passive risk to be managed, the platform turns them into an active detection layer that improves with every reported message, closing the exposure window that no gateway or ICES architecture can close alone.

Security leaders evaluating secure email gateway vs ICES architecture can pair either approach with a cybersecurity awareness training program built for the AI-driven cyberattacks defined throughout this guide. Outcomes, not feature checklists, are what determine whether an organization actually reduces its breach exposure.

A gateway or an ICES platform closes part of the gap; the employees who receive what slips through close the rest. Adaptive Security equips them to do it.

Take a self-guided tour

Frequently Asked Questions About Secure Email Gateway vs ICES Email Security

What is the Difference Between a Secure Email Gateway (SEG) and Integrated Cloud Email Security (ICES)?

A secure email gateway is an inline, SMTP-based security appliance that sits in front of a mail server, inspecting email before delivery by rerouting MX records, relying on signature-based detection, URL reputation filtering, and attachment sandboxing. Integrated Cloud Email Security connects directly to cloud email platforms like Microsoft 365 and Google Workspace through APIs, requiring no mail flow changes, and uses behavioral AI, natural language processing, and social graph analysis to detect cyber threats post-delivery. The architectural distinction matters: gateways are blind to internal email traffic, while API-based ICES can monitor internal communications for lateral phishing and compromised account activity.

Does ICES Require MX Record Changes to Deploy?

No. Integrated Cloud Email Security deploys without any MX record changes. Because ICES connects to cloud email platforms through API integrations, specifically the Microsoft Graph API for Microsoft 365 and the Google Workspace APIs for Google environments, it does not sit inline with mail flow. Organizations can activate ICES in minutes rather than the days or weeks often required to reconfigure DNS for a traditional gateway, and the API-based model eliminates the single-point-of-failure risk: if the ICES API connection becomes unavailable, email continues flowing normally through the cloud provider.

Can ICES and a SEG be Used Together in a Layered Defense?

Yes. Many organizations deploy an ICES solution alongside an existing secure email gateway to create a defense-in-depth architecture. Gartner has recommended augmenting gateway deployments with ICES before considering full replacement, since the gateway provides pre-delivery blocking of known malware, bulk spam, and blocklisted URLs, while API-based ICES adds behavioral detection and post-delivery remediation for the sophisticated cyberattacks that bypass the gateway. This layered model is widely adopted because the two architectures compensate for each other's blind spots without introducing conflicting mail flow policies.

Can ICES Detect Business Email Compromise (BEC) and Social Engineering Cyberattacks?

Yes. Detecting business email compromise and social engineering is a core design strength of ICES. Unlike gateways, which depend on known-bad signatures, malicious URLs, or attachment sandboxing, ICES platforms build behavioral baselines for every user and analyze communication patterns across the organization. When a cyberattacker attempts executive fraud, invoice fraud, or conversation hijacking, cyberattacks that often contain no links or attachments, the ICES engine flags anomalies in sender behavior, tone, timing, and relationship context. ICES also detects AI-generated phishing email that signature-based systems classify as clean because it contains no traditional threat indicators.

What Percentage of Phishing Emails Bypass Secure Email Gateways?

Independent benchmarking consistently shows that a substantial share of advanced phishing email bypasses leading secure email gateways, particularly payload-less cyberattacks containing no links or attachments. Miss rates vary meaningfully across vendors, and payload-less business email compromise remains the category gateways struggle with most, since there is no malicious URL, attachment, or signature to detect in the first place. Bypass patterns like these are why organizations increasingly layer behavioral, AI-based ICES protection behind a gateway, and why a trained workforce remains the critical last line of detection when technical controls fall short.

Key Takeaways

• The core secure email gateway vs ICES decision is about mail flow position: a gateway inspects before delivery by rerouting MX records, while ICES inspects after delivery through native cloud APIs;
• A secure email gateway offers deterministic pre-delivery blocking but introduces a single point of failure if the gateway itself goes down or is misconfigured;
• ICES deploys in minutes, requires no MX record changes, and sees internal-to-internal email that a perimeter gateway structurally cannot inspect;
• Neither architecture alone catches the identity-deceptive, payload-less cyberattacks like business email compromise and AI-generated phishing that now cause the most financial damage;
• Regulated industries, including healthcare, financial services, and organizations bound by GDPR, should weigh secure email gateway vs ICES architecture against their specific compliance exposure rather than a generic feature comparison;
• A cybersecurity awareness training program and phishing simulations close the human layer gap that persists regardless of which email security architecture an organization chooses;
• Many organizations run a gateway and ICES together, layering pre-delivery blocking with post-delivery behavioral detection for defense in depth.

Architecture decides what gets blocked before delivery; people decide what happens with everything else. Adaptive Security builds the cybersecurity awareness training program that turns employees into the layer neither a gateway nor ICES can replace.

Book a demo