Impersonation scams can be reduced by verifying requests through a separate trusted channel before acting. Train staff and customers to check for urgency, payment redirection and unusual identity claims, and use call-back procedures, approval workflows and payment confirmation. Monitor lookalike domains, spoofed accounts and social engineering attempts that target finance, HR and support functions.
How impersonation scams succeed in practice
impersonation scam work because the attacker borrows authority, not because the target lacks intelligence. The most effective versions create pressure, urgency, or embarrassment, then route the victim into a fast decision path where normal checking breaks down. That is why the core mitigation is to slow the decision, separate confirmation from the original request, and make it easy to verify the requester independently.
Controls that rely on the same communication channel as the scam are weak by design. A reply to the suspicious email, text or call can be intercepted, spoofed, or socially engineered again. Organisations get better results when they require out-of-band verification for payment changes, account changes, and sensitive approvals, especially where finance, payroll, HR, executive support, or customer support teams are exposed to high-value requests.
Which mitigations reduce the attacker’s leverage
Training helps, but only when it reinforces specific behaviours that are hard for attackers to bypass. Staff should be taught to treat urgency, secrecy, payment redirection, and requests for unusual identity validation as warning signs, then check those requests through a trusted second path. Customer-facing teams need the same discipline, because social engineering often targets whichever person can be persuaded to make the next approving click or transfer.
Process design matters as much as awareness. Call-back procedures, approval workflows, dual control for payment changes, and explicit payment confirmation steps reduce the chance that one compromised conversation becomes a completed fraud. For organisations handling payments or identity-sensitive requests, Authorised Push Payment (APP) Fraud Guide is directly relevant because it covers scam patterns, confirmation checks, and bank-side controls that lower the chance of a successful redirection.
Where monitoring and verification should focus
Impersonation scams often leave weak but useful signals before the payment or data loss happens. Look for lookalike domains, spoofed sender accounts, unusual requests arriving outside normal business patterns, and attempts to move a conversation away from established channels. Monitoring should pay special attention to the teams most likely to receive authority-borrowing requests, because finance, HR, support, and executive operations are common choke points.
Verification should also include the identity claims themselves. If a message claims to come from a senior leader, supplier, bank, or internal service desk, confirm the request against known contact data rather than the details in the message. Where email and identity infrastructure are part of the threat path, Entra ID actor token flaw (CVE-2025-55241) is a useful reminder that impersonation risk can also be amplified by account or tenant compromise, not just by social engineering alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Impersonation scams exploit weak request verification around payment and account changes. |
| Recommendation — Enforce approval and verification steps before changing accounts or payment details. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Separate verification and approval reduce abuse of trusted identities in scam-driven requests. |
| Recommendation — Require independent verification before authorising sensitive actions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Spoofed accounts and impersonation depend on weak identity verification paths. |
| Recommendation — Harden authentication checks where requests can be submitted or accepted. | ||
| MITRE ATT&CK | T1656 — Impersonation | The subject is the adversary tactic of pretending to be a trusted party. |
| Recommendation — Map observed scam lures to impersonation tactics and build detections around them. | ||
Practitioner Guidance
What to prioritise: Put the strongest friction in front of payment changes, bank-detail changes, and account changes. Those are the moments where impersonation scams convert from a conversation into a loss, so they deserve the most robust callback and approval controls.
What to verify: Test whether the organisation can independently verify a request without relying on the channel used to deliver it. If staff can only validate by replying in the same thread, calling a number in the email, or trusting a caller ID, the control is too weak.
Common mistake: Treating awareness training as the main control while leaving business workflows unchanged. If the process still allows a single person to approve a sensitive request under pressure, the scammer only needs one mistake.
Practitioner takeaway: The best mitigations combine human scepticism with workflow friction, because impersonation scams succeed when an attacker can compress verification into the same moment as the request.