Passkeys by Default: Is Your Account Recovery Phishing-Resistant Too?

Microsoft is changing authentication in Entra ID. But the real Identity risk may sit in the process you use when a legitimate user loses access.

From 1 September 2026, Microsoft is making a significant change to the authentication experience in Microsoft Entra ID.

Users who are still enabled for SMS or voice authentication will be automatically enabled for passkeys and enrolled into a Registration Campaign prompting them to register a passkey.

From 1 February 2027, Microsoft-provided telecom delivery for SMS and voice authentication will be retired. Organizations with a documented operational or regulatory requirement to retain SMS or voice will still be able to use a customer-managed telecom provider.

The direction is right.

Passkeys use public-key cryptography and are designed to provide phishing-resistant authentication. In Microsoft Entra ID, Passkeys (FIDO2) are available across all editions, including Microsoft Entra ID Free, without an additional licensing requirement for the authentication method itself.

But there is a second question that, in my view, matters more than the rollout itself:

What happens when the legitimate user can no longer use their passkey?

Because the effective assurance of an authentication architecture is not determined only by the strength of the primary authenticator.

It is also determined by the process that can replace it.

Phishing-Resistant Authentication. Phishable Recovery?

The Microsoft Digital Defense Report 2025 provides a useful perspective.

Modern Multi-Factor Authentication (MFA) still reduces the risk of identity compromise by more than 99%.

In Microsoft Defender XDR and Microsoft Entra ID Protection data for April–June 2025:

• more than 97% of identity attacks were password spray or brute-force attacks,

• token theft by malware represented 2.4042%,

• Adversary-in-the-Middle (AiTM) attacks represented 0.2375%,

• direct attacks on MFA represented just 0.0033%.

Those numbers should not be interpreted as proof that attackers have stopped targeting MFA.

But the same report identifies another important trend.

Ransomware operators are increasingly using social engineering to obtain or reset credentials, particularly through vishing and tech-support scams.

Microsoft also documents helpdesk-themed social engineering as a real attack pattern.

That leads to an important architectural conclusion:

Phishing-resistant authentication does not automatically mean phishing-resistant account recovery.

Account Recovery Is an Authentication Control

When an employee loses a phone, replaces a device, or can no longer use an authenticator, some process has to restore access.

Depending on the environment, that process may include:

• Self-Service Password Reset (SSPR),

• helpdesk-assisted password reset,

• removal or replacement of authentication methods,

• forced re-registration,

• issuance of a Temporary Access Pass (TAP),

• lost-device or replacement-device procedures,

• administrator-assisted recovery,

• intervention by a Managed Service Provider (MSP).

These processes are often treated as operational helpdesk workflows.

From a security perspective, they are more than that.

They are alternative authentication paths.

If an attacker can use social engineering to trigger registration of a new authenticator or issuance of a Temporary Access Pass, they do not need to compromise the existing passkey.

They need to compromise the process that allows it to be replaced.

And that process may involve a human decision.

Approval Is Not the Same as Identity Verification

A common control-design error appears here.

“MFA changes require manager approval.”

That can be a useful control.

But it is not necessarily identity proofing.

A manager may confirm that an employee genuinely needs recovery or a replacement device.

That does not, by itself, prove that the person on the phone or behind the ticket is actually that employee.

High-impact recovery actions require a predefined identity-verification process.

Depending on the risk level, that may include:

known communication channels, trusted corporate records, independent verification, out-of-band confirmation, and dual control.

Most importantly, the process should be:

documented, repeatable, and auditable.

It should not depend on how convincing the caller sounds.

What If the Helpdesk Is External?

The risk changes again when password resets, authentication-method changes, or privileged Identity operations are performed by an external IT provider.

In that model, part of the organization’s Identity Security boundary effectively sits outside the organization.

This matters particularly for organizations that depend on external IT providers and Managed Service Providers (MSPs).

The correct security question is therefore not only:

“Does our provider use MFA?”

It is:

“How does our provider verify the identity of one of our employees before changing an authentication method or restoring access?”

That immediately leads to harder questions.

Who can authorize recovery?

Can a single helpdesk operator issue a Temporary Access Pass?

Is the process different for privileged accounts?

Is every change attributable to a named operator?

Is there an alert after a high-risk recovery action?

Is that event correlated with new authentication-method registration and the next sign-in?

If you do not know the answers, you do not fully understand the assurance level of your authentication environment.

The Marks & Spencer Incident

The 2025 cyberattack against Marks & Spencer is a useful reminder of this risk.

On 8 July 2025, M&S Chairman Archie Norman told the UK Parliament that the initial entry point involved sophisticated impersonation.

He explained that the attackers impersonated a specific individual and possessed personal details about that person.

He also confirmed that part of the point of entry involved a third party.

Accuracy matters here.

The official public testimony does not confirm that a specific external helpdesk performed a password reset. There is no reason to attribute more technical detail to the incident than has been formally established.

The lesson is already strong enough:

Identity impersonation and third-party trust are part of the real attack surface.

An exploit is not always required when a critical operational process can be manipulated.

From Identity Security to NIS2 Governance

For essential and important entities within the scope of Greek Law 5160/2024, the issue is not limited to technical configuration.

Law 5160/2024, which transposed the Network and Information Systems Directive 2 (NIS2) into Greek law, requires management bodies to approve cybersecurity risk-management measures and oversee their implementation.

Those measures include, among other things, access-control policies and the use of Multi-Factor Authentication (MFA), where appropriate.

Joint Ministerial Decision 1689/2025, through the National Cybersecurity Requirements Framework, further specifies the framework for essential and important entities.

The relevant governance principle is straightforward:

Outsourcing a function to an external provider does not automatically outsource the associated risk ownership.

If a third party can influence authentication, privileged access, or account recovery, that process needs to be included in the organization’s access-control and supplier-risk framework.

Account recovery is therefore not just a helpdesk issue.

It is an Identity Governance issue.

And for organizations within NIS2 scope, it may also form part of the broader cybersecurity risk-management and compliance framework.

What I Would Review Before Calling a Passkey Rollout Complete

1. Map Every Recovery Path

Do not map only authentication methods.

Document:

• password recovery,

• authentication-method replacement,

• Temporary Access Pass issuance,

• lost-device procedures,

• administrator-assisted recovery,

• external provider workflows,

• privileged identity recovery.

For every path, define who can trigger it, who can approve it, and which controls apply.

2. Perform Identity Proofing Before High-Risk Recovery

“We ask the user a few questions” is not sufficient security design.

The process should define exactly how the claimant’s identity is verified and which communication channels are considered trusted.

3. Apply Different Assurance Levels to Different Impact Levels

Not all recovery operations carry the same risk.

A password reset should not automatically be treated the same way as:

• issuing a Temporary Access Pass,

• replacing a phishing-resistant authenticator,

• recovering an administrator account,

• recovering a privileged identity.

As the potential impact increases, the assurance level of the recovery process should increase as well.

4. Review Privileged Recovery Roles

Who has permission to change authentication methods for other users?

Who can affect privileged accounts?

Are those roles permanently assigned, or controlled through Privileged Identity Management (PIM)?

Is there separation of duties?

Is activity monitored?

Recovery architecture cannot be assessed independently of the privileged-access model.

5. Treat Emergency Access as a Separate Control

Emergency access, or break-glass, accounts are not simply “another admin account.”

Microsoft recommends at least two cloud-only emergency access accounts, using strong phishing-resistant authentication, with independent dependencies, monitoring of every use, and regular validation.

Emergency access should be designed to work when normal controls fail, without becoming a permanent bypass.

6. Monitor the Sequence, Not Just the Individual Event

A password reset can be legitimate.

A new authentication-method registration can also be legitimate.

So can a sign-in from a new device.

But the sequence:

recovery action → new authentication method → unusual sign-in → privilege change

has a very different risk profile.

Identity monitoring should therefore look at event correlation and behavioral sequence, not only isolated alerts.

1 September Is a Trigger — Not the Real Objective

Microsoft’s change is a useful trigger for organizations to move toward phishing-resistant authentication.

But I would not treat it as a simple migration project from SMS to passkeys.

It is an opportunity to review the entire authentication lifecycle:

registration → authentication → replacement → recovery → privileged recovery → emergency access → monitoring.

Passkeys solve an important security problem.

They do not solve every Identity problem.

And an authentication architecture should not be assessed by its strongest control.

It should be assessed by the easiest path that allows that control to be bypassed or replaced.

The Question I Would Ask Today

Not:

“Have we enabled passkeys?”

But:

“If an attacker cannot steal our authenticator, can they convince someone to issue them a new one?”

If the answer is not clear and documented, that is where I would start the review.

Identity Recovery & Passkey Readiness

At Nimbus Cyber, we treat authentication and recovery as one integrated Identity control system.

Our current Identity Recovery & Passkey Readiness Assessment working model examines areas such as:

• passkey readiness and authentication-method architecture,

• account-recovery paths,

• Temporary Access Pass governance,

• privileged recovery,

• emergency access accounts,

• helpdesk and third-party procedures,

• logging, monitoring, and detection,

• alignment with Identity Governance and, where applicable, NIS2 requirements.

The objective is not simply to enable a stronger authentication method.

It is to ensure that the path back into the account is not weaker than the front door itself.