How should security teams decide between gateways, ICES, and authentication?

Why gateways, ICES, and authentication solve different parts of the email problem

Security teams should start by separating the control plane from the trust plane. Gateways and ICES platforms inspect inbound mail, detonate or rewrite risky content, and help with post-delivery remediation. Authentication answers a different question: whether the sender is legitimately entitled to use the domain in the first place. Treating them as substitutes usually leaves one of those questions weakly covered.

The practical distinction matters because an organisation can have strong inbound filtering and still be exposed to domain spoofing, brand impersonation, or abusive outbound use if authentication is weak. It can also have strong authentication and still need gateway or ICES controls for malicious attachments, links, and account compromise scenarios that arrive through valid mail flows. A good design assumes overlap, then assigns each tool to the control it does best.

That is why the decision is rarely binary. The cleaner architecture is usually layered: authenticate legitimate outbound mail, filter and score incoming mail, and use post-delivery actions to catch what first-pass detection misses. If two products are solving the same problem, the task is to remove duplicated spend and duplicated operational burden, not to pick a single winner by category name.

Internal buyers who need a structured comparison of these options can use the Email Security Buyer's Guide to map evaluation criteria, proof-of-concept questions, and vendor claims to the actual control layer being bought.

How to decide what to keep, what to replace, and what to combine

The right decision comes from your threat mix, not from vendor marketing labels. If phishing, malware delivery, and malicious attachments dominate, gateway and ICES coverage deserve most of the attention. If lookalike domains, spoofing, and unauthorized outbound use are the bigger concern, authentication and domain policy deserve more weight. If account compromise and internal distribution are common, post-delivery response becomes important because the message may already be in a mailbox before anyone notices.

One useful way to think about the split is by failure point. Gateways and ICES try to intercept threats before or just after delivery. Authentication tries to stop unauthorised use of the domain and reduce the credibility of spoofed mail. Those are complementary controls, so the best answer is often to keep both, but only at the level of depth your exposure requires.

Overlap is where teams usually waste effort. If two tools both quarantine obvious phishing but only one gives meaningful post-delivery remediation, the weaker duplicate adds little. If both products require separate policy administration, the hidden cost is operator time, tuning drift, and inconsistent outcomes. A security team should measure whether the second tool improves detection, containment, or response enough to justify the extra complexity.

For identity and mailbox controls that sit behind this decision, the Workforce Identity Security Guide is useful when the mailbox problem is really part of a broader sign-in, recovery, and session-theft story.

Where email security decisions fail in practice

Many organisations overestimate what inbound inspection can do against compromised accounts. Once an attacker has legitimate access, messages can look authentic enough to pass normal trust checks, and the malicious content may arrive from a trusted tenant or internal mailbox. In that case, outbound legitimacy and account protection matter as much as content filtering. The reverse is also true: strong authentication does not stop a malicious attachment or URL from arriving in a real message.

The other common failure is misaligned ownership. Email authentication is often treated as a messaging admin task, while gateway policy is treated as a security tool purchase and ICES is treated as a separate cloud-mail add-on. Without one owner for the whole mail trust chain, teams accumulate partial controls, duplicate rules, and blind spots between products.

Teams comparing vendor claims against real attack patterns should sanity-check the difference between spoofing resistance, mailbox compromise response, and token or session abuse. Those are different failure modes, and a product that performs well in one does not automatically solve the others.

Relevant attack patterns are visible in public breach reporting such as Microsoft Midnight Blizzard breach, which shows how legitimate access can bypass many assumptions that only content filtering would catch.

Practitioner Guidance

What to prioritise: Start by classifying your dominant email risk. If inbound phishing and malware dominate, weight gateway and ICES capability first; if spoofing and domain abuse are the bigger issue, prioritise authentication; if mailbox compromise is common, add post-delivery response before you consider more perimeter filtering.

What to verify: Check whether each control covers a distinct failure mode, or whether you are paying twice for the same quarantine decision. Verify policy ownership, tuning responsibility, and the operational path for false positives, because those determine whether the stack will work under real pressure.

Decision rule: If a control does not change a specific outcome, such as blocking spoofing, catching malicious links after delivery, or reducing the credibility of unauthorized outbound mail, it is probably not adding enough value to justify another platform.

Practitioner takeaway: The right answer is usually not gateway or ICES or authentication, it is the smallest combination that covers distinct attack paths without duplicating the same detection logic.

Related resources from NHI Mgmt Group

• How should security teams decide between a PIN and a password for authentication?
• How should security teams decide between certificate-based authentication and MFA?
• How should security teams decide between authentication and governance IAM tools?
• How should security teams decide between hosted authentication customization and a headless auth API in enterprise apps?