So, You’ve disabled Windows Hello for Business, but the User can still Sign-in using a PIN
Hi, it’s Brent from the Windows Directory Services team. I recently worked a case concerning a user who had the Windows Hello for Business (“WHfB”) policy disabled, but the user could still sign-in to the computer using their PIN. As you may have guessed, the Windows admin team of the Active Directory domain for this user wanted to know how this could be and how they could remove this sign-in option from the user. Let’s Talk About the Problem The user retaining the ability to sign-in using their PIN wasn’t the only issue the admin team encountered. After requesting the user to remove the WHfB PIN sign-in, they discovered the option to remove the Windows Hello PIN sign-in was greyed out: Now, it seemed there wasn’t a way to remove the user’s ability to sign-in with their WHfB PIN. How Did We Get Here? A Microsoft Intune policy or Windows Active Directory Group Policy Object (“GPO”) was originally enabled for this user to provision Windows Hello for Business sign-in. Sometime after the user was provisioned and using their PIN to sign-in, the Windows admin team determined this user should no longer use WHfB credentials. To remove the user’s ability to do so, they configured the Intune and/or GPO policy to disable Windows Hello for Business. After refreshing the policy to the user’s computer successfully, they confirmed the PassportforWork registry key was set to disabled as follows: HKLM\SOFTWARE\Policies\Microsoft\PassportForWork Enabled REG_DWORD 0x0 The actions performed above will not remove the ability of an already provisioned user from using Windows Hello for Business PIN to sign-in to the Windows computer. To better understand the issue, the following details are provided to clarify the use of policies such as Intune and GPOs in relation to the Windows Hello for Business credential provider. When either an Intune policy or Windows GPO is configured for a user to enable WHfB, the policy is only enabling the user to enroll for provisioning to use Windows Hello for Business. The provisioning process and authentication process for Windows Hello for Business are two separate components within the Windows Hello for Business feature. Since the policy only enables the ability for a user to activate the provisioning process to enroll for Windows Hello for Business, the policy becomes irrelevant after the user successfully provisions. Once a user is provisioned, they will be able to continue using the Windows Hello for Business PIN sign-in even when the policy has been set to disabled. This behavior is expected and by design, which is documented in the following published article: Manage Windows Hello in your organization - Windows Security | Microsoft Learn However, by setting the policy to disabled, the user no longer has the ability to activate the provisioning process. The remove button under the Windows Hello PIN sign-in option is used to activate provisioning, which would allow the user to un-enroll for Windows Hello for Business. Therefore, the inability to select the remove button is also expected and by design in this configuration. How will the PIN Sign-in be Removed if Provisioning is Disabled? To disable Windows Hello for Business in this situation, the Windows Hello container will need to be deleted for the user. To do so, the user will perform the following steps under their user context on each Windows computer they were successfully provisioned prior to the policy being disabled: Have the user sign-in to the Windows computer using their username and password. Open a command prompt under the user’s context (not admin) and run the following command: certutil.exe -deleteHelloContainer Close the command prompt and restart the computer. With the policy set to disabled, the user will no longer be able to activate the provisioning process on this or any other Windows computer going forward. We wouldn’t want the user to enroll for Windows Hello for Business again after we removed it, right? I hope you found this information helpful in your understanding of Windows Hello for Business administration. Until next time. Brent Crummey Related Registry Keys Computer registry - HKLM\SOFTWARE\Policies\Microsoft\PassportForWork User registry - HKCU\SOFTWARE\Policies\Microsoft\PassportForWork References Windows Hello for Business Frequently Asked Questions (FAQ) - Windows Security | Microsoft Learn certutil | Microsoft LearnHybrid to Entra ID WiFi Certificate Authentication NPS via WHfB Cloud Trust & Cloud PKI-Replace ADCS
Hello Team, We are working in moving our devices Hybrid Entra ID Joined to Intune autopilot Entra ID Joined Current scenario: Hybrid Entra ID Joined devices (joined to both on-prem AD and Entra ID) Active Directory with Entra ID Connect for object synchronization AD Certificate Services (ADCS) issuing user and device certificates via GPO auto-enrollment Group Policies to push Wi-Fi configuration (EAP-TLS using device certificate) NPS RADIUS server using EAP-TLS ("Smart Card or Other Certificate") for secure 802.1X authentication On-prem SSO enabled through standard Kerberos authentication Now, I am testing Autopilot Win11 Entra ID Joined with WHfB using Cloud trust to SSO to on-prem resources. The autopilot is working, however, the WIFI is not working as the autopilot device doesn't have any certificate from the on-prem ADCS. What is the best practice to try be as much cloud and begin to decommision on-prem services. I have 2 options to push the User and computer certificate to the AUtopilot device: Option 1: Intune Certificate Connector that will bridge on-prem ADCS and Intune, In Intune a PKCS profile to install the certificate to the autopilot device. Option 2: Intune Cloud PKI and configuration profile PKCS profile to install the certificate to the autopilot device. on-prem install the root CA from the Intune cloud PKI. https://learn.microsoft.com/en-us/intune/intune-service/protect/microsoft-cloud-pki-deployment For the on-prem SSO I will contine using Cloud Trust. Component Target Device Identity Autopilot + Entra ID Joined only (no domain join) User Sign-In Windows Hello for Business (WHfB) with Cloud Kerberos Trust Certificate Issuance Replace ADCS/GPO with Microsoft Cloud PKI and Intune PKCS Wi-Fi Authentication Retain existing NPS RADIUS using EAP-TLS, but trust both ADCS and Cloud PKI root CAs On-prem SSO Enabled by AzureADKerberos on domain controllers Hybrid Devices Continue current operation during the transition — no immediate impact The 2 network environment needs to coexist: the on-prem and the cloud. Device Type Certificate Issuer Wi-Fi Auth SSO Hybrid AD-joined ADCS via GPO EAP-TLS (device cert) Native Kerberos Autopilot Entra ID Joined Cloud PKI via Intune EAP-TLS (device cert) WHfB + Cloud Trust (AzureADKerberos) How the New Wi-Fi Auth Works: Autopilot devices receive: A device certificate from Cloud PKI via Intune A Wi-Fi profile using EAP-TLS authentication NPS RADIUS server: Validates the device cert Issues access to Wi-Fi WHfB Cloud Trust provides a Kerberos ticket from AzureADKerberos, enabling seamless access to file shares, print servers, etc. This allows Autopilot Entra ID Joined devices to: Connect to Wi-Fi without GPO Access on-prem resources without passwords High-Level Implementation Steps Deploy Microsoft Cloud PKI in Intune Configure PKCS profiles for user and device certificates Deploy WHfB Cloud Trust via Intune + Entra ID (no AD join needed) Configure AzureADKerberos on domain controllers Install Cloud PKI Root CA in NPS server trust store Update NPS policy to accept certificates from both ADCS and Cloud PKI Deploy Wi-Fi profiles to Autopilot devices via Intune (EAP-TLS using device cert) Based on it, what is the best practice to move the device to the cloud as much possible.Windows Hello for Business - Registered Methods and Last-used Method
Hi folks – Mike Hildebrand here! Today, I bring you a short post about gaining more awareness of Windows Hello for Business (WHFB) configuration information from across your fleet of Windows PCs. Over time, we’ve improved the built-in "Authentication Methods" reporting in the Entra portal. As far as WHFB goes, at this point, the Entra Portal provides high-level counts of WHFB registration and usage: However, we IT Pros are a curious bunch, always looking for more information and more detail about what’s going on in our enterprise. A while back, after being asked by numerous customers for a way to get more details about their WHFB deployment, I published a post about using Entra sign-in log data and a custom Log Analytics Workbook to obtain that information. That post/report has proven helpful - from Entra sign in logs, we can determine who is using WHFB, from which device (and there’s even a map to show where in the world it’s happening). Nice. But that's only the 'cloud-side' of the situation - there are almost always two follow up questions that can only be answered from the endpoint: What WHFB methods has a user registered on the endpoint(s)? PIN only? PIN + fingerprint? Face? Which WHFB method was last used by a given user on a given endpoint? Ask, and yee shall receive Here are two easy/quick Intune Proactive Remediation detection scripts you can use that send configurations to a Windows endpoint and retrieve the local device details (via reg-values) around WH4B enrollment methods and the last-used WHFB method. NOTE: In my 12 days of Christmas blog-a-thon, I posted about creative uses of Intune Proactive Remediations. Once again, thanks to Marius Wyss and his core scripts to collect the WHFB registration and 'last used' info from local endpoints. They’re the real magic here. !! CAUTION !! There is PowerShell code involved here. Due diligence is required on your part. Raise your right hand and read this out loud: “Like everything else, I will thoroughly test this and all code/changes that I work with before I deploy to production. I will document the before-change state to ensure I can revert any changes I make.” CODE DISCLAIMER – These sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. REMINDER/NOTE - When using your scripting editing tool of choice, always be aware of any additional spaces or odd quotation marks or other issues that may result from edit/copy/paste. “Enrollment Types” Detection The ‘Enrolled Methods’ script from Marius o Intune-Remediation-Scripts/WH4B/Enrolled Methods at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub o My Remediation Script Settings: o My results: “As of 2/2/2026 at 9:40 AM, Adele registered a PIN (default/required) - a face - and a fingerprint - for WH4B on the SURFACEPRO5 device” “Last Used Method” Detection The ‘Last Used Method’ script from Marius o Intune-Remediation-Scripts/WH4B/Last Used Method at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub o My Remediation Settings: o My results: “As of 2/2/2026 at 9:40 AM, Adele last used a face/camera for WHFB on the SURFACEPRO5 device” Additional Examples of Results Enrollment Types Registered o NOTE: Remember, a PIN is required, so where you see ‘Fingerprint configured’ in the output, it means ‘PIN + Fingerprint’ Last-used method There you have it folks - by combing these two Detection Scripts with the Log Analytics Workbook mentioned at the start of the post, you have a solid solution for ‘end to end’ WH4B reporting. Hilde
Excluding Windows Hello for Business (WHfB) for Windows 10 using Intune assignment filter
Good morning, I'm experiencing a persistent issue with applying an exclusion policy for Windows Hello for Business (WHfB) on Windows 10 devices (actually a testing VM) managed through Microsoft Intune. Despite configuring the assignment filter and verifying its correct evaluation in Intune, Windows 10 devices continue to allow WHfB PIN creation, and the option to remove the PIN is disabled. Scenario and objective: My goal is to enable Windows Hello for Business for all users except when they log in from a Windows 10 device (already enrolled in Intune). Therefore, the intention is to disable WHfB specifically for Windows 10 devices. Current configuration: WHfB policy: I have a device configuration profile named “WHfB” (Platform: Windows) which enables Windows Hello for Business. Policy assignment: This policy is assigned to a “WHfB Dynamic Group” that contains users with the “manager” attribute. Assignment filter (exclusion): I created and applied an assignment filter named “Windows 10 Device Filter” to the policy mentioned above. Filter mode: Exclude. Filter definition: (device.osVersion -contains "10.0.1") Observed behavior: Filter evaluation in Intune (as shown in the previously provided screenshot): For the problematic Windows 10 device, in the “Filter Evaluation” section of the “WHfB” policy, the “Windows 10 Device Filter” shows “Evaluation Result: Match” and “Mode: Exclude.” The message states “Policy not delivered.” This confirms that the filter is working correctly in Intune and that the WHfB policy is not applied to the Windows 10 device. Behavior on the Windows 10 device: Despite the exclusion, the user (AdeleV) can still modify and use the WHfB PIN. The “Remove” PIN option is disabled (greyed out) in sign-in options. Windows Event Logs (HelloForBusiness/Operational): The log displays several errors (Event IDs 7054, 8203, 7204) and informational events (8210, 8200, 8202, 5060 “PIN required”). Event 7054 specifically indicates error 0x1 (or 0x80000000000000001), which is a generic error. Troubleshooting steps performed: Forced sync and restarts: executed multiple times on the Windows 10 device. Sync status in Intune for the “WHfB” policy sometimes shows “Unavailable,” but filter evaluation is always “Match/Exclude.” OS version verification: The OS version on the device (10.0.19045.3803) confirms that the string “10.0.1” is contained, so the filter syntax is correct. Policy conflict search: I reviewed the device’s configuration profiles and compliance policies applied via Intune, but didn’t identify any obvious conflicts or other policies that explicitly enable WHfB. Question: Given that my WHfB exclusion filter works correctly, but WHfB is still enabled on the Windows 10 device (and the PIN can’t be removed, with a generic error in the log), what could be the root cause?
WHFB non destructive PIN
Hello, I've configured Windows Hello for Business and applied the Non-Destructive PIN Reset policy via Intune. However, after resetting the PIN, when I run dscmdreg /status in the User State, it still shows DestructiveOnly. Additionally, Event Viewer logs Event ID 7060 – PIN Recovery Error 0x83750007. Could you please help me troubleshoot this?
Windows Hello for Business - Multi-Factor Unlock - Wireless Trusted Signal WPA3
I have been experimenting with WiFi trusted signal for Windows Hello for Business due to an issue that appears to have popped up after changing access point security to WPA3. I cannot seem to get the trusted signal configuration XML to properly validate the wireless trusted signal when WPA3 is the security type (With security being a required property). It works fine on WPA2, but no syntax for WPA3 seems to work. The official KB article from Microsoft about multi-factor unlock/trusted signals only lists the following as options: Open The wireless network is an open network that doesn't require any authentication or encryption. WEP The wireless network is protected using Wired Equivalent Privacy. WPA-Personal The wireless network is protected using Wi-Fi Protected Access. WPA-Enterprise The wireless network is protected using Wi-Fi Protected Access-Enterprise. WPA2-Personal The wireless network is protected using Wi-Fi Protected Access 2, which typically uses a pre-shared key. WPA2-Enterprise The wireless network is protected using Wi-Fi Protected Access 2-Enterprise. Just worried this may just be straight up incompatible. Has anyone had luck using WPA3 for WHfB with wireless as a trusted signal?Set User Default Credential Provider for Lock Screen
I'm using Windows 10 Enterprise 22 H2 with Intune and MECM (Co-Managed). We enforce that our users enrol for Windows Hello for business. They can use PIN or Biometric. This all works fine but when the user session locks (idle time etc.) it defaults to username/password credential provider even if the user signed into the desktop console session with a PIN. I'm aware there is a system wide policy to set the default credential provider here https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-credentialproviders#defaultcredentialprovider but I am wondering if there is a method to do this per user or have the lock screen default to the credential used for the user sigin in?
Windows hello for business for Hybrid Entra Join
Environment: -No UPN matching between onprem AD and Azure, Third party federation and User provisioning . -Hybrid Entra Joined devices -Enrolled to Intune using device credentials as SCCM is setup with co management (Cloud Attach). Question: Whether setting up Windows hello for business (Which was working before enrollment) using GPO / or Intune. An error is returned. Pin: "this sign in option is only available when connected to your organization's network" "Fingerprint and Face" "The option is currently unavailable" Multiple methods to setup WFH was attempted and none worked so far. -Devices -> Win 10 -> Enrollment -> "Configure Windows hello for business" -Using Custom settings as described here(CSP or GPO): https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/configure -Biometrics devices updated/ Windows updates installed/ All devices and users affected in the organization. -What could be the issue? Any best effort to get the windows hello for business working again?
