Microsoft Entra is adding a tenant-wide way for passwordless users to set a new password without knowing the old one or using SSPR. That sounds contradictory, but for organizations stuck with a few legacy apps, it fixes a very real support problem.
The practical use case is simple. A user signs in day to day with a passkey, a FIDO2 security key, or Windows Hello for Business. Then some old line-of-business app still wants a password. Months later, the user does not remember it, never enrolled in self-service password reset, and the helpdesk gets dragged into a problem that should not exist in 2026.
This change gives that user a way out in My Sign-Ins.
What is changing in Microsoft Entra?
According to the Message Center announcement covered here, rollout starts in late October 2026, reaches GA the same month, and ships disabled by default. When enabled, eligible users can go to My Sign-Ins, choose Change password, prove identity with a registered passwordless method, and set a new password without entering the old one.
The authentication methods Microsoft positions as phishing-resistant in Entra include Windows Hello for Business, passkeys and FIDO2 security keys. That part is sensible. If a user can strongly prove who they are with one of those methods, forcing them to remember a rarely used password is mostly ceremony.
What this does not do is remove passwords from the account. It is the opposite: it makes it easier to maintain a password that still exists because some dependency has not caught up. If you are building Microsoft Copilot and AI agents or broader automation workflows, that same pattern shows up all the time: the modern identity model is fine, but one old integration keeps the old secret alive.
Why the rollout model matters more than the feature
The catch is scope. Microsoft says the setting is tenant-wide. No pilot group. No per-user targeting. No gradual rollout.
That is the bit I would care about most.
For most organizations, this is not a high-risk security regression. The user is still proving identity with a phishing-resistant method. But tenant-wide controls are awkward operationally. If you have a subset of users with awkward legacy dependencies, you cannot enable this just for them and leave everyone else alone. You either expose the option to every eligible user, or to nobody.
That matters because product design choices like this change who owns the decision. It stops being a local admin experiment and becomes an identity governance choice. If you already run a formal AI and automation audit or identity review process, this belongs there as a tenant setting, not as a helpdesk tweak.
What I would check before turning it on
First, find out whether you actually have a problem worth solving.
If your passwordless users are already enrolled in SSPR and helpdesk tickets are low, this feature is useful but not urgent. If you have users on Windows Hello for Business or passkeys who still bounce into old apps and forget passwords, it is more compelling.
Second, review the systems that still require passwords. This feature is a bandage for technical debt. Sometimes that is fine. But if the list of password-dependent apps is longer than expected, the better investment may be removing those dependencies or fronting them with something more modern, including custom MCP servers or other integration layers where that architecture makes sense.
Third, prepare user comms. Because the switch is tenant-wide, users will see a new path in My Sign-Ins the day you enable it. That is the kind of silent UI change that causes avoidable confusion if nobody explains why it appeared.
My take
This is a good change, and overdue. Not because it changes authentication strategy, but because it removes a stupid support edge case created by the halfway state many tenants live in: passwordless for the user, password still required somewhere in the estate.
Still, I do not like the all-or-nothing scope. Microsoft solved the user friction, but not the rollout friction. If your tenant is large, that is not a small omission.
My advice is straightforward: treat this as a tenant identity setting, not a convenience toggle. Check your password-dependent apps, estimate how many passwordless users would see it, and decide whether you are fixing a real operational pain or just adding one more option to an already busy account portal.
