https://www.sikich.com

Using Temporary Access Pass and default credential provider for a smoother Windows sign-in experience 

INSIGHT 5 min read

In today’s blog, I want to build on a topic I covered several months ago: Microsoft’s Temporary Access Pass (TAP) and how it fits into the setup and ongoing experience of Entra ID-joined (formerly Azure AD-joined) Windows devices. Back in August 2024, I wrote a blog post walking through how TAP can be used during the provisioning of new PCs or during cloud migrations. If you haven’t read that post yet, I definitely recommend checking it out first; it lays the groundwork for how TAP works and why it’s so convenient for IT administrators.

Once you’re familiar with TAP, the method used for Entra ID–joined PC provisioning, there’s another detail that I didn’t cover in that original article: what happens to the Windows sign-in experience after TAP is used on a device. This part often catches organizations by surprise, and understanding it can help you avoid unnecessary confusion for your end users.

TAP and the Windows sign-in experience

When you enable TAP for a user and login to a PC using TAP, you’ll use Web Sign-in. This method displays a web-based sign-in screen, Microsoft’s OAUTH window, that handles authentication through Entra ID and allows the person to use a TAP or sign in with their password and MFA. Web Sign-in works great for admins when onboarding and is especially useful in Autopilot scenarios or when you’re repurposing machines during a move away from on-premises infrastructure.

But here’s the catch: Windows will continue using the last credential provider used to authenticate the account as the default sign-in option, unless you explicitly configure it otherwise.

So, let’s say you set up a user’s PC with TAP, and during setup you authenticate using Web Sign-in & TAP. Later, when the user locks their PC or signs in the next day, what do they see?

Web Sign-in again. Not the password field they’re used to.

For IT admins this isn’t surprising, but for end users it often is. Most users don’t know (and shouldn’t have to know) the difference between credential providers, and many will simply roll with whatever appears first. That leads them right back into the web sign-in flow, including a Microsoft-hosted prompt, MFA, and the whole process that comes along with it.

There’s nothing wrong with that from a security perspective. However, it can quickly become annoying, especially on systems with strict inactivity timeouts where users need to log in repeatedly throughout the day. Instead of typing a password and moving on, they’re getting a full web authentication workflow each time.

The solution: Set the default credential provider in Intune

Thankfully, there’s a simple fix, and (as usual) the solution lives in Microsoft Intune. Because Entra ID joined devices are fully manageable from Intune, you can create a configuration profile that explicitly dictates which credential provider Windows should use by default. In this case, we want to make Password Sign-In the default again, even though TAP and Web Sign-in remain available when needed (“Sign-in options” at the login screen).

Here are the exact steps to configure this:

Intune configuration instructions

Goal: Set the Windows default credential provider to Password instead of Web Sign-in.

  1. Go to Microsoft Intune Admin Center
    Devices → Configuration → New Policy
  2. Platform: Windows 10 and later
    Profile type: Settings Catalog
  3. Name the policy:
    Set Default Credential Provider to Password
  4. Under Settings, search for:
    “Assign a default credential provider”
    (Category: Administrative Templates → System → Logon)
  5. Enable the setting.
  6. Specify the credential provider GUID for Password Sign-In:
    60b78e88-ead8-445c-9cfd-0b87f74ea6cd
  7. Assign to: All Devices (or a device group of your choosing)

Important considerations and disclaimer

The guidance in this article assumes an environment where users authenticate to Windows primarily by using a traditional password and where setting the Password credential provider as the default will not conflict with other sign-in methods.

If your organization uses Windows Hello for Business (PIN, facial recognition, fingerprint biometrics), third-party credential providers (such as Duo, Okta, or other MFA extensions), or any alternative primary sign-in method, forcing a single default credential provider may have unintended consequences. In those environments, changing the default provider could alter the expected user sign-in experience or interfere with preferred authentication workflows.

Organizations with mixed authentication methods should carefully evaluate their requirements and may need to:

  • Avoid enforcing a single default credential provider globally
  • Create multiple Intune configuration profiles that set different default credential providers based on user or device groups
  • Pilot and validate behavior across all supported sign-in methods before broad deployment

As with any authentication-related change, testing in a representative subset of devices is strongly recommended prior to production rollout.

You can view a complete list of installed credential providers-and their GUIDs-here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers

Final thoughts

Temporary Access Pass remains one of the most powerful tools available when onboarding Entra ID-joined PCs, whether through Windows Autopilot or during a broader migration away from on-premises to cloud. TAP gives IT administrators a secure and flexible way to authenticate users without needing their passwords, while maintaining a smooth setup experience.

But if you enable TAP and Web Sign-in during provisioning, the Windows login experience can inadvertently shift away from what your users expect. Creating a simple Intune policy to enforce the Password credential provider as the default helps ensure that users continue to enjoy a familiar login flow, even while admins retain the ability to use TAP and Web Sign-in whenever needed.

I hope you found this helpful! If you have questions about TAP, credential providers, or modern device provisioning strategies, feel free to reach out at any time.

Author

Josh Reese is a Senior Network Consultant at Sikich, assisting clients in achieving their business objectives through technology and trusted advice. He holds a Bachelor’s degree in Computer Information Systems from The University of Akron, as well as several Microsoft certifications. His primary area of focus revolves around Microsoft’s Cloud services. This includes working with both Azure and Microsoft 365 environments in order to drive clients toward full cloud enablement.