Windows - Security - ENABLE SMB Signing

What the SMB signing enabler does

This Automox Worklet™ enables SMB digital signing on Windows endpoints by writing the EnableSecuritySignature DWORD to 1 in both the SMB client and SMB server parameter keys. SMB signing attaches a cryptographic signature to every SMB packet so the receiver can verify the packet has not been altered in transit. The configuration applies to Windows 8 and later workstations and to Windows Server 2012 and later, and the change takes effect without a reboot.

The Worklet writes to two registry paths. The SMB client setting lives at HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, and the SMB server setting lives at HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. Setting EnableSecuritySignature=1 on both keys turns on signing for outbound and inbound SMB sessions from the local endpoint.

Enabling signing is the first half of the SMB hardening sequence. The second half is enforcement, controlled by the RequireSecuritySignature value at the same two keys. RequireSecuritySignature=1 rejects any peer that cannot sign. Roll out EnableSecuritySignature first across the fleet, confirm telemetry, then layer enforcement on top with the ENFORCE SMB Signing Worklet to avoid breaking legacy SMB clients that have not yet been remediated.

Why enable SMB signing fleet-wide

Unsigned SMB connections are the staging ground for NTLM relay and SMB man-in-the-middle attacks. An attacker on the same broadcast domain coerces an SMB authentication via PetitPotam, the printer bug, or a poisoned LLMNR response, and relays the credentials to a third host. The relayed session then authenticates as the victim against shares, ADCS web enrollment, or LDAP. Without signing, the relayed session is indistinguishable from a legitimate one. With signing enabled on both ends, the relayed packets fail signature verification and the attack collapses. SMB signing is also called out explicitly in the CIS Microsoft Windows Server and Windows 10 Benchmarks at controls 2.3.8.x (Microsoft network client) and 2.3.9.x (Microsoft network server), and in NIST 800-53 SC-8 for transmission confidentiality and integrity.

SMB signing is exactly the kind of registry-key control that drifts silently: a Sysprep image refresh resets LanmanServer\Parameters, a troubleshooting session disables RequireSecuritySignature for a vendor share, or a legacy GPO overrides the hardened value. A weekly Automox policy run against your Windows workstation and server groups re-applies the SMB relay mitigation, so SMB signing holds without manual verification against each LanmanServer registry path.

How SMB signing enablement works

1. Evaluation phase: The Worklet enumerates the two parameter keys at HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters and HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters and reads EnableSecuritySignature with Get-ItemPropertyValue. If either value is missing or not equal to 1, the script writes a non-compliance message to stdout and exits 1, which queues remediation. If both values already equal 1, the script exits 0 and the endpoint reports compliant.

2. Remediation phase: The Worklet walks the same two keys. For each missing property, it calls New-ItemProperty to create EnableSecuritySignature as a REG_DWORD with value 1. For each present-but-incorrect property, it calls Set-ItemProperty to overwrite the value to 1. The script logs the path it touched and the value it wrote to stdout, which surfaces in Automox activity logs. It exits 0 on success. No reboot is required; the SMB client and SMB server services pick up the new signing capability on the next session negotiation.

SMB signing requirements and prerequisites

• Windows 8, Windows 10, or Windows 11 on workstations; Windows Server 2012, 2016, 2019, or 2022 on servers

• Local administrator rights to write under HKLM:\SYSTEM\CurrentControlSet\Services (the Automox agent runs as SYSTEM and meets this by default)

• PowerShell 5.1 or later, included with every supported Windows version by default

• No reboot is needed; the SMB redirector and SMB server pick up the new EnableSecuritySignature value on the next SMB session

• Plan an enforcement follow-up: this Worklet only enables signing capability. Pair it with the ENFORCE SMB Signing Worklet (RequireSecuritySignature=1) once the fleet baseline holds

• Compatible with both domain-joined endpoints and standalone workgroup endpoints; group policy from a domain controller can override the registry value, so review SMB-related GPOs before deploying at scale

Expected state after SMB signing is enabled

After remediation, EnableSecuritySignature equals 1 at both HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters and HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. The endpoint will sign SMB packets when negotiating with any peer that also supports signing, which covers every modern Windows client and most third-party SMB stacks. Sessions to peers that do not support signing still complete, because RequireSecuritySignature is not yet in play. Verify the registry state from PowerShell with Get-ItemPropertyValue -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters' -Name EnableSecuritySignature and the matching LanmanServer path.

To confirm signing on live connections rather than just configuration, run Get-SmbConnection | Select-Object ServerName, ShareName, SigningEnabled on a client and Get-SmbServerConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature on a server. The SigningEnabled column should report True for sessions against signing-capable peers. Exit code 0 from the Automox activity log on the next evaluation run confirms the endpoint stays compliant. Once the entire fleet reports clean for one or two evaluation cycles, schedule the ENFORCE SMB Signing Worklet to flip RequireSecuritySignature=1 and reject unsigned SMB sessions outright, completing the CIS 2.3.8 and 2.3.9 control set.