Windows users stuck in password reset loop after changing Hexnode password policySolved

Hi @yasmin_farooq,

When a Windows password complexity policy is deployed or updated through Hexnode, Windows may prompt local user accounts to update their credentials after a restart. If the password entered by the user does not meet the configured requirements, the device can also appear non-compliant.

To remove the password policy from only one affected device, first check how the policy is assigned:

1. Go to Manage and select the affected Windows device.
2. Open the Policies sub-tab and confirm whether the password policy is applied directly or through a device group.
3. If the policy is directly associated, remove the policy from the device.
4. If the policy is applied through a static device group, remove the device from that group.
5. If the policy is applied through a dynamic device group, add the device as an exception in the dynamic group criteria using a non-sensitive device identifier available in the device details.
6. After saving the change, confirm from the device’s Policies sub-tab that the password policy is no longer listed.
7. Restart the Windows device and check whether the user can sign in.

Once access is restored, the password policy can be reapplied after confirming that the user password meets the configured complexity rules.

Best Regards,
Isabel Lora
Hexnode UEM

That helped. The device was part of the policy through a dynamic group, so I added it as an exception and it dropped out of the group. The policy no longer showed under the device policies. After that, the user was able to get back in by resetting the Windows password locally.

I’ve seen this happen when a password policy is tightened and then rolled back quickly. Some devices may still have processed the stricter rules before the rollback, especially if they checked in at different times. A restart can then trigger Windows to ask for an updated password even though the admin already changed the policy again.

Yes, changing a Windows password policy and then reverting it can still affect devices that already received the updated policy. Devices may not all process the change at the same time.

For multiple affected users, use this approach:

1. Identify devices still showing the password policy under the device’s Policies sub-tab.
2. Temporarily remove or exclude affected devices from the password policy assignment.
3. Restart the devices.
4. If Windows shows a password recovery or reset screen, reset the local account password on the device.
5. If the local administrator credentials are known, the password can also be changed from Hexnode by going to the device page, opening Local Accounts, selecting the user, and changing the password.
6. Reapply the password policy only after confirming users can sign in and that the new passwords meet the configured policy requirements.

The repeated password reset prompt is generally caused by Windows enforcing the local password requirements or by failed sign-in attempts, rather than the Hexnode portal sign-in itself.

Best Regards,
Isabel Lora
Hexnode UEM