Legacy email security fails against socially engineered attacks

At a glance

What this is: This is Abnormal AI’s on-demand webinar on how legacy email defenses miss socially engineered attacks and why detection now depends on identity, behaviour, and content signals.

Why it matters: It matters because IAM and security teams increasingly need to treat email as an identity problem, where compromised trust and behavioural context affect human, NHI, and autonomous systems alike.

👉 Watch Abnormal AI's on-demand webinar on blocking socially engineered attacks

Context

Socially engineered email attacks are a governance problem as much as a filtering problem. When attackers can borrow trust, mimic context, and bypass message-only controls, secure email gateways stop being enough on their own. For IAM and security teams, the question is no longer just whether an email looks malicious, but whether the identity behind it and the behaviour around it are consistent with normal access patterns.

Cloud migration has also changed where defenders need to look. Email security now sits alongside identity, behaviour, and content analysis because the attack surface follows users, cloud services, and connected identities rather than staying inside a single mail channel. That makes this topic relevant to human access, delegated access, and the broader NHI ecosystem that often underpins modern business workflows.

Key questions

Q: How should security teams handle socially engineered email attacks that bypass secure email gateways?

A: Security teams should treat SEG as one layer, not the whole control stack. The stronger approach is to combine identity validation, behavioural baselines, and content analysis so suspicious requests are judged in context. That means escalating unusual sender identity, request timing, and thread behaviour into identity workflows before users can approve transfers, resets, or delegated access.

Q: Why do cloud migrations make email social engineering harder to stop?

A: Cloud migrations spread trust across SaaS, identities, and delegated workflows, so a malicious message can look legitimate even when no malware is present. Defenders now need to judge whether the sender, the behaviour, and the request fit normal access patterns. Email security must therefore connect to IAM and governance, not sit beside them.

Q: What do security teams get wrong about social engineering prevention?

A: Teams often overestimate the value of message-level filtering and underestimate how much trust abuse depends on identity context. The failure mode is assuming an email control can detect intent on its own. In practice, the same request may be safe or dangerous depending on who sent it, how they normally behave, and what business process it targets.

Q: How can organisations reduce the risk of request-based fraud through email?

A: Organisations should require extra verification for sensitive requests that arrive by email, especially when they involve money movement, credential changes, or privilege escalation. The key is to make the approval path depend on independent identity checks, not just on the email thread. That reduces the chance that a believable message becomes an authorised action.

Background and context

Why secure email gateways miss modern social engineering

Secure email gateways were built around message inspection, reputation checks, and known-bad indicators. That model is weaker when attacks are personalized, low-volume, and context-aware, because the email itself may not contain obvious malware or a blocked sender. Social engineering often succeeds by using believable language, legitimate-looking identities, and timing that matches normal business activity. In cloud-first environments, the attack may also arrive through trusted collaboration patterns rather than a classic phishing template. The result is a control gap between message filtering and actual trust validation.

Practical implication: teams should treat SEG coverage as a layer, not the primary decision point, for socially engineered attacks.

Identity, behaviour, and content analysis as a detection model

Abnormal’s stated detection model combines identity, behaviour, and content analysis. Identity tells you who the sender claims to be and whether that identity is consistent with prior relationships. Behaviour shows whether the pattern of sending, replying, forwarding, or request timing fits the established baseline. Content analysis examines the language, intent, and manipulation cues inside the message itself. The value of the three-pillar model is not that any single signal is perfect, but that together they reduce the chance that a plausible message slips through because it looks ordinary in only one dimension.

Practical implication: build detections that correlate identity, behaviour, and message content instead of relying on one signal class.

Cloud migration and the new email attack surface

Cloud migration changes email risk by stretching trust across SaaS, identities, and connected workflows. A message can be authenticated and still be dangerous if the sender identity is compromised, a thread is hijacked, or the request maps to a normal business process that users are trained to trust. This is why email defense increasingly overlaps with identity governance. Once email becomes a route into credentials, approvals, or delegated access, the issue is no longer only delivery control. It is whether the organisation can recognise when legitimate-looking communication has become an access pathway.

Practical implication: connect email detection outcomes to identity and access workflows so suspicious requests cannot bypass governance.

NHI Mgmt Group analysis

Legacy email filtering is no longer the control boundary for social engineering. The article shows that secure email gateways struggle when attacks are personalised, cloud-aware, and context-driven. That means the effective boundary has moved from message inspection to identity trust and behavioural consistency. Practitioners should stop treating inbox filtering as the definitive email security control.

Identity and behaviour are now first-class email security signals. Abnormal AI’s framing aligns with a broader identity security pattern: the sender identity, the interaction history, and the request timing matter as much as the message payload. This is where human IAM and broader identity governance overlap with email defence, because trust decisions depend on who is acting and whether that action fits normal behaviour. Practitioners should map email detections to identity risk, not just delivery risk.

Social engineering is increasingly an identity lifecycle problem, not just a content problem. Compromised accounts, hijacked threads, and abused delegation all depend on identities that remain trusted longer than they should. The named concept here is trust signal drift: the point where a message still looks valid to a mail control even though the identity and intent behind it have changed. Practitioners should manage that drift with lifecycle-aware controls.

Cloud migration exposes the limits of static security assumptions. When email, SaaS, and identity systems are tightly linked, the old assumption that threats can be separated into a mail layer and an identity layer breaks down. The result is a governance problem across human users and the non-human services that support collaboration, approvals, and automation. Practitioners should design for cross-domain verification instead of isolated controls.

Security teams need a detection strategy that is evidence-led, not signature-led. Modern social engineering evades simple rule sets because it uses legitimate infrastructure, familiar language, and business context. That requires continuous review of identity anomalies, behavioural outliers, and request patterns rather than relying on static blocklists. Practitioners should measure whether detections are catching trust abuse before users act on it.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
• That visibility gap reinforces the need to connect email trust decisions to identity governance and to the NHI Lifecycle Management Guide when delegated access is involved.

What this signals

Trust signal drift: email security teams should watch for the point where a message still passes delivery checks but no longer matches the sender’s normal identity or behaviour. That is where social engineering becomes an access problem, not just a phishing problem.

The practical signal is convergence between IAM, mailbox telemetry, and request risk. When organisations can tie suspicious email to sender identity, delegated access, and prior communication patterns, they stop relying on users to make security decisions in the moment.

A useful benchmark is that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security. That same visibility mindset applies to email trust chains, especially where SaaS approvals and delegated workflows are involved.

For practitioners

• Correlate mailbox alerts with identity signals Route suspicious-email detections into identity workflows so analysts can check sender legitimacy, account status, recent behaviour, and prior relationship history before action is approved.
• Baseline normal communication behaviour Track reply chains, sending patterns, timing, and request frequency for high-risk roles and externally facing accounts so behavioural drift is visible before a message is trusted.
• Tighten governance around delegated requests Require secondary verification for payment changes, credential resets, and approval requests that arrive through email, especially when they involve high-value identities or privileged workflows.
• Review email security beyond the SEG layer Assess where secure email gateways end and where identity-aware controls begin, then document which risky requests still rely on user judgement alone.

Key takeaways

• Socially engineered email attacks defeat legacy mail controls because trust abuse now happens in identity and behaviour, not just content.
• Cloud migration has made email security an IAM problem as much as a filtering problem, especially when delegated access and approvals are involved.
• The most effective response is to correlate message, identity, and behavioural signals so suspicious requests are validated before they become actions.

Key terms

• Socially Engineered Email Attack: An email-based attack that uses deception, context, and trust to influence a person into taking a harmful action. The message may look legitimate, but the real control failure is often identity validation and behaviour assessment, not simple spam filtering.
• Trust Signal Drift: The gap between a communication that still appears valid to email controls and the reality that its sender identity or intent has changed. In practice, it describes when static delivery checks no longer reflect the true risk of a message, especially in cloud-connected workflows.
• Behavioural Baseline: A normal pattern of communication, timing, and interaction that security tools use as a reference point for detecting anomalies. For identity-aware email security, baselines help show when a message fits the network but not the sender’s established behaviour.

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: How Abnormal Blocks Socially-Engineered Attacks. Read the original.