Windows - Security - Enforce Lock Screen on Inactivity

What the Windows inactivity lock screen Worklet does

This Automox Worklet™ enforces an automatic screen lock on Windows endpoints by writing the InactivityTimeoutSecs value under the local machine Group Policy System key. The Worklet reads a single $minutes parameter from the policy, converts that value to seconds, and uses it as the target state every endpoint must match.

The registry path the Worklet manages is HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. This is the same registry location the Group Policy editor writes to when an administrator configures Computer Configuration – Windows Settings – Security Settings – Local Policies – Security Options – Interactive logon: Machine inactivity limit. By targeting the policy hive directly, the Worklet survives reapplication of a domain GPO and keeps unmanaged or workgroup endpoints aligned with the same baseline.

The default timeout is 15 minutes, which writes a DWORD of 900 to InactivityTimeoutSecs. Change the $minutes parameter in remediation.ps1 to match the value your security baseline requires. CIS Benchmark 2.3.7.4 calls for 900 seconds or fewer (and never 0, which disables the policy), and NIST 800-53 AC-11 calls for a session lock after a defined period of inactivity. The Worklet treats both as the same write to the same DWORD.

Why hold the Machine inactivity limit baseline on every Windows endpoint

An unattended Windows endpoint with an unlocked session is a low-cost attack vector. Anyone with brief physical access can copy data to removable media, send mail under the logged-in account, or open the file shares the user already has mapped. The Machine inactivity limit setting closes that window without depending on the user remembering to press Windows+L. CIS 2.3.7.4, NIST 800-53 AC-11, PCI-DSS v4.0 8.2.8 (8.1.8 in v3.2.1), and HIPAA §164.312(a)(2)(iii) all cite an automatic session lock as a required technical control, and auditors verify the registry value during assessments.

A reimage, a recovered backup, a freshly joined endpoint, or an admin who clears the value to debug a UI issue can all leave InactivityTimeoutSecs missing on Windows endpoints that previously passed an audit. The Get-ItemProperty check on HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System fires on every evaluation, and Set-ItemProperty restores the configured second value before the screen-lock control falls off the next CIS 2.3.7.4 scorecard.

How inactivity lock enforcement works

1. Evaluation phase: The Worklet runs Get-ItemProperty against HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and reads the InactivityTimeoutSecs value. The script multiplies the $minutes parameter by 60 to compute the expected DWORD, then compares the stored value against the target. If the value is missing, the property does not exist, or the stored DWORD does not match the expected timeout, the endpoint is flagged non-compliant and remediation is scheduled. Endpoints already holding the baseline exit 0 without writing the registry.

2. Remediation phase: The Worklet calls Set-ItemProperty against HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to write InactivityTimeoutSecs to the computed DWORD, wrapped in a try/catch that exits 0 on success and 2 on failure. The script writes a log line confirming the value it set and a second line noting that a system reboot is required for the change to take effect. A subsequent evaluation reads the same key and exits 0 without writing again.

Inactivity lock policy requirements

• Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, or Windows Server 2022

• Automox agent running with SYSTEM privileges (the default agent context), which has write access to HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

• $minutes parameter set in remediation.ps1 to the timeout your baseline requires; CIS 2.3.7.4 calls for 900 seconds or fewer, so values from 1 through 15 are typical

• Same $minutes value mirrored into evaluation.ps1 so the compliance check compares against the same target the remediation writes

• A system reboot after first remediation so Windows reloads the Group Policy System hive; the remediation script logs this requirement explicitly

• No conflicting domain GPO setting the same value to 0; a value of 0 disables the policy and CIS treats it as non-compliant

Expected state after inactivity lock enforcement

After the required reboot, the endpoint locks the desktop automatically once the inactivity timer reaches the configured threshold. The Windows lock screen appears, and the user must re-authenticate with password, PIN, smart card, or Windows Hello before the session resumes. The behavior applies to every account on the endpoint, including local administrators and service accounts, because the setting lives under the machine policy hive rather than per-user preferences.

Verify the value directly with PowerShell: Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name InactivityTimeoutSecs should return 900 (or whatever DWORD the policy wrote). For Group Policy reporting, run gpresult /h gp.html and inspect the Security Options section for Interactive logon: Machine inactivity limit. The value also surfaces under secpol.msc and in any CIS-CAT or Microsoft Security Compliance Toolkit scan run after the next reboot.

The setting persists across reboots, profile rebuilds, and Windows feature updates because it lives in the policy registry hive. A user cannot override it from Control Panel, Settings, or the personalization screens, and a non-administrator cannot delete the value. If a domain GPO later writes the same value, Windows treats the most restrictive setting as authoritative. If an administrator clears InactivityTimeoutSecs to troubleshoot the lock screen, the next Worklet evaluation rewrites the baseline and restores compliance without manual cleanup.