Audit first, then disable. Turn on SMBv1 access auditing on your Windows file servers, read the event log to see which clients still connect with it, fix or replace those, and disable SMBv1 everywhere else. For a device that cannot change, isolate it and shrink what it can reach.
Why SMBv1 is the classic legacy trap
Microsoft's documentation says SMBv1 has significant security vulnerabilities and strongly encourages people not to use it. It is not installed by default in any edition of Windows 11 or Windows Server 2019 and later, and also not in Windows 10 except Home and Pro editions. Microsoft recommends updating the SMB server that still requires it instead of reinstalling SMBv1, and points to a clearinghouse of partner products that need it and their updates.
So the usual cause is a scanner, a copier, a storage appliance or an old line of business application that only speaks the old protocol.
Step 1: find out who actually uses it
On a Windows server, auditing is a single setting:
Set-SmbServerConfiguration -AuditSmb1Access $true
After that, each time a client tries SMBv1 to connect, an entry with event ID 3000 appears in the Microsoft-Windows-SMBServer Audit log, according to Microsoft. Leave auditing on for a full business cycle so month end jobs show up.
Step 2: check where it is enabled
Get-SmbServerConfiguration | Select EnableSMB1Protocol
For clients, Microsoft documents the Get-WindowsOptionalFeature command with the SMB1Protocol feature name.
Step 3: disable it where nobody needs it
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Microsoft notes you do not need to restart after this server cmdlet. Roll it out in groups, starting with workstations and ending with domain controllers. Microsoft warns specifically to be careful disabling SMBv1 on domain controllers when some systems that need SYSVOL or other shares do not support SMBv2 or SMBv3, for example legacy Windows systems and older Linux and partner systems.
Step 4: for the device that cannot change
| Option | Notes |
|---|---|
| Replace the device or its share | The real fix, schedule it |
| Update its firmware or software | Check the vendor for a version that supports SMBv2 or later |
| Move the data to a current server and push files over a different method | Removes the dependency |
| Isolate it | Put it and its one peer server in a small segment, with deny by default rules |
If you isolate, keep a dedicated file server for that device, with SMBv1 enabled only on that server and only reachable by that device. Do not enable it on a general server for convenience.
Also remember that newer Windows versions raise other requirements. Microsoft says SMB signing is required by default in Windows 11 version 24H2 and Windows Server 2025, and tells people not to disable SMB protocol versions or signing to work around connection failures, but to enable signing on the remote server or update or replace devices that do not support it.
Record the exception
Write down the device, why it needs SMBv1, the segment it lives in, who can reach it, the review date and the replacement plan. The audit log from step 1 is useful evidence that nothing else depends on the protocol.
Quick check
Will disabling SMBv1 break file sharing for modern clients?
Modern clients use SMBv2 or SMBv3, so they are not affected. Only old devices and software that speak SMBv1 alone will fail, which is why you audit first.
Can I just leave it on and rely on the firewall?
Only for a named device in a small isolated segment, with a review date. Leaving it on across the estate widens exposure to every host that can reach those servers.
Sources
Last reviewed: 19 October 2026.
