SMBv1 has been absent from clean installs since Windows 10 version 1709 and Windows Server 2019, and Microsoft has published removal guidance for close to a decade. Despite that, a dialect-aware scan of port 445 across almost any mid-size Windows fleet still turns up a handful of hosts willing to negotiate SMB 1.0. Turning the protocol off is a one-line PowerShell command. Finding out what depends on it first, and enforcing signing correctly afterward, is the part that takes actual planning.
Why SMBv1 still exists in 2026 networks
SMBv1 survives for the same reason most legacy protocols survive: something on the network was built once, worked, and was never revisited. Four categories account for almost every holdout you will find during an audit.
Scanners and multifunction printers
Scan-to-folder is the most common offender. A large share of MFPs shipped before roughly 2018, including older Xerox WorkCentre, Konica Minolta bizhub, and entry-level HP LaserJet MFP firmware, default their SMB client stack to version 1 and never received a firmware update that adds SMB 2.x negotiation. The device is not compromised; it simply cannot speak anything newer unless you flash it.
NAS appliances and embedded storage
Consumer and prosumer NAS boxes running end-of-life firmware branches keep SMB1 enabled for backward compatibility with older media players and set-top boxes. Once the vendor stops shipping firmware updates, the device is frozen at whatever protocol level it shipped with.
Legacy line-of-business applications
The hardest case is custom or third-party software with a hardcoded UNC path and a redirector that was never re-tested against SMB2. This shows up most often on manufacturing floor terminals, point-of-sale back offices, and older medical imaging workstations, where the application vendor no longer exists or the support contract lapsed years ago. EternalBlue and WannaCry made the risk concrete, but the operational reason these systems are still exposed is inertia, not ignorance.
Inventory first: auditing SMBv1 usage before you touch a switch
Disabling SMBv1 blind is how helpdesk tickets happen. Windows gives you an audit mode that logs every SMB1 negotiation attempt without blocking it, and you should run it for at least one full business cycle, including month-end close and any quarterly batch jobs, before flipping the switch.
On the server side, turn on audit logging without disabling anything: Set-SmbServerConfiguration -AuditSmb1Access $true
This writes event ID 3000 to the Microsoft-Windows-SMBServer/Audit channel every time a client negotiates SMB 1.0, including the source IP and the account used. Pull the log directly: Get-WinEvent -LogName “Microsoft-Windows-SMBServer/Audit/SMB1”
On the client side, check what a given machine has already negotiated for its live mapped drives: Get-SmbConnection | Select-Object ServerName, ShareName, Dialect
Forward both event sources to your SIEM or a Windows Event Forwarding collector so you get one list of offending hostnames instead of checking box by box. Tag each offender against your asset inventory so a NAS at one site does not get confused with a printer at another; this is also where a platform that tracks device type and firmware version alongside open ports, such as the asset inventory module, saves you from re-discovering the same handful of legacy devices every audit cycle. Pair the audit log with an external dialect probe: a scan that fingerprints the negotiated SMB version on port 445 across every subnet, not just the ones with domain-joined hosts, will surface unmanaged NAS boxes and IoT-adjacent devices that never show up in Active Directory. The network reachability checks that most scanning platforms run are exactly this kind of protocol-level probe rather than a simple port-open check.
Removing the feature vs disabling the protocol
These are two different operations and they behave differently during rollback.
Disabling is a service-level toggle. The binaries stay on disk, and you can revert instantly if something breaks: Set-SmbServerConfiguration -EnableSMB1Protocol $false
Removing uninstalls the SMB1 client and server binaries (the SMB1Protocol optional feature, which controls srv.sys and mrxsmb10.sys) entirely: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
On Windows 10 1709+, Windows 11, and Server 2019+, the feature is already absent by default on new installs; you are only removing it on machines upgraded in place from older builds. Reverting a full removal requires re-enabling the feature and a reboot, so treat it as the second step after a disable-only period has run clean for a few weeks.
Server 2012 R2, Server 2008 R2, Windows 7, and Windows 8.1 cannot remove the feature at all; it has to be disabled through the registry instead:
- New-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters” -Name “SMB1” -Value 0 -PropertyType DWORD -Force
- Set-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesmrxsmb10” -Name “Start” -Value 4
For fleet-wide rollout, use Group Policy rather than per-machine scripts: Computer Configuration > Administrative Templates > MS Security Guide > Configure SMBv1 client driver (this template ships with the Security Compliance Toolkit ADMX, not Windows by default) combined with a startup script that runs the optional feature removal on first boot after imaging.
SMB signing and encryption: required vs enabled, and what it costs
Signing prevents SMB relay attacks, where an attacker captures an authentication attempt on one connection and replays it against another server. There are three states, and the naming is easy to misread.
| Setting | Behavior | Where to use it |
|---|---|---|
| Disabled | No signing offered or required | Never, outside isolated lab segments |
| Enabled | Signs if the other side supports it, otherwise falls back unsigned | Transitional state only, not an end state |
| Required | Refuses any connection that cannot sign | Domain controllers, file servers, admin workstations |
Set the server side to require signing: Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true
And the client side, since a Windows box is a client for every UNC path it opens: Set-SmbClientConfiguration -RequireSecuritySignature $true
The equivalent GPO paths are Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always), under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Domain controllers have required signing by default since Windows Server 2022; member servers and workstations generally do not, so this is the setting most environments still need to push explicitly.
On performance: signing overhead is a per-packet hash, and on any CPU from the last several years it is not the bottleneck people expect it to be. What admins usually blame on signing is actually SMB’s chattiness on small files over high-latency links, which signing does not materially change. SMB encryption (AES-128-GCM under SMB 3.1.1) is a heavier cost than signing because it encrypts the payload, not just a checksum. Do not enable it blanket-wide on hardware without AES-NI; instead scope it to the shares that actually carry regulated data: Set-SmbShare -Name Finance -EncryptData $true
Reserve Set-SmbServerConfiguration -EncryptData $true -RejectUnencryptedAccess $true for servers where every share needs it, since that setting is global to the server, not per-share.
Failure modes: what actually breaks and how to unblock it
The error message users see after you disable SMBv1 or require signing is usually one of two things: “The specified network name is no longer available” (Windows error 64) or a dialog stating the share is not secure. Both mean the client tried to negotiate SMB1 and got refused, or tried unsigned and was rejected.
Printer scan-to-folder
Check the printer’s firmware release notes for SMB2/3 support before you disable anything company-wide. If an update exists, apply it and re-point the scan destination. If it does not, isolate that one device on a segment with its own file share, still requiring signing on the share itself, and track it as a documented exception rather than pretending the finding does not exist.
Backup agents and imaging tools
Older WinPE-based deployment images (pre-1709 boot.wim) default to SMB1 for network installs during PXE boot, which is why a Windows Deployment Services or MDT share can break the moment you disable SMB1 on the file server hosting the images. Rebuild the boot image from a current ADK rather than reverting the server setting. Some legacy backup agents (older Backup Exec and Veeam proxy configurations in particular) also hardcode SMB1 for agent-to-repository communication; check the agent version against the vendor’s SMB2 support matrix before the maintenance window, not during it.
Legacy LOB applications
If the application vendor is gone and the redirector genuinely cannot negotiate SMB2, the realistic fix is not protocol negotiation, it is network isolation: put the device behind a jump host or an application-layer gateway so the SMB1 conversation never crosses a segment boundary that matters.
Proving the change stuck across the fleet
A GPO reporting “applied” is not the same as SMBv1 actually being gone on every machine. Two things quietly undo this work: reimaging from a stale WIM that predates your removal baseline, and third-party NAS or storage drivers that reinstall the legacy MRxSMB10 filter driver as part of their own client software. Bake the removal into the imaging pipeline itself, either in the unattend.xml answer file or as a provisioning script that runs on first boot, so a new machine never ships with SMB1 present in the first place.
For ongoing verification, do not trust local policy state alone. Re-scan the actual protocol behavior on port 445 across the fleet on a recurring basis, the same way you audited it initially, and compare results against the previous pass. This is the point where retesting matters more than the remediation ticket’s status field: a change management system can show a patch task as closed while the underlying host still negotiates SMB1 because a conflicting local security policy silently overrode the GPO. Platforms built around an eight-phase pipeline, such as SITEY, re-run the exact SMB dialect and signing probe that originally raised the finding during the retest phase, and only mark it resolved when the independent scan confirms the negotiated behavior actually changed, rather than accepting a patch script’s exit code as proof.
Document the exceptions you cannot close, the one printer, the one legacy terminal, as formal risk acceptances tied to a compensating control, not as scan exclusions that quietly disappear from the report. Compliance frameworks including PCI DSS Requirement 2.2, ISO 27001 Annex A control 8.20, and BDDK’s information systems regulations all expect protocol hardening to be evidenced, and mapping each SMBv1 finding to the specific control it satisfies is what turns a spreadsheet of IP addresses into an actual audit trail; this is the kind of mapping a compliance mapping module is built to maintain automatically instead of by hand. Once every host is confirmed clean, the finding should move through a defined retest and closure workflow rather than being marked done by whoever ran the last PowerShell command, so there is a record of who verified it and when.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.