Set Account Lockout for Windows

What the account lockout enforcer does

This Automox Worklet™ enforces an account lockout policy on Windows endpoints so that a fixed number of failed sign-in attempts triggers a temporary lock on the account. The Worklet writes three Local Security Policy values: the lockout threshold (failed attempts before lock), the lockout duration (how long the account stays locked), and the lockout observation window (how long failed attempts are remembered before the counter resets).

The Worklet uses the built-in Windows Security Configuration Editor, secedit.exe, to write each value in turn. For each setting, the remediation script exports the current security policy to c:\secpol.cfg, replaces the target key name with the key-value pair using PowerShell's string replace method, and applies the result with secedit /configure /db c:\windows\security\local.sdb /cfg c:\secpol.cfg /areas SECURITYPOLICY. The temporary file is deleted after each pass. Default values are LockoutBadCount = 10, LockoutDuration = 15, and ResetLockoutCount = 15. Adjust the inline variable assignments in the remediation script before deploying if your security baseline calls for stricter values.

The evaluation script always exits non-zero, which flags every endpoint for remediation on every policy run. This is intentional: the Worklet is designed to enforce the values on each execution rather than perform a conditional check. If you want conditional behavior, the remediation script variables ($lockreset, $lockduration, $lockbadcnt) can serve as the comparison baseline for a custom evaluation script.

Why enforce account lockout on Windows endpoints

Brute force and password-spray attacks against Windows endpoints are cheap to run and rarely produce telemetry until they succeed. Without a lockout policy in place, an attacker with network reach to a workstation or RDP-exposed server can try many passwords against the local Administrator account or a known domain user. Enforcing a lockout threshold limits the number of failed attempts an attacker can make before the account is temporarily locked, which significantly slows automated credential attacks. CIS Microsoft Windows Benchmark control 1.2.x and NIST 800-53 AC-7 both require this control.

Account lockout is easy to set once and lose silently. A build script re-applies a default configuration during sysprep, a re-imaged workstation rolls back to factory defaults, or an old GPO that someone forgot to retire flips the threshold back to 0. Applying the LockoutBadCount, LockoutDuration, and ResetLockoutCount values through a recurring Automox policy re-pins the values on the next run whenever a hardening baseline reset or feature update reverts them.

How Windows account lockout enforcement works

1. Evaluation phase: The evaluation script exits non-zero unconditionally, flagging every endpoint in scope for remediation on each policy run. There is no conditional check against current values; the Worklet is designed to enforce the configured settings on every execution.

2. Remediation phase: The remediation script applies the three lockout values in sequence. For each value, secedit exports the current policy to c:\secpol.cfg, a PowerShell string replace updates the target line, and secedit /configure writes the result back to the local security database. The temporary file is removed after each of the three passes. The script sets ResetLockoutCount to 15 minutes, LockoutDuration to 15 minutes, and LockoutBadCount to 10 failed attempts.

Account lockout enforcement requirements

• Windows 10, Windows 11, or Windows Server (any version that includes secedit.exe and net.exe on the system PATH)

• Local Administrator privileges for the Automox agent (the default System-level agent context already meets this)

• PowerShell 5.1 or later

• Write access to c:\ for the temporary secpol.cfg file (required by the hardcoded export path in the remediation script)

• For domain-joined endpoints, no conflicting Group Policy Object pinning Account Lockout Policy to a different value; a higher-precedence domain GPO will overwrite the local change at the next gpupdate

• Optional: adjust the $lockreset, $lockduration, and $lockbadcnt variable assignments in the remediation script before deploying if your baseline requires values other than 15 / 15 / 10

Expected lockout policy state after remediation

After the Worklet completes, the Local Security Policy on the target endpoint reflects a LockoutBadCount of 10 failed attempts, a LockoutDuration of 15 minutes, and a ResetLockoutCount of 15 minutes. These are the values written by the default remediation script. Local and domain accounts that hit the threshold are locked for 15 minutes, and the bad-attempt counter resets after 15 minutes of inactivity.

Validate from an elevated PowerShell session by running net accounts and checking the Lockout threshold, Lockout duration (minutes), and Lockout observation window (minutes) lines. You can also open secpol.msc, expand Security Settings → Account Policies → Account Lockout Policy, and verify the three values. The settings persist across reboots; they are only displaced by a higher-precedence domain GPO or a manual edit, both of which the next policy run will overwrite.