The Correct Approach to Deepfake Phishing Simulations
The Correct Approach to Deepfake Phishing Simulations
Most deepfake simulations are built to catch people out. The correct approach is built to prove a control. Here are seven deepfake phishing simulation best practices, from scoping to measurement, that turn a cloned voice into evidence your board can act on.
The question is not whether your people can spot a deepfake. It is whether your process holds when nobody does.
We build and run authorized deepfake simulations for enterprise organizations: cloned executive voices from consented audio, live video avatars that join Teams, Zoom and Meet calls, and an AI voice agent that picks up when a target calls back the number we left in a voicemail. We have watched a lot of programs, ours and others, and the difference between a simulation that changes an organization and one that just produces a scary slide comes down to a handful of design decisions.
The short answer: the correct approach to deepfake phishing simulations is to test whether a verification procedure fires before a consequential action, not whether an employee notices that a voice or face is synthetic. Everything below follows from that.
What is a deepfake phishing simulation?
A deepfake phishing simulation is an authorized exercise that uses synthetic voice, video or text impersonating a trusted person, such as an executive, a vendor or an IT support agent, to request a consequential action and measure whether the organization’s verification procedures hold before anything moves.
The phrase that matters in that definition is before anything moves. A well-run deepfake phishing simulation carries the conversation all the way to the edge of the payment, the password reset or the access grant, then stops at the verification boundary. You learn exactly what would have happened, and nothing leaves the building.
The wrong approach and the correct approach, side by side
Many programs drift into the same patterns: a gotcha clip, a quiz about blinking, a single phone call, and a per-person score that ends up in a manager’s inbox. Each of those choices feels reasonable. Together they measure the wrong thing.
What changes when the simulation is designed to prove a control instead of catching a person.
| Dimension | Wrong approach | Correct approach |
|---|---|---|
| Starting point | A clever pretext | A consequential action |
| The question asked | Did they spot the fake? | Did the verification step fire? |
| Channels | One call or one clip | Email, voice, chat and callback, orchestrated |
| Conversation | Pre-recorded | Live and two-way |
| Headline metric | Failure rate per person | Process hold rate per procedure |
| Follow-up | Generic training for everyone | Training for the procedure that slipped |
| Outcome | A scary slide | Evidence a board can act on |
The right-hand column is how every Breacher.ai simulation is designed and reported.
Seven deepfake phishing simulation best practices
Start from a consequential action, not a pretext
The instinct is to start with the story: the CFO on a train, the IT agent with a ticket number. Start one step earlier, with the action that would hurt if it went out. Outbound payments, vendor banking detail changes, credential resets, MFA enrollment or reset, privileged access grants, software installation on request, data exports and physical access.
For each one, ask whether a verification requirement exists, whether it is channel-independent, and whether the person who will be asked can reach it under time pressure. That map is your coverage, and most organizations have never drawn it. The pretext comes last, chosen to pressure the procedure you most need to prove.
Authorize it properly and use consented likeness
A deepfake simulation impersonates a real colleague, so the guardrails matter more than they do for an email test. Get written authorization from leadership, have legal and HR review the rules of engagement, and build cloned voices and video only from audio the impersonated executive consented to. Define the stop point in advance so no funds, credentials or data actually move. Done this way, the exercise strengthens trust instead of spending it.
Orchestrate across channels the way an adversary does
Real impersonation rarely arrives as one perfect call. It is an email that sets up a voicemail, a voicemail that prompts a callback, a callback that moves to a Teams chat with a link. Each stage responds to what the target did at the last one.
Depth of personalization is not orchestration. Getting the name, department and subject line right makes stage one convincing. Orchestration is what stage two does differently because of what happened at stage one. We walk through the return leg in the callback is the simulation.
Make the conversation live and two-way
A pre-recorded clip cannot answer a question, handle a pushback or respond when the target says “let me call you back.” A real caller can, and that moment is where procedures either hold or quietly bend. The correct simulation holds a live, two-way conversation, takes the inbound callback, and joins the meeting as a live video avatar when the scenario calls for it. That is how you test the procedure under the same pressure a real request would apply, from voice to Microsoft Teams.
Measure the procedure, not perception
Whether someone noticed the fake is the least useful number a simulation can produce. Perception does not improve and generation quality improves every quarter, which is why deepfake detection training is a decaying control. A callback to a known number returns the same answer against a crude fake and a flawless one. Measure that.
Report process hold rate, exception rate, time to verify and coverage, each defined by its denominator in the next section. Report them at the organizational level and name every finding against a procedure, not a person. Per-person results are useful for routing training, not for a board slide.
Train the procedure that slipped, in your own terms
When a step does not hold, the follow-up should teach that exact step, in your terminology, aligned to your own policies and controls. Generic content teaches a generic lesson, and hyper-training everyone teaches fatigue. The right module is short, specific and keyed to the failed control, not to the scenario that exposed it.
Track the same control and rank against your peers
A single simulation is a snapshot. Leadership needs context: how this control compares with organizations like yours, and whether it is getting stronger. Follow the same verification control over time, and compare coverage and process hold rate with peers. Those measures are structural, so organizations tested with entirely different pretexts can still be compared fairly.
Seven practices, one principle. Do not grade the person on the fake. Grade the procedure on the request.
What should you measure in a deepfake phishing simulation?
No bank measures whether a teller can eyeball a counterfeit note. They measure whether the teller ran the check. The bill got better. The check did not have to. These are the numbers that tell you whether your check runs, each defined by its denominator.
Did the step fire?
Verification executed through an independent channel, over verification required. The headline number.
How often was it waived?
Checks consciously skipped or granted as exceptions, over checks required. The number that moves as fakes improve.
Is there a step at all?
Consequential actions with a defined verification requirement, over consequential actions identified.
Add time to verify, the elapsed time from request to verification, which separates a working process from a slow one that buckles under urgency. You can see how your organization ranks against its peers on the OSES™ Risk Index, and our social engineering simulation guide covers the full measurement model.
Your pre-launch checklist
- Pick the consequential action first. Name the payment, banking change, reset or access grant the simulation will pressure, and the verification requirement it should trigger.
- Get sign-off in writing. Leadership authorization, legal and HR review of the rules of engagement, and consent from every executive whose voice or likeness is used.
- Define the stop point. The simulation ends at the verification boundary. Nothing real moves.
- Plan at least two stages. Decide how the sequence branches on what the target does, including the callback.
- Agree the metrics before launch. Process hold rate, exception rate, time to verify and coverage, reported against procedures.
- Line up the follow-up. Training for the procedure that slips, ready to go the day results land.
Where this approach stops
Arguments like this get flattened into slogans, so here are the boundaries, stated plainly.
The human is still the control
Procedures are executed by people. We change which behavior we measure, from perception to following procedure under pressure. That is trainable and observable.
Awareness training has real value
We build it. Deepfake training works best when it teaches your own verification procedures rather than a generic list of artifacts.
Machine verification is welcome
Liveness checks, document verification and validation against authoritative sources, especially in the hiring path, are strong controls. We test whether they hold.
Not total invariance. A more convincing fake does not defeat a verification step directly. It raises the pressure to grant an exception, and a procedure only protects the paths where it has been written down. That is exactly why the correct approach measures exception rate and coverage, rather than claiming any procedure is unbreakable.
How Breacher.ai runs deepfake phishing simulations
Breacher.ai was built around the correct approach from day one. The OSES™ simulation platform runs orchestrated, multi-stage campaigns end to end, fully automated: a cloned executive voice that holds a live, two-way conversation, an inbound callback answered by the simulation itself, a live video avatar that joins Teams, Zoom or Meet, and follow-through into email, SMS or the help desk ticket. Live callback handling is a capability most platforms only partially support, and it is where many procedures are decided. Every simulation is aimed at a consequential action and stops at the verification boundary.
When a step does not hold, the Secure Behavior Management platform generates training for that exact procedure in minutes, from your own policy documents, from the simulation finding, or from a news article about a fresh campaign, in any language. It syncs populations from Microsoft Entra ID, supports SSO, exports to SCORM and connects by API and webhooks, and Breacher.ai holds a SOC 2 Type I report with Type II underway. That is what deepfake awareness training looks like when it is tailored to your organization and measured on behavior.
The outcome we design for is simple. A workforce that invokes process defeats our red teams. Building that workforce, and proving it, is the job.
Do not test whether they spot the fake.
Test whether the process holds.
Understand your risk. See how you rank against your peers. Train for what you find.
Thirty minutes. We will show you an orchestrated deepfake simulation run against one of your verification procedures, and the training it generates when a step slips.
Book Your DemoFrequently asked questions
Start from a consequential action rather than a pretext, secure written authorization and consented voice and likeness, orchestrate the simulation across channels the way a real adversary would, stop at the verification boundary so nothing actually moves, measure whether the verification procedure held rather than whether anyone spotted the fake, and train the specific procedure that slipped using your own policies.
A deepfake phishing simulation is an authorized exercise that uses synthetic voice, video or text impersonating a trusted person, such as an executive, a vendor or an IT support agent, to request a consequential action and measure whether the organization’s verification procedures hold before anything moves.
Yes, when it is designed correctly. That means written authorization from leadership, legal and HR review of the rules of engagement, voice and likeness used only with the consent of the person being impersonated, no real funds or data moving, and results reported against procedures rather than used to discipline individuals. The goal is to strengthen a process, not to embarrass a person.
No. Spotting depends on perception, and synthetic media keeps improving while perception does not. Test whether the employee invokes the verification procedure, such as a callback to a known number, because that control works the same against a crude fake and a flawless one.
Use process hold rate, which is verification executed over verification required; exception rate, which is checks waived or skipped over checks required; time to verify; and coverage, which is consequential actions with a defined verification requirement over consequential actions identified. Report them at the organizational level, named against procedures.
A traditional phishing test sends a templated email and counts clicks. A deepfake phishing simulation uses cloned voices, live video avatars and multi-stage, multi-channel sequences that respond to what the target does, and it measures whether a consequential action is verified before it happens.
Run Your Deepfake Simulation the Right Way
Put a live, orchestrated deepfake request in front of your finance team, help desk or executive assistants, and see whether the verification step fires before anything moves.
Book Your DemoLatest Posts
Table Of Contents
About the Author: Jason Thatcher
support@breacher.ai
