Help Desk Caller Verification: A Nine-Step Procedure

The written procedure an L1 technician follows before changing a password, MFA method or access right for anyone who calls, chats or opens a ticket.

Attackers who can't beat MFA ask the help desk to remove it, so every reset has to start with a check the attacker can't research: a push to the user's enrolled device, a call-back to the number already on file, or a live on-camera check. Privileged accounts get a second approver. The change itself is a one-time, short-lived credential, the user and a named client contact are told through a separate channel, and every step is logged against the ticket.

This is the procedure page in the help desk social engineering series. The series hub explains the attack; the MFA reset playbook covers the Entra steps. This page is the part you hand to your L1 technicians.

Why the Help Desk Needs a Written Procedure

CISA's Scattered Spider advisory describes the group using social engineering to convince IT help desk personnel to "reset passwords and/or MFA tokens". Okta reported the same pattern against its customers' service desks in August 2023, aimed at highly privileged users. Microsoft's research on Octo Tempest describes the same path: impersonating users to the service desk.

None of those advisories gives the help desk a procedure. CISA's mitigations focus on phishing-resistant MFA, which is the right end state and doesn't tell an L1 technician what to do when a caller says they've lost their phone. The two sources that do address the desk directly are Mandiant's UNC3944 hardening guidance (May 2025) and the UK NCSC's recommendations after the 2025 retail incidents. The procedure below is built on those, on the account recovery rules in NIST's current authentication guidelines, and on how an MSP desk actually works.

The Procedure, Step by Step

1. Classify the request before you act. Is it a standard user, or a privileged one: an admin in any tenant, finance, executives, anyone who can approve payments, or a service account? Privileged requests take the stricter path in steps 4 and 5. The classification lives in the client runbook, not in the technician's judgement on the call.
2. Freeze until verification completes. Nothing changes on the account until step 3 passes. Urgency, seniority and "I'm about to board a flight" are not verification. Say so in the procedure so the technician can point to it.

3. Verify with a factor the user holds, not facts the caller knows. Mandiant's guidance is that help desks should "positively identify employees before modifying / providing security information". Acceptable methods, in rough order of strength:

   • A push or code to the authenticator the user already has enrolled.
   • A call-back to the phone number in the PSA contact record or HR system. Never a number the caller gives you, and never the number the call came from: caller ID can be spoofed.
   • A live on-camera check against a photo you already hold, or an identity document check. Microsoft documents a verified help desk pattern using Entra Verified ID with Face Check, which compares a live selfie with the photo on the user's Verified ID employee credential.
   • Confirmation from the user's manager using contact details you already hold.

   Date of birth, the last four digits of a national ID, employee number, manager's name and home address are not verification. Mandiant says to avoid publicly available personal data, and all of those can be bought or found.

4. Add a second approver for privileged accounts. A named client contact or an MSP lead approves before any change to an admin, executive or finance account. Two people have to be fooled, on two channels.

5. Make the smallest change that solves the problem. In Microsoft Entra, that usually means Require re-register MFA, Revoke sessions and a short, one-time Temporary Access Pass, rather than a password read out over the phone. The MFA reset playbook has the exact steps and the admin roles each one needs.
6. Notify out of band. Tell the user, by a message to a known device or a call to the number on file as well as by email, and tell a named client contact for privileged accounts. NIST's guidelines say that account recovery "SHALL cause a notification to be sent to the subscriber or their designee". If the real user didn't ask for the reset, this is how you find out within minutes rather than at the incident review. Email alone isn't enough: in August 2026, Google Threat Intelligence Group reported that the group it tracks as UNC6671 deleted password-reset confirmations and security alerts from the mailboxes it had taken over.
7. Log it against the ticket. Who asked, how they were verified, who approved, what changed, in which tenant, and when. If there's no ticket, there's no change.
8. Treat failed verification as a security event. A caller who can't or won't verify isn't told to try later. Close the request as a suspected social engineering attempt, tell the client's named contact, and check the account for recent password or MFA changes.
9. Switch to surge mode when a client is under attack. Mandiant recommends temporarily disabling self-service MFA resets during periods of elevated threat. Route every reset for that client through this procedure until the threat passes, and brief the desk.

What Changes for an MSP Help Desk

An internal service desk verifies one company's staff against one directory. An MSP desk answers for users at dozens of clients, across separate tenants and identity providers, and its technicians rarely know the callers. Four things follow.

• The PSA is your source of truth. The call-back number and the named approver come from the PSA contact record, so keep those fields current and restrict who can edit them. An attacker who can change a phone number in your PSA can pass your verification.
• Exceptions are decided in advance. Some executives won't do video, and some users have no enrolled device. Write the alternative for each client into its runbook before it's needed, so the technician isn't negotiating with a stressed caller.
• Reset rights are a privilege too. A technician with reset rights in forty tenants is a target in forty tenants. Give most technicians the Authentication Administrator role, which can't reset most admin accounts, Global Administrator included, and grant Privileged Authentication Administrator only for a specific, approved task.
• One weak desk process is every client's weak process. The NCSC told organisations to review their help desk password reset processes, including how the help desk authenticates staff before resetting passwords, especially for accounts with escalated privileges. For an MSP, that review covers every client at once.

Where This Sits in the PAM Journey

Caller verification protects the front door. It will fail eventually, because people are tired, rushed or fooled. The PAM journey is what limits the damage when it does.

• Phase 5, enforce MFA and secure access: phishing-resistant MFA on admin accounts removes most of what an attacker would ask the desk to reset. Caller verification belongs in this phase too, because a password or MFA reset is the easiest way around MFA.
• Phase 6, just-in-time access and zero standing privilege: if technician and client admin accounts are disabled until a task needs them, a caller who talks their way into an everyday account finds no standing admin rights on it.
• Phase 7, audit, monitor and alert: alert on every MFA reset or new authentication method on a privileged account, and review the verification log each week.

How CyberQP Handles It

CyberQP's QDesk verifies end users who contact the help desk before a password or MFA reset. The technician sends the request from the ticket or while on the phone, and the user either approves it in the CyberQP mobile app, Microsoft Authenticator or Duo, or reads back a code sent to them by SMS or email. Help desk identity verification is coming to Panthera; it isn't in Panthera yet. In Panthera today, technicians can work from dedicated just-in-time accounts that are disabled by default, can require a second approval and can be tied to a ConnectWise Manage ticket, and changes to privileged accounts show up in Panthera's event log and auditing alerts.

What Done Looks Like

• Every password, MFA and access change requested by phone, chat or ticket is verified by possession, presence or a call-back to a number on file.
• No technician accepts knowledge questions or a caller-supplied number as proof.
• Privileged changes need a second approver, and reset rights for admin accounts are granted per task.
• Users and named client contacts are notified of every recovery through a separate channel.
• Failed verifications are logged and reported to the client as suspected attacks.
• Each client's runbook records its exceptions and its surge-mode contact.

Frequently Asked Questions

Is caller ID enough to verify a caller?

No. Caller ID can be spoofed, and an attacker who has done their research will call from a number that looks right. Call back the number in your PSA or HR record instead.

What if a user won't or can't do a video check?

Use another factor they hold: a push to their enrolled authenticator, or a call-back to the number on file. If none works, a named manager or client contact confirms using contact details you already hold. Record the exception in the client runbook, not on the call.

Should users be allowed to reset their own MFA?

Self-service reset is fine when it requires a factor the user already holds. During an active attack on a client, Mandiant recommends temporarily disabling self-service MFA resets and routing every request through the help desk procedure.

What should an L1 technician do when verification fails?

Stop, make no change, close the ticket as a suspected social engineering attempt and notify the client's named contact. Then check the account for recent password or MFA changes. Don't let the caller retry on a new call with a different story.

Which knowledge questions are safe to use?

None that an attacker could research or buy. Date of birth, national ID digits, employee number and manager's name are all findable. Verify with something the user has, or with a person you can reach independently.

Sources: Mandiant, Defending Against UNC3944 (6 May 2025); NCSC, Incidents impacting retailers (4 May 2025); CISA AA23-320A, Scattered Spider (16 Nov 2023); Okta, cross-tenant impersonation (31 Aug 2023); Microsoft, Octo Tempest (25 Oct 2023); Google Threat Intelligence Group, UNC6671 (6 Aug 2026); NIST SP 800-63B-4, section 4.2 account recovery (July 2025); Microsoft Learn, verified help desk with Entra Verified ID; Microsoft Learn, Temporary Access Pass; Microsoft Learn, privileged roles and permissions.

Related: help desk social engineering: how the attack works, MFA fatigue and MFA reset attacks, zero standing privilege and the PAM journey, QDesk help desk identity verification, start a free trial, book a demo.