SMB signing and SMBv1 removal: two jobs you should not put off
SMB is everywhere: file shares, SYSVOL, remote administration, printing. Without signing, an authentication relayed to an SMB server can be enough to run code or read data. And SMBv1, an old and dangerous protocol, still lingers in many environments.
Relay to SMB
SMB signing guarantees the integrity of each message and proves that the peer knows the session key. Without it, an attacker who intercepts or triggers an NTLM authentication can relay it to an SMB server and act with the victim's rights. If the victim is a local administrator on the target, remote code execution becomes possible. Historically, Windows only required signing on domain controllers.
Requiring signing
Signing is configured separately for the server and client roles, through the policies "Microsoft network server: Digitally sign communications (always)" and "Microsoft network client: Digitally sign communications (always)", or with PowerShell:
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSMB1Protocol Set-SmbServerConfiguration -RequireSecuritySignature $true -Force Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
Microsoft has changed the defaults: Windows 11 24H2 and Windows Server 2025 require signing in more scenarios than before. The exact scope varies by edition and by connection direction; check it on your versions and do not rely on this behaviour for older systems, which still make up most of many estates.
Performance: a real but manageable impact
Signing uses CPU. On recent hardware with SMB 3.x, which relies on hardware-accelerated AES algorithms, the effect is usually modest. It can be noticeable on older file servers, very high-throughput links or some third-party NAS devices. Test on a representative sample before rolling out widely. Note also that when SMB encryption is enabled, it already provides integrity, so signing is not applied on top.
Check third-party devices. Some NAS units, scanners or older Linux distributions do not support signing or handle it poorly. Inventory them before requiring client-side signing across the estate.
Auditing and removing SMBv1
SMBv1 offers neither encryption nor modern protections and has been exploited by major attacks. It is no longer installed by default on recent Windows versions, but it survives on upgraded systems or machines built from old images. Recommended approach:
- Enable SMBv1 access auditing on servers with
Set-SmbServerConfiguration -AuditSmb1Access $true, then watch theMicrosoft-Windows-SMBServer/Auditlog (event 3000). - Identify and replace or update the clients involved.
- Disable the protocol on the server side, then remove the feature:
Uninstall-WindowsFeature FS-SMB1on servers,Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocolon workstations. - Check regularly that the feature has not been reinstalled.
What an audit checks
- the SMB signing requirement on domain controllers, servers and workstations;
- whether SMBv1 is present or enabled;
- consistency of applied GPOs and absence of conflicting settings;
- complementary anti-relay measures such as LDAP signing.