{"id":902,"date":"2026-10-20T22:42:17","date_gmt":"2026-10-20T22:42:17","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=902"},"modified":"2026-10-20T22:42:17","modified_gmt":"2026-10-20T22:42:17","slug":"smb-signing-encryption-overhead-windows-server","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/smb-signing-encryption-overhead-windows-server\/","title":{"rendered":"SMB Signing vs SMB Encryption on Windows Server: Measured Overhead and Safe Rollout"},"content":{"rendered":"
\n

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 \u2014 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<\/a>, such as SQL backups to a file share, or IIS content replication.<\/p>\n

What Each Control Actually Does<\/h2>\n\n\n\n\n\n\n\n
Feature<\/th>\nProtects<\/th>\nCrypto used<\/th>\nWhere enforced<\/th>\n<\/tr>\n<\/thead>\n
SMB signing<\/td>\nIntegrity\/anti-tamper of each packet (prevents NTLM relay and MITM modification)<\/td>\nHMAC-SHA256 or AES-CMAC\/GMAC<\/td>\nServer setting + client setting, per-share not possible<\/td>\n<\/tr>\n
SMB encryption<\/td>\nConfidentiality + integrity of the whole SMB session<\/td>\nAES-128-CCM or AES-128-GCM (3.1.1)<\/td>\nPer-share (EncryptData<\/code>) or server-wide<\/td>\n<\/tr>\n
SMB over QUIC<\/td>\nBoth, via TLS 1.3<\/td>\nTLS 1.3<\/td>\nServer 2022\/2025 with certificate, UDP 443<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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\u201330% 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 \u2014 and it is assisted by the cipher offload instructions exposed by the hypervisor.<\/p>\n

Baseline First<\/h2>\n

Measure before changing anything. Run from a client to the server, with the cache warm and cold:<\/p>\n

# Server side: which dialect, signing, and encryption are in use\nGet-SmbServerConfiguration |\n    Select-Object EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature,\n        EnableSecuritySignature, EncryptData, RejectUnencryptedAccess\n\n# Per-connection view (run during a transfer)\nGet-SmbSession | Select-Object ClientComputerName, Dialect, NumOpens, Signed, Encrypted\n\n# Throughput baseline: 1 GB read and write over SMB\n1..3 | ForEach-Object {\n  Measure-Command { Copy-Item \\\\fs01\\bench\\1gb.bin C:\\temp\\1gb-$_.bin -Force } |\n    Select-Object TotalSeconds\n}\n<\/code><\/pre>\n
Note Dialect<\/code>: 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<\/code> and confirm the share still mounts; older clients from Linux\/Samba need their own minimum set.<\/p>\n
Audit Before You Require<\/h2>\n
Turning on RequireSecuritySignature<\/code> or EncryptData<\/code> on a working file server can break legacy appliances in minutes. Find out first:<\/p>\n
# Audit-only mode logs what would be rejected\nSet-SmbServerConfiguration -AuditSmb1Access $true -Confirm:$false\n\n# Inventory every existing session and what it supports\nGet-SmbSession | Group-Object Dialect, Signed, Encrypted |\n    Select-Object Name, Count\n\n# Enable encryption on a single test share\nSet-SmbShare -Name Reports -EncryptData $true -Force\nGet-SmbShare | Select-Object Name, EncryptData\n<\/code><\/pre>\n
Also check Get-SmbServerConfiguration | Select SmbServerNameHardeningLevel<\/code> and the SMB event logs: Microsoft-Windows-SMBClient\/Security<\/em> and SMBClient\/Connectivity<\/em> record rejection reasons such as event 31017 (encryption required) and 31013 (signing required).<\/p>\n
Measured Overhead<\/h2>\n
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.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Configuration<\/th>\nRead MB\/s<\/th>\nWrite MB\/s<\/th>\nServer CPU during transfer<\/th>\n<\/tr>\n<\/thead>\n
No signing, no encryption<\/td>\n112<\/td>\n108<\/td>\n~8%<\/td>\n<\/tr>\n
Signing (AES-CMAC, 3.1.1)<\/td>\n108<\/td>\n104<\/td>\n~13%<\/td>\n<\/tr>\n
Signing (HMAC-SHA256 forced, 3.0)<\/td>\n94<\/td>\n88<\/td>\n~27%<\/td>\n<\/tr>\n
Encryption (AES-128-GCM, 3.1.1)<\/td>\n101<\/td>\n96<\/td>\n~21%<\/td>\n<\/tr>\n
Encryption + signing (3.1.1)<\/td>\n99<\/td>\n94<\/td>\n~24%<\/td>\n<\/tr>\n
Small-file mix, 10 KB avg, encryption on<\/td>\n\u2014<\/td>\n~40% of large-file rate<\/td>\n~35%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Two conclusions matter more than the exact numbers:<\/p>\n