Someone calls the help desk, says they are locked out, and explains that their phone number changed over the weekend. The agent has a queue of forty tickets and a caller who knows the employee’s manager, start date, and the name of the project they are on. The agent resets the MFA enrollment. The attacker is now inside, holding a legitimate factor, and every downstream control treats them as the real employee.
The security industry spent a decade hardening authentication and left the recovery path mostly alone. That is the gap buyers are shopping for when they start looking at account takeover protection for help desks, and it is why the category is confusing. Products that look similar on a feature grid are solving different problems.
Most of the work in choosing one is telling the approaches apart, which is harder than it should be, because the marketing for all three uses the same words.
What is account takeover protection for IT help desks?
Account takeover protection for help desks verifies that the person requesting a password reset, MFA change, or account recovery is who they claim to be, before the change goes through. It sits in front of the recovery path rather than the login path, which is where social engineering attacks land.
That distinction matters more than it sounds. Login authentication asks whether someone holds a valid credential. Recovery asks whether someone should be issued a new one. An attacker who has already convinced an agent to hand over a factor passes every login check afterward, because at that point they are not bypassing authentication. They own it.
Why the recovery path became the target
Attackers went where the controls were not.
Mandiant’s M-Trends 2026, built on more than 500,000 hours of incident response during 2025, found that highly interactive voice phishing was the most common initial infection vector in cloud intrusions, at 23%, ahead of third-party compromise at 17% and stolen credentials at 16%. Across all intrusions it ranked second at 11%. Email phishing fell to 6%, down from 14% a year earlier.
Attackers did not move to the phone because it scales better. It scales worse. They moved because the phone reaches the part of the system email cannot, which is the person with authority to reset a credential.
The group most associated with the pattern is Scattered Spider, which Mandiant tracks as UNC3944. The playbook is repeatable: research the target on social media and breach dumps, call support, claim a lost or changed device, ask for an MFA reset. M-Trends names the behavior directly, describing how groups like UNC3944 “target IT help desks to bypass multifactor authentication (MFA) and gain initial access to software-as-a-service (SaaS) environments.” No malware, nothing to patch. The technique works because it targets a person who is measured on ticket resolution time and who has been given authority to override the process.
It works often enough to change the shape of the breach data. Obsidian Security, reviewing SaaS breaches over the twelve months to mid-2024, found attackers had subverted MFA in 70% of them.
Generative AI made the calls harder to screen. Voice cloning removes the accent mismatch and the hesitation that used to make an agent suspicious. An agent listening for something that sounds wrong is now the weakest control in the stack, and asking that agent to try harder is not a fix.
The three approaches
Vendors in this category solve the problem in one of three ways. Most buyers do not realize they are choosing between architectures rather than features.
Knowledge-based verification
The caller answers questions: employee ID, manager’s name, last four of the SSN, the security questions set during onboarding.
This is the incumbent approach and the one attackers have had the most success against. Every input it relies on is either in a breach dump, on LinkedIn, or obtainable from a single successful phishing email. It is cheap because it is already built into the ticketing workflow, which is the main reason it persists.
It still has a place for low-risk requests where being wrong costs very little.
Possession of an enrolled factor
The system pushes a prompt to a device the user registered earlier, or sends a code to a number on file.
Stronger than knowledge, and it covers a large share of routine resets. It has a specific structural failure: it cannot help when the enrolled factor is the thing being reset. A user who lost their phone, or an attacker claiming to have lost it, lands in exactly the same queue. That queue is the attack surface. It also fails for anyone who never enrolled, which in most organizations means contractors, day-one hires, alumni, seasonal staff, and the population that refuses to install a corporate app on a personal phone.
It covers the users who enrolled successfully and still hold what they enrolled, which is most people on most days.
Identity proofing at the time of the request
The user proves who they are during the recovery event itself, usually by scanning a government-issued ID that the system checks for document integrity and matches against an authoritative record, alongside signals from the device being used.
This closes the enrollment gap, because nothing has to be registered in advance. It also removes the agent from the decision: the system approves or denies, so there is no judgment call to socially engineer. Trusona’s ATO Protect works this way, checking the document against authoritative sources and reading device signals to catch man-in-the-middle attempts.
It has real limits. A legitimate user under coercion will pass, because they are who they say they are. The check also inherits the integrity of the underlying identity record. If someone established a synthetic identity with real documents years ago, document verification confirms the synthetic identity rather than catching it. Anyone selling document verification as protection against every form of fraud is overselling it.
How this fits alongside your existing MFA
The most common objection is that this duplicates an MFA investment. It does not, and the reason is worth being precise about.
MFA governs authentication: proving control of a credential at login. Identity verification governs recovery: deciding whether to issue a new credential. They cover different moments and different failure modes. An organization with excellent MFA and an unprotected reset path has a strong front door and an unlocked back one, which is the configuration Scattered Spider has been profitable against.
In practice these run as a layer in front of the existing reset workflow rather than a replacement for the identity provider. ATO Protect drops verification links into ServiceNow, Zendesk, Jira, Ivanti, and Freshdesk tickets, with an ITSM API for deeper workflows, so the directory stays where it is. For call center use there is no integration at all, because the agent sends a verification link rather than making a judgment call.
The question to ask any vendor is not whether they integrate with your identity provider. Nearly everyone will say yes. Ask what specifically has to change in the reset workflow, and who has to build it.
The attack that runs the other direction
Everything above assumes the attacker calls the help desk. Some of these attacks reverse the roles: the attacker calls the employee, says they are from IT, and talks them into installing remote access software or handing over credentials. Writing in SecurityWeek in August 2025, Torsten George called impersonating IT help desk personnel by phone or text one of Scattered Spider’s most effective and recognizable tactics.
The technique has not aged out. In August 2026, Google Threat Intelligence published its analysis of UNC6671, a vishing extortion operation that calls employees on their personal mobile phones while spoofing the company’s own help desk number, then pushes them toward credential-harvesting pages dressed up as urgent passkey and MFA migrations.
No amount of verification on the inbound reset path helps here, because the employee is the one being called. The control has to work in the other direction, giving the employee a way to check that the person claiming to be IT is real. Trusona’s Agent Verify does this with a single-use, time-limited code tied to both the agent and the call: the employee asks for the code and confirms it on an internal company page before acting. If no valid code exists, the call ends.
Worth asking any vendor which of the two directions they cover. A product that only verifies inbound reset requests leaves the vishing route open, and the two problems are usually sold as though they were one.
Seven questions to ask any vendor
What happens when the factor being reset is the only factor enrolled?
This is the scenario the whole attack depends on. If the answer routes back to a human agent, the product has not closed the hole it is being bought to close.
How does this work for someone who never enrolled anything?
Contractors, day-one hires, alumni, and staff without corporate phones. In most organizations this population is larger than IT expects, and it is where exceptions get made.
Who makes the final decision, the system or the agent?
If an agent can override the result, then the control is advisory and social engineering still works. Ask whether override is possible, who can do it, and whether it is logged.
What is in the audit record?
After an incident, someone will ask what evidence exists that a given reset was legitimate. A timestamp and a ticket number will not answer that. Ask what the record contains and how long it is retained.
What happens to the identity document after the check?
This determines whether your privacy team blocks the project in month two. Ask whether the document image is stored, for how long, and where. Trusona stores no user PII.
How long from contract to a working reset flow, and what does IT build?
Ask for the shortest real deployment the vendor has done, not the average. Our fastest customer deployment went live in 30 minutes, using the zero-integration option for call center operations. Deployment stays code-light across digital channels.
What does the flow do when verification fails?
The most important question and the one most guides skip. If a failed verification drops the user back to a human agent with no further checks, the attacker simply fails the verification on purpose and proceeds through the path that was always weakest.
Comparing the three approaches
| Knowledge-based | Enrolled factor | Identity proofing at request | |
|---|---|---|---|
| What it checks | What the caller knows | Control of a registered device or number | Whether the person matches an authoritative identity record |
| User setup needed in advance | None | Enrollment before the incident | None |
| Covers users who never enrolled | Yes | No | Yes |
| Works when the enrolled factor is what’s being reset | Yes | No | Yes |
| Agent’s role in the decision | Judges the answers | Confirms a prompt was approved | Removed from the decision |
| Primary failure mode | Breached or public data | Lost, swapped, or never-enrolled device | Coercion; compromised underlying record |
| Typical deployment effort | Already in place | Already in place | Added in front of existing workflow |
What this looks like in practice
The University of Connecticut put identity proofing into its NetID password recovery flow through the ATO Protect API. Students, staff, and alumni recover accounts by verifying with a government ID instead of waiting in the help desk queue, and complete the reset in under a minute. The alumni population is the useful detail: they are exactly the users who never enrolled a corporate factor and who, under the enrolled-factor model, would have no path except a human agent.
Frequently asked questions
What is the best solution to stop account recovery fraud?
There is no single product answer, because the right control depends on which failure mode you have. If your resets already route through enrolled devices and your problem is users who cannot enroll, identity proofing closes that gap. If agents can override any control, fix the override policy first, because no product survives it.
Which products prevent account takeover during support interactions?
The category includes identity verification platforms, IDV and document-verification vendors, and identity provider features. They differ in whether verification happens at enrollment or at the moment of the request. That difference matters more than any feature comparison.
What tools verify remote identities in enterprise IT help desks?
Look for out-of-band verification on a device the user controls, a check against an authoritative record rather than internal HR data, and an automated decision the agent cannot override.
Can account takeover protection work alongside existing MFA?
Yes, and it should. MFA covers login. Recovery verification covers the reset path. Products in this category generally run in front of the existing workflow rather than replacing the identity provider.
What should mid-market IT departments look for?
Deployment effort, more than anything else. Mid-market teams rarely have IAM engineers to spare, so the practical question is whether the control can go live without a development project. Ask for zero-integration or configuration-only options and a real deployment timeline.
How should banks evaluate this for call centers?
Call centers add a regulatory dimension around authentication and recordkeeping that internal IT help desks do not have. The core evaluation is the same, but the audit record requirement is stricter.
Get started today, for free.