Problem activating Windows Hello in an AD/M365 synchronized environment

Question

Problem activating Windows Hello in an AD/M365 synchronized environment

Edgardo Arias Beise 0

Good afternoon, I need your help. I have an Active Directory synchronized with Microsoft 365, and I want to activate Windows Hello. When I configure my computer, it seems to work correctly, but after a few hours, Windows Hello deactivates, and I have to configure it again. I believe this is due to a security policy in the local environment. Could someone help me identify which policies I should check? Thank you.

0 comments

2 answers

Your answer

Answer 1

In a synchronized AD/Microsoft 365 environment, Windows Hello for Business behavior is controlled by a combination of Group Policy (GPO) and MDM/CSP (for example, Intune). If Windows Hello works initially and then deactivates, the most likely cause is a policy conflict or a policy refresh that overwrites the initial configuration.

Key points and policies to check:

Avoid mixing GPO and CSP for Windows Hello for Business
Windows Hello for Business can be configured by Group Policy or by the PassportForWork CSP (for example via Intune), but not a combination of both. If both are configured, the CSP settings are ignored until the GPO settings are cleared. This can cause Windows Hello to appear correctly configured at first and then be overridden when Group Policy refreshes. Actions:
- On a test machine, run gpresult /h report.html and review applied GPOs related to Windows Hello for Business.
- In Intune (if used), review any Windows Hello for Business settings configured via:
  - Settings catalog
  - Security baselines
  - Custom policy using PassportForWork CSP
  - Account protection policy
  - Identity protection policy template
- Decide on a single configuration source (GPO or Intune/MDM) and remove/disable the other for Windows Hello for Business.
Understand policy precedence between GPO and Intune
In hybrid deployments (key trust or certificate trust), if Windows Hello for Business is configured in both Group Policy and Intune, Group Policy takes precedence and Intune settings are ignored. This precedence can explain why a device initially behaves as expected (for example, at enrollment) and then changes behavior after a Group Policy refresh. Actions:
- In a hybrid key trust or hybrid certificate trust deployment, verify that only one of the following is configuring Windows Hello for Business:
  - Group Policy (on-premises)
  - Intune/MDM (PassportForWork CSP)
- If both are present, remove or neutralize the GPO settings so that Intune can apply consistently, or disable the Intune configuration and manage everything via GPO.
Check policy precedence within Windows Hello for Business policies
Some Windows Hello for Business policies exist at both user and computer scope. The precedence is:
1. User – GPO
2. Computer – GPO
3. User – PassportForWork CSP
4. Device – PassportForWork CSP
5. Exchange Active Sync – DeviceLock CSP
Actions:
- Verify that user-level GPOs are not disabling or restricting Windows Hello for Business after sign-in.
- If using DeviceLock CSP (for example via Exchange Active Sync policies), be aware that password/PIN complexity from DeviceLock and PassportForWork are combined, and the strictest policy is enforced. Misconfigured complexity or expiration could force re-enrollment or make PIN invalid.
Verify Intune tenant-wide Windows Hello for Business setting (if Intune is used)
For Microsoft Entra joined or hybrid joined devices enrolled in Intune, there is a tenant-wide Windows Hello for Business policy that is applied only at enrollment time. Later, device configuration policies can change behavior. Actions:
- In the Microsoft Intune admin center:
  - Go to Devices > Windows > Windows Enrollment > Windows Hello for Business.
  - Check Configure Windows Hello for Business and related settings.
- Ensure that this tenant-wide setting and any device configuration policies (settings catalog, security baselines, account protection, identity protection) are aligned and not conflicting.
Confirm that prerequisite checks and enrollment are stable
If prerequisite checks fail intermittently, Windows Hello for Business enrollment might not persist correctly. Actions:
- On an affected device, check Event Viewer → Applications and Services Logs > Microsoft > Windows > User Device Registration for errors or warnings after Windows Hello deactivates.
- Run dsregcmd.exe /status and verify device registration status with Microsoft Entra ID.
Review any password/PIN expiration policies
If password or PIN expiration policies are misaligned, users might be forced into repeated re-enrollment or see failures when authenticating to AD resources, which can be perceived as Windows Hello “deactivating.” Actions:
- Review PIN complexity and expiration policies configured via PassportForWork CSP or GPO.
- If DeviceLock CSP is used for password complexity, remember that Windows enforces the strictest combination of DeviceLock and PassportForWork policies.

By systematically checking:

Whether both GPO and Intune/MDM are configuring Windows Hello for Business, and
Which specific user/computer policies are applied and in what order,

the policy that is disabling or resetting Windows Hello after a few hours can be identified and corrected.

References:

Answer 2

Good afternoon,

The behavior you describe is almost always tied to Group Policy or MDM policies overriding the local Windows Hello configuration. Since your environment is synchronized with Microsoft 365, you need to check both on-premises Active Directory GPOs and Intune/Endpoint Manager policies.

Start by reviewing the following in your local domain GPOs:

Under Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business, confirm that “Use Windows Hello for Business” is set to Enabled. If this is set to Disabled or Not Configured, the client will revert after policy refresh.
In the same path, check “Use biometrics” under Biometrics. This must be enabled, otherwise Windows Hello will be removed after gpupdate.
Also verify Security Settings > Local Policies > Security Options > Interactive logon: Require Windows Hello for Business or smart card. If this is misconfigured, it can force deactivation.

On the cloud side, if you are using Intune, go to Endpoint Security > Identity Protection and check the Windows Hello for Business policy. Ensure that the configuration profile is consistent with what you want (PIN, biometrics, key trust vs. certificate trust). If there is a mismatch between AD GPO and Intune policy, the device will continuously reapply settings and cause the deactivation you’re seeing.

Finally, confirm that your Azure AD tenant is set to allow Windows Hello for Business. In the Microsoft 365 admin center, under Azure Active Directory > Devices > Windows Hello for Business, make sure the state is set to Enabled. If it is set to Disabled or Not Configured, the local setup will work temporarily but be removed after sync.

In short, the key policies to check are:

Windows Hello for Business GPOs in Active Directory.
Biometric usage policies in AD.
Intune Identity Protection profiles if hybrid joined.
Azure AD device settings for Windows Hello.

I recommend running gpresult /h c:\gporeport.html on the affected machine to see exactly which GPO is applying and overriding the Hello configuration. That will give you a definitive answer on whether the local environment is disabling it.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.