How should organisations reduce the risk of deepfake scams in live calls and messaging apps?

The strongest control is to verify identity through a channel that the attacker cannot easily fake. Teams should teach users to pause before trusting urgent requests, confirm the person through a known contact method, and use verified identity checks where available. Digital ID style verification helps because it swaps trusted details rather than relying on voice, video, or profile images alone.

Why live-call deepfake scams work so well

Deepfake scams succeed when the attacker can exploit speed, urgency, and people’s habit of trusting familiar voices or faces. The practical failure is not only synthetic media quality, it is the assumption that a live-looking call or message is itself proof of identity. Once staff rely on appearance alone, the scammer only needs one persuasive interaction to trigger payment, access, or disclosure.

A stronger control is to shift verification away from what is easy to imitate and toward a known, independent channel. That means using pre-established contact details, agreed callback procedures, or a separate verification step before acting on anything unusual. Where digital identity verification is available, it is useful precisely because it checks trusted attributes rather than voice, video, or profile images.

One useful reference point is that organisations often struggle more with secret and trust weaknesses than with the media trick itself, as NHIMG’s Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. The lesson for deepfake defence is similar, trust the verification path, not the surface appearance.

Controls that reduce scam success in calls and chat

The most effective defence is layered: process, user behaviour, and technical verification should all reinforce each other. For calls, that means a hard rule that urgent requests for money, credential changes, or account recovery must be validated through a known method, not answered in the same session. For messaging apps, the same rule applies when a contact suddenly asks for a code, a payment, or a change in instructions.

Training should focus on the moment of decision. Users do not need to become deepfake experts, they need a simple habit: pause, verify, then act. That habit matters because scammers often combine a convincing voice with time pressure, a plausible story, and social proof from a compromised account or spoofed number. The right control is not perfect detection of synthetic media, it is reducing the chance that a single channel can authorise a sensitive action.

Practically, teams should also predefine what counts as a high-risk request. Examples include changes to bank details, password resets, MFA resets, invoice redirection, confidential data sharing, and approval of unusual transfers. Any request in those categories should trigger a second check through a known channel, even if the call sounds authentic or the message looks like it came from a senior person.

Risk and Threat Considerations

Deepfake scams create both social-engineering risk and verification risk, because they target the control gap between “looks real” and “is authorised.” The main exposure is that a single convincing interaction can bypass informal trust, especially in finance, executive support, customer service, and helpdesk workflows where speed often outruns scrutiny.

Failure mechanism: The attacker uses synthetic voice, video, or chat impersonation to trigger an action that should have required out-of-band confirmation, then exploits urgency or authority to prevent the victim from checking a second source.

Impact: Organisations can suffer fraud, account takeover, unauthorised disclosure, and downstream trust erosion, especially when staff believe the initial interaction already proved identity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 5 — Account Management	Controls high-risk approval and account-change workflows targeted by impersonation scams.
	CIS 6 — Access Control Management	Limits unauthorised actions that succeed when identity is accepted from a fake channel.
Recommendation — Require out-of-band verification before approving payments, resets, or privileged changes. Enforce least privilege and separate approval paths for sensitive requests.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Directly supports strong verification and access decisions for high-risk requests.
	PR.AT — Awareness and Training	Users must recognise urgency, impersonation, and verification failures in scams.
Recommendation — Use strong identity verification before executing sensitive actions from calls or chat. Train staff to pause and verify any urgent request that changes money, access, or data.
NIST SP 800-63	IAL — Identity Assurance Level	Supports choosing stronger verification when a transaction needs higher confidence.
	AAL — Authenticator Assurance Level	Supports using stronger authentication for sensitive actions than for routine messaging.
Recommendation — Apply higher-assurance identity proofing for high-impact approvals and recovery flows. Require phishing-resistant authentication for critical approvals and account changes.

Practitioner Guidance

What to prioritise: Protect the highest-impact requests first, such as payments, account recovery, supplier bank changes, and MFA resets. Those are the requests most likely to be exploited because a single false approval can create immediate loss or broader compromise.

What to verify: Make sure the verification step is genuinely independent of the channel under attack. If the callback number, chat account, or email thread can be controlled by the scammer, it is not a verification control, it is just another part of the attack path.

What good looks like: Staff consistently stop when a request is unusual, confirm through a known contact route, and escalate when the requester resists verification. The best outcome is not perfect scam detection, it is that suspicious requests fail closed before any material action is taken.

Practitioner takeaway: Deepfake resistance is mostly a trust-design problem, so the best control is to ensure no single live call or message can authorise something important on its own.