Can a Windows app block Win+L?

No. Win+L is processed by the Windows kernel before any user-mode application receives the keypress. Group Policy can disable it for all users, but no app can intercept it at runtime.

Can a Windows app block Ctrl+Alt+Del?

No. Ctrl+Alt+Del is the Secure Attention Sequence — its entire design purpose is to be uninterceptable by software so users always reach a trusted screen.

Does that mean third-party lock apps are useless?

No. They handle a different problem: stepping away briefly without ending your session, or locking specific monitors. Pairing them with the Windows lock provides layered security: an attacker would need both passwords to access the locked screens.

← All articles Explainer · ~6 min read

Why No App Can Block Win+L on Windows (and Why That's a Feature)

Sooner or later, every developer of a Windows screen-lock tool — and every person who tries one — asks the same question: can I block Win+L? The honest answer is no. Not from user mode, not with admin rights, not on Windows 11 Home, Pro, Enterprise, or Server. And the second question that usually follows — can I block Ctrl+Alt+Del? — has the same answer for stronger reasons.

This article explains why, what it means for screen-lock tools, and how to design a workflow that's actually private despite those two un-blockable shortcuts.

How Windows handles those keys

Win+L is intercepted by the kernel

When you press a key on Windows, the event flows through a chain: keyboard hardware → driver → kernel → Win32 input thread → application. Most key combinations can be captured anywhere in that chain. Win+L is different. It's recognized by Win32k.sys (the kernel-side component handling input and the desktop), and the lock action is performed before the keypress ever surfaces to user-mode apps.

That means a keyboard hook installed by a regular app — even one running as Administrator — never sees the L portion of the combo while Win is held. There's nothing to swallow.

Ctrl+Alt+Del is even more protected

Ctrl+Alt+Del is the Secure Attention Sequence (SAS). It's a security feature that's been baked into Windows since NT 3.1. The whole point is that pressing it always takes you to a screen owned by Winlogon — not by any app running in the current session — so a fake login or fake lock screen can't trick you into typing your password.

If any app could intercept SAS, the trust model collapses: malware could spoof a plausible-looking login screen and harvest credentials. So Windows guarantees, by design, that user-mode software can never see those three keys come in together.

What about Group Policy and the registry?

You can disable Win+L for all users via Group Policy (Computer Configuration → Administrative Templates → System → Ctrl+Alt+Del Options → Remove Lock Computer) or by setting DisableLockWorkstation in the registry. That's not the same as a per-app block — it removes the ability entirely. Most people don't actually want that. And neither setting touches the SAS.

What this means for screen-lock tools

Every third-party Windows lock app — ScreenBlind, commercial tools, open-source ones — has the same limitation. None of them can intercept those two shortcuts. If any product claims it can, they're either using a kernel driver (in which case it requires WHQL signing and a lot of trust), or the claim isn't accurate.

So if blocking Win+L is what you came here looking for, the actual question to ask is: what problem are you trying to solve?

Two different problems, two different tools

If you want to keep your unattended PC secure

Use the Windows lock screen. Win+L, short idle timeout, full disk encryption (BitLocker), strong password or Windows Hello. That's the threat model Microsoft engineered for, and it's the right tool for "I'm leaving for an hour."

If you want to hide specific monitors while staying signed in

Use a selective screen-lock tool. The use case is different: a presentation that needs to keep running, a livestream that should stay live, a dashboard that should keep displaying, while your private monitors get covered up. The Windows lock can't do this — it's all-or-nothing. A user-mode overlay on top of selected monitors can.

The layered model: how the two combine

Pairing a selective screen-lock with the Windows lock gives you something neither provides alone: a layered system where the worst-case path is harder, not easier.

Consider what happens if someone walks up to your desk and tries the obvious things:

They press Win+L: they get the Windows lock screen. To get back to your desktop they need your Windows password. Once they're in, the third-party overlay is still up — they also need the screen-lock password to see the covered monitors.
They press Ctrl+Alt+Del: they reach the Windows security screen. Same chain — Windows password, then the overlay password.
They click on a locked monitor: the cursor is trapped on that screen, the password prompt appears, wrong password gets shake feedback. They can't slide the mouse to a different display to bypass it.

Two passwords are harder to bypass than one. The shortcuts that "can't be blocked" end up routing attackers through more security, not less.

The honest takeaway

"Block Win+L" is the wrong feature request for almost every real situation. The right feature is "selectively hide screens without ending my session." That's a different problem with a different solution — one that doesn't require fighting the kernel.

If you want to try it: download ScreenBlind. It's free, doesn't install a driver, and won't lie to you about what it can do.