Enforcing SMB Signing on Windows Server 2022 Without Breaking Legacy Clients

In my environment, SMB signing isn’t just a checkbox — it’s a critical layer for preventing relay attacks and man-in-the-middle threats on internal file shares. When Microsoft pushed SMB signing as a default requirement in newer Windows versions, many of us running mixed environments hit a wall: how do we secure the protocol without breaking legacy scanners, POS systems, or old NAS devices that still rely on SMBv1 or unsigned SMBv2?

The answer lies in a phased approach using audit mode. Instead of flipping the switch and hoping for the best, Windows Server 2022 lets you log SMB signing failures first, giving you visibility before enforcement. This is where Get-SmbServerConfiguration and Enable-SmbServer -ForceSecurityAuthentication come into play — not as a one-liner fix, but as part of a controlled rollout.

Checking Current SMB Server Settings

Before making changes, I always start by auditing the current state. You can’t secure what you don’t measure.

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, EnableSMB3Protocol, RequireSecuritySignature

This shows whether SMBv1 is still enabled (hopefully not), which versions are active, and critically, whether RequireSecuritySignature is set to True. In most hardened builds, this should already be on — but in upgraded or migrated servers, it’s often missed.

If RequireSecuritySignature returns False, signing is encouraged but not enforced. That means clients can connect without signing, leaving the door open for spoofing attacks.

Enabling Audit Mode First

Jumping straight to enforcement can break silent dependencies. I’ve seen label printers, time clocks, and even some ERP modules fail because they don’t negotiate SMB signing — not because they’re malicious, but because they’re old.

Instead, I enable audit mode. This logs events when a client connects without signing, without blocking the connection.

Set-SmbServerConfiguration -AuditSmb1Access $true -AuditSmb2Access $true

Then, to specifically track unsigned SMB traffic:

Set-SmbServerConfiguration -EnableSecuritySignature $true -AuditInvalidSmbServerAuthentication $true

Now, any attempt to connect without signing will appear in the Windows Event Log under:

Applications and Services Logs > Microsoft > Windows > SMBServer > Audit

Look for Event ID 3000 — these are your warning signs. I usually let this run for 7–10 days, especially after patch cycles or when onboarding new devices.

Reviewing the Logs

You don’t need to parse raw EVTX files manually. A simple PowerShell query helps:

Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' | Where-Object {$_.Id -eq 3000} | Select-Object TimeCreated, Message | Format-List

This shows which clients are connecting unsigned and from where. In one case, I found a warehouse barcode scanner still using SMBv1 with no signing — something the network team had forgotten about during a VLAN migration.

Once you identify the offenders, you can either upgrade them, isolate them on a restricted VLAN, or — if absolutely necessary — create an exception group (though I avoid this unless there’s a documented business case and compensating controls).

Enforcing SMB Signing

After the audit period and cleanup, it’s time to enforce. This is where Enable-SmbServer -ForceSecurityAuthentication does the heavy lifting.

Enable-SmbServer -ForceSecurityAuthentication $true

This command does two things:

Sets RequireSecuritySignature to True
Forces the server to reject any SMB session that isn’t signed

You can verify it took effect:

Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

Should return True.

Now, any client that doesn’t support SMB signing (which includes anything pre-Windows Vista/Samba 3.0 or devices with SMB signing disabled) will get a System error 50 or The specified network password is not correct — misleading, but expected.

Balancing Security and Compatibility

I’ve seen admins skip the audit phase and enforce signing immediately — only to get paged at 2 AM because the time clock stopped punching in. Don’t be that person.

The audit-first method gives you:

Visibility into legacy usage
Time to plan upgrades or workarounds
Proof for compliance audits that you didn’t break things blindly

If you must support an unsigned client temporarily, place it in a restricted OU with loose GPO settings — but treat it like a quarantine zone. Monitor it, plan its retirement, and never let it become permanent.

Final Checks and Monitoring

After enforcement, I keep an eye on the same audit channel for a few weeks. Sometimes, a device reconnects after a reboot or firmware update and tries unsigned again.

Also, remember that SMB signing is negotiated per session. A client that supports it might still connect unsigned if the server doesn’t require it — which is why RequireSecuritySignature is the knob that matters.

For domain-joined servers, consider pushing this via GPO under:

Computer Configuration > Policies > Administrative Templates > Network > Lanman Workstation

Set Enable secure SMB server to Enabled — this ensures consistency across your fleet.

Note:

SMB signing adds a small CPU overhead due to packet signing/validation. On modern hardware, it’s negligible. On older domain controllers or file servers under heavy load, baseline performance before and after.

Tip:

Combine SMB signing with SMB encryption (Set-SmbServerConfiguration -EnableSMB2Encryption $true) for end-to-end protection — especially if your file shares cross subnets or traverse untrusted networks.

By auditing first, then enforcing with Enable-SmbServer -ForceSecurityAuthentication, you get the best of both worlds: stronger security without the surprise outages. It’s not flashy, but in ops, that’s where the real wins happen.

Cover image: Negative Space · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/macbook-laptop-X0CYLUO8E0