Why Voice and Video Are No Longer Proof of Identity
How to Verify Identities Against AI-Powered Impersonation Use out-of-band verification through channels the attacker does not control. Voice and video are no longer reliable identity indicators. When someone appears to be a[...]
How to Verify Identities Against AI-Powered Impersonation
Use out-of-band verification through channels the attacker does not control. Voice and video are no longer reliable identity indicators. When someone appears to be a trusted executive requesting sensitive action, verification must occur through a separate channel that cannot be manipulated by the same attacker. This means callbacks to known numbers, authentication through internal systems, or pre-established verification codes.
Why can’t employees trust voice and video confirmation?
Voice cloning technology requires only three to five seconds of audio to produce a convincing imitation. Real-time video deepfakes can impersonate anyone with sufficient training imagery. The implicit trust that humans place in recognising familiar voices and faces no longer provides security assurance.
High-profile executives are particularly vulnerable because they have abundant public audio and video content available: webinars, investor calls, conference presentations, podcast appearances, and social media. Attackers can obtain this material without any access to internal systems.
What is out-of-band verification and how does it work?
Out-of-band verification uses a communication channel separate from the one where the request originated. If an attacker compromises or manipulates one channel, they are unlikely to control another simultaneously.
| Request Channel | Verification Channel | Why It Works |
| Video call (Teams/Zoom) | Callback to known mobile number | Attacker would need to control the executive’s phone to intercept |
| Voice call | Internal messaging system (Slack/Teams chat) | Requires account compromise in addition to voice cloning |
| In-person confirmation | Physical presence cannot be faked remotely | |
| Any remote channel | Pre-shared verification code/passphrase | Attacker does not have access to information shared prior to attack |
What verification procedures should organisations implement?
Effective verification procedures share common characteristics: they use channels attackers cannot easily access, they are documented and understood before an attack occurs, and they apply consistently regardless of apparent urgency or authority.
For financial transactions:
Any wire transfer or payment change request above a defined threshold requires callback verification to a pre-registered phone number. The number must be documented in the system before the request, not provided during the request. Two-person approval with independent verification by each approver.
For sensitive data access:
Requests for credential resets, access grants, or data exports require confirmation through the internal ticketing system with manager approval. Verbal or video requests do not override documented approval workflows.
For urgent executive requests:
Establish a verification code system where executives have pre-shared passphrases or codes that can be requested during any call. The code should rotate periodically and be known only to the legitimate parties.
How do attackers try to bypass verification procedures?
Attackers use urgency and authority to pressure employees into skipping verification. Common tactics include claiming the standard procedure will cause critical delays, asserting that verification is not needed because the identity is obvious, and implying consequences for the employee who does not act immediately.
Red team testing consistently shows that authority bias can override documented procedures. Employees who would normally follow verification steps may skip them when a perceived executive expresses impatience or urgency. Procedures must be designed with this pressure in mind.
Effective countermeasures include clear policy that verification cannot be waived regardless of urgency, executive buy-in where leadership explicitly supports verification even when it applies to them, and removing negative consequences for employees who follow procedure and cause legitimate delays.
What role should technology play in verification?
Technology can support verification procedures but should not replace process controls entirely. Deepfake detection tools are improving but are not yet reliable enough to serve as the sole defence layer.
Useful technology controls include: multi-factor authentication on all financial systems, digital signatures for transaction approvals, audit logging of all high-value requests, and automated alerts for unusual request patterns.
Technology controls work best when they enforce the process rather than replacing it. A system that requires two authenticated approvers provides a technical barrier even if one person is deceived by a deepfake.
How do organisations test whether verification works?
Red team assessments that include AI social engineering simulations test whether verification procedures hold under realistic conditions. These assessments use voice cloning and video deepfakes to attempt the same attacks that real adversaries would deploy.
Testing reveals whether employees follow documented procedures when facing apparent authority pressure. It identifies specific workflow gaps where verification can be bypassed and validates whether the organisation’s training and awareness investments are effective.
Frequently Asked Questions
What if the executive says the verification code system is too cumbersome?
Executive buy-in is essential for verification procedures to work. Without leadership support, employees face impossible pressure to skip procedures. Frame verification as protecting the executive and the organisation, not as bureaucratic overhead.
Should verification apply to all requests or only high-value ones?
Define thresholds based on risk. Financial transactions above a certain value, access to sensitive systems, and requests involving confidential data should always require verification. Low-risk routine requests may not need the same level of scrutiny.
How do we verify identity when someone is travelling or has limited connectivity?
Establish fallback verification methods in advance. Pre-shared codes work regardless of connectivity. For extended travel, designate an alternative approver or delay non-urgent requests until normal verification is possible.