SMB signing and SMB encryption are the two controls that determine whether your file traffic on a Windows Server can be tampered with or read in transit — and both cost measurable throughput. The engineering question is not “enable them” but “which one, at what settings, and what does the CPU chart look like afterwards.” This guide measures the actual overhead across SMB 3.0.2/3.1.1 signing algorithms, compares signing with encryption, and gives the PowerShell to audit, enable, and roll back safely. It assumes server-to-server file access typical of a Windows Server deployment, such as SQL backups to a file share, or IIS content replication.
What Each Control Actually Does
| Feature | Protects | Crypto used | Where enforced |
|---|---|---|---|
| SMB signing | Integrity/anti-tamper of each packet (prevents NTLM relay and MITM modification) | HMAC-SHA256 or AES-CMAC/GMAC | Server setting + client setting, per-share not possible |
| SMB encryption | Confidentiality + integrity of the whole SMB session | AES-128-CCM or AES-128-GCM (3.1.1) | Per-share (EncryptData) or server-wide |
| SMB over QUIC | Both, via TLS 1.3 | TLS 1.3 | Server 2022/2025 with certificate, UDP 443 |
Signing is cheap relative to encryption but not free: on SMB 2.0/2.1 the signing algorithm was HMAC-SHA256 applied to the entire message and cost 10–30% of throughput. On SMB 3.x with AES-NI, signing uses AES-CMAC or AES-GMAC and the cost is typically single-digit percentage points on modern vCPUs — and it is assisted by the cipher offload instructions exposed by the hypervisor.
Baseline First
Measure before changing anything. Run from a client to the server, with the cache warm and cold:
# Server side: which dialect, signing, and encryption are in use
Get-SmbServerConfiguration |
Select-Object EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature,
EnableSecuritySignature, EncryptData, RejectUnencryptedAccess
# Per-connection view (run during a transfer)
Get-SmbSession | Select-Object ClientComputerName, Dialect, NumOpens, Signed, Encrypted
# Throughput baseline: 1 GB read and write over SMB
1..3 | ForEach-Object {
Measure-Command { Copy-Item \\fs01\bench\1gb.bin C:\temp\1gb-$_.bin -Force } |
Select-Object TotalSeconds
}
Note Dialect: 3.1.1 is the only version that supports AES-GCM encryption and pre-auth integrity. If your servers negotiate 3.0 or 3.0.2, the overhead will be higher and the configuration surface smaller. Force 3.1.1 with Set-SmbServerConfiguration -Smb2DialectMax 785 and confirm the share still mounts; older clients from Linux/Samba need their own minimum set.
Audit Before You Require
Turning on RequireSecuritySignature or EncryptData on a working file server can break legacy appliances in minutes. Find out first:
# Audit-only mode logs what would be rejected
Set-SmbServerConfiguration -AuditSmb1Access $true -Confirm:$false
# Inventory every existing session and what it supports
Get-SmbSession | Group-Object Dialect, Signed, Encrypted |
Select-Object Name, Count
# Enable encryption on a single test share
Set-SmbShare -Name Reports -EncryptData $true -Force
Get-SmbShare | Select-Object Name, EncryptData
Also check Get-SmbServerConfiguration | Select SmbServerNameHardeningLevel and the SMB event logs: Microsoft-Windows-SMBClient/Security and SMBClient/Connectivity record rejection reasons such as event 31017 (encryption required) and 31013 (signing required).
Measured Overhead
The following figures are typical for a 4 vCPU VPS with AES-NI exposed by the hypervisor and a 1 Gbit virtual NIC, copying 1 GB over SMB 3.1.1. Absolute numbers vary by provider; the ratios are the useful part.
| Configuration | Read MB/s | Write MB/s | Server CPU during transfer |
|---|---|---|---|
| No signing, no encryption | 112 | 108 | ~8% |
| Signing (AES-CMAC, 3.1.1) | 108 | 104 | ~13% |
| Signing (HMAC-SHA256 forced, 3.0) | 94 | 88 | ~27% |
| Encryption (AES-128-GCM, 3.1.1) | 101 | 96 | ~21% |
| Encryption + signing (3.1.1) | 99 | 94 | ~24% |
| Small-file mix, 10 KB avg, encryption on | — | ~40% of large-file rate | ~35% |
Two conclusions matter more than the exact numbers:
- Signing at SMB 3.1.1 costs roughly 3–5 percentage points of throughput. Signing at SMB 2/3.0 with HMAC costs roughly 20%. The version you negotiate is a bigger lever than the on/off switch.
- Encryption costs ~10% on large sequential IO but far more on metadata-heavy workloads. A folder with 200,000 small files is dominated by per-operation crypto and round trips, not MB/s.
Configuring It on Server and Client
# Server: require signing, mandate encryption, reject unencrypted fallback
Set-SmbServerConfiguration -RequireSecuritySignature $true -Confirm:$false
# Server-wide encryption (applies to all new shares unless overridden)
Set-SmbServerConfiguration -EncryptData $true -RejectUnencryptedAccess $true -Confirm:$false
# Client side: must also sign when the server requires it
Set-SmbClientConfiguration -RequireSecuritySignature $true -Confirm:$false
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Confirm:$false
# Map a drive with encryption mandated at the client
New-SmbMapping -LocalPath Z: -RemotePath \\fs01\Reports -RequirePrivacy $true
For SMB over QUIC on Server 2022/2025, encryption is inherent (TLS 1.3) and the overhead is comparable to SMB encryption; enable it with New-SmbServerCertificateMapping and the smboverquic listener on UDP 443. That path is useful for internet-facing file access where opening TCP 445 is not acceptable.
Multi-Channel: SMB Direct, Multichannel, and Encrypted Sessions
Crypto overhead is calculated per byte but paid per operation, and SMB Multichannel changes the math in both directions. With multiple NICs (or RSS-capable vNICs on the same subnet), SMB 3.x opens several TCP connections and spreads file IO across them; each connection carries its own signing key and, if encryption is on, its own session key. On a VPS with a single virtual NIC, Multichannel usually does not engage at all, which means signing and encryption are serialized on one core’s crypto path.
# Does the server advertise Multichannel, and is it active?
Get-SmbServerConfiguration | Select-Object EnableMultiChannel
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbMultichannelConnection | Select-Object ServerName, ClientIPAddress, ServerIPAddress, Active
# For a share where a single stream is slow, test RSS and CM
Get-NetAdapterRss | Select-Object Name, Enabled, NumberOfReceiveQueues
Get-NetAdapterAdvancedProperty -Name 'Ethernet' |
Where-Object DisplayName -like '*Receive Side Scaling*'
If Multichannel is unavailable (single vNIC), you can still parallelize by splitting a large copy into four jobs — SMB will use four separate sessions if the client script uses distinct paths and retries. Measure this rather than assuming: on some providers, multiple sessions to the same share serialize on a per-share lock and gain nothing.
For encryption specifically, confirm which cipher negotiated before attributing a throughput drop to crypto:
Get-SmbSession | Select-Object ClientComputerName, Dialect, Signed, Encrypted,
ClientCertificateThumbprint
Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Security' -MaxEvents 20 |
Where-Object Id -in 31017, 31018, 31019
The client events 31017–31019 are the ones that matter during a rollout: 31017 means the server required encryption and the client refused, 31018 means signing was required and not offered, 31019 reports a cipher negotiated below the configured minimum. Those three cover nearly every “the share worked yesterday” report after a signing change.
Rolling Back Without an Outage
- Revert the server setting:
Set-SmbServerConfiguration -EncryptData $false -RejectUnencryptedAccess $false -Confirm:$false. - Per-share revert is instant:
Set-SmbShare -Name Reports -EncryptData $false -Force. Sessions connected with mandatory encryption drop and must reconnect. - Check for stuck handles before and after:
Get-SmbOpenFile | Where-Object ClientUserName -eq 'DOMAIN\svc_backup', thenClose-SmbOpenFileif a stale client blocks the change.
What to Enable and When
- Signing: require everywhere, both directions. The cost at SMB 3.1.1 is small, and NTLM relay against file servers remains one of the most exploited lateral movement paths.
- Encryption: require on shares carrying backups, PII, or anything crossing an untrusted network segment. Leave general content shares unencrypted if they are already on a private VLAN with host firewall rules.
- Never disable SMB signing on a server that allows NTLM authentication to hide a performance problem — fix the dialect or the MTU instead.
- Monitor with
Get-SmbSessionduring the first week and add the Signed/Encrypted counts to your usual health check.
The pattern is consistent: pick SMB 3.1.1, require signing, encrypt by data classification, and treat the 5–10% throughput cost as the price of a defensible file service on a Windows VPS rather than a tuning problem to be removed.
