In this post
Microsoft is rolling out a way for users to set a new Entra password from My Sign-Ins after signing in with a passkey, FIDO2 security key or Windows Hello for Business, with no current password and no self-service password reset (SSPR). Microsoft’s message center post MC1437671 schedules general availability for late October 2026, and the capability is opt-in for each organization.
That is different from SSPR. Passwordless credentials still cannot be used as the verification factor in the SSPR flow, and Microsoft’s authentication methods table marks passkeys, Windows Hello for Business and Authenticator passwordless as unsupported for SSPR. This article explains the difference, how the new flow works, and what admins should decide before turning it on.
Why this matters
Many “passwordless” users still have a password. Legacy apps, older clients and some admin tools can require one, and the user may not have typed it in months. Before this change, a user who forgot it had two options: complete SSPR with a registered method such as an Authenticator push, SMS or email code, or call the help desk.
That gap hurts passwordless adoption. A user who signs in daily with a phishing-resistant credential was still being sent through weaker, phishable verification (SMS or email codes) just to get a password they rarely use. Microsoft’s stated goal for the new capability is to remove that barrier and cut related support requests.
Some organizations go further and scramble passwords for cloud users, setting them to long random values. Microsoft’s guidance for that approach notes that users who still need a password for a legacy app can use SSPR to set it to a known state for a time, until it is scrambled again.
How password change after secure sign-in works
An eligible user opens My Sign-Ins, selects Change password, and proves their identity with a registered passkey, FIDO2 security key or Windows Hello for Business. They then set a new password. The current password is never requested, and SSPR enrollment is not required.
Who is eligible, per the Microsoft message center post:
-
- The user has a registered passkey, FIDO2 security key or Windows Hello for Business credential.
-
- The user also maintains a password.
-
- The organization has enabled the feature, through the Entra admin experience or supported APIs once available.
The flow uses a strong credential as the proof, so the identity check is at least as strong as the user’s normal sign-in. It does not remove passwords from Entra accounts. It only gives users a way to reset one without leaving the passwordless experience.
One naming wrinkle: the post’s title and summary differ between copies (“passwordless password change” versus “password change after secure sign-in”). Both describe the same capability.
Why passkeys and Windows Hello still cannot be used for SSPR
SSPR and the new flow are separate features. SSPR is built for users who cannot sign in and lets them verify with a method on a supported list. The new flow requires the user to already be signed in with a strong credential. Microsoft’s authentication overview marks which methods work for SSPR:
| Method | Sign-in (first factor) | Works for SSPR |
|---|---|---|
| Passkey (FIDO2) and synced passkey | Yes | No |
| Passkey in Microsoft Authenticator | Yes | No |
| Microsoft Authenticator passwordless | Yes | No |
| Windows Hello for Business | Yes | No |
| Temporary Access Pass | Yes | No |
| Microsoft Authenticator push | No | Yes |
| SMS sign-in | Yes | Yes |
| Voice call, email OTP, software OATH token | No | Yes |
The practical effect is that a user who has only passkeys registered cannot use SSPR at all, and a user who has lost their passkeys needs help desk or account recovery. The new flow does not change that: it helps the user who can still sign in with a passkey but has forgotten their password.
One related change: starting September 7, 2026, SSPR accepts only authentication methods users have registered on their account, not contact details stored in profile attributes.
Planning and rollout for admins
Microsoft says to enable the feature through the Entra admin experience or supported APIs when it becomes available in October 2026. This article was written from the message center post and secondary coverage, so confirm exact setting names and locations in the admin center before you plan around them.
Before enabling it:
-
- Confirm which users hold a passkey, FIDO2 key or Windows Hello credential and also keep a password. Only they benefit.
-
- Decide whether SSPR stays on for users who rely on SMS, voice or email verification. The new flow adds an option; it does not replace SSPR.
-
- Brief the help desk. Users can now reset without knowing the current password, so scripts that ask for it first need updating.
-
- Pilot with one group and watch the audit logs for password changes.
-
- Update user guidance: from My Sign-Ins, choose Change password and verify with the passkey or Windows Hello.
Security considerations
The flow ties a password change to a phishing-resistant credential, which is a stronger check than SMS or email codes. The main risks are around the credential itself:
-
- Stolen or unlocked device. Whoever can use the passkey or Windows Hello on a signed-in device can change the password. Keep device compliance and Conditional Access in place for My Sign-Ins.
-
- Registration abuse. One hardening guide describes an attack sequence of registering a new method and immediately using it to reset a password. Watch for new credential registrations followed by password changes.
-
- A password still exists. The account remains usable with a password anywhere sign-in with one is allowed. Pair the feature with a plan to restrict or scramble passwords where legacy apps allow it.
-
- Audit visibility. Review how these changes appear in your logs and alerts before rollout, and consider the notification settings for password resets.
When users lose every method
The new flow needs a working credential. For users who have lost all of them, Entra offers other routes:
-
- Administrator reset. An admin resets the password or issues a Temporary Access Pass (TAP). A TAP lets the user sign in and register new methods, but it cannot be used for SSPR.
-
- Self-service account recovery. For users with no methods left, Entra supports government ID verification with a face match through an identity verification provider, after which temporary access is granted. It requires Entra ID P1, and provider costs vary.
A sensible baseline is to register at least two passwordless credentials per user, for example Windows Hello on a laptop plus a passkey on a phone or a FIDO2 key, so losing one device does not force a recovery.
Sources
As of October 24, 2026. The first two sources are the primary references for the new capability’s behavior; the rollout date is as stated there and may shift.