Skip to content
What Okta and Microsoft's Approaches Tell Us About the Future of Ident

What Okta and Microsoft's Approaches Tell Us About the Future of Ident

Infosecurity-Magazine • September 4, 2026

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 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.

Third of Online Users Hit by Account Hacks Due to Weak Passwords News 2 May 2025

Third of Online Users Hit by Account Hacks Due to Weak Passwords

Advanced Phishing Attacks Put X Accounts at Risk News 16 September 2024

Advanced Phishing Attacks Put X Accounts at Risk

Okta Confirms 2.5% of Customers Impacted by Lapsus Breach News 23 March 2022

Okta Confirms 2.5% of Customers Impacted by Lapsus Breach

Okta Investigates Possible Lapsus Breach News 22 March 2022

Okta Investigates Possible Lapsus Breach

Microsoft: 1000+ Hackers Worked on SolarWinds Campaign News 16 February 2021

Microsoft: 1000+ Hackers Worked on SolarWinds Campaign

What’s Hot on Infosecurity Magazine?

FulcrumSec Claims Responsibility for Manchester Airport Group Breach

Russian Man Extradited Over Malware Campaign Targeting Freelancers

Gambling Goblin Turns Brazilian Government Sites Into SEO Weapons

Nutex Health Says Patient Data Stolen, Hackers Threaten Leak

Hackers Chain Two New SonicWall Zero-Day Vulnerabilities

65% of Enterprises Have Seen AI Agents Act Out of Scope

Attackers Steal METR API Key and Burn $600,000 in AI Credits

Hiring for the AI Era: A New Challenge for CISOs

65% of Enterprises Have Seen AI Agents Act Out of Scope

Fake Voicemail SVG Attachments Fuel Large-Scale Phishing Campaign

How Industry Coalitions Are Rallying to Secure Open Source Software for the AI Era

Threat Actors Abuse Cursor Agent AI to Assist Ransomware Operations

Same Front Door, New Visitors: Securing Humans and AI Agents at the Browser

Human Risk in Cybersecurity: Protecting Your Organization Beyond Technology

Financial Services Cyber Resilience: Stress Testing Third Parties Before Attackers Do

Behind the Curtain of Microsoft 365 Cybersecurity: Lessons from Overlooked Resilience Gaps

Dispelling the Myths of Defense-Grade Cybersecurity

Revisiting CIA: Developing Your Security Strategy in the SaaS Shared Reality

How Faster Cyber-Attacks Are Reshaping Enterprise Cybersecurity Strategies

Researchers Claim First Fully Agentic Ransomware: JadePuffer

AI is Already Powering Cyber-Attacks. Can it Power Cyber Defense?

Google Cloud's New CISO Chris Betz on Integrating AI in Cyber Defenses

How World Cup Password Trends Can Increase Active Directory Risk

New CISA Guide Helps Agencies Adopt SASE For Zero Trust

Extracted Entities

APT Groups (1)

Attack Types (1)

Campaigns (1)

MITRE ATT&CK (1)

Platforms (1)