Every post-breach conversation eventually lands in the same place: someone failed to catch a suspicious request, a ticket was approved that shouldn't have been, and an agent made a judgment call under pressure that turned out to be wrong.

The instinct is to focus on that person. More training, tighter scripts, stricter escalation rules. That response feels proportionate to what happened. The problem is that the failure is structural, and training doesn't fix a process that was never equipped to handle what attackers are doing today.

What the attacker actually did

In September 2023, a member of the hacking group Scattered Spider called MGM Resorts' IT help desk. They had done their homework, gathering enough detail from LinkedIn to pass convincingly as a real employee. The call lasted roughly ten minutes, and by the end of it the agent had reset the caller's credentials and MFA, giving the attacker full access to MGM's systems.

The breach cost MGM $100 million in Q3 2023. Caesars fell to the same group around the same time, reportedly paying $15 million to limit the damage.

Neither company had a help desk staffed by careless people. Both had agents doing exactly what the job asked of them: listen to a caller, ask verification questions, and make a call. The process just didn't give them anything real to work with.

The verification question problem

For years, account recovery has relied on knowledge-based authentication: questions about a mother's maiden name, a prior address, the last four digits of a Social Security number. The assumption seemed sound, because only the real account holder would know these things. It has been quietly obsolete for years.

Personal information is available on the dark web for less than a dollar per record, which means a prepared attacker can now answer security questions more accurately than the legitimate user they're impersonating. What was once a verification layer has become a research assignment, and attackers are doing the homework before they pick up the phone.

According to the CrowdStrike 2025 Global Threat Report, vishing (voice phishing) attacks surged 442% between the first and second half of 2024. These are structured, researched, and repeatable attacks that are working precisely because the process on the other end was designed for a different threat environment.

The pressure your agents are actually under

Here's what a help desk agent is actually being asked to do during an account recovery request: listen to a caller claim to be someone, work through a series of questions that a motivated attacker may already know the answers to, form a real-time judgment about whether this person is who they say they are, and resolve the ticket efficiently, because resolution time is tied to performance metrics.

If they're too cautious and deny a legitimate user, they generate a complaint and hurt their numbers. If they approve a fraudulent request, they may never know what happened until forensics traces the breach back six weeks later. Both outcomes are on them, and neither is preventable with the tools they have.

The Verizon 2024 Data Breach Investigations Report found that 68% of breaches involve a non-malicious human element, meaning a person made an error or fell for social engineering. Pushing more training into that gap doesn't close it when the underlying process doesn't give people better tools to work with. Security awareness training and identity infrastructure are two different things.

The difference between authentication and identity

Authentication confirms that someone has a factor: a password, a device, an authenticator app. What it cannot confirm is that the person presenting that factor is the person it belongs to.

At routine login, that distinction rarely matters. At account recovery, it matters completely, because recovery is precisely the moment when authentication has already broken down. The credentials are gone, the MFA device is lost or inaccessible, and everything the standard process relies on has been severed. The only thing left is a caller's claim about who they are, evaluated in real time by someone with no reliable way to check it.

Answering "is this person actually who they say they are?" with security questions or human judgment under pressure is the gap that sophisticated attackers have learned to exploit at scale. Closing it requires infrastructure that can actually answer that question, rather than routing it to whoever picks up the phone.

What identity-first account recovery looks like

When identity verification handles the recovery determination, the dynamics shift for everyone involved. The agent's role changes from making an identity call they're not equipped to make to routing a request to a process that is. A government-issued ID is validated, liveness detection confirms the person is physically present, and fraud signals are applied before access is restored.

For a global platform with more than 150 million users, that shift produced zero fraudulent password resets on launch and an average recovery time of 12 minutes. Legitimate users got their accounts back quickly, fraudsters were stopped, and the help desk team stopped carrying a burden the process was never designed to give them.

That's the version of account recovery that closes the gap: a verified, auditable process that answers the identity question instead of routing it to whoever happens to pick up the phone.

There's something that becomes obvious when you've spent time inside the certificate authority business. PKI solved the machine identity problem decades ago. When your browser connects to a bank's website, a cryptographically signed certificate tells it exactly who it's talking to, issued by a CA operating under strict audit controls, verifiable by any relying party independently. The whole system works because trust is mathematically provable, not procedurally assumed.

Account recovery has never had an equivalent. It's been running on the honor system. An agent listens, asks questions, makes a call. The trust is assumed because there's no infrastructure to prove it.

What changes with identity-first recovery is that every verification event produces a signed credential, not a log entry. The CA infrastructure that secures global banking traffic is the same infrastructure backing the recovery decision. When a regulator asks who authorized that account restoration, the answer isn't a ticket number and an agent's best judgment. It's a cryptographically verifiable record that holds up under FFIEC examination the same way a TLS certificate holds up under audit.

That's what it means to treat identity as infrastructure rather than process. And account recovery, because it's the moment authentication has already failed, is where that distinction matters most.

Want to see how identity-first account recovery works in practice? Learn how Proof replaces judgment calls with verified identity and what that means for your help desk, your security posture, and your users.

See how Proof handles account recovery →