Supported way to detect input or hotkey when Windows session is locked (secure desktop)

Hello @Jordi Parareda , 

Your current understanding is correct. Windows uses a separate desktop for secure sign-in and unlock, as described in the Winlogon documentation, so a normal application or service should not expect to detect a custom key combination after the session is locked. 

If your requirement is related to sign-in or unlock, the supported direction is to use Windows authentication features such as Credential Providers, Windows Hello, or smart cards. 

Microsoft does document supported hardware button designs, including HID - and driver-based approaches. However, I did not find Microsoft documentation that describes a supported general model where a custom hardware trigger is delivered to a normal application while the session remains locked. 

I hope this information helps with your question. If you found my response helpful, you can follow this guide to leave feedback. 

Thank you. 

From the provided information, only the following points can be confirmed:

1. Keyboard input and secure/locked contexts

The Windows platform explicitly protects certain credential and secure interfaces from remote or automated input. After the January 2026 security update (hardening for CVE‑2026‑20824), Windows credential interfaces:

• Restrict remote keystroke injections, remote virtual keyboards, and automated credential submission from remote tools.
• Ignore input (including virtual keyboard inputs) when it comes from non‑trusted contexts.

This confirms the general direction of the platform: security‑sensitive desktops (such as credential UI) are intentionally hardened against injected or automated input. The documentation also states that applications should be updated to avoid keyboard entry into credential interfaces and instead authenticate through supported Windows authentication interfaces.

While the context does not explicitly describe lock‑screen hotkey behavior, it does confirm that:

• Remote or automated keyboard input into secure credential surfaces is blocked.
• The recommended pattern is to use supported Windows authentication interfaces rather than trying to drive those surfaces via keystrokes.

2. Global hotkeys and keyboard APIs

The Win32 keyboard input model and hotkey support are described as follows:

• Applications can register hot keys with RegisterHotKey, which causes the system to post WM_HOTKEY messages to the thread’s message queue when the user presses the defined combination.
• Hot key controls can also be used, which rely on WM_SETHOTKEY and result in WM_SYSCOMMAND with SC_HOTKEY when the hot key is pressed.

These mechanisms are documented for normal interactive sessions and message queues associated with windows created by the application. The context does not state that these APIs work on the lock screen or secure desktop, and it does not provide any supported mechanism to extend them into that state.

3. Assigned access and keyboard filtering

For restricted user experiences (assigned access / kiosk scenarios):

• Certain keyboard shortcuts (Alt+F4, Alt+Tab, Alt+Shift+Tab, Ctrl+Alt+Delete) are explicitly not blocked by assigned access.
• Additional key combinations can be blocked using Keyboard Filter.

This shows that Windows reserves some key combinations for system control and security even in highly restricted shells. However, the context does not provide any API or pattern that would allow an application or service to receive those key combinations when the session is locked or on the secure desktop.

4. HID, mouse, and other input

The HID and mouse documentation in the context describes:

• HID usage tables and scan codes for keyboard keys.
• Mouse ClickLock as an accessibility feature controlled via SystemParametersInfo flags such as SPI_GETMOUSECLICKLOCK and SPI_SETMOUSECLICKLOCK.

These are standard input and accessibility features for interactive sessions. The context does not describe any supported pattern where a background service or driver can receive arbitrary user‑defined triggers (keyboard or HID) while the Windows session is locked or on the secure desktop.

5. Direct answers to the specific questions (within the limits of the context)

1. Supported API/mechanism to detect key combinations while locked

The context describes:

• Standard hotkey mechanisms (RegisterHotKey, hot key controls) for normal sessions.
• Security hardening that blocks remote/automated input into credential interfaces and requires use of supported authentication interfaces instead.

It does not document any supported API, Windows service mechanism, or platform capability that allows an application or service to detect arbitrary user‑defined key combinations while the session is locked or on the secure desktop.

2. Recommended alternatives for triggers when locked

The only explicit recommendation in the context is in the credential‑hardening article:

• Applications should be updated to avoid keyboard entry into credential interfaces and instead authenticate through supported Windows authentication interfaces.

No alternative trigger mechanism (such as a general “lock‑screen hotkey” API) is described. The context does not provide a Microsoft‑recommended architectural pattern for a generic user‑initiated trigger that must work while the session is locked.

3. Supported approaches using HID devices, USB buttons, drivers

The context:

• Documents HID usage tables and standard keyboard/mouse behavior.
• Does not describe any supported approach where a custom HID device, USB button, or driver is used as a general trigger source that an application can reliably receive while the session is locked.

6. Confirmation of current understanding

From the information available:

• Global hotkeys and standard keyboard input mechanisms are documented for normal interactive sessions.
• Security‑sensitive surfaces (credential interfaces) are explicitly hardened against remote/automated input, and the guidance is to use supported authentication interfaces instead of simulating keystrokes.

Within this context, there is no documentation of a supported mechanism to:

• Register a custom hotkey or input trigger that continues to be delivered to an application or service while the user session is locked or on the secure desktop.

So the understanding that normal global hotkeys and keyboard hooks do not function as a general trigger mechanism in secure/locked contexts is consistent with the security‑hardening direction described.

References:

• New behavior restricting certain applications to autofill credentials introduced by the Windows January 2026 security update
• Keyboard Input Overview
• Assigned Access recommendations
• Mouse Input Overview