Table of Contents
Update Authentication Method Policy for Passwords to Enable New Change Password Behavior
Message center notification MC1437671 originally appeared on 23 July 2026 (last updated 13 October 2026). The implementation of a preview feature to allow Entra users to change passwords without knowing their old password is now rolling out to tenants and should be available everywhere by the end of November 2026. The configuration needed to enable the feature is already present, but the feature is disabled by default and can currently be enabled only through Microsoft Graph. Enabling the setting has no effect until Microsoft deploys the feature to the tenant.
Given the headlong rush to embrace passkeys and passwordless authentication, it might seem strange for Entra to add functionality to allow users to change passwords. But there’s a good reason for doing so. Passwordless sign-ins are great if applications support modern authentication and users have the means to go passwordless, using methods such as the Microsoft Authenticator app, passkeys (FIDO2), or Windows Hello for Business.
But many legacy applications and services are fixed firmly at a point in time when passwords were the only supported authentication method. Even if these applications could technically support passwordless authentication, tenants probably have little desire to invest the time and effort required to upgrade legacy software. After all, the applications are “legacy.” And sometimes people need to change their passwords to access a legacy application but can’t remember their current password. Cue a call to the help desk.
The My Sign Ins Page and Change Password
Today, users can go to the My Sign-Ins page and use the Change password option there. If the new feature is disabled, the user must know their original password. If they don’t, they can go through the SSPR process to reset their password. It can be a frustrating experience.
The new feature allows users to change passwords after they sign in to Entra with a supported strong authentication method. Once again, the user heads for the My Sign-Ins page and chooses Change password. This time, Entra detects that the tenant configuration allows password changes after a secure sign-in, so the form presented to the user prompts only for a new password (Figure 1). There’s no need to use SSPR to reset their password or to seek help desk assistance, and that’s the whole point of making the change.
Using Change password in this manner requires the user to have an Entra P1 or P2 license.
Updating the Password Authentication Method Configuration
To enable the feature and allow users to change their password after a secure sign in, we need to update the Entra authentication configuration policy for the password resource. The API documentation doesn’t cover password (yet) and this is a beta implementation and UX to maintain the policy is unavailable in the Entra admin center.
To update the policy, connect a Microsoft Graph PowerShell SDK interactive session with the Policy.ReadWrite.AuthenticationMethod delegated permission. The signed-in account must hold an Entra role that allows them to update authentication policies, such as Authentication Policy Administrator. After connecting the session, create a hash table to pass as the request body to update the policy, and then run the Update-MgBetaPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration cmdlet to update the policy (this is not the longest cmdlet name generated by the Microsoft Graph PowerShell SDK):
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod" -Nowelcome
$PolicyUpdate = @{}
$PolicyUpdate.Add("allowPasswordChangeAfterSecureSignIn", $true)
$PolicyUpdate.Add("@odata.type", "#microsoft.graph.passwordAuthenticationMethodConfiguration")
Update-MgBetaPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId "Password" -AdditionalProperties $PolicyUpdate
This command is equivalent to running a Patch request against the https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Password endpoint.
To check that the feature is enabled, fetch the authentication method configuration policy for passwords and examine the additionalProperties property. You should find that the allowPasswordChangeAfterSecureSignIn property is now set to true. The effect of changing the policy is almost immediate:
$Configuration = Get-MgBetaPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId "Password" $Configuration.additionalProperties Key Value --- ----- @odata.context https://graph.microsoft.com/beta/$metadata#authenticationMethodConfigurations/$entity @odata.type #microsoft.graph.passwordAuthenticationMethodConfiguration allowPasswordChangeAfterSecureSignIn True
The configuration appears in AdditionalProperties because the current Graph PowerShell SDK model doesn’t expose allowPasswordChangeAfterSecureSignIn as a strongly typed property. As explained in this article about the AdditionalProperties property, the SDK uses this dictionary to hold information that AutoRest cannot map to strongly typed PowerShell properties.
Eliminating Friction is Goodness
I like this change. It makes sense to remove friction from users who are already frustrated because of some difficulty with passwords. The only issue I experienced is when I didn’t complete the Change password operation (I let it time out) and Teams for some reason decided that it didn’t like my attempts to switch from another tenant back to my home tenant. After resetting the password and signing out and back into Teams, all was well, but something screwy might have happened under the covers. The moral of the story is to complete the password change process once you start it or wait for Microsoft to squash any remaining glitches in the new routine.
Microsoft 365 for IT Pros is a trusted source of technical insight that helps tenant administrators stay informed and productive. We update the content every month to reflect changes across Microsoft 365, and monthly update #137 is available now. Get your copy from Gumroad.com and stay up to date with the information that matters most for keeping your tenant secure, compliant, and running efficiently.