The most dangerous call an IT help desk takes rarely sounds dangerous. It sounds like a stressed employee who just got a new phone, is about to board a flight, and needs a password reset or a new multifactor device enrolled before a meeting with the CFO. Attackers have learned that the help desk is built to say yes, measured on how fast it resolves tickets, and staffed by people who genuinely want to help. That combination makes a phone call one of the cheapest ways into a company network, and it works whether the target is a large enterprise or a small business supported by a managed service provider. Spotting these calls is less about catching a nervous voice and more about recognizing a pattern of requests, pressure, and identity claims that do not hold up when someone checks them.
Why the phone is still the weak point
Most organizations have spent years hardening email. Filters catch a large share of phishing, users are trained to hover over links, and suspicious messages can be reported with one click. The phone has none of that. There is no spam filter for a caller who has researched an employee on LinkedIn, spoofed a caller ID, and rehearsed a story.
The risk became widely visible in 2023, when attackers associated with the group tracked as Scattered Spider used help desk calls to reset credentials and multifactor settings at large companies. CISA and the FBI described the technique in a joint advisory (AA23-320A), noting that the actors posed as IT staff or as employees and convinced help desk agents to transfer MFA or reset passwords. Nothing in that playbook required malware. It required a convincing caller and a process that trusted what the caller said.
The requests that should slow you down
Not every reset request is an attack, and treating every caller as a suspect will wreck a help desk's service levels. The better approach is to identify the small set of requests where a mistake hands over an account, and apply friction only there.
High-risk requests include:
- Resetting a password and MFA in the same call
- Enrolling a new phone or authenticator app for MFA
- Adding a new email forwarding rule or mailbox delegate
- Changing the phone number or email used for account recovery
- Granting temporary admin rights or adding someone to a privileged group
- Requests on behalf of an executive, delivered by an assistant or "someone from IT"
A routine printer issue does not need callback verification. A request that changes how a person proves who they are does, every time.
Red flags in the conversation itself
Social engineers lean on a few predictable levers. Urgency is the most common: the caller is boarding a plane, presenting to the board, or locked out right before a deadline. Authority is the second: they name a senior executive, or claim to be one. The third is a plausible excuse for why normal verification will not work, such as a lost phone, a broken laptop, or a new device that has not been set up yet.
Listen for these signals together rather than alone:
The caller resists the standard process. A real employee may be annoyed by a callback, but they rarely argue that the policy should not apply to them. Pushback that escalates into threats ("Do you know who I am?") is a strong signal.
The details are almost right. Attackers often know names, titles, and office locations from public sources. They tend to struggle with internal details, like a recent ticket number, the name of their manager's manager, or which system they used last week.
The story changes. If the reason for the request shifts when questioned, write down both versions. Inconsistency is more telling than any single answer.
The caller ID matches, but the number is new. Caller ID can be spoofed. A familiar name on the display is not proof of anything.
They ask the agent to read something out. Requests to read back a one-time code, a temporary password, or the last four digits of something on file are attempts to harvest information, not to receive help.
Verification that does not rely on the caller
The core rule is simple: verify identity through a channel the caller did not choose. If someone calls asking for an MFA reset, hang up and call them back at the number stored in the HR system or directory, not the number they provide. Better still, require the employee's manager to approve the request through a ticket or a chat message from their own account.
Knowledge-based questions such as date of birth or employee ID are weak, because that data leaks often and is easy to find. Stronger options include a push approval to an already enrolled device, a video call where the agent compares the person to their directory photo, or an in-person check for sensitive changes at offices that have staff on site.
For MSPs supporting many small clients, the challenge is consistency. Each client may have a different process, and technicians move between them all day. Writing a short verification policy per client, stored where techs actually look during a call, prevents agents from improvising under pressure. It also gives them something to point to: "Our policy for your company requires a callback for this. I will call you back in two minutes."
Document every sensitive call
Many help desks only discover a social-engineering attempt days later, when a compromised account starts sending invoices. By then, nobody remembers exactly what the caller said or which agent took the call. A ticket that reads "reset MFA per user request" offers almost nothing to an investigator.
Good documentation captures who called, from which number, what they asked for, what verification was performed, and what was changed. Recording and transcribing calls, where local consent laws allow it, makes that record complete without asking a busy technician to type notes while handling a difficult conversation. Tools that provide AI call documentation can turn a call into a written summary attached to the ticket, which makes it far easier to spot a repeated pretext, compare a suspicious call against an earlier one, or show a client exactly what happened.
Transcripts also help with training. Reviewing a real attempt, with names removed, teaches new agents more than a slide deck about urgency and authority.
Make it safe for agents to say no
A help desk agent who delays an executive's request takes a personal risk. If leadership punishes that delay, agents will learn to skip verification for anyone who sounds important. Management needs to state clearly, in writing, that following the verification process is never wrong, even when the caller turns out to be legitimate and annoyed.
A few practical steps help:
- Give agents a scripted line for refusing, so they are not inventing one mid-call.
- Create an escalation path to a supervisor for callers who push back.
- Tell executives in advance that they will be verified like everyone else.
- Celebrate caught attempts openly, so verification is seen as skill, not obstruction.
Advice for everyday users
Social engineering by phone runs in both directions. Attackers pretend to be employees when calling the help desk, and they pretend to be the help desk when calling employees or consumers. If someone calls claiming to be from IT, your bank, or a tech support company and asks you to install software, read out a code, or approve a login prompt, end the call and contact the organization using a number you look up yourself. No legitimate support team needs your one-time passcode.
The takeaway
Help desks cannot screen out every convincing caller, and they should not try to judge honesty by tone of voice. What they can do is identify the handful of requests that hand over control of an account, verify those through a separate channel every time, and keep a complete record of what was said. Attackers count on speed and goodwill. A short, consistent process takes both away from them.