How to Verify Identity at the Help Desk Before an MFA or Password Reset

Help desk identity verification for MFA resets should be a written procedure, not a judgement call made by whoever is on shift. At minimum, require an out-of-band callback to the number already on file in your HR system, or a confirmation from the person's manager through a separate channel, before any password reset or MFA re-enrolment goes through. Then test it by having someone the help desk does not recognize phone in and try to talk their way past it.

The reason this is worth your attention this week: on October 28 the Canadian Centre for Cyber Security published an alert about an ongoing voice phishing campaign aimed at Canadian organizations, written for IT professionals and managers, with detection and mitigation advice and an offer of direct assistance. This is the control I find broken most often in readiness work, and it almost never shows up as a finding, because nobody tests it.

What help desk vishing actually looks like

The attack does not need malware and it does not need a zero day. Someone calls or messages your service desk claiming to be an employee, usually one with enough seniority to create urgency and not enough technical profile to be questioned. A sales director travelling with a new phone. A finance manager locked out before a board call. The caller already knows the employee's full name, job title, manager, office location and start month, because all of that is on LinkedIn, in a conference speaker bio, or in a press release.

The ask is small and sounds routine: reset the password, or clear the MFA registration so a new device can enrol. If the agent does it, the attacker now holds a valid session on a trusted identity, and everything downstream treats them as that person. Single sign-on makes this worse, not better, because one successful reset hands over the whole application estate.

What makes the control fragile is that the pressure runs one way. Agents are measured on ticket resolution time and on not annoying executives. Nobody is measured on the reset they refused. Until you write the steps down and make refusal the default outcome when verification fails, the procedure is whatever the agent thinks is reasonable under pressure.

What a help desk identity verification procedure needs to contain

Keep it to one page that an agent can read while a caller is waiting. It needs to answer, specifically, what counts as proof of identity and what the agent does when the caller cannot produce it.

• A defined trigger list. Password reset, MFA factor removal or re-enrolment, recovery email or phone change, adding a device, elevating a role. All of these are identity-changing actions and all get the same treatment.
• Out-of-band callback as the primary method. The agent ends the contact and calls the number in the HR record or the identity provider profile, never a number the caller supplies in the conversation.
• A second acceptable method for people with no working phone. A video call where the person matches their HR photo or a government ID, or a confirmation from their manager through a separate channel the agent initiates.
• An explicit prohibition. No verification using information that appears in a directory, an email signature, LinkedIn or a public filing. Employee ID numbers, manager names and start dates are not secrets.
• A failure path. If verification fails, the agent does not reset. They escalate to a named person and log the attempt. Say this in writing so the agent has something to point at.
• No exception for executives. Write the sentence down. Executives are the pretext of choice precisely because the exception is assumed.
• Mandatory ticketing. No reset without a ticket, and the ticket records which verification method was used and who performed it.

If you have no formal policy set yet, this slots into the access control section of a broader document. Our guide to writing your first IT security policy covers where this sits relative to the rest.

How to decide how much friction is right for your company

The decision rule I use is simple: the verification strength should match the blast radius of the account being reset, not the seniority of the person asking. A reset on an account with standing access to production, customer data, the identity provider itself, finance systems or the code signing pipeline gets the strongest treatment available, including manager confirmation on top of callback. Everyone else gets callback alone.

Three factors move the bar up. First, whether you are fully remote: if the agent has never met the caller and cannot walk to their desk, you lose the informal check that in-office companies rely on without realizing it. Second, whether you have a help desk at all, or whether resets are handled by an engineer in a shared Slack channel, which is faster to attack and harder to audit. Third, whether help desk work is outsourced to an MSP, in which case the MSP's internal procedure is your control and you need to see it in writing.

Companies worry that this slows people down. In practice a callback adds two to four minutes. Make that explicit to the business before you roll it out, because the pushback always arrives from sales and the executive team, and it is easier to answer a complaint with a decision that leadership already signed off on.

The steps to put this in place, in order

• Inventory the reset paths. List every way an account credential or MFA factor can currently be changed: the help desk, the IT Slack channel, self-service portals, the identity provider admin console, individual SaaS admin panels. Attackers use whichever path has the weakest check.
• Close the informal paths. Resets happen through the ticket system only. Delete or lock the side doors, including the habit of an engineer with global admin doing favours in direct messages.
• Cut the number of people who can perform resets. Fewer admins means fewer people to train and fewer people to socially engineer. Put the identity provider admin role behind privileged access approval where your tooling supports it.
• Write the one-page procedure using the elements above and date it.
• Make the HR record the source of truth for contact numbers, and define who is allowed to change a phone number in that record, with its own verification. Otherwise the attacker updates the callback number first and the control collapses.
• Set technical backstops. After any MFA re-enrolment, revoke existing sessions, require a compliant or managed device for the next sign-in where you can, and apply a short time window during which the account is treated as elevated risk.
• Turn on alerting. MFA factor removals, recovery contact changes and admin role grants should raise a notification to someone who is not the person who performed them. Tie it into your incident management process so a failed verification attempt gets triaged rather than forgotten.
• Train the agents with scripts, including the exact wording for refusing a senior person politely.
• Test it. Have someone outside the team phone in and try to break it. Do this within the first month and then quarterly.

What evidence an auditor or enterprise buyer will ask to see

Under SOC 2, this lands in the common criteria for logical access, and the auditor will sample credential changes. Under ISO 27001:2022, it maps to the controls on identity management, authentication information and access rights, plus awareness training. HIPAA has an explicit expectation around password management procedures and person or entity authentication. PCI DSS requires identity verification before any change to an authentication factor. The framework language differs; the artefacts are the same.

• The written procedure, with a version number and a review date within the last twelve months.
• A sample of reset tickets showing the verification method recorded in the ticket, not just "reset done". This is the one that fails most often.
• Logs from the identity provider for MFA factor changes and password resets, which the auditor will reconcile against your tickets looking for resets with no corresponding ticket.
• Help desk training records showing who was trained and when, including any MSP staff.
• The list of people who hold reset capability, with evidence of periodic review.
• Results of your social engineering test, including what failed and what you changed.

Enterprise buyers increasingly ask about this directly in questionnaires, usually phrased as whether you verify identity before credential resets and whether help desk staff receive social engineering training. If you are assembling answers for the first time, our walkthrough of how to run a security questionnaire engagement explains how to answer without overstating.

The mistakes that turn this into a finding

The most common is a procedure that exists on paper but leaves no trace in the ticket. If the agent verified by callback and did not write it down, the auditor treats the control as not operating. Add a required field to the reset ticket template and the problem disappears.

Second: calling back the number the caller gave you. It sounds obvious written down, and it still happens, because the caller says their old number is dead and gives a new one in the same breath. The callback number comes from your own record or there is no callback.

Third: verification questions built on data that is not private. Last four digits of an employee number, manager's name, office location and job title are all findable. If you want a knowledge check, pre-enrol a shared secret at onboarding that exists nowhere else.

Fourth: the outsourced help desk gap. Your policy says callback; the MSP's runbook says confirm two data points. Get the MSP's procedure in writing, confirm it meets your standard, and include it in your vendor review.

Fifth: never testing. A control nobody has attempted to break is an assumption. A scoped social engineering test against the help desk is cheap compared with a full red team, and for most companies at this size it is the higher value exercise. Our piece on whether you actually need red teaming covers where the line sits.

How this differs by company size and stage

Under about 30 people you probably have no help desk. One or two engineers hold the admin roles and resets happen in chat. That is workable as long as you write down that resets require a voice or video confirmation with someone the admin recognizes, and that the request is logged somewhere durable. The risk here is not procedure drift, it is that a single admin account compromise ends the discussion.

Between 30 and 100 people, the first dedicated IT generalist arrives and informal recognition stops working, because they do not know everyone yet. This is the stage where the procedure needs to be written and where I most often see the gap during readiness. It is also the stage where an auditor first samples resets in volume.

Above 100 people, you likely have shift coverage, possibly an MSP, and a reset volume high enough that self-service recovery becomes attractive. Self-service is fine if the recovery factors are strong and enrolled at onboarding on a managed device. It is a liability if recovery falls back to an email address or SMS that the help desk itself can change on request.

Common questions about help desk identity verification

How do we verify an employee who genuinely lost their phone and cannot take a callback?

Use a supervised video call where the person shows government ID and their face matches the photo in the HR record, with the agent recording in the ticket who they spoke to and what they checked. The backup path is a manager confirmation initiated by the agent through a channel the agent chooses, not one the caller suggests. Issue a time-limited temporary access pass rather than a permanent credential, require re-enrolment of a proper factor within a set window, and revoke all existing sessions on the account.

Does a SOC 2 Type II audit test the help desk reset process?

Yes, usually through sampling. The auditor pulls a set of password and MFA changes from the identity provider log over the audit period and asks for the ticket or approval behind each one. If the ticket does not show how identity was verified, or if there are log entries with no ticket at all, you get an exception on a logical access criterion. Our explainer on what SOC 2 exceptions actually mean covers how that reads to a buyer.

How often should we test the help desk with a simulated vishing call?

Quarterly is a reasonable cadence for most companies at this size, with an extra test after any change to the procedure, the tooling or the staffing. Keep each test short: three or four calls, scripted pretexts, different agents, and a written result that says whether the reset was refused and at which step. Tell the help desk team in advance that testing happens on an ongoing basis, without telling them when, so the exercise measures the procedure rather than ambushing individuals.

Should executives be exempt from callback verification?

No, and the exemption is the single most reliable way to lose an account. Executive identities are the preferred pretext because agents hesitate to push back and because those accounts often carry finance approval or broad administrative rights. Get the executive team to agree to the rule in writing before you publish the procedure, so the agent on shift has authority behind the refusal instead of having to defend it alone.