Because the verification channel itself can now be spoofed in real time. If attackers can imitate a trusted person’s voice or image long enough to complete the exchange, a call-back no longer proves identity on its own. Teams need corroboration from separate workflow, device, or transaction signals.
Why call-back checks stop working when the attacker can speak and look like the trusted person
A call-back only works if the return channel is harder to spoof than the original contact. Deepfake voice and video remove that assumption by letting an attacker participate in the verification step itself. That means the control can validate continuity of conversation, but not the authenticity of the person unless it is paired with separate, harder-to-fake signals.
In practice, the failure is not that the call-back is poorly executed, it is that the security property it relies on has changed. If an attacker can sustain a believable voice or video interaction long enough, the check can return a false positive. That is why call-back needs to move from “identity proof” to “one input among several” in the verification workflow.
For teams reviewing this control, the key question is whether the callback is still anchored to an independent trust source. If the same channel, device, or communication path can be influenced by the attacker, then the verification value drops sharply. The control becomes much stronger when it is tied to an existing account session, a known device, a signed request, or a transaction that can be independently confirmed.
Why deepfake attacks defeat human recognition more easily than process controls
Deepfake attacks exploit the fact that humans are very good at recognising familiarity and very bad at judging synthetic media under time pressure. A convincing voice or face can reduce suspicion, especially when the request fits an expected business context such as finance, executive escalation, or urgent access approval.
Deepfakes, Social Engineering and AI Impersonation Guide is useful because it treats callback verification as part of a broader anti-impersonation workflow, not as a standalone safeguard. The same applies to payment or access requests, where the attacker is relying on a human to accept the authenticity of the interaction before checking the underlying entitlement or transaction record.
Arup deepfake fraud 2024 shows the practical risk: once a live video interaction feels ordinary, the victim may treat the call as confirmation instead of challenge. That is exactly where callback checks become brittle, because the attacker is no longer bypassing the process, they are impersonating the process owner inside it.
The important distinction is that deepfakes do not need perfect realism to succeed. They only need enough realism to carry the conversation long enough for the target to comply. That makes speed, urgency, and social context part of the attack surface, not just the quality of the synthetic media.
What a robust callback control needs to verify instead
A strong callback should verify something the attacker is unlikely to control at the same time as the conversation. That usually means an independent workflow step, a trusted device, a separate communication channel, or a transaction-specific challenge that cannot be answered from a copied script or replayed image.
Deepfakes, Social Engineering and AI Impersonation Guide supports the practical pattern here: use out-of-band verification, confirm from a pre-registered contact path, and validate the request against business records before actioning it. A callback is useful when it is one check in a chained decision, not when it is the only gate.
NIST AI Risk Management Framework is relevant where organisations need a governance lens on synthetic-media exposure, because it encourages mapping the risk to impact, controls, and monitoring rather than treating it as a one-off fraud issue. For practitioners, that usually means testing whether the callback is tied to identity assurance or merely to conversational plausibility.
CISA cyber threat advisories is a useful external reference point for keeping callback abuse and impersonation tactics in the wider threat picture. Deepfake-enabled fraud is most dangerous when it is combined with familiar social-engineering patterns such as urgency, authority, and account takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST SP 800-63 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern | Deepfake callback failure is an AI risk governance issue requiring controls and monitoring. |
| Recommendation — Map deepfake verification risk to AI governance controls and require independent corroboration. | ||
| NIST SP 800-63 | AAL — Authenticator Assurance Levels | Callback checks fail when they are mistaken for strong identity assurance. |
| Recommendation — Require stronger authentication than a callback for high-impact actions. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Authentication assurance needs stronger, verifiable identity signals than a voice callback. |
| Recommendation — Verify that sensitive workflows rely on robust authentication, not conversational confirmation. | ||
Practitioner Guidance
What to prioritise: Treat callback checks as a corroboration step, not an identity proof. If the request can move money, change credentials, approve access, or release sensitive data, require a second signal that the attacker cannot easily mirror in the same interaction.
What to verify: Confirm that the callback lands on a pre-established contact path, references a known transaction, and is checked against a separate system of record. If any of those can be satisfied by the person on the call alone, the control is too weak for high-impact requests.
Common mistake: Teams often trust that “a familiar voice or face” is enough to validate the request. In deepfake conditions, familiarity is exactly what the attacker is trying to manufacture, so the verification rule has to shift from recognition to corroboration.
Practitioner takeaway: The control fails when the same human-facing channel is expected to prove identity and carry the request, so the fix is to separate verification from interaction and make at least one step independent of the attacker’s synthetic presence.