This blog will show you a strange issue we encountered after deploying some Windows 11 devices using Autopilot for pre-provisioned deployments (White-Glove). The user signed in using a Temporary Access Pass with Web Sign-in. After getting logged out unexpectedly, the option to use Web Sign-in (TAP) simply wasn’t there anymore.
When Everything Seemed to Work
It all started with a pretty standard Autopilot setup. We had a bunch of Windows 11 24h2 devices going through Autopilot pre-provisioning, which is nothing unusual. The devices were enrolled, apps were installed, and all the required policies were applied. Once everything finished successfully, the device was sealed, and handed off to users. The idea was pretty simple: Turn it on, sign in with a Temporary Access Pass (TAP), and start working. First, some background information about TAP.
Temporary Access Pass, or TAP, is a one-time passcode that can be used to sign in without knowing the actual password. It’s limited by time and usage and is usually handed out during onboarding. TAP is extremely useful when rolling out passwordless authentication or setting up Windows Hello for Business. If the user has never signed in before and doesn’t know their credentials yet, TAP makes everything easier and more secure.
The First Web-Sign in… and Then It Breaks
After resealing the device, the user turns it on and is greeted by the Windows sign-in screen. They select Sign-in options, choose Web Sign-in, and are redirected to the familiar Microsoft login page.
They type in their Temporary Access Pass and authenticate successfully, and the login seems to work, until it just disappears. Right after signing in, the session logs out. There is no message or an option to configure Windows hello for business, just a flash and a return to the sign-in screen. When the user needs to click the Sign-in option again, the Web Sign-in option is no longer available.
As shown above, the only two options available are the same: username and password. The option to use the web sign-in to use TAP was completely missing, and since the user did not have a password, they were not able to log in. So, what happened with the web sign for Windows option?
The Web-Sign in Account That Isn’t Really an Account
Digging into the device with a remote background tool, we noticed that at least something had happened. The user had technically signed in, at least partially. But it wasn’t a full Azure AD /Entra or local account. It was the web account, a temporary session built by the Web Account Manager. More specifically, it was the WSIAccount.
The WSIAccount, or Web Sign-In account, is created during the Web Sign-in flow and exists only as long as it needs to (disabled by default). It’s a minimal context that uses token-based authentication to let the user in, complete the first sign-in, and start things like Windows Hello setup. But it’s fragile. It doesn’t create a full user profile and doesn’t persist beyond that initial use case. And if something interrupts that short session, like a forced logoff, the system ends up in a half-signed state.
And that’s exactly what happened. Because the WSIAccount was incomplete, the system believed a user was already present but didn’t allow the same flow again. Web Sign-in was removed from the list of options.
The strange part is that if you sign in with an additional local user account and then sign out again, Web Sign-in suddenly reappears. With it, the WSIccount broken session is cleared, and the web provider is allowed again.
The Real Trigger: DeviceLock
We noticed that after using the TAP/Web sign-in option, the user should normally be redirected to Windows Hello for the business pin setup flow, but instead, the user was now logged out. It’s almost as if the device rebooted, but it just logged out this time. Having your devices reboot during Autopilot is a pretty well-known issue.
Windows Autopilot troubleshooting FAQ | Microsoft Learn
I had the feeling that the policy causing the device to reboot could also cause the user to be logged out after signing in using the web sign-in. After ruling out all the other policies, the web sign-in culprit was indeed caused by a specific configuration profile that applied a DeviceLock setting.
The policy in question was intended to enhance security by enforcing a reboot after ten incorrect password attempts, with the idea that BitLocker would then require its PIN. But the setting used for this, MaxPasswordFailuresBeforeWipe, is backed by the DeviceLock CSP.
The problem is that this CSP has a side effect. When the policy is targeted to a device group, it can somehow force an immediate logoff or even trigger a reboot. And yes, Microsoft even lists this behavior in its FAQ documentation. So, right after the TAP login, the device quietly reacts to that policy and logs the user out before the session is fully established.
Compliance Policies also breaking Web Sign-in
What makes this even funnier is that compliance policies can also invoke the same DeviceLock CSP, especially those based on Exchange ActiveSync (EAS). If those compliance policies are assigned to the device rather than the user, they may behave in exactly the same way. Normally, compliance policies only check if the device is compliant, but this Password Compliance policy would also enforce the device lock policy!
The result? No Windows Web Sign-in, no working profile, and no way to use TAP again.
The Fix: Timing and Scope
After confirming the cause, we removed the password policy that caused the web sign to dissapear. After reenrolling the device again, the issue was indeed fixed. Web Sign-in stayed available after the first reboot. TAP worked as expected.
Alternatively, when dealing with these policies that could break the web sign-in, changing the assignment from device to user also helps prevent this web sign-in issue!
Final Thoughts
In the end, it was just a password policy that applied at exactly the wrong time. The DeviceLock CSP policy did what it was supposed to do, but it broke the web sign-in flow without any warning. If you’re using Autopilot with pre-provisioning and TAP, double-check any policy that touches DeviceLock, whether it’s a device configuration policy or a compliance policy using EAS. One setting is all it takes to kill Web Sign-in right when you need it most.