The service desk as front door: will your helpdesk refuse a reset?

TL;DR

• Attackers rarely need to crack your password. They call the service desk and ask for a new one, or for an MFA reset.
• Google Cloud reported in June 2026, citing M-Trends 2026, that vishing accounted for 23 percent of cloud-related security incidents, and that attackers deploy AI voice clones during high-pressure helpdesk calls.
• The voice is not the weak spot. The verification process is. What does your desk check before it resets anything, and does it still check it at five to five?
• A social engineering test calls your desk and shows whether the script holds under pressure. It judges the process, never the person who picked up.

Every organisation has a door that no firewall covers: the service desk. Someone calls, says they are locked out, sounds stressed and asks for a password reset or a new MFA registration. The person who answers wants to help. That is the job. An attacker knows this, which is why the call tends to come in at the busiest hour of the day.

Our social engineering assessments include that call. We are not testing whether your helpdesk staff are gullible. We are testing whether the verification process they were handed still works when someone pushes. Where it does not, security awareness training gives the desk a script and, more importantly, permission to use it. This post is about that script: what to check, what to refuse, and what a test tells you that a policy document cannot.

Why the service desk is the front door

Most companies have spent years hardening the outside: MFA everywhere and conditional access, a decent EDR. So the attacker stops attacking the outside. If every account is protected by MFA, the cheapest way in is to get someone to reset that MFA for you. The service desk can do that in two minutes. Nobody else in the building can.

Google Cloud put a number on it in June 2026. Based on M-Trends 2026, vishing accounted for 23 percent of cloud-related security incidents, and Google Threat Intelligence Group and Mandiant saw attackers build AI voice clones from public recordings and use them during high-pressure helpdesk calls. The same article makes a point we see in almost every test: desks are measured on speed. Average handle time rewards the agent who resets fast, not the one who calls back first.

If you want the detail on how a cloned voice is built and why it convinces people, read our post on deepfake vishing. This post stays on the other side of the line: what the desk does once that voice is on the phone.

Test the verification process, not the voice clone

Whether the caller is a real colleague, a confident stranger or a synthetic voice makes no difference to the agent. They cannot tell, and we do not expect them to. What they can do is run the checks. So that is what we test.

Most verification scripts we see ask for a name, an employee number, a manager's name and a date of birth. Every one of those is on LinkedIn, in the company directory or in a breach dump from 2019. A script built on known facts is a quiz with the answers printed on the back.

During a vishing test we call with a pretext agreed in the signed scope: a sales rep stuck at an airport, or a new hire in their first week who does not know anyone yet. Then we note which checks the agent runs, which ones get skipped once we add some pressure, and at which point in the conversation the reset is granted. The report describes the process at group level. It does not name the agent, and results are never used to sanction individuals. How a full assessment is scoped and run, we covered in our social engineering assessment guide.

Four measures that hold up on the phone

The first is a callback on a registered number. Not the number the caller gives you, but the number already in your HR system or directory. If the caller cannot be reached there, the reset waits. This single step breaks most pretexts, because the attacker does not hold that phone.

The second is manager approval for every MFA reset. A password reset locks the old password out. An MFA reset hands the account to whoever holds the new device, so it deserves a second pair of eyes. The approval has to go through a channel the caller does not control, such as a message to the manager in your own chat tool.

The third is no verification on data that can be found online. Strike employee number, date of birth and manager's name from the script, or keep them only as a first filter. Replace them with something the attacker cannot look up in advance: a code sent to the registered device, a question only the real person and your system know, or a physical check at the desk for the people who are in the building.

The fourth is a fixed refusal procedure without guilt. The Sophos research team put it plainly: make it acceptable for helpdesk staff not to help, and give them the right to politely refuse a request they cannot confirm, even when it comes from the top. That only works if the refusal is a written step with a next action ("I cannot complete this now, I am sending the request to your manager and will call you back on your registered number"), and if nobody gets a complaint afterwards for following it.

What a test shows: whether the script is followed under pressure

A policy tells you what the desk is supposed to do. A test tells you what the desk does on a Tuesday afternoon with eleven tickets in the queue. Those are two different documents.

We run the calls in waves, monitor them live and stop a scenario the moment it would cause real harm. Afterwards you get a report with what happened per scenario, where the script held and where it broke, and a concrete list of fixes with a step by step plan. Typical findings: the callback was skipped when the caller said they were abroad; the manager approval was requested from a manager the caller had named; the desk had no fixed line to refuse with and improvised. None of this means your people are careless. It means the script leaves them room to be kind, and attackers exploit kindness.

A retest a few months later shows whether the fixes stuck. In our experience, a desk that was called once and debriefed properly is a harder target than a desk that was trained twice and never called.

Frequently asked questions

What is service desk social engineering?

An attack in which someone calls or messages your helpdesk pretending to be an employee and asks for a password reset, an MFA reset or new access. The attacker does not break the technology; they ask a person to open the door.

Why do attackers target the service desk instead of the login page?

Because the login page has MFA and the service desk can remove it. A reset takes minutes, leaves little trace and is a normal part of the desk's day, so it rarely raises an alarm.

Does an AI voice clone make a difference for the helpdesk?

Less than you would think. The agent cannot tell a clone from a real voice anyway, so the defence never depended on recognising the voice. It depends on a callback to a registered number and an approval step the caller does not control.

What does a social engineering test of the service desk involve?

We agree the scope, the pretexts and the rules in a signed agreement, call the desk in controlled waves and record which verification steps are run, skipped or bypassed under pressure. You receive a report at group level with concrete improvements. See our social engineering service.

Will my helpdesk staff get in trouble after a test?

No. Reporting is at group level and results are never used to sanction individuals. The goal is a better script and the permission to follow it, not a list of names.

How often should we test the service desk?

After every change to the verification script, after onboarding a new team or an outsourced desk, and otherwise about once a year. A retest shows whether the fixes from the first round held.

Related services and resources

The call to your helpdesk is one scenario within our social engineering assessments, next to phishing, smishing and a physical mystery guest; the telephone part is described in more detail on our vishing page. The script and the permission to refuse come from security awareness training, and if you want to know what such a programme should contain, start with our security awareness training guide or our post on gamified phishing simulation. For background on cloned voices, read deepfake vishing explained, and for how a full assessment is scoped, the social engineering assessment guide.