The Unlocked-Desktop Attack: Auditing Windows Session Lock Hardening

The lock screen is the last line of defense against someone with physical access. Here are the CIS L1 session-lock settings WinSentinel checks - inactivity lock, secure screensaver, hidden last user, the secure attention sequence, and automatic logon.

Every hardening guide talks about credential theft, lateral movement, and patch latency. Almost none of them talk about the oldest attack in the book: someone walks up to a desk, finds the screen unlocked, and does whatever they want as you. No exploit, no malware, no CVE - just an unattended session and thirty seconds. In an open-plan office, a coffee shop, or a shared lab, the lock screen is the entire perimeter.

Windows has a full set of policies to close this gap, and CIS Windows Benchmark Level 1 requires most of them. They are all single-machine registry settings, which is why WinSentinel's new Session Security module audits them for free. Here is what actually matters and why.

1. The machine has to lock itself

People do not lock their screens. They mean to, they forget, they get pulled into a meeting. The only reliable lock is an automatic one. Windows exposes a machine-wide inactivity limit:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    InactivityTimeoutSecs = 900   (DWORD, seconds)

A value of 0 - or the key missing entirely, which is the default - means the machine never auto-locks. CIS L1 wants this set to 900 seconds (15 minutes) or less. WinSentinel flags a missing/zero value and a value that is set but too long, because "we configured it to 8 hours" is not meaningfully different from off.

2. The screensaver is the fallback lock - if it's secure

Before InactivityTimeoutSecs existed, the password-protected screensaver was the lock. It still works, and on many machines it is the only lock configured. But a screensaver only locks the desktop if all three of these are true:

ScreenSaveActive = 1 - a screensaver is enabled at all;
ScreenSaverIsSecure = 1 - resuming from it requires a password;
ScreenSaveTimeOut - a sane timeout (WinSentinel wants ≤ 900s).

These live under HKCU\Control Panel\Desktop. The subtle failure is a screensaver that is active but not secure: it dims the screen and looks like protection, but pressing a key drops you straight back into the session with no password. WinSentinel calls out each of the three failure modes separately so you know exactly which knob is wrong.

3. Don't hand attackers a valid username

By default, the Windows logon screen shows the name of the last person who signed in. That is half of a credential handed to anyone standing in front of the machine - and a starting point for password spraying or a targeted phish. The fix is one policy:

HKLM\...\Policies\System\DontDisplayLastUserName = 1

Set it and the logon screen asks for both username and password. The same idea extends to the locked screen: DontDisplayLockedUserId = 3 ("do not display user information") stops Windows from showing the account name and full name on the lock screen an idle machine sits on all day.

4. Keep Ctrl+Alt+Del required

The Secure Attention Sequence - pressing Ctrl+Alt+Del before signing in - is a genuinely clever piece of security design. No user-mode program can intercept it, so a fake full-screen "logon" window pretending to harvest your password is defeated the moment you hit the key combination: you land on the real, trusted logon UI instead. Disabling it (DisableCAD = 1) removes that guarantee for a marginal convenience win. WinSentinel warns when CAD has been disabled and passes when it is required (0 or absent).

5. Turn off automatic (passwordless) logon

The single worst setting for physical-access risk is one Windows will happily configure for you: automatic logon. It is common on kiosks, lab machines, and "we just wanted it to boot straight to the desktop" home builds. When it is on, the machine powers up and signs a stored account in with no prompt at all - the desktop is unlocked and authenticated before anyone touches the keyboard. Every lock policy above is irrelevant if the machine hands out a live session on boot.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    AutoAdminLogon = 1
    DefaultUserName = "corp\kiosk"
    DefaultPassword = "..."   <- stored in CLEARTEXT

There is a second, quieter problem: to make auto-logon work, Windows stores the account's password in cleartext under DefaultPassword, readable by any local administrator. So the setting both leaves the machine unlocked and leaks the credential. WinSentinel warns whenever AutoAdminLogon = 1, and escalates the message when a cleartext DefaultPassword value is present. The fix disables it and clears the stored secret:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' `
  -Name AutoAdminLogon -Type String -Value '0'
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' `
  -Name DefaultPassword -ErrorAction SilentlyContinue

What WinSentinel reports

Run an audit and the Session Security module emits one finding per check - a green Pass when the setting is already safe, a Warning with the exact registry path and a one-line PowerShell fix when it is not. For example, the "machine never auto-locks" finding ships with:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' `
  -Name InactivityTimeoutSecs -Type DWord -Value 900

Every one of these checks is local, read-only, and free - part of the full-power single-machine tool. They map directly onto CIS Windows L1's Interactive Logon controls, so clearing them moves your compliance score in the right direction too.

Physical-access attacks don't show up in your EDR console, your SIEM, or your vulnerability scanner. They show up as an unlocked laptop in a conference room. The controls that stop them are boring, free, and one winsentinel --audit away.

Install the CLI and see where your session-lock posture stands:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit