What Is SMB Signing Disabled?
SMB signing disabled usually means that Windows clients, servers, or both do not require signed SMB traffic. On modern Windows systems, the exact control is the RequireSecuritySignature setting on the SMB client and SMB server.
Microsoft's SMB signing documentation is explicit about what the feature does. SMB signing adds a signature to each SMB message using the session key and cipher suite. If an attacker tampers with the message in transit, the signature no longer matches. Microsoft also states that SMB signing helps protect against relay and spoofing attacks.
That is why the security problem is not just "unsigned file sharing." When SMB signing is not required on paths where it should be, the environment is more exposed to adversary-in-the-middle interception and NTLM relay opportunities.
For this article, the scope is Windows SMB 2.x and 3.x in Active Directory environments, with emphasis on relay exposure, verification, and practical hardening. The point is not to claim that SMB signing alone solves every relay path. The point is that disabling or not requiring it removes one of the protocol-level protections Microsoft built specifically to stop tampering and relay on SMB traffic.
How SMB Signing Works
Microsoft describes SMB signing as a security feature that uses the session key and cipher suite to add a signature to a message flowing across the SMB connection. The signature contains a hash of the full message in the SMB header. If anyone changes the message in transit, the signature check fails.
For SMB 2.x and 3.x, signing is controlled by whether it is required, not by the old SMB1-era EnableSecuritySignature logic. Microsoft states that for SMB 2.02 and later, EnableSecuritySignature is ignored and signing is controlled solely by whether it is required.
That distinction matters because teams often think SMB signing is enabled if a legacy setting exists somewhere in policy, even when the effective requirement is still off.
When SMB signing is actually used
Microsoft summarizes the behavior clearly:
- signing is used when the SMB client requires it
- signing is used when the SMB server requires it
- signing is not used only when both the SMB client and SMB server do not require it
That means the vulnerable state is broader than one badly configured file server. If neither side requires signing, the session can proceed unsigned.
Why SMB signing matters in AD environments
SMB is not only a file-sharing protocol. Active Directory environments rely on it for common workflows such as SYSVOL and NETLOGON access, administrative shares, and operational file access between endpoints and servers.
Microsoft explicitly notes that domain controllers require SMB signing by default for connections to them, especially around SYSVOL and NETLOGON. That default exists for a reason: unsigned SMB traffic in identity infrastructure is far easier to tamper with or relay.
SMB Signing Disabled vs. SMB Signing Not Required
In practice, teams often use these labels interchangeably, but the technical nuance matters.
- Disabled usually means the administrator explicitly set
RequireSecuritySignaturetoFalseon the client, server, or both. - Not required means the endpoint can still sign if the other side demands it, but it will also accept an unsigned session when no side requires signing.
From a risk perspective, both states can create the same operational problem: SMB sessions that are allowed to proceed without signing.
This is why many audits collapse them into one finding. The real question is not whether a checkbox says "enabled." The real question is whether the client or server will refuse unsigned SMB.
Why SMB Signing Disabled Still Matters
This control still matters because Microsoft continues to describe SMB signing as a defense against message tampering, spoofing, and relay, and because many relay paths still depend on getting a server to accept traffic without this protection.
Unsigned SMB gives adversaries a weaker protocol path
If a client and server can negotiate an unsigned session, an attacker on the network has more room to interfere with traffic or relay authentication material to another host.
NTLM still exists in real environments
Even in organizations pushing toward Kerberos and stronger protocols, Microsoft continues to document NTLM blocking on SMB as a separate hardening step for Windows 11 24H2 and Windows Server 2025. That is a strong signal that the protocol downgrade and legacy authentication problem is still operationally relevant.
Third-party devices and guest-style access often weaken the path
Microsoft's SMB signing guidance is direct here: if a third-party SMB server does not support signing, some teams disable signing on Windows just to restore compatibility. Microsoft explicitly warns against using that as a workaround because it means trusting guest-style or unsigned access to a remote share.
Preconditions for a Real SMB Signing Exposure
An SMB_SIGNING_DISABLED finding becomes materially important when the following conditions overlap.
1. Neither side requires signing on a relevant path
The core exposure is that the SMB client and SMB server can both proceed without requiring signatures.
2. NTLM is still available on the path
Microsoft's SMB guidance repeatedly recommends Kerberos over NTLMv2 and advises against using IP addresses or CNAME records because those patterns tend to drive authentication away from Kerberos and toward NTLM. That matters because unsigned SMB plus NTLM-oriented access paths is a classic relay-enabling combination.
3. The attacker can sit on or influence the path
Relay and interception attacks are not remote magic. The attacker must be able to coerce or position traffic through a system they control, or otherwise abuse a path where they can relay credentials.
4. Administrative or high-value shares are reachable
A relay against a harmless share is one problem. A relay against a management server, administrative share, or sensitive file service is a different one. If those systems are also reachable through weak operational hygiene, the blast radius grows. That is one reason to review Stale Privileged Accounts: Hidden Risk in Active Directory alongside relay-facing network settings.
5. The environment still contains legacy clients, devices, or guest workflows
Operational pressure to support old NAS devices, appliances, scanners, or guest-like access patterns is one of the main reasons signing ends up not required in the first place.
The Attack Chain
A practical attack path involving disabled SMB signing often looks like this.
Step 1 - Find an unsigned SMB path
The attacker identifies a server or client pair where neither side requires SMB signing.
Step 2 - Coerce or intercept authentication
The attacker causes a target system or user to authenticate over SMB on a path they can observe or influence.
Step 3 - Relay the authentication attempt
If the broader conditions permit it, the attacker relays the authentication attempt to another SMB service or another protocol endpoint that accepts the relayed identity.
Step 4 - Use the resulting access immediately
Relay is useful because the attacker does not need to crack the password first. If the relay succeeds, they can act with the victim's access in real time.
That is why this finding belongs next to NTLM Relay Attacks: Hijacking Authentication in AD. Disabled SMB signing is not the whole relay story, but it is one of the clearest ways to make SMB relay easier than it should be.
Detection
Detection for this issue has two parts: configuration detection and operational detection.
Configuration detection
The most direct validation method is to check whether the SMB client or SMB server actually requires signing.
Microsoft documents the exact PowerShell checks:
Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignature
If the value is False, signing is not required on that side.
From Group Policy, Microsoft places the relevant settings under:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security OptionsMicrosoft network client: Digitally sign communications (always)Microsoft network server: Digitally sign communications (always)
This is the fastest way to turn a vague audit statement into a concrete yes or no.
Audit compatibility before enforcing
One practical improvement in newer Windows releases is SMB signing and encryption auditing. Microsoft documents the following audit controls:
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $trueSet-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
The related events are logged in:
Microsoft-Windows-SMBClient/Auditwith event IDs31998and31999Microsoft-Windows-SMBServer/Auditwith event IDs3021and3022
Those events are especially useful when you want to make signing mandatory but first need to discover which third-party systems will break.
Operational detection
If you suspect actual abuse rather than only weak configuration, correlate:
- hosts where signing is not required
- NTLM-heavy SMB traffic patterns
- relay-style activity uncovered in Active Directory Monitoring: Security Event IDs That Matter
- unexpected access to administrative shares or sensitive file services
- systems using IP-based SMB access or non-Kerberos naming patterns
There is no single Windows event that says "NTLM relay succeeded because SMB signing was disabled." The better model is to identify the unsigned path first, then correlate surrounding authentication and access activity.
Remediation
The primary remediation is straightforward: require SMB signing where it is supposed to be required, then reduce the adjacent protocol behaviors that keep relay viable.
1. Require SMB signing on both sides where possible
Microsoft documents the exact PowerShell commands:
Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true
At the policy level, the relevant settings are:
Microsoft network client: Digitally sign communications (always)Microsoft network server: Digitally sign communications (always)
If you control both the Windows clients and Windows file servers, this is the cleanest baseline.
2. Do not treat third-party incompatibility as a reason to normalize weak SMB
Microsoft explicitly cautions against disabling SMB signing as a workaround for third-party servers and against trying to use signing with guest accounts. If a third-party appliance does not support signing correctly, document it as technical debt or isolate it. Do not quietly lower the Windows baseline for everything else.
3. Prefer Kerberos and avoid patterns that push you into NTLM
Microsoft recommends:
- using Kerberos instead of NTLMv2
- not connecting to shares by IP address
- not using CNAME records for SMB access where they force NTLM behavior
Those are not cosmetic details. They directly reduce the chance that an unsigned or weakly protected path becomes a practical NTLM relay path. Password hygiene and protocol hygiene still matter around the same attack surface, which is why Active Directory Password Security: Misconfigurations That Matter is part of the same review.
4. Use newer SMB hardening features where your platform supports them
Microsoft now ships stronger defaults and adjacent protections on current releases:
- Windows 11 24H2 Enterprise, Pro, and Education require both inbound and outbound SMB signing
- Windows Server 2025 requires outbound SMB signing by default
- Windows 11 24H2 and Windows Server 2025 add SMB signing audit controls
- Windows 11 24H2 and Windows Server 2025 add SMB NTLM blocking on the client side
That means remediation is not only about toggling one old policy. On newer platforms, you can use auditing and NTLM reduction to make the environment safer without guessing which dependency will fail.
5. Review guest access and legacy NAS dependencies separately
Microsoft states that requiring SMB signing also disables guest access to shares. If your business still depends on guest-style SMB access, that is a design exception that should be isolated and reviewed, not silently folded into the normal estate.
6. Review local admin sprawl on the same systems
Unsigned SMB on workstations and member servers is more dangerous when the same hosts also share local admin credential problems. If you are hardening the estate, review Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter on the same set of systems.
7. Pair signing with relay-focused reviews
If SMB signing is disabled, also review the adjacent findings that make relay easier:
- NTLM Relay Attacks: Hijacking Authentication in AD
- How to Audit Active Directory Security: Practical Checklist for Internal Teams
- Active Directory Monitoring: Security Event IDs That Matter
If you are choosing how to operationalize those checks across the estate, Active Directory Security Audit Tools: What to Compare Before You Choose is also relevant.
The control is strongest when you treat it as part of a relay-reduction program, not as an isolated registry value.
Validation After Hardening
After changing policy, validate the result directly.
- run
Get-SmbClientConfigurationandGet-SmbServerConfigurationto confirmRequireSecuritySignatureisTrue - confirm the effective Group Policy settings match the intended baseline
- enable signing audit events first if you expect third-party compatibility issues
- identify devices or software that do not support signing before forcing the requirement broadly
- test whether old guest or unsigned workflows still exist and whether they should be retired instead of preserved
- review whether IP-based share access, CNAME usage, or NTLM-heavy SMB paths are still present
- include the control in the broader review described in How to Audit Active Directory Security: Practical Checklist for Internal Teams
The real success condition is not a policy screenshot. It is that clients and servers no longer accept unsigned SMB where relay exposure matters.
How EtcSec Detects Related Exposure
EtcSec can model this issue directly because SMB_SIGNING_DISABLED is a concrete network hardening finding, not only a broad best-practice recommendation.
In practice, the most useful related catalogue links are:
- direct
SMB_SIGNING_DISABLEDfindings on systems that still allow unsigned SMB NTLM_RELAY_OPPORTUNITYfindings where relay prerequisites remain in place- surrounding AD monitoring and hardening checks that explain whether the issue is isolated or part of a broader relay-friendly environment
That is why this topic belongs with NTLM Relay Attacks: Hijacking Authentication in AD and How to Audit Active Directory Security: Practical Checklist for Internal Teams, not only with generic file-server guidance.
Related Controls
If you are reviewing disabled SMB signing, also review NTLM Relay Attacks: Hijacking Authentication in AD, Active Directory Monitoring: Security Event IDs That Matter, How to Audit Active Directory Security: Practical Checklist for Internal Teams, Active Directory Password Security: Misconfigurations That Matter, Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter, Stale Privileged Accounts: Hidden Risk in Active Directory, and Active Directory Security Audit Tools: What to Compare Before You Choose. Those articles cover the surrounding coercion, relay, and monitoring paths that determine whether unsigned SMB is merely a weak setting or a practical attack path.