Within a few weeks this summer, two companies at the center of enterprise identity made several related announcements: First, Microsoft announced that passkeys will become the default authentication method in Microsoft Entra ID with SMS and voice options deprecated by the end of the year, and that security questions will be retired from the self-service password reset (SSPR) feature as of March 2027.

Around the same time, Okta's threat intelligence team published research detailing how attackers are increasingly targeting passkey enrolment and recovery flows to complete account takeovers. Importantly, Okta also found that organizations frequently targeted by serious threat actors almost always have their users enrolled in phishing-resistant methods.

This convergence is not a coincidence, and it raises a question that every CIO should be sitting with: Now that you’ve rolled out phishing-resistant MFA across your organization, what happens when an employee claims they lost their device?

Stronger Authentication Doesn’t Stop Attacks, it Redirects Them

A hard lesson of security is that better defenses don’t stop attacks so much as shift them to other vectors. As phishing-resistant MFA makes the login screen harder to crack, attackers are moving to the parts of the identity lifecycle that are still soft. Okta named those parts plainly in its recent research, describing how strong sign-in policies shift a threat actor's options to "the next weakest point in the user lifecycle: enrolment and account recovery."

Microsoft concurs. In May, their threat intelligence researchers documented how a threat group, tracked as Storm-2949, breached a cloud environment without defeating a single authentication control. The bad actors triggered a self-service password reset (SSPR) for a target account, called the victim employee while impersonating IT support and talked them into approving the resulting MFA prompt. Once inside, the attackers removed the existing authentication methods and enrolled their own device.

Nothing was hacked, and the recovery process did exactly what it was designed to do: the MFA prompt was legitimate, and approved by the real employee. The problem was that the SSPR flow didn’t verify the actual person re-enrolling the authenticator, creating a social engineering opportunity that a clever attacker exploited.

Why Account Recovery is the Soft Spot

Authentication during account recovery has a property that primary authentication does not: it is invoked at the precise moment an employee has lost their normal way of proving who they are. In fact, the stronger your primary authentication factor, the more your security depends on what happens the day it goes missing.

Consider the methods most enterprises fall back on at the moment of recovery: a push notification to a registered device, or a one-time passcode sent by SMS or email. Sometimes it’s handled via self-service, though more frequently I see account recoveries getting sent to the helpdesk. Importantly, none of these factors tell you who someone is. Rather, they confirm that the person has access to something: a device, a phone number, an inbox. And as the Storm-2949 incident shows, any credential-based authenticator can be accidentally handed to an attacker by a well-meaning employee.

As good and necessary as passkeys are, they simply don’t solve the account recovery problem. When a device is lost, stolen, or replaced, employees land back in a recovery flow which must typically downgrade to a different authentication factor. The solution, then, is obvious: design a recovery flow that upgrades to an even higher-assurance factor.

How to Evaluate Your Account Recovery Controls

Here is the question I would put at the center of any IT security review this year: Does our account recovery process verify the person behind the action, or does it verify their access to something?

That distinction reorganizes the problem. Authentication answers which account is acting; recovery, done properly, needs to answer a harder question: which human is acting? The tools that answer the first question were never built to answer the second.

If you are assessing your account recovery controls, test them against a short list:

• Does it confirm the identity of the human, or that they have possession of a particular credential or device?
• Does it still work when the primary factor is the very thing the employee has lost? (i.e., does it pass the “dropped my phone in a lake” test?”
• Does it introduce an opportunity for social engineering?
• Does it return a clear decision, or a signal that someone has to interpret?
• Is it fast and simple enough that employees will not demand a manual exception?

Moving the enterprise to phishing-resistant authentication is the right call, and it will retire an entire class of attacks. The point is that the same move concentrates risk at the recovery step, and recovery deserves the rigor we have finally brought to login.

The organizations that get this right will treat account recovery as what it has quietly become: an identity problem. They will ask the same question at recovery that they already ask when they hire someone and before they approve a high-privilege action. Who is this person, really?

Passkeys close the front door. The enterprises that also verify the human at the moment of recovery are the ones who will not spend 2027 watching their attackers walk through another one.