Home / Blog / Help Desk Social Engineering:...
Product Update

Help Desk Social Engineering: How MSPs Verify Caller Identity Before Resetting Passwords or MFA

Jake Gipson
Nov 5, 2026
Help Desk Social Engineering: How MSPs Verify Caller Identity Before Resetting Passwords or MFA
9:12

Help desk social engineering is when an attacker contacts your service desk posing as a real user and talks a technician into resetting a password, registering a new MFA device, or granting access. For MSPs, it’s one of the easiest ways into every client you manage. Your desk holds the keys, and it’s built to say yes.

Anyone can call your help desk from any number and claim to be anyone. A convincing voice and a sense of urgency are often all it takes. The fix isn’t training your techs to distrust every caller. It’s making identity verification a standard step every time a sensitive request comes in, and making that step take one click.

 

Why are MSP help desks a top target for social engineering?

MSP help desks are a top target because one desk holds administrative access to dozens of client environments, and its job is to resolve requests fast. An attacker who gets a single password or MFA reset approved at your desk doesn’t just get one account. They get a foothold inside a client you’re responsible for protecting.

This attack doesn’t need malware or a clever exploit. It needs a phone and some homework:

  • Find a real name. LinkedIn, the client’s website and press releases hand over names, titles and reporting lines.
  • Mask the number. Caller ID is easy to spoof, and “I’m on my personal phone” covers everything else.
  • Add pressure. A board meeting in ten minutes. A CEO waiting. A flight about to board.
  • Ask for something routine. A password reset or a new phone for MFA. Your techs handle these all day.

In September 2023, attackers used this playbook against MGM Resorts. They found an employee on LinkedIn, called the IT help desk, and talked their way into access. MGM later estimated the hit at about $100 million. That was a company’s internal desk, where techs at least work for the same employer as the people calling. On an MSP desk serving dozens of clients, your techs rarely know the caller’s voice at all.

The enemy here isn’t your technicians. It’s trust-by-voice: a service model where a caller’s identity is assumed from what they say. Everything else about the desk reinforces it. SLAs reward speed. CSAT rewards helpfulness. Phone is still where urgent requests land, and fast voice support is a good thing, as long as identity is confirmed before anything sensitive changes. Without that check, your best techs are the easiest ones to fool, because they’re the ones trying hardest to help.

 

Why don’t security questions and callbacks stop it?

Security questions check what someone knows, and that information is often public or already leaked. Callbacks and standalone verification tools are stronger, but they sit outside the ticket, add steps techs skip when the queue is full, and leave no record that the check happened.

Here’s how the common defenses break down in practice:

  • Security questions. Employee ID, manager’s name, last four of a phone number. An attacker who has done their homework already has the answers.
  • Callbacks to the number on file. Better, but slow. The number is often outdated, and when 40 tickets are waiting, “I’ll call you back” is the first step to get dropped.
  • Standalone verification tools. Another login, another subscription, another place where the record lives apart from the ticket. Techs have to leave the work to do the check, so the check doesn’t get done.

These all share one problem. Your policy says “verify the caller,” and nothing proves it happened. When something goes wrong, you’re piecing together what happened from memory and a tech’s best guess.

 

How should an MSP verify a caller’s identity?

An MSP should verify callers with something the user has, through a channel the attacker doesn’t control, from inside the ticket, with every outcome logged automatically. If any of those four is missing, the check is either easy to beat or easy to skip.

Use this as your standard, whatever tool you use:

  1. Something they have, not something they know. A push to their phone beats any question an attacker can research.
  2. A separate channel. Send the challenge to a device already on file, never to the number that’s calling.
  3. Built into the workflow. If verifying takes more than a click, it won’t survive a busy Monday.
  4. Logged automatically. Every request and result should be recorded on the ticket, with no extra work from the tech.
  5. Clear triggers. Write down which requests always require verification: password resets, MFA changes, access requests, and anyone asking for ticket details by phone.

 

How Thread Verify works

Thread Verify is identity verification built into the Thread AI Service Desk. It confirms a contact’s identity with a Microsoft Authenticator push or an SMS link before a sensitive request moves forward, and it logs every result on the ticket.

Here’s what that looks like for your tech:

  1. Start the check from the ticket. One click from the contact details panel, the Actions menu, or the /verify shortcut. The workspace default method is already selected.
  2. Thread reaches the contact’s own phone. The contact gets either an Approve/Deny push in Microsoft Authenticator (no code to type) or a one-tap SMS link. If the default method can’t reach them, Thread tries the other method you’ve turned on.
  3. The contact approves or denies. Your tech goes ahead with the reset only after the contact approves. Pushes expire after about five minutes by default, and you set how long SMS links last.
  4. The result is logged on the ticket. Every outcome (verified, denied, expired or undelivered) is added as an internal note on the ticket automatically.

A few details make this hold up on a real desk. Contacts don’t install anything or set anything up in Microsoft Authenticator. The Authenticator method works once the client’s Microsoft 365 tenant is connected, and SMS works for any contact with a mobile number in your PSA. The verification page carries your own logo and colors. When an SMS check succeeds, the contact goes straight into live chat with your team, so the conversation keeps moving instead of starting over.

 

What does a verification audit trail give you?

A verification audit trail gives you proof. Every check, whether approved, denied or expired, is recorded with who triggered it, which method was used, and the device and IP address of the person who completed it. When a client, an insurer or an auditor asks how you verify callers, you show them the record.

Thread Verify’s Activity log records the date, contact, client, ticket, method, who triggered the check, the outcome, the device and IP that completed it, and delivery status. Summary cards show request volume, verified rate and expired count, and you can filter by client, method, status or date range.

That record pays off in several places:

  • Client conversations. Show clients exactly how you protect their accounts from social engineering, with real numbers.
  • Cyber insurance and compliance. Answer “How do you verify identity before credential resets?” with a log, not a policy document.
  • Incident review. A denied or expired check is a signal worth looking into, and now you can see it.

It also means one less tool to buy. Thread Verify is included in AI Pro, so there’s no separate verification product to pay for, roll out and keep in sync with your service desk.

 

Close the front door

Your help desk will always be the front door to your clients. That’s the job. What’s changed is who’s knocking, and how good they’ve gotten at sounding like someone you trust. The MSPs that stay out of breach headlines aren’t the ones with the most suspicious techs. They’re the ones where checking an ID is part of the work, takes one click, and leaves a record every time.

Book a demo and watch a tech verify a caller in one click, without leaving the ticket.

 

Frequently asked questions

What is vishing?
Vishing, or voice phishing, is social engineering over the phone. The attacker impersonates someone trusted, often a user calling the help desk, to get credentials reset or sensitive information shared.

Does the contact need to set anything up in Microsoft Authenticator?
No. As long as the contact already has Microsoft Authenticator registered on their Microsoft account, they get an Approve/Deny push with nothing extra to set up.

What happens if a verification is denied or expires?
The outcome is logged as an internal note on the ticket and in the Activity log. The tech doesn’t proceed with the request and can resend the check or try another method.

What’s required to use the Microsoft Authenticator method?
The client’s Microsoft 365 tenant needs to be connected to Thread, which a Global Administrator approves once. The client’s contacts in Thread also need email domains that match the tenant.

Can I use SMS verification for clients without a connected Microsoft 365 tenant?
Yes. SMS works for any contact with a mobile number on file in your connected PSA, with no Microsoft 365 connection needed.

 
Product Update MSP Maturity

Similar Posts

Don't want to close your eyes? Don't want to miss a thing?

Sign up for our newsletter to get the latest and greatest delivered directly to your inbox by Aerosmith. just kidding, it's us, and the newsletter is awesome.