By NHI Mgmt Group Editorial TeamPublished 2026-06-26Domain: EventsSource: Abnormal AI

TL;DR: DexKo Global says replacing its legacy SEG with a Microsoft plus Abnormal API-based architecture across 7,000 employees and a partner-heavy supply chain freed budget and bandwidth while improving protection and automation, according to Abnormal AI. The real shift is that email security is moving toward API-level control and operational efficiency, not just filter tuning.


At a glance

What this is: DexKo Global’s webinar argues that retiring a legacy SEG for an API-based email security stack changed both protection and operational capacity.

Why it matters: It matters because email security choices increasingly affect identity-adjacent workflows, partner access, and the ability to automate controls across human, NHI, and delegated environments.

By the numbers:

  • 7, exKo Global replaced its legacy SEG with a Microsoft + Abnormal API-based architecture across 7,000 employees and dozens of locations.

👉 Watch Abnormal AI's webinar on DexKo Global's SEG retirement and email security modernization


Context

Email security becomes harder to govern when the enterprise depends on a legacy SEG to mediate traffic across a distributed workforce and a large external collaboration surface. In practice, the problem is not just detection quality. It is whether the security stack can keep pace with partner access, mailbox workflows, and the operational demands created by modern identity-heavy communication channels.

DexKo Global is presented as a manufacturer with 7,000 employees, dozens of locations, and a supply chain that includes hundreds of partners and contractors. That combination makes email a governance problem as much as a threat-detection problem, because security controls must work across internal users, external collaborators, and the systems that support them. The webinar frames the move away from the legacy SEG as a modernization of the control plane, not a simple product swap.


Key questions

Q: How should security teams decide whether to keep a legacy SEG or move to an API-based email security model?

A: The decision should hinge on where the organisation needs control. If your main challenge is perimeter filtering, a SEG may still cover basics. If your environment depends on cloud mail, partner collaboration, and rapid post-delivery response, API-based control usually fits better because it aligns security actions with mailbox and identity workflows.

Q: Why do partner-heavy organisations need a different email security approach?

A: Partner-heavy organisations face a broader trust surface, because threats can arrive through legitimate threads, shared mailboxes, and vendor relationships rather than only through obvious phishing. That means email security must support governance across external identities and not just block suspicious messages at the edge.

Q: What breaks when email security is treated as a perimeter-only problem?

A: The organisation loses visibility and response speed once messages are delivered. Perimeter-only controls struggle to manage compromised conversations, delayed detection, and mailbox-level remediation. In a distributed enterprise, that creates a gap between identifying a threat and containing it.

Q: How do teams know if their email security stack is limiting programme maturity?

A: Look for operational drag: manual remediation, duplicated policy work, slow response to mailbox threats, and limited automation across cloud email and identity workflows. If the platform mainly preserves legacy processes instead of reducing them, it is constraining maturity rather than enabling it.


Background and context

Why legacy SEG architectures struggle with modern email governance

Secure email gateways were built around a perimeter model: inspect, filter, quarantine, and block messages before they reach users. That model breaks down when collaboration is distributed, identity is federated, and attacks move through trusted accounts, vendor threads, or cloud-connected mailboxes. A SEG can still detect commodity phishing, but it often adds latency, operational overhead, and policy brittleness when the environment changes quickly. API-based architectures shift control closer to the mailbox and the identity layer, which is why they can support more dynamic response patterns.

Practical implication: reassess whether your email control stack is still optimized for perimeter inspection instead of identity-aware response.

What an API-based email security architecture changes

An API-based email security model integrates with the mail platform rather than standing in front of it. That allows the security layer to inspect existing messages, remove malicious content, take action after delivery, and correlate activity with user and tenant context. The architectural advantage is not just automation. It is that the control plane can operate with better visibility into cloud-native email environments, where timing, identity, and remediation matter more than static filtering. In mixed human and partner ecosystems, that can reduce the gap between detection and containment.

Practical implication: map which post-delivery response actions you can automate only if the security platform has mailbox-level API access.

Why partner and contractor ecosystems increase email risk

Large supply chains expand the attack surface beyond employees. Contractors, suppliers, and acquired entities all introduce additional mail routes, trust relationships, and identity sprawl. That makes email controls less about blocking bad messages at the edge and more about governing who can receive, forward, or act on messages once trust has already been established. When organisations depend on a broad external ecosystem, the email platform becomes part of access governance, because compromise often arrives through legitimate conversation threads rather than obvious malware payloads.

Practical implication: include partner-facing mail flows and external trust paths in your email and identity risk reviews.


NHI Mgmt Group analysis

Legacy email security is increasingly a governance problem, not just a detection problem. The DexKo example shows a distributed enterprise with employees, partners, and contractors that needed more than perimeter filtering. When the collaboration surface expands, email security has to support identity-aware control, post-delivery response, and operational flexibility. The practical conclusion is that legacy SEG decisions now affect wider access governance, not only message inspection.

API-based email security is best understood as a control-plane shift. Moving security logic into the email platform changes what teams can automate, what they can correlate, and how quickly they can respond. That matters most in organisations where communication flows cross internal and external identities every day. The implication is that practitioners should evaluate email security by how well it supports cloud-native governance, not by whether it preserves a familiar gateway pattern.

Supply-chain complexity raises the value of controls that can act after trust has already been granted. Hundreds of partners and contractors create legitimate conversations that perimeter tools often treat as normal traffic. The result is a smaller margin for error once a message lands in a mailbox. Teams should treat email security as part of delegated access oversight, because the threat often travels through approved relationships rather than suspicious infrastructure.

Identity blast radius: the more identities, partners, and mail workflows an organisation supports, the more any single compromise can move through legitimate communication paths. This is the core governance concept this webinar surfaces. In environments like DexKo's, the blast radius is shaped by external collaboration patterns as much as by malware detection quality. Practitioners should use that lens when deciding whether a legacy SEG still fits the operating model.

From our research:

  • Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
  • Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%.
  • For a broader lifecycle lens, read NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce control sprawl.

What this signals

Identity-adjacent security stacks are converging on platform-integrated control. Email, secrets, and workload governance are increasingly evaluated by how well they attach to identity workflows, not by how well they mimic older perimeter patterns. That shift matters because once security is embedded in the platform, teams can align remediation with mailbox activity, access paths, and delegated trust relationships more directly.

A fragmented control environment usually produces budget waste as well as blind spots. Our research shows organisations maintain an average of 6 distinct secrets manager instances, which is a useful warning sign for any programme that still relies on separate tools to govern related identity surfaces. The same operational logic applies to email security: too many disconnected controls create friction that attackers can exploit and teams must then clean up.

Email security is moving closer to delegated trust governance. When contractors, suppliers, and cloud mail systems are part of the operating model, the relevant question is not just whether a message is malicious. It is whether the organisation can respond across the identity and collaboration paths that message travels through, using controls that fit modern mailbox reality.


For practitioners

  • Map your email security control plane to identity flows Document where mail access, partner collaboration, and mailbox actions are governed today. If the stack only inspects inbound traffic, identify what happens after delivery and which response actions require platform integration.
  • Assess external trust paths alongside employee mail risk Review contractor, supplier, and acquisition-related mail flows as part of the same governance model. A large external ecosystem often creates the conditions where legitimate-looking conversations become the attacker’s entry point.
  • Prioritise post-delivery response capability Test whether your email platform can search, recall, quarantine, or remove messages after they reach the mailbox. That capability matters when malicious content arrives through trusted threads or delayed compromise.
  • Use the migration as a budget reallocation signal Track whether legacy gateway maintenance is consuming time that should be spent on identity-aware controls, mail remediation, and cross-platform automation. If the answer is yes, the stack is limiting programme maturity.

Key takeaways

  • Legacy SEG retirement is a governance decision as much as a tooling decision, because email security now sits inside broader identity and collaboration flows.
  • Partner-heavy environments demand controls that can act after delivery and inside the mailbox, not only at the perimeter.
  • Teams should measure email security by how much manual remediation, duplication, and response delay it removes from the programme.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Email access and delegated trust require least-privilege governance across users and partners.
NIST Zero Trust (SP 800-207)PR.AC-1API-based email security aligns with continuous verification in cloud collaboration flows.
NIST SP 800-63Federated access and external collaboration depend on identity assurance across mail workflows.

Treat email security as part of zero-trust access decisions and verify identity context continuously.


Key terms

  • Secure Email Gateway: A secure email gateway is a control layer that inspects and filters email before it reaches users. It is designed primarily for perimeter-era threat blocking, but it can become less effective when collaboration is cloud-based, identity-driven, and spread across internal and external mail relationships.
  • API-Based Email Security: API-based email security integrates with the mail platform through application interfaces rather than sitting in front of traffic. This lets security teams inspect delivered messages, automate remediation, and connect email actions to mailbox and identity context in cloud-native environments.
  • Identity Blast Radius: Identity blast radius is the amount of operational and security impact that can flow from a single compromised identity path. In email environments, it grows when employees, contractors, vendors, and delegated mail workflows all share trusted communication channels.

Deepen your knowledge

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

This post draws on content published by Abnormal AI: The Fast Lane: How DexKo Global Rolled Off of Its Legacy SEG. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org