Helpdesk Security: Defending the Service Desk Against Vishing Attacks

For years we hardened the perimeter, rolled out phishing-resistant MFA, and told everyone the human was the weakest link. Attackers agreed — and then they found the one human whose entire job is to help locked-out people get back in. The IT helpdesk is now a primary attack surface, and if your service desk can reset a password or re-enrol MFA on the strength of a convincing phone call, you have a front door with no lock.

Why the service desk became the target

The intrusions attributed to Scattered Spider — including the widely reported attacks on MGM Resorts and Caesars Entertainment — did not begin with a zero-day. They began with a phone call. An attacker who has done ten minutes of LinkedIn research calls the helpdesk, impersonates an employee, projects just enough urgency, and asks the agent to reset a password or move MFA to a new device. The agent, measured on call-handling time and trained to be helpful, complies. Minutes later the attacker owns a valid identity inside your tenant, and every technical control you bought is now working on their behalf.

This is vishing — voice phishing — and it works because it targets process and psychology, not code. The defence is therefore also process and psychology, reinforced by identity controls that make the agent's good intentions irrelevant to the outcome. Below are the seven technical and procedural controls every security team should put in place, expanded with the reasoning and the implementation, followed by the human playbook that ties them together.

The seven controls the service desk needs

Treat the following as a baseline, not a menu. Each one closes a specific move in the attacker's playbook, and they are strongest in combination — a call-back channel is far more powerful when it fires automatically on every reset, and device compliance is far more powerful when new registrations are also being watched.

• Do not accept inbound requests from untrusted or external domains — restrict who can even reach the desk. Why: attackers often route in from outside your identity boundary, using spoofed external email or numbers to open a ticket or a chat. How: restrict ticket creation, chat, and reset workflows to authenticated internal accounts and known corporate numbers; block or heavily quarantine requests originating from external or unverified domains; and never let an inbound external channel initiate a credential change. If a request cannot be tied to a managed identity, it does not get a reset — it gets escalated.
• Monitor and flag any change to a user's authentication method, especially from an overseas or unusual location. Why: swapping the registered phone or authenticator app is the attacker's goal, because it hands them the second factor permanently. How: alert on every MFA method add, change, or removal, enriched with geolocation and device context. A phone-number change or authenticator re-enrolment originating from a country the user has never signed in from should raise a high-severity alert and, ideally, be blocked pending human confirmation.
• Monitor and challenge phoned-in password-change requests from unusual or new locations. Why: the caller ID says one thing, but the associated sign-in and geolocation signals often tell the truth. How: when a reset is requested, pull the account's recent sign-in locations and risk score into the agent's console. If the account is simultaneously showing sign-in attempts from an anomalous geography, the agent should treat the call as hostile until proven otherwise and route it to the high-risk playbook.
• Allow login only from domain-joined or managed, compliant devices. Why: even a valid credential is far less useful to an attacker if it can only be used from a device your organisation controls. How: enforce Conditional Access (or the equivalent) requiring device compliance or domain join for access to sensitive applications. An attacker who talks their way into a password then hits a wall because their own laptop is not an enrolled, compliant device. This single control blunts the payoff of a successful helpdesk compromise.
• Monitor for new device registration from anomalous locations. Why: registering a fresh device is how an attacker turns a stolen credential into durable access and a working second factor. How: alert on every new device join or Azure AD/Entra device registration, correlate it with location and time, and flag registrations that appear from unexpected geographies or immediately after a helpdesk interaction. A new device appearing overseas within minutes of a phoned-in reset is a near-certain compromise signal.
• Auto-trigger step-up MFA or identity re-verification for anyone who calls to reset a password. Why: the phone call itself is the untrusted channel, so the reset must be re-anchored to something the real user possesses. How: make a reset request automatically fire an out-of-band verification — a one-time code to the registered authenticator, a push the user must approve, or a code read back from a device of record. The agent cannot complete the reset until that step-up succeeds. This is the control that most directly defeats the Scattered Spider pattern.
• Maintain verified call-back channels and accept resets only through them. Why: the attacker controls the inbound call; they do not control the number on file. How: for any sensitive reset, the agent ends the inbound call and calls the user back on the number stored in the HR or identity system — never a number the caller supplies. For high-risk cases, add manager verification, or a live video call with a photo-ID check. If the real user cannot be reached on a channel of record, the reset waits. The inbound call is a request; the outbound call is the verification.

An identity-verification playbook for agents

Controls fail without a script that removes the agent's discretion to be talked out of them. Give every agent a written, mandatory playbook and the explicit backing of leadership to follow it — even for executives, even under pressure.

The playbook should open by classifying the request into a risk tier. Low-risk requests — a printer problem, an app issue, or a standard password reset for a non-privileged account on an already-compliant device — proceed with normal identity confirmation. High-risk requests — MFA re-enrolment or method changes, any privileged or administrative account, new-device registration, requests tied to an anomalous location, or anything the monitoring signals have flagged — trigger the full verification path: step-up MFA, a call-back on the number of record, and out-of-band manager approval before anything changes.

Every reset, low or high risk, is logged: who called, what account, which tier, what verification was performed, which agent acted, and the outcome. That log is both your audit trail and your detection dataset — a cluster of resets against privileged accounts from one region is a pattern you can only see if you write it all down. For privileged accounts specifically, require out-of-band manager approval as a hard gate: the agent contacts the account owner's manager through a separate, verified channel and gets explicit sign-off before touching the credential.

Not sure how exposed your identity estate is to this exact pattern? Our identity risk calculator walks you through the questions — MFA coverage, privileged-account hygiene, device compliance, and helpdesk process — and scores where the service desk sits in your overall identity risk.

Train against MFA fatigue and urgency

The two levers attackers pull hardest are fatigue and urgency. MFA fatigue — spamming approval prompts until a tired user taps Accept — should be countered technically with number-matching and prompt throttling, and culturally by teaching every employee that an unexpected prompt is a report-it event, not an annoyance to dismiss. Urgency is the vishing attacker's whole toolkit: the fake deadline, the impatient executive, the threat of a missed deal. Train agents that urgency is itself a red flag, that the verification policy is non-negotiable and applies to everyone, and that slowing down is exactly what leadership expects. An attacker's power evaporates the moment the agent is genuinely allowed to say no.

Service desk hardening checklist

• Restrict who can reach the desk: block reset workflows initiated from untrusted or external domains and unverified numbers.
• Alert on every MFA method add, change, or removal, with location and device enrichment.
• Alert and challenge on password-change calls that coincide with anomalous sign-in geography.
• Enforce Conditional Access requiring domain-joined or compliant devices for sensitive apps.
• Alert on every new device registration and flag anomalous locations or post-call timing.
• Auto-trigger step-up MFA or re-verification on every phoned-in password reset.
• Call the user back on the number of record — never a number the caller provides.
• Add manager verification or a video/ID check for high-risk and privileged resets.
• Classify every request into low-risk or high-risk tiers and route accordingly.
• Log every reset: caller, account, tier, verification performed, agent, and outcome.
• Require out-of-band manager approval as a hard gate for all privileged accounts.
• Deploy number-matching and prompt throttling, and train staff to report unexpected MFA prompts.
• Give agents written, leadership-backed permission to slow down and refuse under pressure.
• Run regular vishing simulations against the desk and feed the results back into training.

None of these controls is exotic, and that is the point. The Scattered Spider playbook works not because it is sophisticated but because most service desks were built to optimise helpfulness and speed, never to withstand a determined liar on the phone. Rebuild the process so that a reset can only complete through a verified, out-of-band channel, wrap it in monitoring that watches for the attacker's tell-tale moves, and the phone call stops being a way in.