Securing SMB: Signing, Encryption, and Retiring the Legacy Dialects

No protocol in a Windows environment carries more sensitive data with less scrutiny than SMB. Payroll spreadsheets, HR folders, source code, the finance share — all of it rides the file-sharing protocol every hour of every day, on settings many organizations have never revisited. The uncomfortable truth is that SMB's defaults are a negotiated compromise with decades of old equipment, and the oldest dialect of the protocol is one of the most attacked pieces of software in history.

The good news: hardening SMB is a staged, low-drama project when done in the right order. This article walks that order — understand the dialects, discover before you enforce, retire the legacy dialect without breaking the office scanner, then decide deliberately about signing and encryption instead of inheriting defaults. A copyable checklist at the end holds the whole campaign. It is part of our Shares vs Transfer series, which begins with the more basic question of when a share is the right tool at all.

Dialects: The Version Conversation Under Every Session

SMB is not one protocol but a family of dialects — protocol versions with materially different security properties. When a client connects to a server, the first exchange is a negotiation: the client lists the dialects it speaks, and the server picks the best one both sides share. Every session on your network made that choice silently, and your security posture is set by the worst dialect you still allow, because that is the one an attacker will ask for.

• SMB1 — the original generation, designed for small trusting LANs in an era before anyone imagined hostile networks. Weak integrity protection, no encryption, and an implementation so old and complex that it became the vehicle for some of the most damaging worm outbreaks ever seen. Every current security guide, including the vendor's own, says the same thing: it should not exist on your network.
• SMB2 — the clean-slate redesign: a smaller command set, request compounding, larger reads and writes, better signing. This generation is the floor a modern network should stand on.
• SMB3 — the SMB2 line extended with the security features this article turns on: per-share and per-server encryption, faster hardware-accelerated signing, and integrity protection for the negotiation itself, which blunts downgrade tricks.

Why does one forgotten SMB1 device matter if modern machines negotiate modern dialects among themselves? Three reasons. Keeping SMB1 available means the vulnerable code stays loaded and reachable on every server that still offers it. An attacker on your network does not politely use the best dialect — they request the worst one you accept. And without integrity protection on negotiation, a machine-in-the-middle can try to talk both ends down to the weakest common option. One straggler device is therefore not one device's problem; it is the reason the whole network keeps the old door unlocked.

Discover Before You Enforce

The cardinal rule of this entire project: never flip an enforcement switch on a protocol you have not measured. SMB touches everything, and surprises live in the corners — the multifunction copier that delivers scans to a share, the venerable NAS in a branch office, the lab instrument with firmware nobody dares update, the line-of-business server everyone forgot. Discovery costs a few weeks of passive observation and prevents every one of those from becoming an outage with your name on it.

Start on each file server by reading the current posture and the live sessions:

# Where do we stand? (run in an elevated PowerShell on each file server)
Get-SmbServerConfiguration |
  Format-List EnableSMB1Protocol, RequireSecuritySignature, EncryptData

# Who is connected right now, speaking which dialect?
Get-SmbSession |
  Select-Object ClientComputerName, ClientUserName, Dialect |
  Sort-Object Dialect

# Turn on auditing of SMB1 arrivals, then watch for a few weeks
Set-SmbServerConfiguration -AuditSmb1Access $true
# Hits appear in Event Viewer under:
#   Applications and Services Logs > Microsoft > Windows > SMBServer > Audit

Reading the Dialect column is straightforward once you know the shape: values beginning with 1 are the legacy dialect you are hunting; 2.x values are the redesigned generation; 3.x values are the modern generation with encryption available. You are not aiming for a uniform number — mixed 2.x and 3.x is normal and negotiated per client — you are aiming for the total absence of anything below 2, and for 3.x on every session that touches a share you intend to encrypt.

The session snapshot only shows the moment you ran it, so schedule it — a task that appends the output to a log a few times a day builds an honest picture across month-end jobs, weekly backups, and the once-a-quarter process nobody remembers. The SMB1 audit log is the near-complete answer for the legacy dialect specifically: every client that connects with SMB1 gets an event naming its address. An empty audit log after several representative weeks is your permission slip to proceed.

Expect the straggler list to be short and eccentric: printer-scanners doing scan-to-share, old NAS boxes, embedded controllers, and the occasional ancient PC running something irreplaceable. For each one there are four honest options: update its firmware to a modern dialect, replace the device, isolate it (its own VLAN with tightly scoped access, accepted and documented as risk), or change the workflow so it no longer needs SMB at all — many copiers, for instance, can deliver scans over FTP or SFTP instead of to a share, and pointing them at a transfer server such as Sysax Multi Server retires their SMB1 dependency without replacing the hardware.

Retiring SMB1, Step by Step

With discovery clean, retirement is an anticlimax — which is the goal. Take it in two moves per server, not one:

# Move 1: stop offering SMB1 to clients (reversible in seconds)
Set-SmbServerConfiguration -EnableSMB1Protocol $false

# ...watch for fallout for a week or two, then:

# Move 2: remove the SMB1 component entirely
#   on server editions:
Remove-WindowsFeature FS-SMB1
#   on desktop editions:
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Move 1 changes behavior while leaving the code installed; if something screams, one command restores the old state while you fix the real problem. Move 2 is the security payoff — the vulnerable code is gone from the machine, not merely asked to behave — and it is the step that worms cannot argue with. Do the same on the client fleet through your usual configuration management, because a modern client that will happily fall back to SMB1 is half the risk. Current Windows releases ship with SMB1 absent or auto-removed, so much of the fleet may already be done; the point of the exercise is making that true everywhere and keeping it true.

Signing: Integrity for Every Message

SMB signing attaches a cryptographic seal — a message authentication code computed with the session's key — to each protocol message, letting the receiver verify the message really came from its authenticated peer and was not altered in transit. It is a defense against tampering, and, most importantly in practice, against relay attacks: the trick where an attacker positions themselves between a client and a server, takes the client's genuine authentication handshake, and forwards it to a different server to act with the victim's identity. Signing defeats the relay because the forwarded session cannot produce valid seals — the attacker never learns the session key. Relay is not exotic; it is one of the standard moves in every internal penetration test, and unsigned SMB is its favorite food.

Signing is negotiated: each side can support it or require it, and if either end requires, the session signs. Modern practice is to require it in both directions — current Windows releases have been moving to exactly that default — and the honest cost is CPU: every message gets a computation, which shaves some throughput on bulk streams. On modern hardware, with the hardware-accelerated algorithms of the newer dialects, the tax is usually modest — but "usually" is not a measurement. Benchmark your heaviest real flow (the backup job, the nightly media copy) with signing required before you enforce it fleet-wide, so the performance conversation happens on your numbers rather than folklore from decade-old hardware.

Encryption: Confidentiality on the Wire

Signing proves messages are authentic; anyone on the path can still read them. SMB encryption, available from the SMB3 generation onward, encrypts the session's traffic end to end between client and server — and because its authenticated encryption also guarantees integrity, an encrypted session does not need separate signing; the requirement is considered satisfied.

Windows lets you scope encryption per share or per server, which turns the deployment into a policy statement:

# Encrypt one sensitive share
Set-SmbShare -Name "Payroll" -EncryptData $true

# Or encrypt every share on the server
Set-SmbServerConfiguration -EncryptData $true

# Check whether unencrypted clients are refused (default: they are,
# once encryption is required — the RejectUnencryptedAccess setting)
Get-SmbServerConfiguration | Format-List EncryptData, RejectUnencryptedAccess

The tradeoffs are two. First, compatibility: clients that predate the SMB3 generation cannot do encrypted sessions, and with rejection on (the default, and the setting that makes encryption meaningful) they are locked out of the encrypted share — which is why encryption comes after dialect discovery in this article's order. Second, CPU on both ends, larger than signing's cost but shrinking with every hardware generation thanks to accelerated cipher instructions. A sane rollout: require encryption immediately on the shares whose names say it all — payroll, HR, finance, legal — and on any share whose traffic crosses network segments you trust less than the server's own rack; expand toward server-wide encryption as measurements allow. If SMB traffic must traverse links outside your buildings, encryption stops being optional — though at that point you should also be asking whether a stretched share is the right design at all, per why mapped drives crawl over VPN and WAN.

The Rest of the Hardening Pass

Dialects, signing, and encryption are the headline items; four quieter settings finish the job.

• Kill guest and anonymous access. Modern Windows clients refuse guest access to shares by default because a server that cannot authenticate you cannot protect you — an attacker impersonating the server can serve you anything. Ensure nothing in your fleet re-enables insecure guest logons, and audit old servers for shares readable by everyone-and-nobody.
• Prefer Kerberos authentication over NTLM. Relay attacks ride the older NTLM challenge-response scheme; Kerberos tickets are bound to the specific service they were issued for, which starves the relay. Inside a domain, Kerberos is already the default when clients connect by proper DNS name — so the practical step is small: stop using IP addresses in UNC paths and mapped-drive definitions (an IP forces NTLM fallback), audit where NTLM still occurs, and tighten from there.
• Never expose port 445 to the internet. SMB's port 445 facing the public network is a standing invitation — it is among the most scanned ports in existence. External file exchange is what transfer protocols are for: an SFTP or HTTPS endpoint is designed to be knocked on from outside, with per-user jails and per-action logs. If a partner asks to "reach the share," that request has outgrown the share by definition — the redesign path is in recognizing when a workflow has outgrown the shared drive.
• Limit east-west SMB. Workstations rarely need to reach each other's port 445 at all — file service flows workstation-to-server. A host-firewall rule blocking inbound SMB on workstations removes the highway that worms and lateral movement ride, at nearly zero operational cost.
• Keep watching. The scheduled dialect report and the SMB1 audit log from the discovery phase are not scaffolding to tear down; they are the monitoring that keeps the network in its hardened state when the next appliance arrives speaking something old.

The Hardening Checklist

The whole campaign on one screen — copy it into your ticket system and work down:

SMB HARDENING CHECKLIST

Phase 1 — Discover (weeks, passive)
[ ] Inventory posture on every file server (Get-SmbServerConfiguration)
[ ] Schedule recurring session/dialect snapshots (Get-SmbSession)
[ ] Enable SMB1 access auditing; review after representative weeks
[ ] List stragglers: device, owner, dialect, remediation option

Phase 2 — Remediate stragglers
[ ] Firmware-update, replace, isolate, or re-point each SMB1 device
[ ] Convert scan-to-share devices to modern dialects or FTP/SFTP delivery
[ ] Re-check audit log is empty over a full business cycle

Phase 3 — Enforce (server by server, rollback plan noted)
[ ] Disable SMB1 serving; observe
[ ] Uninstall the SMB1 component on servers and clients
[ ] Require signing both directions after benchmarking heavy flows
[ ] Require encryption on sensitive shares; plan server-wide expansion
[ ] Verify guest/anonymous access is refused

Phase 4 — Contain and monitor (permanent)
[ ] Block port 445 inbound at every internet edge
[ ] Block workstation-to-workstation SMB with host firewall rules
[ ] Keep dialect reports and SMB1 auditing running; alert on hits
[ ] Route partner/external file exchange through a transfer endpoint

The Order Is the Method

Everything above compresses into a sequence: learn the dialects, measure what your network actually speaks, fix the eccentric stragglers, and only then enforce — SMB1 gone entirely, signing required, encryption on the shares that deserve it, guest access dead, port 445 contained, and the measuring tools left running as monitoring. Done in that order, the project produces no war stories, which is the highest compliment an infrastructure change can receive. For the neighboring protocol in mixed shops, NFS fundamentals covers the equivalent trust decisions on the Unix side; and for the flows that should never have been on SMB in the first place — anything crossing an organizational boundary — our SFTP series covers the protocol built for that job.

Frequently Asked Questions