There is a version of an intrusion that involves no exploit, no malware, and no anomalous traffic. Someone calls the help desk, says they are an employee locked out ahead of a meeting, answers every verification question correctly, and receives a password reset and an MFA re-enrollment. Ninety seconds later there is a fully authenticated identity in your tenant that no control flagged, because nothing that happened was technically abnormal. It was your own process, executed correctly, on behalf of the wrong person.

We build and run this exact sequence against enterprise organizations as an authorized engagement, and it is the one that most reliably changes the mood in a room. Mature programs. Good analysts. Documented procedures. The call still works, and what it produces in a controlled simulation is the same thing it would produce for an adversary who is not obligated to hand it back.

The uncomfortable part is that the help desk is not failing. It is succeeding at the job it was given. Speed, courtesy, and getting a blocked user back to work are the metrics that desk is measured on. Impersonation does not break those incentives, it uses them.

Two Directions, One Pretext

Most write-ups treat IT support impersonation as a single technique. In practice it is two, and they fail differently.

Outbound, IT to employee. The caller poses as internal support and asks the user to authenticate, approve a prompt, read back a code, or join a remote session. This works because the ask is the job. Nothing about a support engineer requesting an authentication is anomalous, and the user believes they are receiving help rather than granting access, so the part of their judgment that would normally engage never does.

Inbound, employee to help desk. The caller poses as a locked-out employee and requests a password reset or an MFA re-enrollment. This is the direction behind the most damaging enterprise intrusions of recent years, and it is worse for a simple reason: a successful outbound call usually yields one session, while a successful inbound call yields a working identity, complete with a credential the adversary chose and a second factor bound to a device they control.

The inbound direction also concentrates risk in a way most organizations have not modelled. Every employee is one target. The help desk is one target that can be reached about every employee, from any phone, at any hour, with unlimited retries and no rate limit.

How the Call Runs

Below is the inbound sequence as we observe and reproduce it. Open each phase to see what the caller is actually doing underneath the friendly version, and where it can be stopped. Nothing here requires exotic capability. It requires patience and a phone.

Take the Call Yourself

Reading the phases is not the same as sitting in the chair. Below is the same inbound sequence as a scripted simulation you work through as the analyst. At every step it tells you plainly what just happened and why it worked. Read the disclosure first, because being explicit about what this is and is not is the whole point of running it on a public page.

If you would rather not work through it, the short version is in the phase cards above. Nothing in the simulation is withheld from the written breakdown.

Why Identity Proofing Fails

The standard verification script is knowledge-based authentication with a friendlier name. It works only when the knowledge is private, and for a corporate employee almost none of it is. Manager name, job title, department, office location, start date, device platform, and even the subject line of a recent ticket are public, inferable, or purchasable.

So the question worth asking is not whether your desk verifies identity. It is which of the questions on your script would survive a caller who spent an afternoon preparing. Work through your own script below.

Two results are worth sitting with. If the second group is empty, your desk is not verifying identity, it is verifying preparation. And if the second group has entries but they are optional, applied at analyst discretion, then under queue pressure they are effectively absent, because discretion is exactly what a good pretext is designed to move.

Why Detection Training Does Not Save You

The instinct is to train the desk to spot the fake voice. It is the wrong control, for three reasons that have nothing to do with how hard people try.

It degrades by design. Every artifact you teach someone to listen for, the flat prosody, the odd pause, the breath that is not there, is a defect in the current generation of synthesis, and those defects are being engineered out. A control whose effectiveness declines as the adversary improves is not a control, it is a countdown.

It puts the decision in the worst place. You are asking an analyst, mid-queue, on a call they did not initiate, to make a forensic media authenticity judgment they are neither trained nor equipped to make. Specialists get this wrong with tooling.

It manufactures false confidence. An analyst who has completed detection training and believes they can tell is more dangerous than one who knows they cannot, because certainty is precisely what the pretext needs in order to skip the callback.

The Controls That Hold

Everything below shares one property. It works whether or not the person on the phone is real.

• Ticket-first for every privileged action. No password reset, MFA re-enrollment, or remote session without a pre-existing ticket the requester can independently see in the portal. This takes the judgment call off the analyst and turns it into a state check.
• Out-of-band callback to the number of record. Sourced from the directory, never from the caller, the caller ID, or a link in a text. In the outbound direction, the same rule for users: end the call, look up the number yourself, dial it.
• Proofing that is not researchable. Replace knowledge questions with possession or attestation. A code to an already enrolled device, a callback, or a manager confirming on a separate channel. If a question can be answered from a public profile, it is theatre.
• Treat factor re-enrollment as the crown jewel. It is the action that converts a call into an identity. Highest friction, separate approval, never bundled with a password reset in the same interaction, and a hard escalation path for privileged accounts.
• A standing negative rule, published everywhere. IT will never ask for your password, never ask you to read back an MFA code, and never ask you to approve a prompt you did not personally start. A rule with no exceptions is a rule a user can apply under pressure. A rule with exceptions is a rule an adversary can talk their way into.
• Reporting that costs less than complying. If reporting takes six minutes and a form, and complying takes ninety seconds, you have already chosen the outcome. One button, one number, no judgment required about whether it was worth reporting.
• Notify the real user, every time. A reset or re-enrollment should generate a message on the user's known-good channel. It is the cheapest way to shrink the window between the call and the first person who knows something is wrong.

None of these ask anyone to be a detector. They ask people to follow a procedure, which is a thing organizations already know how to build, staff, and measure. We walked through how the same procedural controls behave in a remote support scenario in our remote support simulation breakdown, and the voice side of the same problem in our analysis of AI spear vishing.

Measure the Right Thing

Click rate is meaningless on a phone call, and its equivalents are not much better. If your program reports how many people answered, you have measured availability, not risk. These are the questions worth answering after a simulation.

The last two matter most. An analyst who felt something was wrong and hung up without reporting is not a success, it is an adversary who gets to try the next analyst with nobody watching. And an internal trend line only tells you whether you improved against yourself, which is a low bar when you do not know where you started relative to peers.

What We Would Do First

If you have one week and no budget, do these three things in this order.

Publish the negative rule. IT will never ask for your password or your MFA code, and will never ask you to approve a prompt you did not start. Put it in plain language everywhere your users look, including the signature block of every help desk analyst.

Audit the reset script against a researched caller. Sit with an analyst, take the procedure they actually follow, and ask of every verification question: could someone find this on a professional profile, in a job posting, in a data broker record, or in a public filing? Whatever survives is your real control, and it is usually shorter than the script. The audit above is a fast way to run that conversation with the desk in the room.

Then run the call. Not a survey, not a module, a scoped and authorized simulation against your real process, measured on the action rate and the verification rate. The gap between what people say they would do and what they do on a live call is the entire problem, and it does not close on its own.

Frequently Asked Questions