Passwordless + Autopilot + Preview builds in Update rings ≠ True

Microsoft have been advocating passwordless for a long time and we (me, colleagues at Coligo, friends and others working with security in the Microsoft area) are pushing more and more customers towards passwordless. The most obvious reason for going passwordless is improved security, but it can and will also mean an increased user experience. However, there is a problem in the modern world which still lingers and negatively impacts the user experience.

Modern deployment meaning Autopilot and Intune

Organizations staying at the top of game is not using only passwordless but also Autopilot and Intune. Using Autopilot without the ESP page is not really an option, so I see this as a requirement for most organizations and use cases. That means blocking the device until “everything” is deployed to the device. This is also where the problem kicks in.

The problem: Update rings containing devices

The problem is with update rings when using Windows Update for Business or Autopatch (which by the way are in the process of being merged together). If the update ring has the setting “Enable pre-release builds” set to Enabled in combination with the update ring being targeted to devices, this causes a forced reboot during the Autopilot process. The setting behind the scene is the ManagePreviewBuilds CSP.

Enabling this setting breaks the passwordless flow, as the user will have to go through a second round of passwordless authentication before ultimately reaching the desktop, causing potential service desk calls and causing a bad user experience.

History

This problem has been around for a long time and still exist in Windows 11 24H2 which has just been released. Two additional problems are that the current release of Windows 11 24H2 breaks web sign-in (step 5 below) and that is really troublesome as these users will be forced to going back to using passwords!

Also, the coming feature to automatically have Windows updated during OOBE will likely break this passwordless flow, but fortunately I think we will see controls for the Windows updates during OOBE.

However, it would be best if Microsoft could just make sure to make sure that (new) features do not interfere with the passwordless authentication flow in the first place, of course.

Let’s look at the difference in flow during Autopilot

Below is an illustration of difference in flow and how the user targeted update rings mean a better user experience!

Autopilot with update rings targeted to devices, and having preview builds enabled.

Autopilot with update tings targeted to users, and having preview builds enabled

1. OOBE sign-in with passwordless phone sign-in (could also be FIDO2 or certificate for instance). 2. ESP page kicks in. 3. Reboot occurs during Device setup due to update ring target groups containing devices and having preview builds enabled. 4. Windows welcome screen – passwordless authentication flow is broken. 5. Sign in with for example TAP or passwordless phone sign-in to continue (using web sign-in). 6. Windows Hello for Business enrollment. 7. Desktop.

1. OOBE sign-in with passwordless phone sign-in (could also be FIDO2 or certificate for instance). 2. ESP page kicks in. 3. Windows Hello for Business enrollment. 4. Desktop.

Root cause and workarounds?

Applying this configuration, i.e. ManagePreviewBuilds should not warrant a forced reboot. The fix to this issue is something Microsoft must fix.

Potential workarounds are to keep using Windows Update for Business Update Rings (or Autopatch) targeted to devices, and to keep devices that should be running a preview build in a separate group which is excluded from all regular update rings. Then target update rings with preview build specifically to groups containing users instead.

What about upcoming Windows Autopilot device preparation?

The new “Autopilot 2.0” which is called Windows Autopilot device preparation do not have this problem (for the moment). The flow is a bit different from Autopilot and the Enrollment Status Page so let’s keep this under monitoring as device preparation evolves. For the moment there are quite a few things missing before we can start migrating away from Windows Autopilot to Windows Autopilot device preparation.

Summary

Reducing necessary (or unnecessary) reboots should be top of mind to fix, and if not easily fixed we should be able to control this and make a decision of our own instead of having a reboot forced upon us.

Whenever new features are built from scratch, or changed, two very strict guidelines should apply;
1) Do not force reboots upon anyone (or let organizations control this behavior).
2) Do not break the passwordless flow and keep it intact to keep a secure and user-friendly experience.