Help Desk Password Resets: How to Verify Who's Calling

The fastest way into your network isn't a zero-day. It's a phone call to whoever answers IT, from someone who sounds stressed, knows an employee's name and title, and needs a password reset before a client meeting. Most small businesses have no written rule for what happens next, which means the answer depends on how busy and how agreeable that person is.

By Joel Baum, The NetSys Group

Is this actually happening to small businesses?

Yes, and the volume is climbing. CrowdStrike's 2026 Threat Hunting Report found that vishing intrusions in the first half of 2026 increased 2x compared to the second half of 2025. Voice is growing because it works, and it works best against the person whose job is to unblock people quickly.

The method isn't a secret. FBI and CISA documented it in their joint advisory on Scattered Spider, describing actors who "use voice communications to convince IT help desk personnel to reset passwords and/or MFA tokens." The same advisory notes they pose as IT staff to get employees to hand over one-time codes.

Note what's missing from that description: no malware, no exploit, no alert. A successful call looks exactly like good customer service.

Why does a reset request work so well?

Because everything that makes a help desk good makes it vulnerable. Fast response, benefit of the doubt, and a strong dislike of leaving a colleague stuck.

The caller supplies the rest. Names, job titles, reporting lines, and office locations are on LinkedIn, and a manager's name plus a plausible reason covers the social pressure. If your verification is "what's your employee ID" or "what's your date of birth," that data is cheap to buy and often already leaked.

Then there's voice itself. Cloned audio is now good enough that recognizing someone by their voice proves nothing, which we covered in AI voice cloning fraud. Familiarity is no longer evidence.

What does good verification look like?

Verify through a channel the caller doesn't control, using something an attacker can't look up. That single sentence rules out most of what small businesses currently do.

Three approaches hold up in practice:

• Call back on the number in your directory. Not the number they're calling from, not one they give you. If they're who they say, they answer. This alone stops the majority of attempts and costs nothing.
• Verify in a separate authenticated channel. Message them in Teams on their known account, or have them respond from a registered device. An attacker with a phone but no session can't complete it.
• Require a manager's approval for resets on privileged accounts. Two people, contacted independently. Slower, and correct for the accounts that matter.

Video calls are weaker than they feel. If you use one, ask the person to do something unscripted on camera rather than simply appear on it.

What should never count as verification?

Anything discoverable or guessable. Employee ID, date of birth, the last four of a Social Security number, a manager's name, a home address, the department they work in. All of it is either public, purchasable, or sitting in a prior breach dump.

Caller ID is worth its own line. It's trivially spoofed, and treating it as evidence is the single most common mistake we see. A call that displays your office's main number proves nothing at all.

Write the rule down

The policy matters less than its existence. Staff cave to pressure when they're improvising and there's no cover for saying no.

Put it in writing, keep it to one page, and make three things explicit: the exact steps for verifying a reset request, that nobody is ever penalized for following them, and who to escalate to when a caller pushes back. That last part is the tell. Real employees accept a callback. Attackers escalate, invoke a deadline, or name-drop an executive.

Then rehearse it. A verification rule nobody has practiced folds on the first angry call. Drilling the awkward conversation once is worth more than the document, which is why we build this scenario into security awareness training rather than leaving it to a policy binder.

Reduce how often the call happens at all

Every password reset you handle by hand is a chance to be fooled, so cut the volume. Self-service reset moves routine resets to a path with no human to persuade.

Worth knowing: Microsoft is tightening how self-service reset proves identity, and users who haven't registered an authentication method lose it in November and land back on your help desk. We cover what to do in the Entra ID SSPR deadline.

Phishing-resistant methods help for the same reason. A passkey can't be read aloud to a caller, which removes the one-time-code handover entirely. And if your team is already fielding MFA fatigue attacks, the two problems share a fix.

Frequently asked questions

We're a 25-person company. Is this really a risk for us?

Yes, and small size cuts both ways. You're less likely to be individually targeted, but you're also more likely to have one person handling resets with no written procedure and no second pair of eyes. Attackers run these calls at volume against whoever answers, and a smaller company rarely has the logging to notice afterward.

Our IT is outsourced. Whose problem is this?

Both of yours, and it needs to be settled in writing. Ask your provider exactly how they verify a caller claiming to be your employee, and what they do when someone pushes back. If the answer is vague or sounds like it depends who picks up, that's the gap. Agree the procedure and put it in the service agreement.

Won't callbacks and approvals slow everyone down?

A callback adds a couple of minutes to a reset that already takes several. Reserve the heavier steps, like manager approval, for administrator and finance accounts rather than applying them to everyone. The goal is friction proportional to what the account can reach.

How do we verify someone who's genuinely locked out and travelling?

Decide this in advance, because it's the scenario attackers imitate. A pre-registered personal number, a colleague who can vouch on a known channel, or a manager confirming separately all work. What doesn't work is improvising an exception mid-call, which is exactly the outcome the attacker is steering toward.

How would we know if this already happened?

Look for password or MFA resets that weren't preceded by a ticket, sign-ins from new locations shortly after a reset, and changes to MFA methods on accounts that didn't request one. If nobody reviews those events, start there.

Want your reset procedure written, tested against a real call, and handed to whoever answers the phone? Book a complimentary security assessment and we'll pressure-test how your team handles it.

The NetSys Group has delivered managed IT, cybersecurity, and cloud services since 1998. Our engineers hold degrees in electrical and computer engineering and are certified Microsoft and Cisco instructors, serving businesses across NY, NJ, CT, PA, and Southwest Florida.