SMB Signing on Windows 11 24H2 & Server 2025: The Helpdesk Fix Guide (2026)
Windows 11 24H2 enforces SMB signing by default, breaking older NAS devices with STATUS_INVALID_PARAMETER and access denied errors. Here is the PowerShell diagnostic runbook, GPO settings, and NAS firmware matrix helpdesk teams actually need.
SMB signing troubleshooting on Windows 11 24H2 and Windows Server 2025 almost always comes down to one root cause: the client now requires signed SMB sessions by default, and the target server or NAS is either negotiating an unsupported signing algorithm, refusing to sign at all, or being reached with cached credentials that skip signing entirely. In this guide I'll walk through the error codes you'll actually see in tickets, the PowerShell one-liners that cut Mean Time To Resolution (MTTR) in half, and the Group Policy levers that keep First Call Resolution (FCR) rates high without weakening security posture.
Windows 11 24H2 and Windows Server 2025 enforce SMB client signing (RequireSecuritySignature=1) by default; older NAS firmware that only supports SMB1 or unsigned SMB2 will fail with STATUS_INVALID_PARAMETER or STATUS_ACCESS_DENIED.
The default SMB signing algorithm on 24H2 is AES-128-GMAC; NAS devices stuck on HMAC-SHA256 must be patched or the connection will be rejected during the SMB2 NEGOTIATE exchange.
Guest fallback authentication is disabled by default in 24H2. Ticket volume for “can’t browse the shared drive at home” spikes after every feature update because of this, not because of signing itself.
Use Get-SmbConnection, Get-SmbMultichannelConnection, and the Microsoft-Windows-SMBClient/Connectivity event log to prove whether signing is the actual failure point.
The correct fix in enterprise environments is to patch or replace the NAS, not to disable signing with EnableSecuritySignature=0. Measure and report the number of unsigned share endpoints monthly.
What actually changed in Windows 11 24H2 and Server 2025
So, the behavioural change that drives most of the current ticket flood is subtle but load-bearing: the SMB client on Windows 11 24H2 (build 26100 and later) and Windows Server 2025 sets RequireSecuritySignature to 1 out of the box, up from the historical default of 0. That flag means the client will negotiate SMB signing on every outbound connection and drop the session if the server cannot or will not sign. On top of that, guest fallback authentication was disabled by default starting with Windows 11 Enterprise/Education in 22H2 and is now off across every 24H2 SKU (including Home and Pro), so anonymous access to old shares fails silently before signing even enters the picture.
The second change is algorithmic. Windows 11 24H2 negotiates AES-128-GMAC as the preferred signing algorithm because it's roughly twice as fast on modern CPUs as HMAC-SHA256. Older NAS firmware, particularly Synology DSM 6.x, QNAP builds shipped before QTS 5.1, and TrueNAS CORE releases prior to 13.0, only advertise HMAC-SHA256. The negotiation still succeeds because both sides can fall back, but any NAS advertising AES-CMAC without proper padding will trigger a STATUS_INVALID_PARAMETER during the SMB2 NEGOTIATE response. Honestly, I've watched helpdesks lose entire mornings chasing DNS and Kerberos when the actual cause was a signing algorithm mismatch on a single Synology in the finance closet.
Most tier-1 techs recognise the strings, but not the difference between them. Getting this triage right shaves 5–10 minutes off every SMB ticket. Here are the four errors that account for roughly 90 percent of my post-24H2 volume, along with the actual root cause in each case.
STATUS_INVALID_PARAMETER (0xC000000D) during connect: usually a signing algorithm mismatch. The server advertised a hash the client cannot verify.
STATUS_ACCESS_DENIED (0xC0000022) immediately on net use: the server requires signing, the client accepted it, but the credential handshake produced no session key. Almost always Kerberos or NTLM downgrade.
STATUS_NOT_SUPPORTED (0xC00000BB): the client asked for signing, the server (typically an ancient SMB1-only NAS) does not implement SMB2 at all. There is no fix short of replacing or patching the NAS.
You can’t access this shared folder because your organization’s security policies block unauthenticated guest access: guest fallback disabled, not signing. Redirect the user to authenticated credentials or update the NAS to require them.
Log every occurrence to your ticket system with a tag such as smb-signing-24h2 so you can pull a monthly volume report. If STATUS_NOT_SUPPORTED is trending, that's your automation queue for firmware upgrades.
How do I check if SMB signing is required on Windows 11?
The three PowerShell cmdlets below cover 95 percent of the diagnostic surface. Run them in an elevated session on the affected client, in that order.
# 1. Client-side signing policy (what THIS PC demands of the server)
Get-SmbClientConfiguration |
Select-Object RequireSecuritySignature, EnableSecuritySignature,
EnableInsecureGuestLogons, Smb2DialectMax
# 2. Actual state of live SMB sessions to remote shares
Get-SmbConnection |
Select-Object ServerName, ShareName, Dialect, Signed,
Encrypted, NumOpens
# 3. Detailed multichannel view (shows negotiated signing hash per NIC)
Get-SmbMultichannelConnection |
Select-Object Server, SelectedClientInterfaceIndex,
SelectedServerInterfaceIndex, Signed
The critical column in the output of Get-SmbConnection is Signed. If it says True for the target share, the signing negotiation succeeded and your problem is elsewhere (usually NTFS permissions, share ACLs, or Kerberos). If Signed is False on a 24H2 client, the connection succeeded only because RequireSecuritySignature was tampered with somewhere in your GPO stack. Audit for that.
For deeper analysis, enable the SMB client connectivity event log and reproduce the failure:
# Enable the analytic channel (disabled by default)
wevtutil sl Microsoft-Windows-SMBClient/Connectivity /e:true
# Reproduce the failure
net use Z: \\legacy-nas\finance /persistent:no
# Pull the last 20 events and look for SmbSigningRequired mismatches
Get-WinEvent -LogName Microsoft-Windows-SMBClient/Connectivity -MaxEvents 20 |
Format-List TimeCreated, Id, LevelDisplayName, Message
Event ID 30809 tells you exactly which signing algorithm the client asked for and which one the server accepted. If the numbers don't match, you have your smoking gun. For a broader background on Windows event triage, our Windows Event Viewer troubleshooting guide covers filter syntax and PowerShell log queries that pair well with the SMB channels above.
How to fix NAS access denied errors after upgrading to 24H2
NAS access denial is the single largest category of SMB signing tickets in mid-market environments (roughly 40 percent of the volume I see). The permanent fix is always firmware, but you need a triage flow that gets the user unblocked in the same call. Here is the runbook I have my tier-1 team follow, in strict order.
Confirm the failure is signing-related. Run Get-SmbConnection as shown above. If Signed is True or you see no rows for the affected server, signing isn't the problem.
Identify the NAS make and firmware. Ask the user or open the vendor portal. Log it in the ticket, because this is how you build the “endpoints to patch” report next month.
Apply the vendor patch if available. Synology DSM 7.2 and later, QNAP QTS 5.1.5+, TrueNAS SCALE 24.04+, and Ubiquiti UNAS OS 2.0+ all support AES-128-GMAC and the modern signing negotiation.
If firmware upgrade is blocked (usually because the NAS is out of support), the temporary workaround is to leave client signing enforced and, on the NAS, force SMB2 protocol level 3.1.1 with HMAC-SHA256. Never set EnableSecuritySignature=0 on the Windows client.
If the NAS is a Buffalo, D-Link or a rebadged consumer unit older than 2019, replace it. There's no supported signing story and every subsequent Windows update will break it again.
The nuclear-option registry tweak, which I list here for completeness but do not endorse for production, is to override the client requirement per-machine:
# DO NOT deploy this to fleets. Temporary lab / triage use only.
Set-SmbClientConfiguration -RequireSecuritySignature $false -Confirm:$false
If you deploy that to every machine to make a legacy NAS work, you've effectively rolled back the security posture Microsoft shipped in 24H2 for every share on the network, not just the broken one. See the Microsoft File Cabinet blog post on SMB signing enforcement for the vendor rationale.
Guest authentication and the “you can’t access this shared folder” error
This one is technically not a signing problem, but it's filed as one so consistently that it belongs in every SMB runbook. When a user browses to \\home-nas and gets the message “You can’t access this shared folder because your organization’s security policies block unauthenticated guest access”, they are hitting the AllowInsecureGuestAuth block, not signing.
The fix in enterprise environments is to configure the NAS or file server to require credentials and hand the user a domain or local account. Don't re-enable guest fallback with:
# AGAIN, not for production. This weakens the client for every share.
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Confirm:$false
In BYOD or hybrid work scenarios where the NAS is genuinely a home appliance owned by the user, provide a clear self-service KB article showing how to set a NAS password and use it. Track how many of these tickets convert to self-service the following month. That's your FCR metric for the whole guest-auth category.
Group Policy and Intune settings for SMB signing
For managed fleets, always control signing behaviour from Group Policy or Intune rather than per-machine PowerShell. That way the setting survives image refreshes and appears in your policy reports. Here are the four settings that actually matter, with their canonical locations:
Setting
GPO path
Intune CSP
Recommended value (2026)
Microsoft network client: Digitally sign communications (always)
Computer Config → Windows Settings → Security Settings → Local Policies → Security Options
If a GPO already sets RequireSecuritySignature to 0 as part of a decade-old “file server compatibility” baseline, that GPO will override the 24H2 default. Audit for it with gpresult /h gpresult.html and remove the legacy baseline. For teams doing bulk device onboarding, our Windows Autopilot troubleshooting guide covers how ESP-phase policy application can silently overwrite the shipping defaults during initial provisioning.
SMB over QUIC, alternative ports and firewall implications
Windows Server 2025 makes SMB over QUIC generally available in Datacenter and Datacenter: Azure Edition, and Windows 11 24H2 clients can act as QUIC clients out of the box. QUIC runs over UDP port 443, tunnels SMB inside TLS 1.3, and makes remote SMB usable from cafes and hotels where TCP 445 is universally blocked. Signing is still enforced inside the QUIC tunnel (QUIC provides transport encryption, not payload signing), so all of the diagnostic techniques above still apply.
Two practical implications for helpdesk teams:
If a remote user reports that a share works on the VPN but not off it, and you've already checked VPN split-tunnel behaviour, consider whether SMB over QUIC would remove the whole class of ticket. Our VPN troubleshooting guide covers the diagnostic side of that decision.
Client-side firewall rules for QUIC are separate from the classic SMB 445 rules. Verify with Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing over QUIC'. If the group is missing, the machine is on an older build than reported.
What to measure next month: MTTR, FCR and unsigned endpoint count
Every troubleshooting effort that ends without a metric ends up being repeated. If you're inheriting a mixed-vendor NAS estate rolling into 24H2 upgrades, put these five KPIs on your service dashboard immediately and review them on the first Monday of every month:
Ticket volume tagged smb-signing-24h2. Trend line, not absolute number. If it's falling, your patching program is working.
Mean Time To Resolution (MTTR) for the tag. Target under 20 minutes once the runbook is in place; anything above 45 minutes means the runbook is being skipped.
First Call Resolution (FCR) for the tag. Aim for 70 percent or higher, because the runbook is short enough that tier-1 shouldn't need to escalate.
Number of unsigned SMB endpoints on the network. Pull this from a scheduled Get-SmbConnection sweep across a representative sample of clients. Every one of these is a future ticket.
Percentage of NAS devices on a supported firmware version. This is the leading indicator; everything else lags it.
Publish the dashboard in the same channel where you announce feature updates. Executives who can see the “unsigned endpoints” number trend toward zero are much easier to convince when it's time to fund the NAS refresh cycle.
Frequently Asked Questions
Why does SMB signing suddenly break my NAS on Windows 11 24H2?
The Windows 11 24H2 SMB client sets RequireSecuritySignature=1 by default, so it drops any session where the server can't sign. NAS devices on firmware older than roughly mid-2023 often only advertise HMAC-SHA256 or lack modern signing support, so the negotiation fails during the SMB2 NEGOTIATE response.
Can I disable SMB signing on the client to fix a NAS problem?
You can, using Set-SmbClientConfiguration -RequireSecuritySignature $false, but you shouldn't. Disabling signing on the client weakens every SMB session that machine ever makes, not just the one to the broken NAS. Patch or replace the NAS instead, and keep signing enforced.
How do I tell if a specific SMB connection is actually signed?
Run Get-SmbConnection | Select ServerName, ShareName, Signed, Dialect in PowerShell. The Signed column is True when the session negotiated signing successfully and False when it did not. On Windows 11 24H2 defaults, False should never appear. If it does, some GPO or registry key is overriding the shipping requirement.
What is the difference between SMB signing and SMB encryption?
Signing proves that the SMB packets were not tampered with in transit and that they came from the expected principal. Encryption additionally hides the contents. Signing is on by default in 24H2 and Server 2025; encryption remains opt-in per share and adds a measurable CPU cost. Enable encryption on shares containing sensitive data even after signing is enforced, because they solve different problems.
Does SMB over QUIC replace SMB signing?
No. QUIC provides transport-level encryption and reachability over UDP 443, but SMB signing still happens inside the tunnel. A QUIC connection to an unsigned server on Windows 11 24H2 will still fail with the same status codes; QUIC just changes how the packets get there, not how they are authenticated.
Why do I still see “guest access blocked” even after I re-enabled guest logons?
Guest fallback and signing enforcement are independent. Re-enabling EnableInsecureGuestLogons tells Windows it's allowed to authenticate anonymously, but the SMB session still needs a signed handshake with the server. If the NAS can't sign, the session will fail regardless of the guest setting. Fix signing first, then decide whether guest logons are actually necessary.
Fix W32Time drift and Kerberos 5-minute skew lockouts on Active Directory domains. Covers PDC Emulator NTP setup, Hyper-V VMICTimeProvider trap, event IDs 47/50/129/138/142, GPO scoping, and the w32tm commands I actually use in incidents.
A field-tested playbook for enforcing LDAP signing and channel binding on Windows Server 2025 domain controllers, without taking your line-of-business apps down.
Fix the Exchange Online 550 5.7.68 TenantInboundAttribution NDR. Audit Direct Send traffic, build a partner connector for printers, and roll back safely with PowerShell.
