Back learn.microsoft.com

Smb Signing Overview

learn.microsoft.com • November 11, 2026

Access to this page requires authorization. You can try signing in or changing directories .

Access to this page requires authorization. You can try changing directories .

Applies to: ✅ Windows Server 2025 , ✅ Windows Server 2022 , ✅ Windows Server 2019 , ✅ Windows Server 2016 , ✅ Windows 11 , ✅ Windows 10 , ✅ Azure Local 2311.2 and later

This article describes Server Message Block (SMB) 2.x and 3.x signing in Windows and Windows Server. The article also describes SMB signing security considerations and policy settings.

SMB signing means that every SMB message contains a signature generated using a session key and AES. SMB signing adds a signature containing a hash of the entire message in the SMB header. If someone tampers with the message in transit, the data in the tampered message doesn't match the hash in the signature. The hash also includes the identities of the original sender and the intended recipient. Signature mismatches alert users to possible foul play, helping them protect their deployments from relay and spoofing attacks.

SMB signing is a security feature that uses the session key and cipher suite to add a signature to a message going across a connection. SMB2 message integrity manifests on a signed session where signed packets flow from client to server. On a signed session, every signed packet includes a signature that the receiver can validate. Unlike SMB1 signing that uses the MD5 [RFC1321] hashing algorithm, SMB2 uses a better hashing for signing. The security model in MS-SMB2 relies upon authenticating the client-user identity before accessing a on the server. After the user is authenticated, the server can mandate message signing or encryption. The server also controls access to the based on which users, groups, or claims are authorized to have various levels of access.

SMB signing is enabled in all versions of Windows. SMB signing requirements can involve both outbound signing, which covers traffic from the SMB client, and inbound signing, which covers traffic to the server. Windows and Windows Server can require outbound signing only, inbound signing only, both, or neither. If your environment uses non-Microsoft file servers, your system settings can prevent the default settings and connections from taking effect. In this case, you might need to disable the requirement for SMB signing. See Control SMB signing behavior for guidance on how to disable SMB signing.

Security considerations in SMB2 and SMB3

All cryptographic keys used in SMB 2.x and 3.x signing are derived from the session key. The security of SMB 2/3 signing and encryption relies on the session key. If someone changes a message during transmission, the hash doesn't match, and SMB knows that someone tampered with the data. The signature also confirms the sender's and receiver's identities, and prevents relay attacks.

When using SMB signing, you should consider:

Because the session key itself is derived from your password, using a long, complex, nondictionary password enhances SMB signing and encryption.

Using Kerberos instead of NTLMv2 is recommended so that your session key starts strong.

Policy locations for SMB signing

The policies for SMB signing are located in Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options .

Microsoft network client: Digitally sign communications (always) Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters Registry value: RequireSecuritySignature Data Type: REG_DWORD Data: 0 (disable), 1 (enable)

Microsoft network server: Digitally sign communications (always) Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters Registry value: RequireSecuritySignature Data Type: REG_DWORD Data: 0 (disable), 1 (enable)

In these policies always indicates that SMB signing is required.

Understanding "RequireSecuritySignature" and "EnableSecuritySignature"

The EnableSecuritySignature registry setting for SMB2 and later clients and servers is ignored. Therefore, this setting does nothing unless you're using SMB1. SMB 2.02 and later signing is controlled solely by being required or not. This setting is used when either the server or client requires SMB signing. Signing doesn't occur only when both the server and client have signing set to 0 .

In summary SMB is signed when:

Both the SMB client and server have RequireSecuritySignature set to 1 .

The SMB client has RequireSecuritySignature set to 1 and the server has RequireSecuritySignature set to 0 .

The SMB server has RequireSecuritySignature set to 1 and the client has RequireSecuritySignature set to 0 .

Signing isn't used when:

The SMB client and server have RequireSecuritySignature set to 0 .

SMB signing and encryption auditing

Starting with Windows 11, version 24H2, administrators can enable auditing for the SMB client to detect third-party clients or servers that don't support SMB encryption or signing. If a third-party device or software claims to support SMB 3.1.1, but doesn't support SMB signing, it violates the SMB 3.1.1 pre-authentication integrity protocol requirement.

Adjusting the SMB signing and encryption auditing settings can be modified in Group Policy or through PowerShell. These settings for Group Policy are stored in the paths:

Computer Configuration\Administrative Templates\Network\Lanman Server\Audit client does not support encryption

Computer Configuration\Administrative Templates\Network\Lanman Server\Audit client does not support signing

Computer Configuration\Administrative Templates\Network\Lanman Workstation\Audit server does not support encryption

Computer Configuration\Administrative Templates\Network\Lanman Workstation\Audit server does not support signing

For PowerShell, running the following commands enables auditing the same settings:

The Event Viewer captures these events under the following paths with their respective Event IDs:

The following articles provide additional information SMB:

Control SMB signing behavior

Overview of File Sharing using the SMB 3 protocol in Windows Server

SMB security enhancements

Configure SMB Signing with Confidence

Was this page helpful?

Need help with this topic?

Want to try using Ask Learn to clarify or guide you through this topic?

Last updated on 2024-10-25

The full story

This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.

Microsoft Patches Outlook Zero-Day Exploit in November 2026 Update On November 10, 2026, Microsoft released its Patch Tuesday updates, addressing 1,093 vulnerabilities, including the actively exploited Outlook zero-day, CVE-2026-124194. This spoofing vulnerability allows an attacker to obtain a user's NTLMv2 hash by tricking them into opening a malicious file. The flaw affects Microsoft 365 Apps for Enterprise and Office LTSC versions 2021 and 2024. Microsoft rated the vulnerability as moderate, with a CVSS score of 6.5, and it was discovered by researchers using Anthropic's Claude AI model. CISA has added this vulnerability to its Known Exploited Vulnerabilities catalog, urging federal agencies to patch by November 24. The update also included 63 critical vulnerabilities, with a significant number related to remote code execution and privilege escalation. This month’s patch release follows a record 1,413 vulnerabilities patched in October 2026, indicating a growing trend in vulnerability disclosures. 17 sources 73

Smb Signing Overview

The full story

Extracted Entities

Companies (1)

Platforms (2)