Watch for vendor requests that create urgency, bypass normal approval paths, or ask for payment or account changes outside established channels. Repeated graymail, inconsistent sender behaviour, and requests that rely on trust rather than verification are strong indicators that business email is being used as an identity attack surface.
What the signs mean in practice
Email impersonation becomes an identity risk when the sender relationship is being used to steer decisions, not just to send a message. The warning signs usually show up in the process around the email: requests for payment, bank detail changes, password resets, payroll edits, or urgent exceptions that arrive outside the normal approval path.
At that point, the concern is not only spoofing. It is that a trusted identity, or something that looks close enough to one, is being used to move work, override checks, or trigger action before verification happens.
Look for messages that create time pressure, discourage callbacks, or ask the recipient to keep the request private. Those patterns matter because they aim to weaken the control that should sit between a request and an approved business action.
Where the boundary between email fraud and identity abuse shifts
Impersonation becomes more serious when the same message pattern keeps targeting the same decision points, such as finance, HR, vendor management, or executive assistants. Repeated graymail, inconsistent sender behaviour, and lookalike domains are early indicators; direct requests for account changes, invoice redirection, or new payment instructions show that the attacker is trying to exploit trust in an identity relationship.
That boundary also shifts when the mailbox itself becomes part of the attack path. If an attacker can reply from a compromised account, create believable thread continuity, or exploit mailbox rules and delegated access, the risk is no longer just message authenticity. It is an access and authority problem.
Security teams should treat any email that combines urgency with an unusual request channel as a potential identity event, not only a phishing event. Email Identity and BEC Guide is useful here because it ties sender authenticity, mailbox abuse, and payment verification into one operational view.
What usually changes before a compromise is visible
Most organisations do not notice the risk because one message looks strange. They notice it because a pattern develops: the same kind of request keeps arriving, the senders vary slightly, the language becomes more directive, and the request depends on trust rather than verification. That is often the moment when business email is becoming an identity attack surface.
Another signal is when normal controls are quietly bypassed. If approvals move from a ticketing or procurement workflow into email-only decisions, the attacker has found a weaker control path. If staff start accepting email as sufficient proof for financial or access changes, the organisation has created a low-friction route for impersonation to become fraud.
Mailbox takeover, reply-chain abuse, and token or consent abuse can make the impersonation feel legitimate even when the original message was not. For that reason, indicators should be reviewed against both sender authenticity and the authority implied by the request. The OWASP Non-Human Identity Top 10 is a useful external reference for the broader identity-security failure modes that often sit behind trusted-account abuse.
Risk and Threat Considerations
Impersonation becomes material when it can redirect money, reset access, or override established approval paths. The risk is highest when employees trust the sender relationship more than the request verification process, because attackers can then turn a convincing message into an authorised-looking business action.
Failure mechanism: The attacker exploits urgency, familiarity, or thread continuity to bypass a check that should validate the request independently of the email.
Impact: Payments can be rerouted, credentials or account settings can be changed, and a compromised or spoofed identity can be used to spread trust to other targets.
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 OWASP API Security Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Impersonation often follows theft or misuse of trust material and mailbox access. |
| NHI-04 — Insecure Authentication | The question centers on sender authenticity and weak verification of trusted identities. | |
| NHI-05 — Overprivileged NHI | Compromised mail or delegated access becomes more damaging when authority is too broad. | |
| Recommendation — Reduce exposed trust material and rotate any credentials that enable message or account abuse. Strengthen authentication and verification so requests cannot rely on appearance alone. Limit mailbox and delegated access so impersonation cannot trigger high-impact actions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Sender authenticity and account takeover are identity issues analogous to broken authentication. |
| Recommendation — Require stronger authentication for any workflow that can change payment or account data. | ||
Practitioner Guidance
What to prioritise: Focus first on request types that can move money, change access, or alter vendor records, because those are the highest-value impersonation targets. If those requests are still being approved from email alone, the organisation has a control problem, not just a spam problem.
What to verify: Verify whether staff have a defined out-of-band check for payment changes, bank detail updates, password resets, and executive requests. The most useful test is simple: can a convincing message still trigger action without a separate trust check?
Practitioner takeaway: When email starts influencing high-impact business decisions without independent verification, the risk has moved from message hygiene to identity abuse, and the control objective should shift to proving authority before action.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- How should security teams validate identity in AI-assisted email workflows to reduce impersonation risk?
- What are the signs that legacy identity systems are becoming a budget risk?
- What are the signs that an identity platform’s extensibility is becoming a governance risk?