The Help Desk Callback Verification Script: What to Say and When

A phone call can now undo everything your security budget bought. In September 2023, an attacker called MGM Resorts’ IT help desk, pretended to be an employee, and talked an agent through a password reset and an MFA re-enrollment. No malware. No exploit. The intrusion cascaded into a ransomware attack that MGM later said cost the company about $100 million. The same playbook hit Caesars for a $15 million ransom, and in 2025 it hit Marks & Spencer through an outsourced help desk.

Mandiant’s M-Trends 2026 report, built on more than 500,000 hours of incident response work, now ranks voice phishing as the second most common way attackers get in, and the number one way they get into cloud environments at 23% of cases. CrowdStrike measured a 442% surge in vishing during 2024 and watched it double again between late 2025 and mid-2026.

The attack works because the help desk does everything right except verify who is on the phone. The agent issues a legitimate credential to a criminal, and from that moment your own systems vouch for the attacker. This article gives you the fix the way help desks need it: exact scripts, a clear verification standard, and a workflow for the cases where verification stalls.

Why Knowledge-Based Verification Fails Against Scripted Callers

Most help desks still verify callers the same way they did a decade ago. Employee ID. Date of birth. Manager’s name. Maybe the last four digits of a phone number. The problem is that none of this proves identity anymore. It proves access to public data.

LinkedIn tells an attacker your org chart, your manager’s name, and your job title. Breach dumps supply dates of birth, phone numbers, and partially masked passwords. Data brokers sell the rest. Pindrop analyzed confirmed fraud calls at financial institutions and found fraudsters pass knowledge-based verification up to 90% of the time. When the check is predictable, the attacker only needs research, not skill.

Caller ID is equally useless. Spoofing a phone number has been trivial for decades, and SIM swapping lets an attacker take over the real number entirely. A matching caller ID is a detail the attacker supplied.

Help desks are measured on average handle time and first-call resolution. An agent who walks a caller through a five-minute reset looks productive. An agent who escalates to a callback verification looks unhelpful, and in some organizations gets coached for it. The metrics push in exactly the wrong direction, and attackers know it. The r/pcicompliance version of this attack even has a name for the trick: borrowed urgency. “The payment run is in twenty minutes” exists to make you skip the step you would normally take.

The 442% figure is CrowdStrike’s measurement of its own telemetry, so treat it as a directional signal rather than a market census. And Pindrop’s 90% KBA pass rate comes from financial institutions, the best-defended contact centers in the world. In a corporate help desk with no fraud team watching, the pass rate is likely worse.

Two Independent Checks, One Resistant to Voice Impersonation

Here is something worth writing into policy: no password reset or MFA change without two independent checks, and at least one of them must be resistant to voice impersonation. That one rule, adopted by a growing number of security teams, closes the gap no single tool covers.

Why two? Because every individual check has a failure mode. A callback alone fails if the directory data is stale. A video ID check fails against a real-time deepfake, which is exactly what happened in the Arup case, where a finance employee wired $25.6 million after a meeting where every other participant was synthetic. Pairing checks means the attacker needs to defeat two different systems in one phone interaction, which is a different class of problem.

Use this table to build your check menu.

Check	How it works	Voice-impersonation resistant?
Directory callback	Agent calls the number already in HR or the identity system, never one the caller provides	Yes, if the record is current
In-session portal approval	Caller approves the reset from an authenticated corporate portal session	Yes
Device-bound prompt	Verification push to a device the user already has enrolled and controls	Yes
On-camera ID	Live video against the internal employee photo database	Partially
Manager attestation	Approval logged in the ticketing system by a verified manager	Partially

What does not count as a check:

• Any phone number, email, or link supplied during the request itself
• A reply to the email thread that started the ticket
• Voicemail, or an assistant confirming on the executive’s behalf
• Security questions, employee ID, date of birth, or manager name used alone
• “The voice sounded right” or “the caller knew our processes”

NIST SP 800-63B, the federal standard for digital authentication, draws the same boundary from the standards side. It restricts use of the phone network for out-of-band delivery and states that VoIP and email cannot serve as out-of-band channels because they can terminate on multiple endpoints. If the federal baseline for authentication will not accept email as proof, your help desk should not either.

Word-for-Word Scripts for Each Scenario

Scripts beat judgment under pressure. A smooth caller can out-argue an improvising agent, but nobody can talk their way past a line the agent reads the same way every time. Adapt the wording to your culture, but keep the structure: verify first, help second.

The opening, for any sensitive request:

“Totally happy to help. Quick verification first, and then we’ll get this sorted.”

The wording frames verification as routine instead of as suspicion, which keeps the caller cooperative and keeps the agent from feeling like the villain.

Password or MFA reset, standard employee:

“I can start that reset now. Two quick steps. First, can you confirm the request from your authenticated portal session? I’ve sent the approval prompt now.”

“Second, our policy requires me to call you back on the number we have on file. I’ll do that now, and once we’ve spoken there, the reset takes about a minute.”

The two steps are the two checks. The callback number comes from your directory, never from the caller and never from caller ID.

Executive or privileged account:

“Accounts with elevated access follow an enhanced process. I’ll need a quick video call where you can show your corporate ID against our photo database, and I’ll also need your manager’s confirmation logged in the ticket before I can action the reset.”

Privileged resets deserve the higher-friction path. If the process is uniform, attackers reset an admin account as easily as a standard one, and they count on exactly that.

The refusal line, when verification fails or the caller resists:

“Policy requires callback verification for every reset. I can’t skip that step, even for an urgent request. I’m initiating the callback now, and we’ll continue as soon as it’s confirmed.”

That last sentence is the one worth rehearsing. It is a sanctioned script the agent can read to a vice president without fearing the aftermath, and it works only if leadership has said in writing that nobody can waive the control on the call. Without that clause, the impersonator simply says “skip the callback this once,” and the script collapses.

Handling voicemail and gatekeepers:

“I’ve reached the number on file but got voicemail. I’ll hold the ticket open until I can confirm the request directly. Is there another pre-registered contact point you’d like me to try?”

A callback that reaches voicemail verifies nothing, and an assistant confirming “yes, that was really the CEO” verifies almost as little. The callback has to reach the actual person, and policy should say so explicitly, because polite-but-wrong confirmations are how a staged call survives a half-hearted verification.

When the Caller Cannot Be Verified

Here is the scenario every help desk dreads and almost no security guidance answers. A real employee calls. Their phone is lost at an airport. Their registered device is gone, which means the device-bound prompt cannot reach them, the portal approval cannot reach them, and if they cannot answer the registered number, the callback cannot either. Meanwhile they are locked out before a client meeting, and they are frustrated.

Attackers know this deadlock exists, and manufactured versions of it are the standard pretext. So you need a documented path that verifies without collapsing. Practitioners who have run this problem down converge on a consistent workflow. Treat this section as field-tested practice rather than vendor guidance, because no primary source has standardized it yet.

1. Verify the request, not just the person. Route the request to the caller’s manager for attestation inside the ticketing system. The manager confirms that the travel, the lost phone, and the reset request are real. The agent never decides alone.
2. Use an alternative live proof. A video call where the employee shows government ID against the HR record works when the phone channel is dead. In-person verification at a known office is the gold standard where it’s practical.
3. Apply the cooling-off delay. Hold the reset 15 to 30 minutes after verification completes. High-risk resets may warrant longer. The hold gives your monitoring a window to correlate the request with anything anomalous, and it removes the urgency the attacker depends on. Security teams who have studied the Scattered Spider complaints suggest that if your help desk can complete a reset in under five minutes from a cold call, the process is the vulnerability.
4. Notify on a separate channel. When the reset completes, alert the employee’s registered contact point and their manager through email or chat, so a fraudulent request gets flagged by the real person within minutes.
5. Protect the metric. State in policy that a held ticket pending verification is a successful outcome. An agent who makes an unverifiable caller wait is doing their job. If your coaching framework punishes that, you have rebuilt the vulnerability with a performance review.

The deadlock is also a design signal. If a meaningful share of resets arrive as emergencies, fix the underlying device and credential resilience, spare authenticators, clear re-enrollment paths from trusted sessions, so the emergency path gets rarer and the verification can afford its own friction.

Metrics, Drills, and Making the Script Stick

A script in an SOP document is not a control. Attackers probe for the gap between policy and behavior, and they find it by calling twice: once politely, once escalated. Three practices close that gap.

Alert on the enrollment event. Treat every MFA device re-enrollment as a security signal, not routine maintenance. Wire the identity provider into your SIEM so each re-enrollment arrives with its ticket ID and the verification method used. Suriq’s analysis of the 2025 federal complaint against a Scattered Spider-linked actor highlights reset velocity as the tell: three accounts taken over in two to three hours is a pattern worth an alert on its own. An unverified re-enrollment should page somebody.

Drill with live voice. Run vishing simulations that place real calls to your agents and employees, using the same pretexts attackers use: the lost phone, the urgent executive, the helpful IT callback. Measure one thing above all: did the person follow the verification policy? Whether they sounded convinced by the voice is irrelevant. The behavioral muscle you’re building is the callback habit, and it develops through repetition, not through an annual poster. Programs that measure policy compliance rather than fake-detection give you a training signal you can actually act on.

Fix the metrics that fight you. If average handle time punishes verification, verification loses. Track a paired metric instead: resets completed with two checks logged, and held tickets resolved correctly. For MSPs and outsourced desks, put the questions in the contract review: walk me through the lost-phone call, has your desk been social-engineered this year, do you verify on a separate channel, and how much of your close time is verification? A provider who answers all four quickly is telling you the truth. One who bristles at the callback question is telling you something else.

Bait & Phish and similar platforms now treat voice as a first-class simulation channel with compliance reporting, which makes the drill program a procurement decision rather than a tooling project. The cheaper option, pre-shared code words for high-risk pairs, costs nothing but rotation discipline. Use both if the account population justifies it.

What Phishing-Resistant MFA Does and Does Not Solve Here

The standard response to credential attacks is to deploy passkeys or FIDO2 keys, and at the login step they genuinely work. The UK’s NCSC assessed that FIDO2 credentials are as secure or more secure than any traditional MFA against the attacks seen in the wild, and CISA’s advisory on Scattered Spider recommends exactly this: FIDO or PKI-based authentication, precisely because push bombing and SIM swap don’t touch it.

But look at where attackers have moved. In 2026, Okta tracked a campaign it calls Pink, run by the group O-UNC-066, that targets passkey enrollment itself. The operator phones an employee, poses as IT, walks them through a convincing fake enrollment portal with a live human adapting the pages in real time, and enrolls their own credential in the victim’s real account while the victim transcribes a meaningless recovery phrase. Passkeys were the victim’s protection at sign-in and irrelevant at enrollment.

The pattern is now familiar and it repeats: every security control gets attacked at its provisioning step, because provisioning still runs on human trust. CISA’s own advisory documents Scattered Spider doing the same with legacy MFA years earlier: call the desk, engineer a reset, register a device.

So treat recovery and enrollment as first-class security events with the same two-check standard as everything else in this article. The encryption does not hear the phone ring. Microsoft’s Secure Future Initiative pairs its passkey rollout with Temporary Access Pass and video-based identity verification for exactly this reason. The cryptographic factor covers the login. The script covers the human moment where a credential is born.

Deploy both, and rehearse the script that covers what cryptography can’t reach.

Rehearsing the Callback Habit with Brightside

The drill program is the part of this system most teams underbuild, and it is the piece Brightside’s AI vishing simulator is built around. It places live, adaptive calls to your agents and employees that respond to what the person actually says, using the pretexts this article covered: the lost phone, the urgent executive, the helpful IT callback. You set the attack goal and caller persona, and the platform can generate the persona, draft the opening line, and recommend a tactic mix. An in-browser preview lets your team hear the call before it goes out, and executive-impersonation drills support self-serve voice cloning from a one-to-two-minute recording, with consent.

The measurement matches the standard this article set. The dashboard tracks what the person did under pressure: answer rate, failure rate, call duration, and trends. A cooling period prevents retargeting the same employee too soon, and a failed call triggers follow-up training automatically, so the callback habit gets the repetition it needs.

Help Desk Verification FAQs

Can someone reset your MFA with just a phone call? Yes, if verification is weak. Attackers call the help desk, impersonate an employee, and get a legitimate reset issued. The two-check standard, a callback to a number on file plus one voice-resistant factor, prevents it.

What is out-of-band verification for password resets? It’s confirming the request through a channel independent of the call itself: a callback to a pre-registered number, an approval prompt in an authenticated portal session, or a device-bound verification to an already-enrolled device.

Why did the MGM breach start at the help desk? An impersonator convinced a help desk agent to reset credentials and re-enroll MFA on a device the attacker controlled. The authentication was legitimate; the requester was not. No exploit was needed.

What should IT support never use to verify identity? Caller ID, security questions, employee ID or date of birth used alone, and any contact detail supplied in the request. All of it is collectable from LinkedIn, breach data, or the attacker’s own inputs.