What signals help detect email impersonation before money moves?

The most useful signals are deviations in sender-recipient relationships, request timing, tone, and thread history. A request that fits the mailbox but not the relationship is a stronger warning than a suspicious link. Teams should escalate any payment or vendor-change request that breaks the normal communication pattern.

Why This Matters for Security Teams

Email impersonation is rarely detected because the message looks obviously malicious. It is usually detected too late, after the request has already fit the inbox well enough to trigger a payment, vendor-bank-change, or invoice workflow. The strongest warning signs are behavioural: a new urgency pattern, a sender who is “right” but not normal for the relationship, and thread history that does not match how the organisation actually communicates. That is why mailbox security, finance controls, and identity governance have to be treated as one problem, not three separate ones. Guidance from the NIST Cybersecurity Framework 2.0 reinforces this integrated view of detection and response, while NHIMG’s Top 10 NHI Issues shows how credential and access weaknesses often turn a single impersonation into a business event. If the target can approve payments, update vendors, or forward messages, the attacker does not need perfect phishing tradecraft, only a believable operational context. In practice, many security teams encounter email impersonation only after funds have moved, rather than through intentional review of communication anomalies.

How It Works in Practice

Effective detection looks for mismatches between message content and the normal relationship, not just bad links or spelling errors. The most reliable signals usually appear across four layers:

• Relationship drift: the sender is known, but not normally involved in this type of request, or the recipient is unusual for the thread.

• Timing anomalies: the request arrives outside the normal cadence, often with urgency that suppresses verification.

• Thread history gaps: the message claims continuity, but the visible thread is missing expected prior context, replies, or signatures.

• Process-breaking asks: the content pushes bank detail changes, payment exceptions, or invoice overrides that bypass the standard approval path.

For defenders, this means building detection around business process signals, not only email hygiene. Current guidance suggests combining mailbox intelligence with payment controls, vendor-master change alerts, and step-up verification for any request that touches money. NHIMG’s NHI Lifecycle Management Guide is useful here because impersonation often succeeds when identity, approval, and revocation controls are fragmented. The practical goal is to make a suspicious request hard to complete even if it reaches the inbox. That includes callback verification on known numbers, dual approval for bank changes, and alerting when an external sender suddenly inherits a trusted thread. These controls tend to break down when finance teams can complete exceptions faster than security teams can validate relationship context because speed becomes the attacker’s advantage.

Common Variations and Edge Cases

Tighter payment controls often increase operational friction, requiring organisations to balance fraud resistance against closeout speed and vendor service levels. Not every impersonation is a spoofed domain or a compromised mailbox. Some attacks use a real account, an internal compromise, or a subtly altered reply chain, which is why “look for suspicious links” is usually too narrow. Best practice is evolving toward context-aware review, but there is no universal standard for this yet, especially across shared mailboxes, outsourced accounts payable, and executives who routinely bypass normal queues.

Two edge cases matter most. First, executive communications often look irregular by design, so a high-trust mailbox can generate false positives unless teams baseline who normally sends what, to whom, and when. Second, vendor communications can change legitimately during mergers, staffing changes, or bank migrations, which means investigators should verify the relationship, not just the text. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks helps frame the broader identity risk: once trust is established in a channel, downstream abuse often looks routine until money moves. For teams handling high-value payments, the safer pattern is to treat any request that changes financial instructions as an identity event, not a simple email event.

Related resources from NHI Mgmt Group

• What signals show that email security controls are no longer keeping up?
• Why do vendor fraud and impersonation attacks bypass legacy email defenses?
• How should security teams detect business email compromise without relying on payloads?
• How should security teams detect identity-based attacks that move through email and login paths?