The help desk is the new perimeter: harden MFA resets

Why support became the target (the conclusion in one sentence)

If your organization already has MFA on every account, the likeliest attack no longer tries to break it: it tries to get someone on your team to turn it off for the attacker. That someone is almost always the help desk. An attacker posing as a locked-out employee calls, asks for a second-factor reset and, if the verification process is weak, walks away with access without exploiting a single technical vulnerability.

The conclusion, in one sentence: support became the perimeter, and you harden it with process, not with more tools. The first concrete step, the one that pays off most, is to require out-of-band verification before approving any MFA reset, so that the caller's identity does not depend on data anyone can look up.

It is worth understanding why this flank weighs so much. Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor, and the help desk concentrates that factor at a single decision point: one person, under pressure, authorizing a sensitive change over the phone. It is not carelessness, it is the very design of support work, which exists to unblock people fast. The attacker does not attack a system flaw, the attacker attacks the willingness to help.

How the attacker turns support into the shortcut around MFA

The deception rarely starts on the call. It usually starts earlier, by email. According to CISA, more than 90 percent of successful cyberattacks start with a phishing email, and that first email gives the attacker exactly what they need: a leaked password, a real name, the manager's name, the internal jargon. With that they build a credible pretext and only then pick up the phone. The call to support does not replace email, it adds to it as the second move that turns a stolen credential into full access. Phone-based social engineering against support has been growing sharply through 2026, and much of today's initial access starts from credentials that were already exposed.

The script is always similar. The attacker introduces themselves as an employee with an urgent problem: a trip, a client meeting, a lost phone, and asks to reset the MFA to get back in. They supply exactly the data a weak process asks for as proof, the last digits of an ID, the hire date, the manager's name. All of that data leaks or gets bought. When the support agent, with the best intentions, approves the reset, the attacker enrolls their own device as the second factor, and from then on the MFA protects them.

What follows is fast, and that speed is what raises the stakes. According to Mandiant's M-Trends 2026 (Google Cloud), the hand-off time between initial access and the actor who executes the attack collapsed from more than eight hours in 2022 to 22 seconds in 2025. In help desk terms: between the reset being approved and the intruder starting to move laterally there is almost no window to react. The control has to sit before the reset, never after.

Step 1: require out-of-band verification before any reset

The principle is simple: the proof that someone is who they claim cannot travel over the same channel they use to ask for the favor. If the request comes in by phone, the verification goes out another way. In practice this means calling back the employee's registered number in the directory (not the number they called from), sending a code to an already validated channel, or requiring a video confirmation with the ID in view for sensitive roles.

The non-negotiable rule: whoever requests the reset does not control the channel through which their identity is verified. That single change collapses most pretexts, because the attacker can imitate a voice and a tone, but cannot answer the real employee's phone or receive the code on their registered device.

Step 2: separate who requests from who approves (dual control)

An MFA reset approved by a single person is a single point of failure, and attackers know it: they pick the busiest hour, the overnight shift, the newest agent. The defense is dual control. For the highest-risk accounts, finance staff, executives, system administrators, whoever receives the request should not be the one who approves it.

The agent logs the request and a second role, a supervisor or the account owner themselves through a separate channel, gives the go-ahead. There is no need to apply it to all thousand employees equally, you apply it where the damage of an improper reset is greatest. That way the friction concentrates where it really matters, and the attacker loses the single link they came for.

Step 3: harden identity proof beyond data that leaks

The most common mistake is verifying identity with data that stopped being secret a long time ago. The ID number, the date of birth, the job title, the hire date, even recent transactions, all of it shows up in breaches, appears on social media or gets bought in forums. Asking for it gives a false sense of rigor.

Strong proof rests on something the attacker does not have: a factor the company controls end to end. A one-time code sent to a previously registered device works, so does a physical security key for critical roles, or a video liveness check with the employee showing their ID for the most delicate resets. The underlying criterion is a single one: if the answer can be looked up, it proves nothing.

Step 4: log, limit and review every MFA reset

All of the above falls apart if no one watches what happens. Every MFA reset is logged with who requested it, who approved it, through which channel it was verified and at what time. That log turns an invisible event into an auditable signal.

On top of it you set limits: alert when the same account requests several resets in a short span, when the request arrives outside the employee's working hours, or when several cluster into a short window. And you review: a weekly read of approved resets catches the pattern a single agent, in the moment, cannot see. The goal is not to slow support down, it is to leave a trail so a fraudulent reset does not go unnoticed precisely in the days when it does the most harm.

How you test and validate that support withstands the deception

A written process proves nothing until someone tries to break it. That is why support, like any high-exposure role, is put to the test: you simulate the deception attempt and measure how the team responds under real pressure, not in an exam where the person knows they are being evaluated.

And here a distinction backed by evidence is useful. Peer-reviewed work, by Grant Ho and his team at the 2025 IEEE Symposium on Security and Privacy, and earlier by Daniele Lain and colleagues in 2022, shows that completing training does not by itself predict that a person will act differently against a real attack. What proves the change is not the course, it is testing the behavior again weeks later, with a different scenario, and seeing whether the team applied what it learned. We call that a retest, and it is the difference between assuming support learned and confirming it.

This piece hardens the process; to understand the anatomy of the phone attack that tests it, we wrote separately about vishing against the help desk, which describes the fraud itself, not how to shield the reset. They are complementary pieces: one explains the attack, this one raises the defense.

At Fensivo we treat the support team for what it is, a high-exposure role, and we test it with phishing simulations by email personalized to its function, not with a generic course. When someone falls, training arrives right away and, weeks later, a retest with a different template validates whether behavior actually changed. We do not operate your help desk or replace your verification process: we give you the signal of which roles withstand the deception and which do not yet, so you harden the reset where it is needed most. You can see how it fits in our use cases.

So the uncomfortable question is this: if an attacker called your help desk today posing as your CFO and asked to reset their MFA, what would stop them, your process or the luck of whichever agent picks up?

Sources and references

• Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", May 27, 2025: https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity
• CISA, "4 Things You Can Do To Keep Yourself Cyber Safe": https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe
• Mandiant (Google Cloud), "M-Trends 2026 Report": https://cloud.google.com/security/resources/m-trends
• Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/11023357
• Lain, D., Kostiainen, K. and Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/9833766