Disable SMBv1 on Windows Server: Security Hardening Guide

SMBv1 should have died in 2017 when WannaCry ransomware exploited the EternalBlue vulnerability (MS17-010) to infect 300,000+ Windows systems worldwide in 72 hours. Yet five years later, most enterprise environments still have SMBv1 enabled by default — not because they need it, but because it’s legacy technical debt that “works” and nobody wants to break file shares. This guide shows how to disable SMBv1 on Windows Server safely: audit current usage, migrate dependencies to modern SMBv2/v3, remove the protocol entirely, and verify compliance across the fleet.

SMBv1 isn’t just “legacy and slow” — it’s a fundamental security vulnerability. The protocol lacks modern security features (no encryption, weak authentication, vulnerable to man-in-the-middle attacks), has known exploitable bugs (EternalBlue, EternalSynergy, EternalRomance), and Microsoft officially deprecated it in 2014. Windows Server 2025 ships with SMBv1 removed entirely from clean installs. If your environment still runs SMBv1 in 2026, you’re carrying attack surface that nation-state actors actively exploit.

TL;DR — SMBv1 removal in 6 steps

The complete migration path from “SMBv1 everywhere” to “SMBv1 nowhere”:

1. Audit — Run Get-SmbServerConfiguration and log SMBv1 usage for 2 weeks via Event ID 3000
2. Inventory — Identify every client and device still using SMBv1 connections
3. Migrate — Update clients to SMBv2/v3, replace legacy NAS appliances, fix applications
4. Disable — Turn off SMBv1 server and client via Group Policy or PowerShell
5. Remove — Uninstall the SMBv1 feature entirely from Windows installations
6. Verify — Confirm SMBv1 is disabled and monitor for residual connection attempts

Total deployment time: 2-4 weeks for most environments. Emergency deployments (active ransomware threat): 48-72 hours with acceptable breakage.

Why SMBv1 is a critical security vulnerability

Three technical realities that make SMBv1 indefensible in modern networks:

1. SMBv1 has no encryption. All data flows in plaintext over the network. File contents, authentication credentials, and metadata are visible to anyone with network access. SMBv2/v3 support AES-based encryption that makes network interception useless.

2. Multiple critical CVEs target SMBv1 specifically. The most serious:

EternalBlue remains actively exploited by ransomware families (Ryuk, Maze, Conti, LockBit) and nation-state actors. Patches exist, but SMBv1 itself remains the attack surface.

3. SMBv1 authentication is fundamentally weak. The protocol uses NTLM authentication with no modern protections against relay attacks, credential theft, or brute-force. SMBv2/v3 integrate with modern Kerberos, support message integrity checking, and resist the attack patterns that work against SMBv1.

SMBv1 vs SMBv2 vs SMBv3: what you gain by upgrading

The performance improvement alone justifies the migration — SMBv2/v3 use pipelining, larger buffer sizes, and modern TCP optimizations that make file operations dramatically faster. The security improvements are the primary justification.

Prerequisites and planning

Before you disable anything:

• Inventory SMBv1 usage for at least 14 days to capture monthly batch jobs and quarterly processes
• Identify legacy devices that might only support SMBv1 (older NAS appliances, printers, some Linux distributions pre-2010)
• Test SMBv2/v3 connectivity from critical clients to ensure modern SMB works
• Document rollback procedure — how to re-enable SMBv1 if something critical breaks
• Plan maintenance windows for client updates and server reboots
• Prepare communication for users about potential file share disruptions
• Backup configurations before making changes

Step-by-step SMBv1 removal guide

Step 1: Audit current SMBv1 usage

Before disabling anything, you need visibility into what’s actually using SMBv1. Microsoft provides built-in auditing that captures every SMBv1 connection attempt.

Enable SMBv1 audit logging via Group Policy:

Computer Configuration
  └ Policies
    └ Administrative Templates
      └ MS Security Guide
        └ SMB1 auditing
          = Enable auditing for SMB1 connections

Or via registry on each server:

# Enable SMBv1 connection auditing
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
  -Name "RequireSecuritySignature" -Value 1 -Type DWord
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" `
  -Name "AuditReceivingNTLMTraffic" -PropertyType DWord -Value 2 -Force

# Check current SMB configuration
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol*

Monitor SMBv1 connections for 14 days minimum:

# Watch for SMBv1 connection attempts in real-time
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Audit'; ID=3000} -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

# Export 2 weeks of SMBv1 usage data
$StartTime = (Get-Date).AddDays(-14)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Audit'; ID=3000; StartTime=$StartTime} |
  Select-Object TimeCreated, @{N='ClientIP';E={($_.Message -split '\n' | Select-String 'Client Address').ToString().Split(':')[1].Trim()}}, 
                @{N='UserName';E={($_.Message -split '\n' | Select-String 'User Name').ToString().Split(':')[1].Trim()}},
                @{N='ShareName';E={($_.Message -split '\n' | Select-String 'Share Name').ToString().Split(':')[1].Trim()}} |
  Export-Csv -Path C:\SMBv1_Audit.csv -NoTypeInformation

The key metrics to track: which client IPs, which user accounts, which shares, and what time of day SMBv1 connections occur. Patterns like “every Tuesday at 2 AM” suggest scheduled tasks that need explicit migration.

Step 2: Inventory and migrate dependencies

Open the CSV from Step 1 and categorize each SMBv1 connection:

• Windows XP/2003 clients — Upgrade to supported OS or replace with modern hardware
• Legacy NAS appliances — Check vendor firmware updates or plan replacement
• Old printers/scanners — Update firmware or use IP printing instead of SMB
• Linux/macOS clients — Configure to use SMBv2/v3 explicitly
• Applications with hardcoded SMBv1 — Update application or find alternatives
• Scheduled tasks/scripts — Update to use modern UNC paths with SMBv2+

Migration approaches:

• Linux clients: Update /etc/samba/smb.conf to set min protocol = SMB2
• Windows clients: Ensure Vista/2008+ and use New-SmbMapping with integrity checking
• Legacy NAS: Check vendor firmware updates or plan hardware replacement

Step 3: Disable SMBv1 via Group Policy

Once you’ve migrated the dependencies, disable SMBv1 across the environment using Group Policy for consistency.

Create a new GPO or edit an existing security hardening policy:

Computer Configuration
  └ Policies
    └ Administrative Templates
      └ Network
        └ Lanman Server
          ├ SMB1 server = Disabled
        └ Lanman Workstation
          ├ SMB1 client = Disabled

Apply via PowerShell for immediate effect:

# Disable SMBv1 server (stops serving files via SMBv1)
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# Disable SMBv1 client (stops accessing other SMBv1 shares)
Set-SmbClientConfiguration -EnableSMB1Protocol $false -Force

# Verify the changes
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EnableSMB3Protocol
Get-SmbClientConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EnableSMB3Protocol

# Force Group Policy update
gpupdate /force

Test connectivity after changes:

# Test SMBv2/v3 connectivity to file server
Test-NetConnection fileserver01.corp.local -Port 445
New-SmbMapping -LocalPath Z: -RemotePath \\fileserver01\shared -Persistent $false

# Verify SMBv2/v3 is being used
Get-SmbConnection | Select-Object ServerName, Dialect, Encrypted, Signed

The Dialect field should show 2.002, 2.100, 3.000, 3.002, or 3.110 — anything except 1.000.

Step 4: Remove SMBv1 Windows features entirely

Disabling SMBv1 via configuration leaves the code installed and potentially re-enable-able. For maximum security, remove the SMBv1 Windows features entirely.

Windows Server (remove server-side SMBv1):

# Check if SMBv1 feature is installed
Get-WindowsFeature | Where-Object Name -like "*SMB*"

# Remove SMBv1 feature completely
Remove-WindowsFeature FS-SMB1 -Restart

# Alternative method for Windows 10/11/Server 2016+
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -Remove -All

Windows clients (remove client-side SMBv1):

# Check current SMBv1 feature status
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol*

# Remove SMBv1 client and server features
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Client -Remove -All
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Server -Remove -All
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol-Deprecation -Remove -All

# Verify removal
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol* | Select-Object FeatureName, State

Step 5: Verify compliance and monitoring

After disabling and removing SMBv1, implement monitoring to ensure it stays disabled and catch any legacy devices that attempt connections.

Compliance verification script:

# SMBv1 Compliance Check Script
$ComputerName = $env:COMPUTERNAME
$Results = @{}

# Check SMB server configuration
try {
    $SmbServer = Get-SmbServerConfiguration -ErrorAction Stop
    $Results.SMB1ServerEnabled = $SmbServer.EnableSMB1Protocol
    $Results.SMB2ServerEnabled = $SmbServer.EnableSMB2Protocol
} catch {
    $Results.SMB1ServerEnabled = "Unable to check"
}

# Check SMB client configuration
try {
    $SmbClient = Get-SmbClientConfiguration -ErrorAction Stop  
    $Results.SMB1ClientEnabled = $SmbClient.EnableSMB1Protocol
} catch {
    $Results.SMB1ClientEnabled = "Unable to check"
}

# Check Windows features
$SMB1Features = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol* -ErrorAction SilentlyContinue
$Results.SMB1FeaturesInstalled = ($SMB1Features | Where-Object State -eq 'Enabled').Count -gt 0

# Check for recent SMBv1 connection attempts
$Recent = (Get-Date).AddDays(-7)
$SMB1Attempts = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SMBServer/Audit'; ID=3000; StartTime=$Recent} -ErrorAction SilentlyContinue
$Results.RecentSMB1Attempts = $SMB1Attempts.Count

Write-Output "=== SMBv1 Compliance Check for $ComputerName ==="
Write-Output "SMBv1 Server Enabled: $($Results.SMB1ServerEnabled)"
Write-Output "SMBv1 Client Enabled: $($Results.SMB1ClientEnabled)"  
Write-Output "SMBv1 Features Installed: $($Results.SMB1FeaturesInstalled)"
Write-Output "Recent SMBv1 Connection Attempts: $($Results.RecentSMB1Attempts)"

if ($Results.SMB1ServerEnabled -eq $false -and $Results.SMB1ClientEnabled -eq $false -and $Results.SMB1FeaturesInstalled -eq $false) {
    Write-Output "STATUS: COMPLIANT - SMBv1 is fully disabled and removed"
} else {
    Write-Output "STATUS: NON-COMPLIANT - SMBv1 is still present"
}

Set up SIEM alerting for SMBv1 connection attempts:

Monitor these Event IDs across all Windows file servers:

Splunk query example:

index=windows (EventCode=3000 OR EventCode=1001 OR EventCode=40961)
| eval severity=case(EventCode=3000,"high",EventCode=1001,"medium",1=1,"low")
| stats count by src_host, EventCode, severity, _time
| where EventCode=3000
| eval message="SMBv1 connection detected - investigate legacy client"

Network hardening

Once SMBv1 is disabled, configure network firewalls to block SMBv1 traffic. Most enterprise firewalls (Palo Alto, Fortinet, Checkpoint) support application-layer SMB inspection to block only SMBv1 while allowing SMBv2/v3.

Common migration issues and solutions

Emergency rollback

If needed: Set-SmbServerConfiguration -EnableSMB1Protocol $true and Enable-WindowsOptionalFeature -FeatureName SMB1Protocol-Server. Document all rollbacks and plan re-migration within 30 days.

Compliance verification

Key compliance checks:

• SMBv1 disabled in server and client configuration
• SMBv1 Windows features removed entirely
• Group Policy blocks SMBv1 organization-wide
• SIEM monitors Event ID 3000 for connection attempts
• All legacy NAS appliances upgraded or replaced

Frequently asked questions

Conclusion: eliminate the EternalBlue attack surface

SMBv1 removal is table stakes security hygiene in 2026. The protocol has been deprecated for over a decade, exploited by major ransomware campaigns, and offers no benefits over modern SMBv2/v3. Every day SMBv1 remains enabled is another day your file servers are vulnerable to well-known, actively-exploited attack vectors.

The migration process — audit, inventory, migrate, disable, remove, verify — typically takes 2-4 weeks in most enterprise environments. The alternative is carrying the EternalBlue attack surface indefinitely. Modern SMBv2/v3 delivers better security, better performance, and better compliance posture.

Start this week:

1. Run the audit script on all file servers to baseline SMBv1 usage
2. Enable Event ID 3000 logging to capture connection attempts
3. Schedule maintenance windows for client updates and server changes
4. Document the rollback procedure before making any changes

Pair SMBv1 removal with the NTLM hardening guide and Windows LAPS implementation to eliminate the three most-exploited Windows attack surfaces in a single security sprint.

References

• Microsoft Security Advisory ADV170005: SMBv1 deprecation — Microsoft’s official SMBv1 deprecation notice
• Microsoft Learn: How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows
• MITRE ATT&CK T1021.002 — Remote Services: SMB/Windows Admin Shares
• CVE-2017-0144 (EternalBlue) Details
• CISA Alert AA17-132A — SMB Vulnerability
• Microsoft Security blog: WannaCrypt ransomware worm targets out-of-date systems
• SANS: Disabling SMBv1 through Group Policy