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, and the secure attention sequence.

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).

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