Will a New Entra User Be Forced to Change Their Password During Autopilot Enrollment?

Several administrators report that requiring a password change can interfere with the first Windows sign-in when the user has no cached profile yet. The behavior can vary depending on the Autopilot profile, authentication method, synchronization configuration, and whether Web sign-in is enabled, so a lab test is more reliable than assuming the OOBE experience will match a standard domain logon.

A cleaner modern onboarding approach is to avoid handing out a temporary password for this step. A Temporary Access Pass can let the user bootstrap Windows Hello for Business, configure a PIN, and register an authenticator. That avoids depending on a password-change prompt appearing at exactly the right point in Autopilot.

With Password Hash Synchronization configured, marking a newly created on-premises account as “must change password at next logon” should also make the synchronized cloud account require a password change at its first Entra sign-in. The ForcePasswordChangeOnLogOn setting mainly affects administrator-initiated password resets; it isn’t required for this initial synchronized-account scenario.

The important distinction is where the sign-in occurs. Entra authentication through an application should present the password-change prompt, but the normal Windows password credential provider on an Entra-joined device generally does not handle temporary or expired-password changes during the initial Windows sign-in. Web sign-in can potentially be used for this workflow, but forcing it and disabling the normal password provider is a specialized configuration that should be tested carefully.

SSPR is not required for a normal password change; it is primarily for user-initiated recovery or reset. The safest approach is to validate the exact Autopilot flow with a disposable test account and device before changing the production process.