The next step in a passwordless Windows experience

We most likely all know passwords don’t have a future and therefore I’m happy more and more companies embrace authentication options without using a password (passwordless). One of the companies that is at the forefront of this is Microsoft, at least on Windows (of course on Windows). Microsoft supports passwordless authentication options like Windows Hello (for Business), phone sign-in (with the Microsoft Authenticator app) and FIDO2 security keys.

But a Windows device is originally not designed to sign in to the device without a password, so on several parts in the Windows system we see the password sign-in option (or related settings). With the recent release of the Enable Passwordless Experience setting in Microsoft Intune and the release of Windows 11 23H2, we now have an option to hide password-related settings and the password sign-in option. But wait, didn’t we already have such an option when we exclude credential providers which I described in this blog post? Well, these two settings don`t exactly do the same thing. So let’s have a look at these two settings.

Enable Passwordless Experience (configure the Intune profile)

Let`s start with the newly released Enable Passwordless Experience setting. As written in the Windows IT Pro blog;

Once the policy is set, it removes passwords from the user experience, both for device sign-in as well as in-session auth scenarios like password managers in a web browser, “Run as” admin scenarios, and User Account Control (UAC). Users will need to use Windows Hello for authentication in place of a password.

Enabling this setting only hides the password option from certain parts of the Windows system.

Let`s see how we can configure this using Microsoft Intune and how the end-user experience is.

Let’s sign into the Intune portal.

• Browse to Devices, Windows, Configuration profile
• Click Create profile
• Select Windows 10 and later as Platform
• Select Settings Catalog as Profile type
• Click Create

• Enter a Name for the profile
• Enter a Description (optional)
• Click Next

In the Settings Picker browse to the Authentication section. Here check Enable Passwordless Experience.

The setting is added to the configuration profile. Select Enabled from the drop-down list.
Finish creating the profile by assigning the profile to a (device) group.

That’s all to enable the new Passwordless experience for our Windows devices.

But you might want to consider configuring another setting, Enable Web sign-in.
Web sign-in can be used as a recovery mechanism when the end-user for some reason can’t sign in anymore to the device with for example a FIDO2 key or Windows Hello for Business. For Web sign-in, the user needs to have a Temporary Access Pass (TAP) or phone sign-in activated with the Microsoft Authenticator app.

Web sign-in is also found under the Authentication section in the Settings Catalog profile.

When you enable Web sign-in on your Windows devices, you might consider a second optional setting. This is because when a user starts his device, a Sign in button is shown in the middle of the screen, which opens the Web sign-in experience. But as written, this is just a recovery option, thus not the default sign-in option for the end user. This could be confusing for the end-user, so you might want to configure a default sign-in option. We can do this by configuring a default credential provider, as I showed in a previous blog post. In that article, a FIDO2 security key was assigned as the default sign-in option, below I show you how to assign the PIN (code) as the default option.

A few well-known credential provider GUIDs related to Windows Hello are:

This setting is also found in the Settings Catalog profile but under Administrative Templates, System, Logon section. Add the Assign the following credential provider as the default credential provider setting to your profile, switch the setting to enabled, and add the GUID to the text box.

All is set now, to switch over to the end user device.

Unfortunately, the Enable passwordless Experience wasn’t applied to my Windows Insider test device (on which I tested this setting at first) and also not on my 23H2 machine (version 10.0.22632.2428). I have no idea why the setting doesn’t work for me. Some people in the community report the setting from the Settings Catalog does work fine and others report it also doesn’t work for them.
We can also deploy the setting as custom OMA-URI CSP, so let me also show you how that is done, as that setting does work as expected.

We need to create an additional configuration profile for this setting.

• Click Create profile
• Select Windows 10 and later as Platform
• Select Templates as profile type
• Select Custom and click Create

Enter a Name and Description and click Next.

Click Add, to add an OMA_URI row.

Enter below information to the policy;
Name: EnablePasswordlessExperience
OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Authentication/EnablePasswordlessExperience
Data Type: Integer
Value: 1

When we finished creating the profile, it is time to switch to the end user device.

Enable Passwordless Experience (end-user experience)

As you can see, I was already signed in with my demo user account. On the Windows logon screen, the option to sign in with a password is not available.

When we go to Other user, we do have the password authentication option available.
We can also see the Sign in button in the middle of the screen, screaming to the user to be selected.

But that Sign in button is to start the Web sign-in experience. And as written, that option does only work when the user enabled phone sign-in in the Microsoft Authenticator app (or with TAP) as recovery option.

Or isn’t that really the case, I still see a Use your password instead option available 🙁

In case you have assigned PIN (or another provider) as the default credential provider, the Sign in button isn’t shown in the middle of the screen.

When we are signed in to the device, we see the password option is removed in the Settings, under

We can still use a password when we use the Run as option.

But the option to use a password in a UAC prompt is removed, which makes remote assistance for a help desk employee who needs to elevate his permissions challenging.

This Microsoft article describes the password option is disabled for User Account Control (UAC) elevation, except if a local user account is used for elevation.

We do however still have the password authentication option when we remotely need to connect to another device using Remote Desktop Connection.

Exclude the password credential provider (configure the Intune profile)

Another option to remove the password authentication option from the Windows logon screen is using the setting Exclude the following credential providers. As already briefly mentioned in a previous blog post this setting completely removes the option to use the password authentication option from our Windows devices.

The setting uses the credential provider GUID to exclude a credential provider. The GUID for the PasswordProvider is {60b78e88-ead8-445c-9cfd-0b87f74ea6cd}.

The setting is like the new setting, available in the Intune Settings Catalog profile.

This is all we need to configure for this setting. We can of course, also enable Web sign-in or configure a default credential provider, but that is already shown in the previous part.

Exclude the password credential provider (end-user experience)

In the below example we see we only have the authentication options security key (FIDO2) and PIN available (I have not configured face recognition or fingerprint). Password is removed from the Windows logon screen.

But when we choose Other user, we see that now also the password authentication is removed from the Windows logon screen.

When we are signed in to Windows, we see password setting is not removed from the Windows settings.

The password authentication option is not available anymore when using Run as to start a program.

Also in the Remote Desktop Connection, we have no option anymore to use a password.

Conclusion

Let’s end this article with a short conclusion in taking the next step in going passwordless on a Windows device.

We have two different options available to hide/ remove the password authentication option from Windows. Using the Exclude credential provider option is most likely too restrictive for most companies. Using this setting removes the option to authenticate with a password when using an RDP connection to another machine. A lot of IT admins still need to use RDP during their daily job, this already eliminates this configuration on a lot of these devices. Besides that, a service desk employee who remotely takes over a device from a user also has no option left to elevate permissions because the password option is also removed from UAC. These two examples make this setting not useful for a lot of companies is my expectation.

Using the new Enable Passwordless Experience setting might be more useful for companies. It allows IT admins to use their password when they need to set up a RDP connection.
However, providing remote assistance might be challenging when elevation is needed.

The only option to elevate permissions for helpdesk support is, referring to the Microsoft documentation, using a local administrator account. That actually means Microsoft is pushing organizations to their Windows LAPS solution as just enabling a local administrator account and putting a password on it might not be the best idea. I think only allowing a local administrator account for this situation is blocking a lot of companies, as companies still use (second/ separate) domain accounts for this job, instead of local accounts. But time will tell us what steps are taking in this situation.

In case a company or a part of its users/ devices has no need for RDP or remote support (that needs elevation using UAC), a combination of the two settings might also be a good option. Because why not hide the password settings, when you completely remove the password credential provider? But that is most likely at the moment a step too far for many organizations. Although using an endpoint privilege management solution might help in this journey as well.

I’m curious how the passwordless experience is evolving in the near future.

Thanks for reading the post til the end. What are your experiences and thoughts on taking the next step in the passwordless journey?