Windows - Configuration - Disable Automatic Logon

What the Disable Automatic Logon Worklet does

This Automox Worklet™ disables the Windows automatic logon feature on workstations and servers. Automatic logon lets the operating system sign a user into the desktop at boot without prompting for a password. The lock screen becomes a formality, and physical access turns directly into full session access.

The Worklet inspects the four registry values that control automatic logon under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon: AutoAdminLogon, DefaultUserName, DefaultPassword, and DisableCAD. When any of them indicate that automatic logon is enabled or that Ctrl+Alt+Del has been suppressed, the Worklet remediates. It clears the cleartext credential values, sets AutoAdminLogon to 0, and forces DisableCAD to 0 so the secure attention sequence is required at every sign-in.

Both the evaluation and remediation scripts relaunch themselves through sysnative\WindowsPowerShell\v1.0\powershell.exe so a 32-bit Automox agent on a 64-bit OS still reads the correct Winlogon hive. The Worklet takes no input parameters, which simplifies policy authoring and review.

Why disable automatic logon

Automatic logon stores the target account name in DefaultUserName and the password in cleartext in DefaultPassword. Any local administrator, any process running as SYSTEM, and any attacker with offline access to the SYSTEM hive can read that password directly. Rapid7 tracks the configuration as WINDOWS-AUTOLOGIN-ENABLED, and CIS Microsoft Windows 10 and Windows Server Benchmarks require both AutoAdminLogon disabled and DisableCAD set to 0 as Level 1 controls. NIST 800-53 IA-2 and AC-7 expect interactive authentication on every session.

AutoAdminLogon drifts in three predictable ways: a field-service technician enables auto-logon for a kiosk and forgets to revert it, an imaging template carries the value forward into every clone, and a lab workstation gets re-deployed with the DefaultPassword still in the Winlogon hive. The Worklet asserts the Winlogon baseline continuously on every endpoint in scope, so the next evaluation catches the drift before it becomes a finding on a CIS or NIST report.

How the Winlogon enforcement works

1. Evaluation phase: The Worklet reads the four target values under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon using Get-ItemProperty and a helper Test-RegistryValue function. The endpoint is flagged for remediation if DefaultPassword exists, if DefaultUserName exists, if AutoAdminLogon is anything other than 0, or if DisableCAD is anything other than 0. The script returns 1 on any drift and 0 when all four conditions match policy.

2. Remediation phase: The Worklet calls Remove-ItemProperty against any DefaultPassword and DefaultUserName values it finds, then uses Set-ItemProperty to write AutoAdminLogon=0 and DisableCAD=0. Each write is wrapped in a try/catch so a failure to update a single value exits the script with code 1 and surfaces in the Automox activity log. On success, the script prints Device is compliant. and a follow-up evaluation returns 0.

Winlogon registry requirements

• Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, or Windows Server 2022 (workstation and server SKUs are both in scope)

• Local Administrator or SYSTEM context to write under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

• PowerShell available at %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe (the script invokes the native 64-bit host to read the correct registry view)

• No active automatic logon session on the endpoint at the time of remediation; any user signed in through automatic logon must be ready to re-authenticate after the next reboot

• Exception path for kiosk or lab endpoints that legitimately require auto-logon: scope this Worklet to a policy group that excludes those endpoint tags before deploying fleet-wide

Expected Winlogon state after remediation

Once the Worklet completes, every targeted endpoint requires a user to enter credentials and press Ctrl+Alt+Del at sign-in. The cleartext credential values under Winlogon are gone, and the AutoAdminLogon and DisableCAD values are both set to 0. The next evaluation run exits with code 0, and the Automox console reports the endpoint as compliant for this configuration.

You can confirm the state directly with PowerShell on a sample endpoint:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' |
  Select-Object AutoAdminLogon, DisableCAD, DefaultUserName, DefaultPassword

A compliant endpoint returns AutoAdminLogon=0, DisableCAD=0, and no DefaultUserName or DefaultPassword properties on the key. Pair the Worklet with Set Account Lockout for Windows and Enforce Password Complexity to cover the broader local-authentication baseline. Rerun this Worklet on the same schedule as the rest of your CIS-aligned hardening policies so any drift is caught at the next evaluation window.