Help Desk Social Engineering: An Identity Verification Approach for MSPs

The short answer: Help desk identity verification for MSPs means confirming who a caller is before any account change, using a call-back to a number of record, a push or code to an enrolled device, or manager approval rather than easily researched facts, with stricter steps for MFA resets, privileged accounts and executives, and recording the verification on every ticket. MSPs often enforce the same script on a white-label help desk.

Why the help desk is a target

Help desks exist to help people regain access, which makes them attractive to attackers. A caller who sounds stressed, claims to be traveling and asks for an MFA reset is a standard social engineering approach. For an MSP, the risk multiplies: one weak process can expose many client tenants.

The answer is a verification step that is applied every time, is hard to fake and is quick enough that technicians do not skip it under pressure.

Methods that do not hold up

Name, email address, job title, manager’s name and date of birth are easy to find on social media, company websites or past breaches. A caller who knows them proves very little. Caller ID can be spoofed, and an employee ID number is often printed on badges and emails.

These facts can support verification but should never be enough on their own for a password or MFA change.

Methods that hold up better

Stronger options include calling the user back on a number held in the directory or HR system, sending a push or one-time code to a device already enrolled for the user, asking the user’s manager to approve the request through a known channel, or video verification against a photo of record for high-risk changes.

The right method depends on the client’s tools and risk, but it should rely on something an attacker is unlikely to control.

Stricter steps for higher-risk requests

Not every request carries the same risk. A how-to question needs no verification; a password reset needs a standard check; an MFA reset, a change to a privileged or admin account or any request involving an executive needs the strictest path, often two methods or manager approval.

Write these tiers into the script so technicians do not have to judge risk on the fly. See SOC tier 1 alert triage for how suspicious requests reach security monitoring.

Holding the line under pressure

Social engineering relies on urgency: the caller is about to board a plane, the CEO needs access now, the deadline is in ten minutes. Scripts should give technicians a polite, firm line that does not bend, and a way to escalate to a lead rather than make an exception.

MSPs should make clear to clients, in writing, that the verification step applies to everyone, including executives, so technicians are backed when they enforce it.

Record the verification on the ticket

Every change should record who was verified, which method was used, when and by whom. Without a record, there is no way to audit the process or investigate an incident later.

PSA ticket templates in ConnectWise, Autotask or HaloPSA can include required verification fields, so the ticket cannot be closed without them.

Per-client rules in a multi-tenant desk

Different clients have different tools and risk appetites. Keep a verification profile per client, stored with the client’s documentation in IT Glue or Hudu: which methods are available, which requests need which tier and who can approve.

Technicians should check the client profile on every call, not rely on memory. See help desk outsourcing for enterprise service desk practices.

Audit and test the process

Each month, sample tickets for account changes and check that verification was recorded and followed the client’s profile. Periodically run test calls, with client permission, that attempt a reset with only easily researched information.

Findings should feed coaching and script updates. A process that is never tested will drift.

Reducing risk with self-service resets

Self-service password reset, with users enrolled in strong verification methods in advance, removes many routine reset calls from the help desk entirely. That leaves technicians with fewer, higher-risk requests, which are easier to handle carefully.

MSPs can include enrollment in self-service reset as part of onboarding for each client’s staff, and track the share of resets handled without a call.

When the user has lost their device

The hardest calls come from users who have lost the phone they use for MFA. They cannot receive a push or code, which is exactly what an attacker would claim. These requests should follow the strictest path: manager approval through a known channel, a call-back to a number of record not tied to the lost device, or in-person or video verification where available.

Temporary access passes, where the identity platform supports them, can restore access for a short time without permanently weakening the account.

Verification at offboarding

Offboarding requests carry risk too: an attacker might ask to remove a user’s access to cover tracks, or a request to delay offboarding might keep a former employee’s access alive. Offboarding requests should come from authorized contacts at the client through known channels, and be recorded with the approver.

Checklists for removing sign-in, MFA methods, licences and shared access should be signed off on the ticket, so nothing is left behind.

Training technicians to spot social engineering

Technicians should hear what social engineering sounds like: urgency, flattery, name-dropping senior people, frustration when asked to verify and requests to skip steps just this once. Short scenario exercises, repeated regularly, build the habit of holding to the script.

New technicians, including those on an outsourced desk, should complete the exercises before taking live calls.

When a reset may have been fraudulent

If a technician suspects a change was made for an impostor, the response should be fast and agreed in advance: revoke sessions, reset credentials through the strict path, review recent sign-ins and mailbox rules, and alert the client and the security team.

Record what happened and update the script or client profile so the same approach does not work twice.

Putting verification in place

Write the script, define risk tiers, build verification fields into PSA templates, agree client profiles and train every technician, including outsourced ones. Then audit and test regularly.

Our MSP white-label help desk outsourcing page explains how vetted Philippine desks support MSP clients under the MSP’s brand and procedures, and our guide to SOC triage playbooks covers the security monitoring side.