Require SMB signing only after proving every client and server path

Bottom line: SMB signing adds a cryptographic signature to SMB messages so peers can detect modification and authenticate message origin within the session. Requiring signing is a connection-compatibility change. Measure clients, servers, dialects, names, authentication, and throughput before enforcement.

Source fact: what Microsoft documents

Microsoft’s SMB signing overview explains that SMB signing helps protect message integrity and resist relay attacks. Microsoft documents signing behavior for SMB client and server roles, policy and PowerShell management, and Windows-version-specific defaults.

The documentation distinguishes enabling support from requiring signing and explains that a session is signed when either side requires it. Microsoft also connects strong session keys to authentication choice and warns against access patterns that fall back from Kerberos, such as using an IP address or an incorrectly handled alias. Newer Windows releases include newer signing algorithms and changed defaults, while third-party SMB implementations may have different support. Signing can have a performance cost, especially on older hardware and workloads.

What the source does not establish

Signing does not encrypt file contents, protect data at rest, decide who should access a share, or eliminate all credential attacks. A server setting does not prove every established connection negotiated signing. A successful Windows-to-Windows test does not prove an appliance, scanner, camera export, NAS, backup product, or embedded system will work. Requiring signing also does not force Kerberos if the naming and identity path still cause NTLM.

Applicability questions

• Which clients and servers initiate or accept SMB, including appliances and application service accounts?
• What SMB dialect, signing state, authentication protocol, server name, and alias does each path negotiate?
• Are IP-address paths, DNS CNAMEs, DFS namespaces, clustering, scanning, backup, or legacy devices involved?
• What throughput and latency are required, and does signing affect the workload on deployed hardware?
• Which Windows defaults already apply by edition and version?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Inventory SMB clients, servers, shares, application owners, dialects, signing state, and authentication on production-like traffic.
2. Fix name and service-principal dependencies that prevent Kerberos where Kerberos is expected. Do not hide them by lowering signing requirements.
3. Test signing-required client and server behavior separately with every critical application and non-Windows implementation.
4. Benchmark representative file sizes, concurrency, backup, Hyper-V, and high-throughput paths.
5. Enforce through rings, monitor failures and performance, and give every temporary exception an owner and retirement plan.

Verification and evidence

• Preserve client and server policy, OS/build, appliance firmware, exception register, and approvals.
• Capture negotiated dialect, signed state, authentication protocol, server name, and connection result for each critical path.
• Record baseline and post-change performance under representative load.
• Demonstrate that unsigned test connections fail where enforcement is intended and signed paths continue to function.

Official references

• Overview of Server Message Block signing in Windows — Microsoft