Cloud migration is no longer only about moving mailboxes, files, or applications. For many organizations, the real transformation starts when user devices and identities move away from traditional on-premises dependency.
Today, many customers are migrating Windows devices from local Active Directory joined or Hybrid Microsoft Entra joined states to Microsoft Entra joined devices. This shift is usually part of a bigger cloud-first journey where the device moves to the cloud first, and later, once application dependencies are removed, the user identity can also become cloud-managed using User Source of Authority transfer.
I have prepared a detailed blog on User Source of Authority (SOA) change, explaining why and how to move a user’s Source of Authority from Active Directory to Microsoft Entra ID and How to Change Active Directory Group Source of Authority to Microsoft Entra ID
User Source of Authority capability helps organizations move user management from on-premises Active Directory Domain Services to Microsoft Entra ID when AD dependency is no longer required. Microsoft positions this as part of AD DS minimization and cloud-first identity management.
Passwordless Adoption Is Growing ,But Recovery Must Be Planned
As part of the cloud identity journey, many organizations are moving away from traditional password-based authentication and adopting modern passwordless methods such as:
- Windows Hello for Business
- Passkeys / FIDO2 security keys
- Passkeys in Microsoft Authenticator
- Microsoft Authenticator passwordless sign-in
This is the right direction. Passwordless authentication improves the user experience and reduces password-related risks. Microsoft also recommends phishing-resistant authentication methods such as Windows Hello for Business, passkeys, FIDO2 security keys, and certificate-based authentication for stronger sign-in protection.
But there is one practical question every organization must plan for:
What happens when the user loses access to their passwordless method?
Why Recovery Design Matters in Passwordless Deployments
When organizations move to passwordless authentication, the initial focus is usually on enrollment:
- How do we register Windows Hello for Business?
- How do we enable passkeys?
- How do we enable Microsoft Authenticator passwordless sign-in?
- How do we block weak authentication methods?
All these are important. But passwordless design is incomplete without a proper recovery design.
Microsoft always recommends keeping alternative authentication methods available for recovery scenarios. This is because every passwordless method can have its own failure case:
- A phone can be lost\Phone Display Not working.
- Microsoft Authenticator can be removed.
- A FIDO2 security key can be forgotten.
- A Windows Hello PIN can stop working.
- A device can be replaced.
- A user may end up with no working authentication method.
For a complete authentication lockout scenario, Microsoft Entra Account Recovery can help users regain access by verifying their identity through Verified ID and Face Check. Once verified, a Temporary Access Pass can be issued to allow the user to re-register authentication methods.
This is especially useful when users have lost all registered authentication methods and traditional SSPR cannot help. I have explained this in detail in my previous blog:
Windows Sign-in Recovery with Web Sign-in
In this blog, we are focusing on a more specific recovery scenario:
Windows sign-in recovery when Windows Hello for Business is not working, but the user can still use another approved method such as Temporary Access Pass or Microsoft Authenticator.
This is not a full account recovery scenario. The user still has access to another cloud authentication method. The issue is mainly with the Windows sign-in method on the device.
The Real-World Problem
Let us take a common scenario.
A user has a Microsoft Entra joined Windows 11 device. The organization has already moved toward passwordless authentication. The user signs in every day using Windows Hello for Business with face recognition, fingerprint, or PIN.
Everything works fine until one day Windows Hello stops working.
Maybe the PIN container is corrupted. Maybe the biometric option fails along with PIN. Maybe Windows Hello for Business needs to be re-provisioned.
In a traditional environment, the user might fall back to a password. But in a mature passwordless deployment, the password option may be hidden, discouraged, or no longer part of the preferred recovery flow. Some organizations may also reduce their dependency on SSPR because their recovery strategy is no longer built around password resets.
At this point, the user is not completely locked out of the account. The issue is specifically with the Windows sign-in method on the device.
This is where Web sign-in becomes very useful.
What Is Web Sign-in for Windows?
Starting with Windows 11, version 22H2 with KB5030310 or later, Microsoft allows organizations to enable a web-based sign-in experience on Microsoft Entra joined devices. This feature is called Web sign-in.
Web sign-in is a Windows credential provider that allows users to authenticate to Windows using cloud-based sign-in methods. It was originally introduced with support for Temporary Access Pass, but supported scenarios have expanded in Windows 11.
Depending on the tenant configuration and sign-in scenario, users may be able to sign in using methods such as:
- Microsoft Authenticator
- Passkey
- Temporary Access Pass
- SAML-P federated identity
This gives users another secure path to sign in to Windows when Windows Hello for Business is not available.
Important: Web Sign-in Works Only on Entra Joined Devices
Before going further, this point is very important.Web sign-in is supported only on Microsoft Entra joined Windows devices. It is not supported on Hybrid Entra joined or traditional domain joined devices. Internet connectivity is also required because authentication happens through the cloud sign-in flow.
So, this blog scenario mainly applies to organizations that have already moved, or are moving, their Windows devices to Microsoft Entra joined.
The Actual Scenario Covered in This Blog
In this blog, we are focusing on the following case:
- The user has a Microsoft Entra joined Windows 11 device.
- The user normally signs in using Windows Hello for Business.
- Windows Hello is not working or needs to be reconfigured.
- The user still has access to another cloud authentication method such as:
- Microsoft Authenticator
- Temporary Access Pass
- Passkey
- The organization wants the user to sign in, recover access, and set up Windows Hello for Business again without performing a password reset.
This is a practical recovery flow for cloud-first and passwordless environments. It helps users regain access to their Windows device securely while avoiding unnecessary password reset dependency.
Temporary Access Pass: A Reliable Recovery Method
A Temporary Access Pass, commonly called TAP, is a time-limited passcode issued by an administrator. It can be configured as single-use or multi-use. Users can use TAP to sign in and onboard passwordless authentication methods. Microsoft also highlights TAP as useful when a user loses or forgets a strong authentication method.
This is why TAP is very useful in passwordless recovery.
For example, TAP can be used:
- To onboard Windows Hello for Business
- To register a FIDO2 security key
- To register Microsoft Authenticator
- To recover when a user loses a strong authentication method
- To support device setup or recovery when the user does not know or does not have a password
The key point is this: TAP gives the user a temporary secure sign-in path. It does not replace the user’s password, and in many passwordless recovery scenarios, it avoids the need to reset the password.
Deployment Steps
Step 1: Validate Device and OS Requirements
Before enabling Web sign-in, validate the following:
- Device is running Windows 11 version 22H2 with KB5030310 or later
- Device is Microsoft Entra joined
- Device has internet connectivity during sign-in
- Device is managed through Microsoft Intune
- User has a supported authentication method available
Step 2: Enable Web Sign-in Using Microsoft Intune
In Microsoft Intune, Web sign-in can be configured using the Settings Catalog.
Go to Microsoft Intune admin center.Navigate to Devices > Configuration profiles.
Optionally, you can enable Web sign-in using the Windows Registry.
Navigate to the following registry path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\
Create a new key named: Authentication
Inside the Authentication key, create a new DWORD (32-bit) Value named: EnableWebSignIn
Set the value to:1 This enables Web sign-in on the device
To disable Web sign-in, change the value of EnableWebSignIn to:0 This will disable the Web sign-in option.
Step 3: Enable Temporary Access Pass (Only Required, if you don't have any other Authentication methods available for Sign-in)
Before users can sign in with TAP, the Temporary Access Pass method must be enabled in the Microsoft Entra Authentication methods policy. TAP can be created for any user, only users included in the TAP policy can actually sign in with it.
Go to Microsoft Entra admin center.
Navigate to Entra ID > Authentication methods > Policies.
Select Temporary Access Pass.
Enable the method.
Scope it to the required users or groups or All users.
Configure lifetime, one-time use, and passcode length based on your organization policy.
Save the policy.
TAP Lifetime and Usage Must Be Controlled
TAP is powerful and should be treated as a sensitive recovery method.
Microsoft allows TAP to be configured with minimum lifetime, maximum lifetime, default lifetime, one-time use behavior, and passcode length.
Recommended operational controls:
- Use short TAP validity where possible.
- Prefer one-time TAP for high-risk scenarios.
- Use multi-use TAP only where the enrollment or recovery process needs it.
- Monitor TAP usage in sign-in logs.
- Train helpdesk not to send TAP through insecure channels.
- Remove expired or unused TAP entries where required.
Step 4: Create a Temporary Access Pass for the User
When a user needs recovery, an administrator can create a TAP from the user’s authentication methods page.
Go to Entra ID > Users. Select the affected user. Open Authentication methods.Select Add authentication method.
Configure duration and one-time or multi-use behavior.
Important: Note that the TAP value must be copied when it is created because it cannot be viewed again after selecting OK.
User Signs in from Windows Lock Screen Using Web Sign-in
Now we have a test VM where Windows Hello PIN is not working. The user is unable to sign in using the PIN and is also unable to set up a new PIN.
When the user tries to set up the PIN, as shown in the screenshot, the process does not work as expected because Windows Hello is malfunctioning (Everything was working smooth earlier).
In this scenario, the user is unable to complete the Windows Hello PIN setup. At the same time, the user does not know their password, which means they cannot use the traditional password-based sign-in or recovery option.This creates a practical recovery challenge where the user needs an alternative authentication method, such as Temporary Access Pass (TAP), to regain access to the device and reconfigure Windows Hello for Business.
In this scenario, let us see how the user can recover access using Temporary Access Pass (TAP).
From the Windows lock screen, the user selects Web sign-in.
The user then authenticates using their Microsoft Entra ID account and the Temporary Access Pass provided by the administrator.
Alternatively, the user can select Sign in another way and authenticate using any other passwordless method already registered to their account and currently available to them.
For demonstration, I will select Sign in another way to show the available authentication options.
For example, if the user selects Microsoft Authenticator, the sign-in process will trigger the Authenticator number matching prompt. The user can then approve the request from the Authenticator app to complete the sign-in.
This option is useful when Windows Hello PIN is not working, but the user still has access to another registered authentication method such as Microsoft Authenticator, FIDO2 security key, passkey, or another supported passwordless method.
I will switch back to Temporary Access Pass (TAP) and use it to complete the sign-in.
After the user successfully signs in, we will perform Windows Hello recovery by deleting the existing Windows Hello container from the device. Once the container is removed, the user will sign out and sign in again using Web sign-in with TAP or Any other Passwordless Methods available in that Account.After successful authentication, the user will get prompt to setup Windows Hello for Business again from scratch.
After signing in with Temporary Access Pass (TAP), the Windows Hello for Business setup wizard will appear automatically to configure a new PIN.
Since the user has already completed authentication using TAP, no additional authentication prompt is required at this stage. The user can continue with the Windows Hello for Business wizard and set up a new PIN.
Once the PIN setup is completed, Windows Hello for Business is re-registered for the user, and the user can use the new PIN for future sign-ins.
Important Consideration
Before resetting Windows Hello or deleting the Windows Hello container, it is important to understand the impact.
In certain scenarios, such as TPM reset or destructive Windows Hello PIN reset, the keys used by Personal Data Encryption (PDE) to protect content may be lost. If these keys are lost, any content protected using Personal Data Encryption can become inaccessible.
The only way to recover such protected content is from a backup. If the files are synced to OneDrive, the user may need to resync OneDrive to regain access to the files.
For this reason, Microsoft recommends using the Windows Hello for Business PIN reset service wherever possible. The PIN reset service supports non-destructive PIN reset, which helps reset the user’s PIN without deleting the underlying Windows Hello container and associated keys.
A destructive PIN reset, or manually deleting the Windows Hello container, should only be used in controlled recovery scenarios where the impact is understood and proper backup or recovery options are available.
Optionally Reconfigure Windows Hello for Business
Depending on the organization’s policy, Windows may automatically prompt the user to set up Windows Hello again. If the prompt does not appear, the user can manually configure it from:Settings > Accounts > Sign-in options
From there, the user can set up a new PIN, face recognition, or fingerprint authentication method, based on the options enabled by policy and supported by the device.
Validate Windows Hello Sign-in
After Windows Hello for Business is configured again, validate that the recovery was successful.
Sign out from Windows.Sign in again using the newly configured Windows Hello method, such as PIN, face, or fingerprint.
This confirms that Windows Hello for Business has been successfully reconfigured and the user can continue working normally.
Important Considerations If you are Planning Web Sign for Entra Joined devices
1. Internet is Required
Web sign-in requires internet connectivity because authentication happens over the internet. If the device is offline, Web sign-in cannot be used. cached credentials are not supported with Web sign-in.
This means Web sign-in is not a replacement for offline Windows sign-in. It is a cloud-based recovery and sign-in path.
2. Not Supported for Hybrid Joined or Domain Joined Devices
This is only for Microsoft Entra joined devices. Web sign-in is not supported for Hybrid Entra joined or domain joined devices.
For customers still running hybrid joined devices, this is another reason to carefully plan the device migration journey.
3. Web Sign-in May Become Default for New Users
Once enabled, Web sign-in can become the default credential provider for new users signing in to the device. The default credential provider can be changed using the DefaultCredentialProvider ADMX-backed policy if required. This should be tested before broad deployment.
4. User May Not Appear After Sign-out
After sign-out, the user may not be displayed in the user selection list. This is expected behavior.
User & Helpdesk teams should be aware of this behavior to avoid confusion during support calls.
5. Ctrl + Alt + Delete Can Exit the Web Sign-in Flow
If the user needs to exit the Web sign-in flow and return to the Windows lock screen, they can press Ctrl + Alt + Delete.This as the workaround for a known issue where selecting Back to sign-in may not return the user to the lock screen when the device is offline.
6. One-Time TAP and Windows Hello Enrollment Timing
If your organization enforces one-time TAPs, remember that passwordless registration must be completed within the expected time window. when a one-time TAP is used to register a passwordless method such as WHfB, FIDO2 security key , registration must be completed within 10 minutes of sign-in. This limitation does not apply to a multi-use TAP.
For Windows Hello recovery, test your end-user flow properly. In some cases, a multi-use TAP with a short lifetime may create a smoother recovery experience, but it should be balanced with security monitoring.
Final Thoughts
Moving Windows devices from local AD or Hybrid Entra joined to Microsoft Entra joined is an important step in the cloud journey. Moving user identities to a cloud-managed Source of Authority is the next step once application and AD dependencies are removed.
But passwordless adoption should not focus only on sign-in. It must also include recovery.
Windows Hello for Business, passkeys, and Microsoft Authenticator passwordless sign-in provide strong authentication. However, users still need a reliable way to regain access when one method fails.
This is where Web sign-in with Temporary Access Pass becomes valuable.
It gives IT teams a practical recovery option for Entra joined devices without making password reset the default solution. It also helps users sign in, recover access, and reconfigure Windows Hello for Business smoothly.
My recommendation is simple:
Do not design passwordless only for happy-day sign-in. Design it for recovery as well.
























0 Comments