macOS auto-lock change triggers Change password at next login promptSolved

Hello @ronnie ,

Yes, if the “Change password at next login” option remains enabled, modifying any other setting in that policy will re-trigger the password prompt for all assigned Macs.

This happens because the auto-lock timer and the “Change password at next login” setting are part of the same macOS Passcode configuration payload. When you update the auto-lock value and save the policy, Hexnode UEM redeploys the entire payload. macOS processes the payload as a whole, meaning the “Change password at next login” command gets reapplied to all assigned devices, causing existing users to receive the prompt again.

To prevent this, the recommended approach is to create and manage two completely separate policies:

• Onboarding Passcode Policy: Create a dedicated policy just for new enrollments. Enable “Change password at next login” here. Assign this policy only to newly enrolled devices or a specific onboarding group. Once a device completes the initial setup, unassign this policy from the device.

• Maintenance Passcode Policy: Create a second, separate policy for your active production devices. Leave “Change password at next login” disabled here, but configure all your ongoing settings (like your auto-lock timer and complexity rules).

This setup prevents routine configuration changes in your second maintenance policy from triggering unexpected password resets across your existing fleet.

Regards,
Simon Scott
Hexnode UEM

If we don’t want to create two policies, is there a safe single-policy method? We only need the password prompt during enrollment, but we occasionally tweak passcode settings later.

A single-policy approach is possible, but it requires careful manual toggling before every update.

Before editing settings like the auto-lock timer, you must first disable “Change password at next login” and save the policy. Once the change is synced, you can safely modify your auto-lock settings. Afterward, you must remember to re-enable “Change password at next login” so it is ready for the next batch of new enrollments.

While this works, it is very easy to misconfigure or forget a step, especially in larger deployments. Creating two separate onboarding and maintenance policies remains the safest and most reliable practice, as it completely isolates the password reset action from your active users.