Skip to content

[Bug] Windows Security Update KB5087539 bypasses 2FA prompt on RDP reconnect/unlock (NLA enabled) #137

@anyagixx

Description

@anyagixx

Description:

Describe the bug
After installing the recent Windows Security Update KB5087539 (released around May 2026), the multiOTP Credential Provider fails to trigger the 2FA prompt when reconnecting to a disconnected RDP session (Unlock scenario). This happens when Network Level Authentication (NLA) is enabled.

During the initial Logon, the 2FA prompt works perfectly. However, upon reconnecting to an active/disconnected session, Windows bypasses the custom Credential Provider entirely.

To Reproduce
Steps to reproduce the behavior:

Install multiOTP Credential Provider 5.10.2.2 on Windows Server.

Ensure NLA (Network Level Authentication) is enabled via GPO.

Install Windows Security Update KB5087539.

Connect to the server via RDP (using standard MSTSC or Remmina).

The first login works correctly (multiOTP asks for the 2FA code).

Disconnect the session (close the window without logging off).

Reconnect to the same server.

Error: The system bypasses the 2FA screen. It either logs the user right into the desktop (if credentials are saved/passed via NLA) or only displays the default Windows password prompt.

Expected behavior
The multiOTP Credential Provider should intercept the session unlock process and prompt for the 2FA code, exactly as it did before the Windows update.

Environment:

OS: Windows Server (with KB5087539 applied)

multiOTP Version: 5.10.2.2

RDP Clients tested: MSTSC (Windows 10), Remmina (Ubuntu)

Additional context & Troubleshooting:

We tested connecting with Thincast RDP client (which seems to fall back to standard RDP Security Layer instead of NLA) and the 2FA prompt worked correctly on reconnect.

Disabling NLA on the server restores the expected multiOTP behavior, but this is not an acceptable security workaround for our infrastructure.

Root cause confirmed: Uninstalling KB5087539 completely resolves the issue and restores normal CP behavior during session unlocks with NLA enabled. It appears Microsoft has changed how CredSSP or winlogon handles third-party Credential Providers during unlock events.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions