Your Help Desk Might be a Risk. Here's How to Verify Every Caller.

"Hey, it's Dave from accounting. I'm locked out again. Can you reset my password?"

Your tech has talked to Dave a dozen times. The voice sounds right and the request is routine. Thirty seconds later, the password is reset.

But was it Dave?

For many MSP service desks, the honest answer is "probably." This post explains why that's become one of the biggest gaps in an MSP's security, why the usual verification methods don't close it, and what a practical caller verification policy looks like.

Why attackers call the help desk

Breaking in through a firewall is hard. Asking a helpful person for a password reset is easy.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the FBI describe this playbook in their advisory on the Scattered Spider group. According to the advisory, the group:

• Made several calls to a company to learn how its password resets work.
• Called the help desk posing as employees and persuaded staff to reset passwords or move MFA to a device the attackers controlled.
• Posed as IT staff to trick employees into handing over credentials.
• Flooded users with MFA push prompts until someone pressed "Accept."

This isn't a past problem. Some of the most expensive attacks of the last two years started with a conversation:

• Co-op (UK), April 2025. Attackers impersonated an employee and answered security questions to get an account reset. Co-op told the UK Parliament that malicious activity started about an hour after they got in (Claims Journal, via Bloomberg).
• Marks & Spencer, April 2025. M&S's chairman told the same Parliament committee the attack came from a "sophisticated impersonation" of one of its third-party users. M&S estimated the cost at about £300 million in operating profit (same source).
• Clorox, lawsuit filed July 2025. Clorox sued its outsourced help desk provider for $380 million over a 2023 attack. The complaint alleges agents reset passwords and MFA without the required identity checks, and in one recorded call simply read a password to the caller. The provider disputes the claims (The Register).
• Financial services, 2025–2026. CrowdStrike named a group it calls Mutant Spider as the most active threat to financial firms from April 2025 to March 2026. Its main move: calling employees over Microsoft Teams while posing as IT support, getting credentials and MFA reset, then registering its own devices (VentureBeat, May 2026).

MSPs are an especially attractive target. The Clorox case shows why: when the help desk is outsourced, the provider's verification process becomes the client's security, and the client's lawyers notice. One reset at an MSP's service desk can open the door to a client's email, files and systems. Attackers don't need to beat your security tools if they can talk their way past your people.

Why common verification methods fall short

Most service desks already do something to check who's calling. The trouble is that the most common checks are easy to fake.

There's a second problem: even good policies get skipped. When the queue is long and the caller is impatient, a check that takes several minutes is the first thing to go. And if the check isn't recorded, nobody can prove it happened.

What good caller verification looks like

Strong verification follows a few principles:

1. Verify with something only the real user has. Send the check to a device already registered to them, like an authenticator app, not to contact details the caller provides.
2. The help desk starts the check, not the caller. Attackers control the conversation when they get to choose how they're verified.
3. Verify before you act. Confirm identity before changing a password, MFA method or permission, not after.
4. Make it fast. If verification takes seconds instead of minutes, techs won't be tempted to skip it.
5. Log every result. Approved or denied, the record should sit with the request, so you can show clients, auditors and insurers what happened.
6. Teach users to deny prompts they didn't expect. An approval request they didn't trigger is a warning sign, not a nuisance. Report it.

A starter verification policy for MSPs

You don't need to verify every "my printer is jammed" call. Focus on the requests an attacker would want.

To put it into practice:

• Agree the high-risk list with each client and add it to their onboarding.
• Tell clients' users in advance how your help desk will verify them, so a real request isn't a surprise.
• Never use a phone number or email address the caller gives you during the call.
• Write down what techs do when a check fails or a user can't be reached.
• Record the verification result on every high-risk ticket.
• Review failed and skipped verifications every quarter.
• Run a mock social engineering call against your own desk at least once a year.

Where Thread fits

We built Thread Verify to make the high-risk check a one-click step. From the ticket, the tech sends a Microsoft Authenticator push or SMS link to the contact's own phone, and the result is logged on the ticket. Because it's part of Thread, the request can be resolved in the same flow once the caller is confirmed. If you'd like to see it, book a demo.

Whatever tools you use, the principle is the same: "I know that voice" was never proof. Verify the caller before you act.