NTLM signing security improvements in Windows

Applies To
Windows 11 version 26H2, all editions Windows 11 version 26H1, all editions Windows 11 version 25H2, all editions Windows 11 version 24H2, all editions Windows 11 version 23H2, all editions Windows 10 Enterprise LTSC 2021 Windows Server 2025, all editions Windows Server 2022, all editions Windows Server 2019, all editions Windows Server 2016, all editions

Original publish date: November 10, 2026
KB ID: 5135557

Summary

Windows updates released on and after November 10, 2026, contain additional protections that address CVE-2026-118737. These updates represent the first phase of improvements to NTLM message signing. These changes help ensure that authenticated NTLM sessions always establish a cryptographic session key and negotiate real message signing, reducing exposure to relay attacks.

Timeline

  • Phase 1 (November 10, 2026): Windows client devices begin offering NTLM signing on all connections by default. Servers accept both signed and unsigned clients. Auditing events identify clients not using signing.

  • Phase 2 (May 2027): Windows servers begin requiring NTLM signing by default. Clients that do not offer signing will be rejected by secure servers.

Note

All supported Windows Server versions are capable of NTLM signing. This rollout simply helps ensure that signing is negotiated and eventually required by default.

Background

NTLM supports two signing modes.

Mode Flag Protection
NTLMSSP_NEGOTIATE_SIGN 0x00000010 Real HMAC-MD5 signing. Session key established. Cannot be forged.
NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0x00008000 Legacy 16-byte zero placeholder. No cryptographic protection.

Prior to this change, applications that did not request ISC_REQ_INTEGRITY or ISC_REQ_RELAY_DETECT or ISC_REQ_SEQUENCE_DETECT (Context Requirements - Win32 apps) received contexts using the ALWAYS_SIGN placeholder. All supported Windows servers already support signing. This change helps ensure that it is used consistently.

NTLM auditing: How do I know if NTLM is using SIGN?

  1. Start by reviewing the negotiated flags for every NTLM authentication. They appear under Event ID: 4023 (server-side) and Event ID: 4022 (client-side) in Microsoft-Windows-NTLM/Operational.

    Note that these events are available on Windows Server 2019 and later with the NTLM Enhanced auditing.

    GOOD — Event 4023: Signing Negotiated
    (Phase 2-ready)    		 ⚠️ BAD — Event 4023: Signing Absent
    (Will be rejected in Phase 2)
    Level: Warning
    A remote client is using NTLM to authenticate to this workstation.

    Process Information:
    Process Name: svchost

    Remote Client Information:
    Username: Administrator
    Domain: corp.contoso.com
    Client Machine: WORKSTATION-01
    Client IP: 10.1.2.100

    NTLM Security:
    Negotiated Flags: 0xE0888215
    NTLM Version: NTLMv2
    Session Key Status: Present
    Channel Binding: Supported    		 Level: Warning
    A remote client is using NTLM to authenticate to this workstation.

    Process Information:
    Process Name: svchost

    Remote Client Information:
    Username: Administrator
    Domain: corp.contoso.com
    Client Machine: WORKSTATION-01
    Client IP: 10.1.2.100

    NTLM Security:
    Negotiated Flags: 0xA0888205
    NTLM Version: NTLMv2
    Session Key Status: Missing
    Channel Binding: Not Supported

  2. Look for the key difference in Session Key Status: Present and Negotiated Flags containing bit 0x10 (SIGN) and 0x40000000 (KEY_EXCH). A connection is secure when both bits are set. See MS-NLMP NegotiateFlags for full flag definitions.

  3. Decode negotiated flags using the following table.

    Bit value Flag name Meaning
    0x00000010 NTLMSSP_NEGOTIATE_SIGN ✅ Real signing negotiated. Session key present.
    0x40000000 NTLMSSP_NEGOTIATE_KEY_EXCH ✅ Session key exchanged. Required for SIGN.
    0x00008000 NTLMSSP_NEGOTIATE_ALWAYS_SIGN ⚠️ No protection if SIGN is absent.

  4. Diagnose your connection as:

    • Phase 2-ready: 0xE0888215 — contains 0x10 + 0x40000000 + Session Key: Present

    • Needs attention: 0xA0888205 — no 0x10 (SIGN) bit, Session Key: Missing

Find clients not sending SIGN

Do not filter by event level alone — both signed and unsigned connections appear at the same Warning level. Check the SIGN bit directly.

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -ErrorAction SilentlyContinue |
  Where-Object { $_.Id -in @(4022, 4023) } |
  ForEach-Object {
    $flags   = if ($_.Message -match "Negotiated Flags:\s+(0x[0-9A-Fa-f]+)") { $Matches[1] } else { "?" }
    $flagVal = if ($flags -ne "?") { [long]$flags } else { 0L }
    if (-not ($flagVal -band 0x10)) {   # NTLMSSP_NEGOTIATE_SIGN bit absent
        [PSCustomObject]@{
            Time       = $_.TimeCreated
            Id         = $_.Id
            ClientIP   = if ($_.Message -match "Client IP:\s+(\S+)")          { $Matches[1] } else { "-" }
            ClientHost = if ($_.Message -match "Client Machine:\s+(\S+)")     { $Matches[1] } else { "-" }
            User       = if ($_.Message -match "Username:\s+(\S+)")           { $Matches[1] } else { "-" }
            Flags      = $flags
            KeyStatus  = if ($_.Message -match "Session Key Status:\s+(\S+)") { $Matches[1] } else { "-" }
            Process    = if ($_.Message -match "Process Name:\s+(.+)")        { $Matches[1].Trim() } else { "-" }
        }
    }
  } | Sort-Object ClientIP -Unique | Format-Table -AutoSize

Registry keys introduced by the November 10, 2026 Windows updates

ClientAllowUnsignedNtlm

Item Details
Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Value name ClientAllowUnsignedNtlm
Type REG_DWORD
Value 0 (default) - Client offers SIGN on all non-anonymous connections.
1 - Client does NOT offer SIGN. Use only for temporary compatibility.

ServerRequireNtlmSign

Item Details
Path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Value name ServerRequireNtlmSign
Type REG_DWORD
Value 0 (default) - Server accepts both signed and unsigned clients for secure connections.
1 - Server rejects unsigned clients. Recommended once auditing confirms readiness.
Note No restart required. Enable ServerRequireNtlmSign=1 once sufficient Event ID: 4023 auditing shows no unsigned connections.

Frequently asked questions (FAQ)

Will this change affect Kerberos?

    No. These changes apply only to NTLM authentication.

Will anonymous (null session) connections continue to work?

    Yes. Anonymous connections (ISC_REQ_NULL_SESSION) are explicitly exempt. They have no session key by design. Both Phase 1 and Phase 2 exempt anonymous connections.

Will guest account connections continue to work?

    Yes. Guest account connection is also exempt. Like anonymous connections, it carries no real session key and no meaningful privilege. There is no security value in requiring signing for guest sessions.

What if a client connects to an older server that does not support SIGN?

    If the server does not echo SIGN back in its Challenge, the client automatically removes SIGN from the session and falls back to legacy ALWAYS_SIGN behavior. No connection failure. All Windows servers echo SIGN by default.

What error will rejected clients see in Phase 2?

    SEC_E_UNSUPPORTED_FUNCTION (0x80090302). The server logs Warning Event 4023 with this status code.

How do I know if my environment is ready for Phase 2?

    Run the PowerShell script included in this article. If no results appear (no unsigned connections), you are ready. Proactively set ServerRequireNtlmSign=1 to enforce it early.

Will the registry keys be removed in the future?     Microsoft might remove the registry keys at a future date and will update this documentation with further information.

Additional resources