An impersonation scam is a fraud in which an attacker pretends to be a trusted person or organisation to trick a victim into sending money, data, or access. Defenders and users should verify requests through an independent channel, watch for urgency and payment changes, and train staff to challenge identity assumptions.
How Impersonation Scams Work
An impersonation scam succeeds by borrowing trust. The attacker may pose as a colleague, executive, supplier, bank, regulator, help desk agent, or other familiar authority so the victim treats the request as routine rather than suspicious.
The core technique is social engineering, not technical exploitation. The scammer uses a believable role, a plausible backstory, and a request that feels time-sensitive or business-critical, then pushes the target toward sending money, sharing information, or approving access before normal verification can happen.
Common Impersonation Patterns
Impersonation scams are often classified by the role being faked, such as executive impersonation, vendor impersonation, bank impersonation, customer support impersonation, or government impersonation. The fake identity is chosen to fit the action the attacker wants the victim to take.
Some variants focus on payment diversion, such as invoice redirection or authorised push payment fraud, while others aim at data theft, credential capture, or remote access. In practice, the scam works best when the victim expects the request to be legitimate and has a reason to comply quickly.
A useful way to understand the pattern is to compare it with structured payment-fraud guidance such as Authorised Push Payment (APP) Fraud Guide, which shows how trust, urgency, and payment change requests are commonly combined.
Why Impersonation Scams Are Effective
These scams work because people naturally rely on context: display names, email threads, caller ID, logos, familiar language, and expected workflows. That context can be copied or manipulated, so the appearance of legitimacy is often enough to bypass casual judgement.
Impersonation also exploits urgency and authority. A request that is framed as confidential, urgent, or coming from a senior person reduces the chance that the target will stop and verify it through a second channel. The attacker does not need perfect impersonation, only enough credibility to trigger action.
When impersonation is paired with account compromise or infrastructure abuse, the risk can extend beyond a single fraudulent request. For example, identity compromise in cloud environments can make a fake internal request appear far more convincing, which is why identity assurance and trust boundaries matter even when the incident begins as a scam.
How to Reduce Exposure
Defence starts with process, not just awareness. Organisations should require independent verification for payment changes, account changes, and access-related requests, especially when the request is unusual, urgent, or outside the normal business flow.
Training should focus on recognising pressure tactics, not memorising a checklist of scam types. People need to know that a request can look polished and still be fraudulent, and that it is acceptable to pause and verify rather than act immediately.
Technical and procedural controls also help reduce exposure. Payment controls, callback procedures, mail and domain protections, and stronger identity verification all make it harder for a scam to succeed. Where a request is tied to access or login activity, a separate verification step should be treated as mandatory rather than optional.
For identity-sensitive or delegated access workflows, defensive thinking should also include token and trust handling. Standards such as RFC 8693: OAuth 2.0 Token Exchange show why on-behalf-of flows must be tightly governed, because abuse of delegated trust can make impersonation harder to spot.
Risk and Threat Considerations
Impersonation scams are dangerous because they turn normal trust relationships into attack paths. The immediate loss may be a fraudulent payment or data disclosure, but the broader risk is that one successful deception can create repeatable access to money, accounts, or internal workflows.
Failure mechanism: The victim accepts a forged identity as genuine and completes the requested action without an independent trust check, allowing the attacker to convert social trust into unauthorised transfer, disclosure, or access.
Impact: Organisations can suffer direct financial loss, credential or data exposure, secondary fraud, and reputational damage, and they may also inherit longer-lived compromise if the scam was used to gain account access rather than just a one-time payment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1656 — Impersonation | Covers adversaries posing as trusted parties to gain compliance or access. |
| Recommendation — Map impersonation behaviour to T1656 and train users to verify requests through an independent channel. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Requires stronger user authentication where fake identities seek trusted access. |
| Recommendation — Strengthen IA-2 enforcement so users must authenticate before sensitive requests or approvals are accepted. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports control of who can request, approve, or alter access and payment details. |
| Recommendation — Tighten account governance so impersonation cannot easily exploit privileged request paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | Addresses controlled access decisions that impersonation scams try to subvert. |
| Recommendation — Use PR.AA-05 to enforce approval checks before money, data, or access changes are processed. | ||
Practitioner Guidance
Why practitioners should care: The key control question is whether the business can safely distinguish a legitimate request from a convincing impersonation before money, data, or access changes hands. If the answer depends on human judgement alone, the process is fragile.
What to watch for: Requests that are urgent, confidential, off-process, or paired with a change in payment destination, banking detail, or account access deserve extra scrutiny. Any request that asks someone to bypass the usual verification path should be treated as suspicious until independently confirmed.
Practitioner takeaway: The strongest defence is to make verification routine, separate, and expected, so that challenging an identity claim is a normal part of the process rather than an exception.
Related resources from NHI Mgmt Group
- How should crypto compliance teams adjust controls when scam revenue falls but impersonation scams keep rising?
- How should investigators trace impersonation scam proceeds across exchanges and crypto ATMs?
- What are the signs that a crypto impersonation scam is part of a larger coordinated group?
- What should consumers do after spotting a fake asset recovery website linked to an impersonation scam?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org