Voice and Video Impersonation: Verifying People Without Trusting Faces

The call comes from a number that looks familiar, and the voice on the line sounds like the director who signs off on payments. The request is reasonable on its face and urgent in tone. Everything about the moment says to act quickly, and that is the reason the process has to be stronger than the moment.

Why recognition stops being evidence

People recognize one another through voice and face, and those cues are fast, usually reliable and rarely examined. They were built for a world where imitating someone convincingly was difficult and expensive. That is no longer the case. Short recordings and public video can support imitations good enough to pass casual recognition, which means the cues an employee relies on can be produced by someone else.

It is worth being precise about the limits. Quality varies, and a poor imitation is easy to hear or see. A good one may not be. Detection tools exist, and some are useful as a signal, but they are not reliable enough to be the only control. A verification process should not depend on whether an imitation can be spotted, since that is exactly the test it is likely to fail under pressure. The same reasoning covers voice notes and recorded messages, which can be fabricated or replayed. A recording is a message to be verified, not proof of who sent it.

Verify through a separate channel

The core principle is out-of-band verification. When a request arrives through one channel, confirm it through a second, independent channel. If a request came by phone, call back using a number already held in your records, not one supplied during the call. If it came by video, confirm through a message in the organization's usual system to a known contact. The point is that an attacker controlling one channel does not control the other.

Be strict about what counts as independent. A reply inside the same thread, a number read out during the call, or an email from an address that appeared in the request are not separate channels. A video call is not a check either, because the call is itself the channel under question, however normal it looks. For each workflow, write down which channels are acceptable for confirmation and which are not.

Use procedures, not memory

Some organizations use shared code words for high-risk requests. They can work if they are agreed in advance, stored outside the channels an attacker might control, changed on a schedule and used only for defined actions. They fail when they are guessable, easily overheard or requested by a caller who should not know them. A code word is a check on the procedure, not a substitute for one.

A more dependable approach is a documented call-back procedure with steps, owners and required evidence. The person handling the request follows the steps in order, and the outcome does not depend on how convincing the caller sounded. If verification fails, the procedure says what happens next, and the default is that the request waits.

Put approval into the workflow

Payments, changes to supplier bank details and changes to access rights should require approval from more than one person, through systems that record each approval. Set thresholds so that large or unusual requests always reach a second approver. The second approver should never be the person who made the request or someone who reports to them, because a reporting line is one more thing a pressured request can exploit. Add a waiting period when payee details change, so that a newly added account cannot receive money on the day it is added.

The procedure needs one rule above the others: urgency does not waive a step. Requests that stress speed, secrecy or the authority of the sender deserve the most care, because those features are what a social engineering attempt is built to produce. A workflow that depends on a person resisting that pressure in the moment will fail some of the time. A workflow that enforces the steps in its system makes the pressure much less effective.

Train without causing panic

Training should teach the procedure rather than the art of detecting fakes. Ask staff to practice the call-back and approval steps in a realistic drill, and make clear that pausing to verify is the expected behavior. Recognize people who verify a request that turns out to be genuine, because that is the behavior you want repeated.

Avoid training that makes people feel they must spot a fake by ear or by eye. That message creates anxiety and moves the risk into judgment under pressure. Measure whether the procedure was followed, not whether people were fooled in a simulation. Simulations should be fair, with clear reporting routes, and they should never shame the person who was tested.

Practice a procedure with a colleague

Choose one workflow that matters, such as changing a supplier's bank details. Write a one-page call-back procedure for it. List each step, who performs it, what evidence is needed before the next step, and what happens if verification fails. Name the channel used for confirmation, and state which channels are not acceptable.

Then walk a colleague through the procedure as a tabletop exercise. Give them a scenario in which a convincing request arrives under time pressure, and watch where they hesitate or where the steps are unclear. Each hesitation points to a gap in the document. Close those gaps before anyone needs the procedure for real.