Almost every security team I talk to already agrees the help desk is exposed. That is not the hard part anymore. The hard part is that agreeing costs nothing and deploying costs something, and the thing that costs something keeps losing to whatever else is on the roadmap.
So this is not another piece arguing that help desk social engineering is a problem. Mandiant settled that. In M-Trends 2026, highly interactive voice phishing was the most common initial infection vector in cloud intrusions during 2025, at 23%, and the second most common across all intrusions, at 11%, behind exploits. Over the same period email phishing fell to 6%, down from 14% the year before. Attackers moved to the phone because the phone works, and the report names UNC3944, the group publicly tracked as Scattered Spider, targeting IT help desks specifically to get around multifactor authentication.
This is about why the fix does not get deployed, and what a version that ships looks like.
Detecting account takeover during remote support
Most teams try detection first, and it is useful to understand why that goes the way it does.
The signals that a remote support interaction is fraudulent are real:
A caller who knows a great deal of static information, employee ID, manager, start date, but stumbles on something operational and recent, like what they were working on yesterday or who else is on their team. A contact detail changed shortly before a reset request arrives. Requests that carry urgency plus a reason the normal channel cannot be used. Resets requested for accounts with elevated access, clustered in a short window. Calls timed to shift changes, Friday afternoons, or holidays when senior staff are out. Several requests across unrelated accounts from numbers that resolve to the same carrier or region.
Each of these is a genuine indicator. Here is the problem with all of them.
They are pattern signals, and a support agent handling a queue does not see patterns. They see one call. The clustering that makes these obvious is visible in aggregate, usually during a post-incident review, which is to say after it worked. Meanwhile the agent has a resolution time target and a caller who sounds stressed and reasonable.
Voice cloning removed the last signal that used to be available in the moment. The hesitation, the accent that did not match, the pause before answering a personal question: all of that is now synthesizable from a few seconds of public audio.
Detection training is worth doing and it will not close this. You cannot ask a person to out-perform a system built specifically to fool people, while also hitting an SLA. The durable version is removing the judgment call, so the agent is never the control.
Why the deployment stalls
Every team that reaches this conclusion runs into some subset of the following. None of these are security objections, which is what makes them hard to argue with.
The identity team has no capacity
Whoever owns the identity provider is already carrying an SSO migration, a joiner-mover-leaver cleanup, and an audit finding. A new integration goes into the queue behind all of it. In mid-market organizations that queue is often one person.
Change control is slower than the threat
A change to the password reset path touches production authentication. That means CAB review, a rollback plan, and a window. Three weeks minimum in most places, longer if the window keeps getting bumped.
Privacy raises document handling
Asking employees to scan a government ID triggers a conversation about what is stored, where, for how long, and under which legal basis. In Europe or anywhere with a works council or organized labor agreement, add a consultation step measured in months. This objection is legitimate and gets a lot of projects paused.
Accessibility review is not optional
A verification flow that only works one way needs to be defensible under accessibility obligations. Anything requiring a specific mobile app or a camera interaction has to have a documented alternative before it clears review, and if the alternative is “call the help desk,” you have rebuilt the hole.
Nobody owns the outcome
Security owns the risk, IT owns the reset workflow, and support owns the ticket queue and the SLA. The control improves the first, complicates the second, and is measured against the third. Projects with three owners and no single one accountable stall by default.
The pilot never ends
This is the honest one. Enough teams run a limited proof of concept, confirm it works, and then never expand it, because expansion means the change control conversation again with a broader blast radius.
What a deployment that ships looks like
The pattern in the projects that go live quickly is consistent, and it is mostly about what they avoid rather than what they do.
Start where no integration is required. If the control can run from the agent side, with the agent sending a verification link rather than the system changing the reset flow, then nothing in production authentication has been touched. That takes CAB out of the critical path entirely for the first phase. Our zero-integration option for call center operations works this way, and deeper workflows through the ITSM API come later, once the control has proved itself and has a sponsor.
Solve the enrollment problem before it becomes a project. Any control depending on users having registered something in advance inherits an enrollment campaign, which is its own project with its own timeline and its own long tail of non-compliers. Verification that requires nothing set up in advance removes that dependency, and it removes the population that would otherwise need an exception path.
Get the privacy answer up front, in writing. Not at the review, before it. What is captured, what is retained, what is discarded, and who can see it. Trusona stores no user PII. Whatever your vendor’s answer is, having it documented before the conversation starts turns a multi-week detour into an agenda item.
Pick one flow, not the category. Highest-risk resets, or one team, or one privileged group. A scope small enough that no single group has to reorganize around it is a scope that can go live without a steering committee.
Have the fallback designed before launch. What happens when verification fails is the question that determines whether the control is real. If a failure routes to an agent with no further check, an attacker fails on purpose and takes the old path. The fallback needs a defined, controlled route, and someone has to own it.
Our fastest customer deployment went live in 30 minutes. That is not typical and I would not present it as typical. It is worth stating because it establishes what the technology requires when nothing organizational is in the way, which means every timeline longer than that is being set by process rather than by the product. That is a much more tractable problem, and it is a different conversation than “this will be a six month integration.”
Deployment effort by approach
| Approach | Touches production auth | Requires user enrollment | Typical blocker |
|---|---|---|---|
| Extend knowledge-based questions | No | No | Does not work, attackers already have the answers |
| Add a factor-possession check to the reset flow | Yes | Yes | Identity team capacity plus an enrollment campaign |
| Agent-initiated verification link | No | No | Agent workflow change and training |
| Integrated identity proofing in the reset path | Yes | No | Change control and privacy review |
The third row is where most fast deployments start, and the fourth is where they end up. The mistake is trying to begin at the fourth.
Frequently asked questions
What makes account takeover protection hard to deploy in help desks?
Rarely the technology. The common blockers are identity team capacity, change control on production authentication, privacy review of identity document handling, accessibility requirements, and unclear ownership between security, IT, and support. Deployments that ship quickly start with an option that does not touch the reset flow.
How do mid-market IT teams detect account takeover during remote support?
The reliable signals are pattern-based: contact details changed shortly before a reset request, urgency combined with a reason the normal channel cannot be used, clustered resets on privileged accounts, and callers strong on static data but weak on recent operational detail. The limitation is that agents see individual calls rather than patterns, so detection alone is not a sufficient control.
Can help desk agents be trained to spot social engineering?
Training helps and is worth doing, but it cannot be the primary control. Voice cloning removes the cues agents were trained to notice, and an agent working against a resolution time target is being asked to out-perform a system designed to fool people.
How long does an identity verification deployment take?
It depends almost entirely on whether it touches production authentication. Agent-side verification that requires no integration can go live in a day. Our fastest customer went live in 30 minutes. Integrating into the reset flow itself adds change control and privacy review, which in most organizations is measured in weeks.
Do we need to integrate with our identity provider first?
No, and starting there is usually what stalls the project. Beginning with an agent-initiated flow proves the control and builds the internal case, which makes the integration conversation easier when you get to it.
What happens if identity verification fails for a legitimate user?
This has to be designed before launch. If a failed verification simply routes back to an agent with no additional control, an attacker will fail on purpose to reach the weaker path. The fallback needs to be defined, controlled, and owned.
Up and running in as little as 30 minutes.