TL;DR: Legacy secure email gateways miss payload-less, socially engineered attacks that bypass static rules, while one real-world text-only email led to a $753,000 loss and Abnormal AI says replacing third-party SEGs can cut licensing costs by 42% and SOC time by 95%. The governance issue is no longer spam filtering, but whether identity-aware email controls can detect behavioural anomalies before trust is exploited.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's blog post: Legacy secure email gateways miss payload-less fraud and business email compromise, while behavioural detection closes gaps static filters leave open.
Why it matters: For IAM, SOC, and security teams, the issue is that email abuse increasingly exploits identity and trust signals, so controls that only inspect payloads can miss the path to fraud and account compromise.
Context
Secure email gateways were built for a different threat model: high-volume spam, known bad links, and obvious malicious attachments. Payload-less fraud, business email compromise, and vendor impersonation do not fit that model well because the message can look clean while the trust relationship is the real target.
For identity and access teams, the key question is no longer only whether an email contains malware. It is whether the communication pattern matches the expected identity context for the sender, recipient, and vendor relationship, especially when payment instructions or account changes are involved.
Abnormal AI's article frames this as a migration from static perimeter filtering to behaviour-based detection inside the cloud email environment. That matters because the control problem is now about recognising abnormal trust use before a human authorises the loss.
Key questions
Q: What breaks when secure email gateways are used against payload-less fraud?
A: They break because the detection model is built around malicious content, while payload-less fraud uses context, trust, and identity cues instead. That means a clean-looking email can pass the gateway even when the communication pattern is abnormal. Teams need controls that evaluate relationship behaviour, not only message indicators.
Q: Why do vendor email accounts create fraud risk?
A: Vendor email accounts matter because they can become trusted entry points into procurement and finance workflows. If an attacker impersonates or compromises a supplier mailbox, the business may accept the message as routine, which allows fraudulent payment requests or account changes to pass through established approvals.
Q: How can teams tell whether behavioural email detection is working?
A: It is working when suspicious requests are flagged before approval, when impersonation patterns are detected across channels, and when legitimate business processes still move without excessive friction. The best signal is fewer unsafe actions taken on convincing but fraudulent requests.
Q: Should organisations replace a SEG with integrated cloud email security?
A: Replacement makes sense when the organisation needs correlated inbound, outbound, and identity-aware controls that a SEG cannot provide on its own. The decision should be based on coverage gaps, response speed, and how well native platform telemetry can be combined with policy enforcement. If the stack is fragmented, consolidation may improve governance.
Technical breakdown
Why payload-less email bypasses static SEG rules
Secure email gateways inspect messages for signatures of abuse such as malicious links, attachments, spoofed domains, or known bad infrastructure. That works when the attacker needs a payload. It fails when the message is plain text and the abuse lives in the social context, such as an urgent payment request from a trusted contact. In those cases the gateway sees a message that is syntactically normal, even though the surrounding identity relationship is not. The result is a mismatch between the control's detection logic and the actual attack surface.
Practical implication: teams should evaluate whether their email controls can inspect identity and communication behaviour, not only message content.
How behavioural AI changes email detection
Behavioural AI builds a baseline of normal activity across users, vendors, devices, and applications. Instead of searching for known bad indicators, it looks for deviations in sender relationships, communication frequency, tone, and unexpected actions such as payment-detail changes or unusual sign-ins. That shifts detection from content matching to context validation. In governance terms, the system is treating trust patterns as observable identity signals, which is closer to how modern invoice fraud and account takeover actually unfold.
Practical implication: establish baselines for normal sender and vendor behaviour so deviations can be quarantined before users engage.
Why running a SEG alongside cloud email often duplicates control
The article argues that third-party SEGs and native cloud email security frequently overlap on commodity threats, so the enterprise pays twice without getting proportionate coverage. The architectural issue is that a perimeter SEG and a cloud-native email layer can both address spam-like content, but only one of them can be tuned directly to cloud identity and behavioural context at the point where collaboration happens. That means the stack can become broader without becoming more effective.
Practical implication: map which threat classes are actually covered twice and which remain invisible when you keep both layers.
Threat narrative
Attacker objective: The attacker wants to exploit a trusted communication path to induce payment transfer, account compromise, or confidential-data leakage.
- Entry begins with a text-only email sent from a spoofed or compromised trusted contact, allowing the message to pass static SEG filters because it contains no malicious payload.
- Credential or trust abuse follows when the recipient relies on the apparent legitimacy of the sender and responds to a payment or vendor-change request.
- Impact occurs when the human authorises a transfer or shares data, producing direct financial loss before traditional controls can intervene.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Payload-less fraud creates an identity signal gap, not just a content-filter gap: The failure is not that email controls miss malware. The failure is that they treat message content as the primary indicator of risk while attackers increasingly abuse trusted relationships instead. That changes email security from a spam problem into an identity and trust problem, which means behaviour becomes the control surface practitioners have to govern.
Static perimeter email controls are mismatched to relationship-based attacks: SEGs were designed around known bad domains, attachments, and links, so they struggle when the threat is a legitimate-looking message from the wrong context. That is why the same architecture can reduce commodity spam while still leaving invoice fraud and business email compromise exposed. Practitioners should read that as a structural control mismatch, not a tuning issue.
Identity-aware email analysis is becoming part of NHI governance by another route: Vendor impersonation, payment-detail manipulation, and account takeover all depend on trust relationships that behave like access paths, even when no credential is stolen. The named concept here is the trust relationship exposure window: the period in which a user accepts a message as legitimate before behaviour is validated. That window now matters as much as the inbox itself.
Defence in depth is not the same as duplicate defence: Running a SEG next to cloud-native email protection only helps if the layers cover different failure modes. When both layers optimise for the same payload indicators, organisations absorb extra cost and analyst workload without closing the behavioural gap that modern fraud uses. Practitioners should re-evaluate whether the stack is layered or merely redundant.
The email attack surface now sits inside the collaboration fabric: The practical boundary has moved from the perimeter to the user relationship graph, where sender history, payment patterns, and vendor behaviour are the real indicators. That means governance has to span email, identity context, and fraud detection together. Security teams that keep these domains separate will continue to miss the point of these attacks.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Trust relationship exposure window: Email fraud is now governed by the period between message arrival and user validation, not just by message hygiene. Once attackers can operate with text-only social engineering, the control problem becomes behavioural verification inside the collaboration flow, where sender history, vendor patterns, and payment change requests can be monitored together.
Replacing a third-party SEG with a cloud-native behavioural layer changes the governance question from coverage breadth to decision quality. If a control stack cannot distinguish between normal and abnormal trust behaviour, it will continue to over-invest in duplicate filtering while under-investing in the signals that actually precede fraud.
For practitioners
- Validate email controls against payload-less fraud Test whether your current stack detects plain-text, socially engineered messages that contain no links or attachments but do contain abnormal payment or vendor cues.
- Baseline sender and vendor behaviour Define normal communication frequency, sender relationships, and payment-change patterns for high-risk users, vendors, and finance workflows.
- Measure duplicate control coverage Compare what the SEG and cloud-native email layer each actually stop, then remove assumptions that both are contributing unique protection.
- Escalate abnormal payment requests for review Route unexpected bank-detail changes, urgent transfer requests, and unfamiliar sign-in context into a manual verification workflow before funds move.
Key takeaways
- Legacy email gateways still miss the kind of social engineering that relies on believable context instead of malicious payloads.
- The article grounds that gap in a real loss of $753,000 and in the broader mismatch between duplicate filtering layers and modern fraud patterns.
- Practitioners should treat abnormal communication behaviour, not just malicious content, as the control point for preventing email-enabled fraud.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Trusted email paths are being abused through human reliance on identity context rather than machine compromise. |
| Recommendation — Review email-driven approval paths where human trust in a sender can substitute for verified identity context. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Abnormal payment-detail changes and vendor impersonation depend on weak trust and authorization checks. |
| Recommendation — Tie high-risk email actions to explicit authorization checks before funds or data are released. | ||
| MITRE ATT&CK | TA0001;TA0009 — Initial Access; Collection | The article describes social engineering entry followed by fraudulent data or payment collection. |
| Recommendation — Map payload-less email fraud to initial-access and collection tactics in detections and response playbooks. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity and vendor context in email workflows rely on disciplined account governance and review. |
| Recommendation — Apply account-management controls to the identities that can approve or redirect payment-related requests. | ||
Key terms
- Payload-Less Email Fraud: Email abuse that relies on believable text and trusted context rather than malicious links or attachments. The control problem is behavioural, because the message can look clean while still steering a user toward payment fraud, account takeover, or data disclosure.
- Anomaly Detection: Anomaly detection is the use of rules, statistics, or behavioural models to identify access patterns that differ from the expected baseline. In identity programmes, it helps surface compromised credentials, misuse of service accounts, and suspicious changes in authentication or access behaviour.
- Trusted App Impersonation: A failure mode where a malicious application borrows the identity or approval of a known app to obtain access through a legitimate authorisation path. For identity teams, this means the allowlist can be correct while the runtime software is still fraudulent.
- Trust Relationship Exposure Window: The period between receiving a message and validating whether the request is legitimate. In modern email fraud, this window is where losses occur, because attackers rely on a user acting before behavioural checks or secondary verification can intervene.
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.
Published by the NHIMG editorial team on June 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org