AI Phishing Simulation Scenarios: What to Train Employees On in 2026
Voice phishing is now the second-most common initial infection vector, and most programs still only simulate email. Five AI phishing simulation scenarios to build next, with what to teach and how to measure each.
Most security awareness programs simulate one thing: a suspicious email. Meanwhile, the attacks that actually produce intrusions have been drifting away from the inbox for two years. Attackers call the help desk, get an employee to approve an app, steal a live session instead of a password, and send the lure from a domain nobody can block.
This guide covers five scenarios worth adding to your simulation library, based on campaigns documented in 2025 and 2026. For each one: what the employee actually experiences, why the technique works, what to teach, how to build the simulation, and what a passing result looks like.
The Five Scenarios Worth Building First
- An email that already knows the details. Correct project name, correct manager, correct tone, nothing to catch.
- A phone call from IT support, usually with a text arriving first. The caller wants a credential reset or an MFA change.
- An approval screen where nothing is fake. A real vendor domain asks the employee to authorize an app or read back a code.
- A sign-in page that takes the session, not the password. The employee completes MFA correctly and the account is still compromised.
- A lure delivered from infrastructure you trust and cannot blocklist. A real file-share notification, a real code repository, a real thread the employee was part of.
The last section covers what the research actually says about whether simulations change behavior, including the studies that found they don’t.
Your Simulation Library Is Testing a Shrinking Share of the Attack Surface
Mandiant’s M-Trends 2026, drawn from more than 500,000 hours of frontline investigations in 2025, reports that highly interactive voice phishing surged to 11% of initial infection vectors, making it the second-most common way attackers get in, behind exploitation at 32%. In the same body of investigations, email phishing accounted for 6% of observed initial intrusions.
That 6% sits oddly next to the Verizon 2026 DBIR, which puts phishing at 16% of initial access. The two aren’t in conflict. Mandiant measures incidents it was called in to investigate, which skews toward larger intrusions; the DBIR measures a much broader corpus of reported breaches. Different populations, different denominators. Both agree on direction: voice and identity-centric approaches are taking share from the inbox.
The DBIR adds a finding that speaks directly to simulation design. In its analysis of phishing simulation data, “median success in mobile-centric vectors is 40% higher than email.” If your program has never run a voice or SMS simulation, the vector where employees are most likely to fail is the one you have no measurement for.
This is not a training-volume problem. Fortinet’s 2025 Security Awareness Report found that 94% of organizations already run regular training, while 69% still say their employees lack adequate awareness. The useful question isn’t how often you simulate. It’s what you simulate.
Scenario 1: The Email That Knows Where You Work and What You’re Working On
The employee gets a message naming the project they’re actually staffed on, referencing the person who actually approves their expenses, arriving at a plausible moment in the week. There’s no grammatical tell, no mismatched logo, and nothing about the urgency that feels manufactured, which leaves the employee with nothing to inspect.
A study published at USENIX Security 2026 tested this against 7,741 participants. Generic emails drew a 3.9% click rate; emails automatically personalized by a language model drew 10.0%, a 2.74x increase. Human-written personalized emails drew 24.2%, which is the part most coverage skips: automated personalization hasn’t caught up with a skilled human, so this is a floor rather than a ceiling.
The economics change your threat model. The researchers put the cost at roughly $0.03 per personalized email, and about $150 to personalize for all 3,310 users in their sample with usable public information. Targeted phishing used to be reserved for people worth the research time. At three cents a message, everyone is.
One finding should change how you tier risk: participants with low-to-medium public information footprints produced the highest click rates. The employees you probably deprioritize, because they have no public profile and no budget authority, are the least accustomed to receiving anything personalized at all.
What to teach: evaluate the request and the channel it arrived through, not the quality of the writing. Polish is no longer evidence of anything in either direction.
How to build it: personalize to each employee’s profile, role and context rather than sending one template to everyone, and rate each lure’s difficulty using something like the NIST Phish Scale. Without a difficulty rating, a year-over-year drop in click rate might just mean you sent easier emails.
What passing looks like: report rate and time-to-report. A click reported in four minutes beats a non-click nobody mentions.
Scenario 2: The IT Support Call, and the Text That Arrives First
A text lands about a login problem. Twenty minutes later the phone rings. The caller knows the employee’s manager, their device, and roughly what they’ve been working on. They’re friendly, competent, slightly rushed, and they need a code confirmed or a reset approved.
Harvard and Meta researchers ran the largest controlled evaluation of this to date, testing AI voice phishing against 4,100 US adults across 37 conditions. Overall compliance was 16.5%, rising to 36.1% for a cloned-voice scenario involving a relative in distress. Two caveats: compliance was self-reported willingness rather than observed behavior, and the recordings were edited to remove refusals, so live deployment would likely perform worse.
Two findings should change what your curriculum teaches. Caller persuasiveness predicted compliance far better than how human the voice sounded, and neither general AI familiarity nor regular voice-assistant use improved detection accuracy at all. Teaching employees to listen for robotic artifacts trains the wrong signal, and being comfortable with AI protects nobody.
Mandiant’s profile of UNC3944 describes calls to service desks seeking password resets and MFA removals, often after a smishing message softens the target. A separate campaign against US law firms moved from an invoice lure to a help-desk vishing call to a remote-access install to exfiltration inside a single business day. Mandiant’s explanation of why the pretext lands is worth repeating to your workforce: remote and outsourced IT support has made it normal for employees to take instructions from unfamiliar external staff.
What to teach: a fixed callback procedure that never uses a number the caller supplied. The help desk needs its own version of this drill, since they’re the ones being asked to perform the reset.
How to build it: start with voice-only calls, then progress to a call paired with a matching email as one coordinated sequence, because that’s how the real campaigns run.
What passing looks like: whether the callback procedure was followed, not whether the employee sounded suspicious.
Scenario 3: The Approval Screen Where No Password Is Ever Stolen
An employee is asked to approve an application, or to enter a short code on a legitimate sign-in page. The domain is real. The consent screen is real. The Microsoft or Google branding is real, because it is Microsoft or Google. Nothing on the screen is fraudulent except the reason the employee is there.
Mandiant documented UNC6040 impersonating IT support to walk employees through authorizing a malicious version of Salesforce Data Loader on the connected-app page, enabling mass CRM exfiltration. No password was ever typed into a fake form. The employee granted access, and the grant persisted.
Microsoft’s Defender research team published an April 2026 analysis of a device-code campaign that had automated the whole chain. The technical advance worth understanding is that codes were generated dynamically the moment the user clicked, defeating the standard 15-minute expiry window defenders had relied on. Reconnaissance ran 10 to 15 days ahead, and the landing page faked the sign-in window using a browser-in-the-browser technique.
What to teach: nobody should read an authentication code aloud, and nobody should approve an application they didn’t personally initiate. The trigger for suspicion is being asked to approve something unsolicited, not spotting a suspicious URL. There is no suspicious URL here.
How to build it: this is the scenario most awareness platforms can’t simulate natively, and it’s worth being honest about that rather than waiting for a vendor to solve it. Use a tabletop exercise with the real screens, or a controlled test in a lab tenant with a test client ID. A well-run tabletop here beats a well-run email simulation on anything else, because employees have genuinely never seen it.
What passing looks like: refusal plus a report, and whether the employee can articulate what they were being asked to approve. Confusion is the failure mode here, not carelessness.
Scenario 4: The Sign-In Page That Steals the Session Instead of the Password
The employee clicks a link, lands on a sign-in page, enters their credentials, completes the MFA prompt correctly, and reaches the document they expected. Everything worked. The attacker now has their session.
This is commodity capability, not an advanced adversary. Microsoft Threat Intelligence’s March 2026 analysis of the Tycoon2FA platform, published alongside a takedown with Europol, reported campaigns reaching more than 500,000 organizations monthly, with panel access sold from $120 for ten days. The framing Microsoft used in its original writeup of the technique is the line to put in front of employees: this is not a vulnerability in MFA. The session cookie is stolen after authentication, so the attacker inherits the authenticated session regardless of how strong the sign-in method was.
That has a consequence your help desk needs as much as your employees do. A password reset does not remediate this. Sessions and tokens have to be explicitly revoked, or the attacker keeps access straight through the reset. Okta’s threat intelligence team documented a variant where a caller drives the whole thing live, controlling what the target sees in their browser in step with the instructions given on the phone, which defeats any MFA that isn’t phishing-resistant.
What to teach: report it even when the sign-in appeared to succeed, which is exactly the moment people don’t. The response window is the only variable employees control here, and most people never report a login that worked.
How to build it: a credential-harvest simulation is a reasonable proxy and most platforms can run one. Be clear internally that you’re simulating the lure and the sign-in, not the session theft itself.
What passing looks like: time-to-report, and whether the report triggered session revocation on your side rather than a password change. This scenario tests your incident process as much as your people.
Scenario 5: The Lure That Arrives From a Domain You Cannot Block
A file-share notification arrives from a real vendor’s tenant. A link points at a real code-hosting domain. A reply appears inside a thread the employee genuinely participated in last week. Every trust signal your training taught them to check comes back clean.
A large-scale study of enterprise phishing infrastructure, conducted with Barracuda across more than 800,000 delivered phishing emails, found that over one-third originated from highly reputable networks including Amazon and Microsoft. Those networks are stable over time and overwhelmingly carry legitimate mail, which is exactly why they work. The authors’ conclusion was blunt: no single defense such as a static blocklist can work against this.
Cofense Intelligence reports a parallel pattern in code repositories, with 95% of observed Git-repo phishing abuse involving GitHub, and 2025 alone accounting for 45% of all such abuse recorded since 2021. Microsoft has separately documented file-hosting abuse where attackers restrict files to the designated recipient or make them view-only, specifically to stop automated analysis from seeing the payload.
The lure content has adapted to match. A campaign Microsoft analyzed in May 2026 reached more than 35,000 users across 13,000 organizations in three days using a “code of conduct” disciplinary theme. Its most instructive detail was preemptive authenticity: the messages claimed they had been issued through an authorized internal channel and that the links had been reviewed and approved for secure access.
What to teach: any trust signal the sender supplies is worthless, because supplying it is free. Verify against the workflow you expected, not the domain you received.
How to build it: thread-hijack scenarios, file-share notifications from a plausible partner, and at least one lure that loudly asserts its own legitimacy.
What passing looks like: whether the employee checked the expected process. “I wasn’t expecting a document from them, so I asked” is the behavior you’re training.
What the Evidence Says About Whether Any of This Works
The research on phishing training is genuinely mixed.
A field experiment involving 12,511 participants found no significant effect from training on either click rates or reporting rates. In the same study, click rates moved from around 7% on easy lures to 15% on difficult ones, which says considerably more about lure difficulty than about the people receiving them. Meta-analyses of security awareness training do find a positive overall effect, but consistently show behavioral change smaller than knowledge or intention change, and that the stronger the study design, the smaller the measured behavioral result.
One design holds up better. Point-of-error training, delivered at the moment of failure rather than weeks later in a scheduled module, shows roughly a 40% reduction in susceptibility across a 42-study meta-analysis. That’s the mechanism worth building around.
Which raises the question of what the follow-up content should actually be, and it isn’t the annual compliance deck. A course that fires after a failed consent-grant simulation has one job: show the employee the screen they just approved and explain what it granted. That’s a different design goal from a course teaching a policy, and the two shouldn’t share a format. Completion rates favor the short version anyway, with micro-courses typically finishing at rates long-form modules never reach. Match each piece of content to a single goal, whether that’s recognizing a specific attack, changing a specific behavior, or satisfying a specific compliance requirement, and keep the interaction short enough that people finish it while the failure is still fresh.
It’s also worth knowing how to read vendor numbers. A benchmark showing a drop from 33.2% to 4.2% over a year is observational data from customers who bought a product and stuck with it. It isn’t a randomized result and shouldn’t be weighed against controlled studies as if it were.
The honest position: adding these scenarios closes a specific, measurable gap between what you test and what employees will meet. It does not make anyone unphishable, and any program sold on that promise is selling something.
Sequencing, Rotation, and Not Wrecking Employee Trust
These five scenarios are additions to an existing AI phishing training program, not a replacement for one. The sequencing question is which to build first. Start with the scenario matching your most likely intrusion path, not the most alarming one. For most mid-size organizations that’s the IT support call, because the help desk is a small, identifiable group with the authority to reset credentials, which makes it both the highest-value target and the easiest place to see improvement.
Rotate deliberately. Vary lure difficulty on purpose, and leave a cooling period before reusing a sender domain against the same person. Without one, you’re measuring whether people remember last quarter’s test rather than whether their behavior changed.
These scenarios raise the stakes on employee trust in a way email simulations don’t, because cloning a voice and impersonating a colleague is a different kind of exercise. Tell your workforce that simulations happen, including voice ones. Keep the framing non-punitive, route repeat failures to coaching rather than a leaderboard, and make reporting frictionless. Treat over-reporting as a healthy signal: Cloudflare has noted that more than 90% of reports to its internal security team turn out not to be threats, and that employees are never discouraged from sending them.
One practical constraint: voice and SMS simulation isn’t equally permissible everywhere. Telecoms rules, regional privacy law, and works-council obligations all bear on this. Check before you launch.
Platforms That Can Actually Run These Scenarios
Evaluate platforms on two questions rather than template-library size. Which of these five scenarios can the platform natively simulate? And can voice and email run as one coordinated sequence, or only as two disconnected campaigns?
Scenario 3 is the category’s collective weak spot. No mainstream awareness platform simulates OAuth consent grants or device-code approvals well, so expect to cover that one with tabletop exercises regardless of vendor.
Adaptive Security
Adaptive Security positions on multi-channel coverage spanning email, voice, SMS and deepfake-based simulations. A credible fit where the primary gap is channel breadth under one vendor.
Pros
- Broad channel coverage including voice and synthetic media
- Aimed at AI-era threat scenarios rather than compliance content
Cons
- Public documentation provides limited detail for comparing individual capabilities
- Newer entrant, so long-run program data is thinner than incumbents’
Brightside
Brightside is built around multi-vector simulation rather than content breadth, which maps closely to the scenarios above. Its Hybrid Attack runs a voice call and a trackable phishing email as one coordinated workflow rather than two separate campaigns, which is the sequence scenario 2 describes. A tactic builder assembles scenarios from named social engineering techniques, admins can preview a call in the browser before launching, and voice cloning is self-service from a one to two minute recording. Simulations arrive by direct inbox injection over API or mail server, removing gateway whitelisting from the rollout, and a hidden honeypot link separates security-scanner clicks from real human clicks so reported numbers aren’t inflated. Difficulty is aligned to the NIST Phish Scale.
On the learning side, each course is built around one primary goal, either topic awareness, behavior change, or compliance knowledge, with a methodology matched to that goal rather than one format stretched across all three. Delivery is chat-based and interactive, working through short exchanges with Brighty, an interactive learning companion that guides the employee through the material, and courses can use branching, quizzes, mini-games, audio and video where those genuinely support the point rather than decorate it. The library runs in English, French, German, Italian and Spanish, and SCORM-delivered courses count the same as native completions if you already have content you want to keep.
Pros
- Voice plus email as a single coordinated sequence, not two campaigns
- Voice cloning and tactic-level scenario construction are self-service
- No whitelisting required, removing a common rollout blocker
- Honeypot filtering produces cleaner reporting
- Goal-aligned courses in five languages, matched to a single learning goal each
- Positive-reinforcement-only achievements, with no wall-of-shame mechanics
Cons
- No native OAuth consent or device-code simulation
- Narrower content library than KnowBe4 or Proofpoint
Hoxhunt
Hoxhunt has repositioned around human risk management, with adaptive simulations that adjust to individual behavior and micro-training delivered immediately after a failure, which lines up with the point-of-error evidence above. It supports live adaptive vishing conversations and applies a cooling period between simulations against the same person.
Pros
- Adaptive difficulty and immediate post-failure training
- Live adaptive voice conversations supported
Cons
- Enterprise-oriented pricing and rollout effort
- Gamification doesn’t suit every organizational culture
KnowBe4
KnowBe4 offers the largest template and content library in the category, with a self-managed console suiting teams that want to run campaigns without much vendor involvement. If your constraint is compliance coverage across many topics and languages rather than scenario realism, it remains the widest option available.
Pros
- Largest content and template library
- Well understood by auditors, which simplifies compliance conversations
Cons
- Template-driven realism lags purpose-built multi-vector platforms
- Scenario depth beyond email is limited relative to specialists
Proofpoint
Proofpoint’s awareness training extends its email security business, and its main advantage is modelling simulations on threat intelligence from its own detection estate. It partially supports NIST-aligned difficulty rating, which matters if you want results comparable across years, and fits best where Proofpoint email security is already deployed.
Pros
- Simulations informed by the vendor’s own threat telemetry
- Partial NIST-aligned difficulty rating
Cons
- Training is a module within a larger platform rather than a purpose-built product
- Less compelling without the surrounding Proofpoint stack
Phishing Simulation Scenario FAQs
Which scenario should we build first if we can only add one this quarter?
The IT support call. Voice is the vector with the largest gap between how often attackers use it and how often organizations test it, and the help desk is a small enough group to drill properly in a quarter. It also produces the clearest before-and-after signal, because callback procedure compliance is binary and easy to measure.
How often should we rotate scenarios, and does repeating one make the result meaningless?
Repetition is fine and necessary; repeating the same lure against the same person within a short window is not. Leave a cooling period before reusing a sender domain or pretext with someone who has already seen it, and vary difficulty deliberately. Otherwise improvements reflect recognition rather than changed behavior.
Do we need employee consent to run voice or SMS simulations?
Requirements vary by jurisdiction and are stricter than for email. Telecoms regulations, privacy law, and works-council agreements can all apply, particularly in the EU. Most organizations handle this with a general workforce notice that simulations occur across channels rather than per-exercise consent, but confirm your position with legal before launching.
Should we simulate deepfake video calls?
Rarely first. Voice cloning is practical, self-service on several platforms, and covers most of the realistic risk. Video deepfake simulation is typically a scoped managed engagement aimed at a small executive group, and it costs considerably more attention than it returns until the voice and consent-approval scenarios are already running.
If an employee fails a consent-grant or device-code simulation, what should happen next?
Immediate feedback showing exactly what they approved and what access it would have granted. This failure is almost always a comprehension gap rather than carelessness, because most employees have never been taught what a consent screen does. Treat it as a content problem, not a discipline problem, and retest the same group within the quarter.