Why account restoration is now the weakest hyperlink in safety
The call came in on a Tuesday morning. A senior finance executive at a large enterprise couldn’t access her account. She’d been locked out after a routine system update, and she needed in fast. Payroll was running that afternoon.
The helpdesk agent, under pressure and working through a queue of tickets, asked a few verification questions. Confirmed her name. Her department. Her manager’s name. All information that, as it turned out, was readily available on the company’s own LinkedIn page.
Director of Product Management at AU10TIX.
Within twenty minutes, her account was reset, her MFA methods cleared and re-registered under the attacker’s control, and access was restored, effectively bypassing the very controls the organization had spent years putting in place.
The only problem? It wasn’t her.
By the time anyone realized what had happened, the attacker had spent three weeks inside the company’s financial systems, had rerouted two vendor payments, and had moved on.
The breach was never triggered by a failed login. There was no brute force attack, no stolen password, no phishing email that someone clicked by mistake. The attacker simply called the helpdesk and asked nicely.
The door we forgot to lock
For years, enterprise security has been focused on the login. Multi-factor authentication, passwordless systems, hardware tokens, biometric sign-ins: the front door of the digital enterprise has never been more fortified. And this fortification works. Attackers are increasingly blocked at the front door. So they stopped trying.
Instead, they’ve turned their attention to a much softer target: the moment when a legitimate user loses access and needs help getting it back. Account recovery. Password resets. MFA re-enrollment. Helpdesk escalations. These are the moments when the rules of authentication are temporarily suspended.
Critically, during recovery, policy enforcement mechanisms such as Conditional Access are often bypassed entirely, replaced by whatever evidence a support agent can gather in the moment.
The carefully constructed walls around an enterprise account are briefly dismantled so someone can be let back in. Increasingly, that someone isn’t who they claim to be.
Phishing attacks rose 58% between 2024 and 2025. Losses from impersonation scams have crossed the billion-dollar mark. Global cybercrime is projected to reach $23 trillion by 2027. These numbers are staggering, but they obscure a more pointed truth: nearly 70% of breaches involve a human element.
Not a zero-day exploit. Not a nation state attack on critical infrastructure. A human being making a judgment call, often under pressure, often with incomplete information, often in a recovery workflow that was designed for convenience rather than security.
What recovery actually looks like
To understand why recovery has become such a rich target, we need to understand what recovery actually looks like in most enterprise environments.
A user reports they can’t access their account. Maybe they’ve changed devices, lost their authenticator app, or been locked out after too many failed attempts. They contact IT support. The support agent, whose job is to help people and resolve tickets efficiently, needs to verify the person is who they say they are.
But the very tools that normally handle verification, the MFA app, the hardware token, the passkey, are exactly what the user has lost access to. So the agent falls back on what’s available.
That might be an SMS code sent to a phone number on file. It might be a set of security questions. It might be a conversation in which the user confirms their name, their team, their manager, their employee ID. It might be an email to a personal address.
In some organizations, it might be a manager or HR colleague confirming verbally that yes, this person works here.
These are not just fallbacks. SMS and email verification are identity downgrades: weaker signals being substituted for stronger ones at precisely the moment when the stakes are highest. Each represents a significant reduction in identity assurance, and each is exploitable in ways that have become dramatically easier in the past two years.
Consider what a determined attacker can do today with relatively modest resources.
Voice cloning technology, freely available and increasingly convincing, can replicate a person’s voice from as little as a few seconds of audio.
An attacker who has found a short video of a target on a company website, or a recording from a public earnings call, or even a podcast appearance, now has the raw material to impersonate that person in a phone call to the helpdesk. The agent on the other end hears what sounds like a stressed but familiar voice.
They want to help. The attacker knows this.
But the threat has evolved beyond individual impersonation attempts. Attackers are now using AI agents to rehearse recovery flows in advance, probing helpdesk systems to learn exactly which verification questions get asked, how agents respond to pressure, and where the soft points in the process are.
By the time the real attack takes place, the attacker has effectively audited the organization’s recovery process on their behalf.
Synthetic identities, constructed from fragments of real personal data and augmented with AI generated documents and deepfake imagery, have become sophisticated enough to pass visual inspection by untrained humans.
They’ve been used to open fraudulent accounts, pass KYC checks, and increasingly, to re-establish access to enterprise systems by convincingly impersonating real employees.
And these attacks are no longer the domain of skilled, patient threat actors. Fraud as a Service platforms now package the tools, the scripts, and even the training required to execute social engineering attacks at scale.
What once required a sophisticated criminal operation can now be attempted by almost anyone willing to pay for access to the right toolkit.
The invisible asymmetry
There is a fundamental asymmetry at the heart of account recovery that most organizations haven’t fully reckoned with.
When a user logs in normally, the authentication system carries most of the cognitive and procedural burden. The user presents credentials. The system validates them against known factors. The decision is largely automated, consistent, and resistant to social pressure.
When a user needs to recover access, that burden shifts to a human being. The helpdesk agent must assess the situation, weigh the information available, and make a judgment call.
They do this dozens of times a day, under time pressure, with incomplete information, while being evaluated partly on how quickly they resolve tickets.
The attacker, meanwhile, has had time to prepare. They know the target’s name, their team, their recent projects. They’ve constructed a convincing story. They may have already rehearsed the recovery process as a dry run to learn what questions get asked.
This asymmetry is the exploit. Not a vulnerability in code, but a vulnerability in process.
The moment trust must be re-established
It’s worth stepping back from the mechanics of attack to think about what account recovery actually represents from an identity standpoint.
At onboarding, organizations typically apply their most rigorous identity proofing: government-issued document verification, biometric checks, liveness detection. That high-assurance baseline is what strong authentication builds on.
Recovery, by contrast, often reverts to a fraction of that standard. The gap between the two is not a minor inconsistency. It is a structural vulnerability.
When a user logs in with strong authentication, they are proving, continuously and automatically, that they are the person who was onboarded. Recovery is the moment when that chain of continuous verification breaks. The user is effectively saying: I am who I say I am, but I can no longer prove it in the way we agreed. Trust me anyway.
That’s a high-risk moment and should be treated as such. The standard applied at recovery should not be lower than the standard applied at onboarding. It should, if anything, be higher, because the context is inherently more suspicious. A recovery request is, by definition, anomalous.
Something happened. Someone lost something, or claims to have lost something. That’s a signal, not a reason to relax scrutiny.
Rethinking recovery as an identity problem
The path forward isn’t to make helpdesk agents more skeptical, or to give them longer checklists, or to add more security questions. Human judgment under pressure will always be exploitable. The solution is to remove human discretion from the critical trust decision entirely.
The principle is straightforward: if recovery can override your strongest controls, it becomes your weakest control.
An organization that has invested in phishing-resistant MFA, Conditional Access policies, and hardware tokens, but allows those controls to be cleared and re-registered through a phone call to the helpdesk, has not secured its identity perimeter. It has created a bypass.
High assurance recovery means treating recovery as a step-up authentication event requiring higher assurance than login itself, not lower.
It means applying the same rigorous identity verification to a recovery event as to initial onboarding: not knowledge checks, not SMS codes, not a manager’s word, but verifiable, government grade identity evidence processed by automated systems resistant to deepfake and synthetic manipulation.
But automation alone is not enough. The right recovery process is one that is continuously updated to keep pace with the most sophisticated attackers, layering document authenticity checks, biometric verification, liveness detection, and behavioral signals into a unified defense that evolves as the threat does.
Critically, this cannot come at the cost of the user experience. A legitimate employee who has lost access should be able to recover it quickly and without friction. The same process that stops a determined attacker must also be fast and seamless for the person it is designed to protect.
Speed and security are not opposites. Done well, high assurance recovery is faster than a helpdesk call and far more trustworthy than any agent’s judgment.
It means auditing every recovery path in the organization as a potential attack path, and knowing which workflows bypass your strongest controls before an attacker discovers them first.
In an era of voice cloning, AI rehearsed social engineering, and synthetic identities, the question is no longer whether your login is secure. It’s how to make your recovery just as secure.
We’ve featured the best online cybersecurity course.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit