Windows screen lock not enforcing after 5 minutes despite Hexnode screensaver policySolved

Hi @m ,

For Windows devices, it is important to distinguish between a Screensaver policy and the Windows machine inactivity lock.

A Screensaver policy can configure values such as the screensaver timeout and whether the screensaver should be secure. However, applications that keep the session active or reset the idle timer can interfere with screensaver-based locking.

For a more reliable Windows lock based on actual keyboard/mouse inactivity, configure the Windows security policy value InactivityTimeoutSecs using Hexnode’s Registry Editor automation.

Use the following registry configuration:

• Action: Write Value
• Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
• Value name: InactivityTimeoutSecs
• Data type: REG_DWORD
• Value type: Decimal
• Data: 300 300 equals 300 seconds, or 5 minutes.

After applying the registry value, restart the device. If Fast Startup is enabled, perform a full restart rather than only shutting down and powering on again, because Fast Startup can prevent some registry-based policy changes from taking effect immediately.

Regards,
Isabel Lora
Hexnode UEM

I tried setting the registry value through Automation, but it stayed pending on one test device. Also, I added a few devices to the target group after creating the automation. Those devices didn’t show the automation in Action History. Is that expected?

Yes, that can happen depending on how the automation schedule and target were configured.

If the automation is scheduled as Once, ASAP, it applies to the devices that are in the selected target group at the time the automation is created. Devices added to that group afterward may not automatically receive that same one-time automation run.

To apply it to newly added devices, use one of these options:

1. Recreate or update the automation so the current target devices are included.
2. From the device page, use the Initiate Automation action for the specific devices.
3. Confirm the device is online and checking in with Hexnode. If a device is not communicating with the portal, the automation can remain pending until the device checks in.

Once the action runs successfully, you should see the registry value written on the endpoint.

Regards,
Isabel Lora
Hexnode UEM

That explains the pending status. I manually initiated the automation on the affected devices. It worked on most of them after a reboot, but one PC still does not lock even though the registry value exists and is set to 300.

If the registry value is present and correctly set, Hexnode has already delivered the required configuration to the device.

When a single Windows device still does not lock after that, the next thing to check is whether a local process is preventing Windows from considering the machine idle. Activity monitoring, screen recording, remote access, media playback, or similar background applications can call Windows APIs that keep the session awake or continuously reset the idle timer.

To confirm this, temporarily stop the activity monitoring/screen recording process on that endpoint and leave the device idle for 5 minutes. If the lock works after stopping the process, the issue is caused by that application or its configuration rather than Hexnode policy delivery.

In that case, check with the application vendor for a setting that allows Windows idle lock or machine inactivity policies to function while the app is running.

Regards,
Isabel Lora
Hexnode UEM

We tested this and the registry automation worked on the other devices. The remaining device appears to be affected by the monitoring app keeping Windows active. We’re checking the app-side settings with the vendor now.

That is the right next step. For future deployments, the recommended approach is:

1. Configure InactivityTimeoutSecs using Hexnode Registry Editor automation.
2. Use decimal 300 for a 5-minute lock.
3. Make sure the automation actually runs on each target device.
4. Restart the endpoint after the registry value is applied.
5. If only specific devices fail, check for apps that reset Windows idle state.

Re-enrollment is usually not required if the registry value is already present and correct. Re-enrollment may refresh device management state, but it will not resolve a local application that is actively preventing Windows from locking.

Regards,
Isabel Lora
Hexnode UEM