SMB Signing Now Required: NAS and Old Client Access Failures

Direct answer: Windows 11 version 24H2 and Windows Server 2025 changed two SMB defaults that break some third-party storage:

1. SMB signing is required by default. Windows 11 24H2 Enterprise, Pro and Education require it on outbound and inbound connections. Windows Server 2025 requires it on outbound connections only. Windows 11 24H2 Home requires neither.
2. Guest access and guest fallback are blocked on Windows 11 Pro, bringing it in line with Enterprise and Education. Separately, because guest sessions cannot be signed, a signing requirement on its own stops guest access working.

So when a share on a NAS, router or older appliance stops working after an upgrade, first find out which of the two it is:

• STATUS_INVALID_SIGNATURE / 0xc000a000 points at signing: the device may not sign, or may sign incorrectly.
• "…your organization's security policies block unauthenticated guest access" or System error 3227320323 means the session fell back to guest. That can be a guest-only share, but also a wrong or missing stored credential that the device maps to guest.

Treat both as leads. Confirm with the stored credentials, the device's guest-mapping setting and its signing support before you call it a guest-only or non-signing device.

Then fix the device: turn on signing, give the share a real username and password, update the firmware, or replace the device. Turning signing off or re-enabling insecure guest logons is a recorded, per-machine risk decision, not the default fix, and never an estate-wide Group Policy change.

Why it matters

Signing protects SMB traffic against tampering and against relay attacks that forward a user's credentials to an attacker's server. Microsoft made it mandatory because most environments never switched it on. Its blog post on the change is blunt: Windows cannot tell the difference between "a NAS that doesn't have SMB signing enabled and an evil server that doesn't want SMB signing enabled".

The failures appear in places people don't expect:

• Mapped drives and backup targets on a NAS fail from a freshly installed Windows 11 24H2 desktop or a new Windows Server 2025 server. Older machines next to them keep working.
• Scan-to-folder from a multifunction printer to a share on a Windows 11 24H2 Pro or Enterprise PC fails, because those editions now require inbound signing too, and the printer is the SMB client.
• Scripts, scheduled jobs and services that copy to a NAS by IP address or with guest access fail silently overnight on a new server.

The quick "fix" found online is to disable the signing requirement and enable insecure guest logons on every machine through Group Policy. That removes the protection for every SMB connection those machines make, including to your own file servers, to fix one device. This article helps you prove the cause, fix it in the right place, and contain any exception.

How it works

What "required" means

Windows controls SMB 2 and 3 signing with one setting per role. RequireSecuritySignature on the client (Lanman Workstation) covers outbound connections, and on the server (Lanman Server) covers inbound. The Group Policy names are Microsoft network client: Digitally sign communications (always) and Microsoft network server: Digitally sign communications (always). For SMB 2.02 and later, the older EnableSecuritySignature value is ignored.

The rule Microsoft documents is simple: a session is signed if either side requires it. Signing is skipped only when both sides have the requirement off. So a Windows 11 24H2 Pro client that requires signing will insist on it from every server it talks to. If the server cannot sign, the connection fails.

What changed and where

Microsoft's own pages disagree slightly about Windows Server 2025 inbound signing. The SMB security hardening overview says "all outbound and inbound SMB connections are now required to be signed by default" for Windows 11 24H2 and Windows Server 2025. The more specific "Control SMB signing behavior" page says Windows Server 2025 requires outbound signing only. This article follows the more specific page. Check the actual value on your server (see the checks below) rather than relying on either.

Why guest and signing collide

A guest session has no user credentials, so there is no session key to sign with. Microsoft states that guest logons "don't support standard security features such as SMB signing and SMB encryption". Two things follow:

• A device that only offers guest access fails against a Windows 11 24H2 Pro client twice: guest is blocked, and the session cannot be signed.
• Enabling insecure guest logons on its own is not enough while signing is required. Microsoft's guest article says both the signing and encryption policies must be disabled for guest logons to work. That is exactly why this combination is so risky.

Which third-party servers are affected

Most current NAS software is built on Samba or a commercial SMB stack that supports signing. In Samba, signing for SMB 2 and later cannot be disabled: a setting of disabled is treated as auto, so a Windows client that requires signing gets it. The common failure in practice is therefore guest-only shares (Samba's map to guest and guest share options, or a vendor's "public share" switch) rather than missing signing support. Older consumer devices, routers with USB storage, and embedded SMB implementations in printers and appliances are the usual exceptions. Microsoft's blog asks people to report devices that cannot sign.

SMB1

Windows 11 has SMB1 disabled by default, and Microsoft describes it as deprecated and removed by default. A device that only speaks SMB1 is a separate problem, with worse security. SMB1 always allows guest fallback. Treat an SMB1-only device as a replacement candidate, not a configuration problem.

Kerberos, names and signing strength

Microsoft recommends Kerberos rather than NTLMv2 for SMB, because the signing key comes from the session key. It also warns that connecting by IP address or through a DNS CNAME makes Windows fall back to NTLM. For domain file servers, use the real server name or a proper alternate computer name. Most NAS devices that are not domain-joined use NTLM regardless, which is acceptable with a strong account password. The Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used covers NTLM auditing.

Read-only checks

None of these was run for this article. All are read-only unless marked otherwise. Run them on the Windows machine that fails, in an elevated Windows PowerShell session (the SMB cmdlets need administrator rights to read configuration).

1. Capture the exact error

Reproduce the failure with the path the user or job uses, and note the full message:

net use \\nas01\backup

Run this without saving credentials (no /persistent:yes, no password on the command line). It is a connection attempt, not a configuration change. Classify the result:

2. Read the client's SMB settings

Get-SmbClientConfiguration |
    Format-List RequireSecuritySignature, EnableInsecureGuestLogons

If the server side is also in question (a Windows 11 PC receiving scans, or a Windows Server 2025 file server):

Get-SmbServerConfiguration | Format-List RequireSecuritySignature

True means signing is required. Compare a working machine with a failing one. If they differ, find out whether the difference comes from the OS default or from Group Policy:

gpresult /h C:\Temp\gp.html

This writes a report file; it does not change policy. Look under Security Options for the two Digitally sign communications (always) settings and under Lanman Workstation for Enable insecure guest logons.

3. Look at the SMB client event logs

Get-WinEvent -LogName 'Microsoft-Windows-SmbClient/Security' -MaxEvents 50 |
    Format-List TimeCreated, Id, Message

Microsoft's guest article lists 31017 "Rejected an insecure guest logon" (task category RejectedInsecureGuestAuth) in this log. It also lists 31018 and 31022, which are warnings logged when an administrator has enabled insecure guest logons. Their presence tells you someone already applied the workaround.

The Microsoft-Windows-SmbClient/Connectivity log often holds the network-level failure for the same attempt. Read it as supporting evidence; this article does not cite specific connectivity event IDs.

4. Optional: audit before you enforce anything new

On Windows 11 24H2 and Windows Server 2025 you can turn on auditing that records servers (or clients) that do not support signing or encryption. This is a configuration change, although it is non-blocking:

# Changes configuration: enables audit events only. Undo by setting $false.
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

The matching Group Policy settings are under Administrative Templates\Network\Lanman Workstation\Audit server does not support signing (client) and Lanman Server\Audit client does not support signing (server). Events appear in Applications and Services Logs\Microsoft\Windows\SMBClient\Audit (IDs 31998 and 31999) and SMBServer\Audit (IDs 3021 and 3022). Microsoft's pages list the IDs together without mapping each to signing or encryption, so read the message text. Auditing records only what the audited machines actually connect to while auditing is on, so it cannot find a dormant device or one no audited machine talks to. Before relying on it for a rollout, record:

• which machines were audited (client audit for outbound, server audit for inbound, so both SMB directions are covered) and that they run a supported build;
• the observation window, long enough to include monthly, quarterly and other infrequent jobs such as scan-to-folder and year-end exports;
• the log size and retention, so events are not overwritten inside the window.

Combine it with the guest events (31017) and a representative acceptance test of each known device and job with a named credential. No audit events means no non-signing device was seen during the window, not that every device will work.

5. Check the device itself

On the NAS or appliance's own management console, or its documentation, find out:

• whether the SMB service supports signing, and its setting (for Samba-based devices, the server signing option or the vendor's equivalent);
• whether the share is configured for guest or public access, and whether a named user can be assigned instead;
• which SMB versions it supports (SMB1 only is a replacement signal);
• the firmware version, and whether the vendor has published a fix for Windows 11 24H2 or Server 2025.

6. Confirm the connection afterwards

When a connection succeeds, record what it negotiated:

Get-SmbConnection -ServerName nas01 | Select-Object *

Microsoft's documented output includes Dialect, Encrypted and the Credential used. Check that the credential is a named account, not guest. This article does not rely on a signing field being present in that output on every build.

Interpreting the results

Decision guidance

Work from the safest option to the least safe, which is the order Microsoft recommends.

1. Enable signing on the device

If the device supports it, turn signing on (or set it to "auto" or "mandatory") in its SMB settings.

Verification: the connection from the failing Windows client succeeds with no changes on Windows; 31998/31999 audit events (if enabled) stop for that server.

Rollback: set the device setting back. No Windows change was made.

2. Replace guest access with a named account

Create a dedicated local user on the device for each purpose: a user for staff mapping drives, and a separate service user for a backup or copy job. Give it only the shares it needs and a long, unique password, then disable guest or public access on those shares. Store the job's credential in the job's own credential store, not in a script.

Verification: Get-SmbConnection shows the named credential; the guest-rejection events stop; anything that previously relied on anonymous access is identified and moved to the named account.

Rollback: re-enable guest access on the device share. This restores the old exposure but changes nothing on Windows.

3. Update or replace the device

If the device cannot sign or cannot use credentials, check for firmware that adds support. If none exists, plan replacement and migrate the data. Microsoft's blog also asks for the make and model of devices that cannot sign to be reported, so vendors can be pressed for a fix.

4. Last resort: a contained, recorded client exception

If the business needs access to an unfixable device before replacement, make the exception as narrow as possible:

• Scope: only the specific machines that must reach the device, through a Group Policy object filtered to those computers or a local setting on them. Never the default domain policy, never "all workstations".
• Smallest change: if the device signs but only offers guest access, fix guest access; do not disable signing. If it cannot sign, disabling the client signing requirement is the change; enable insecure guest logons only if the device truly cannot use credentials.

powershell # CHANGE on the selected machine only. Lowers SMB protection for ALL its outbound connections. Set-SmbClientConfiguration -RequireSecuritySignature $false

Microsoft's guidance is explicit: it does not recommend disabling SMB signing as a workaround for third-party servers, nor trying to sign with guest accounts. Note that this client setting applies to every server the machine connects to, not just the NAS. That is why the scope must stay small. - Record: the device, the machines covered, the owner, the reason, the planned replacement date, and the exact settings changed. - Verification: the device is reachable from the covered machines, and only those machines show the changed values in Get-SmbClientConfiguration (or show 31018/31022 for guest). - Before the change: record the effective RequireSecuritySignature and EnableInsecureGuestLogons values on each covered machine, and which policy controls them (gpresult /h), or that they are local settings. - Rollback, local-setting route: set RequireSecuritySignature back to $true (and EnableInsecureGuestLogons to $false) on the machine. - Rollback, Group Policy route: removing or unlinking the exception GPO is not a guaranteed restore, because a security option can stay at the last applied value when no other policy sets it. Set the approved values explicitly (signing required, insecure guest logons disabled) in the controlling policy, run gpupdate, and confirm with Get-SmbClientConfiguration, gpresult and a new connection to a file server that requires signing. Retire the exception GPO only after those checks pass. - Remove the exception as soon as the device is fixed or replaced.

Windows as the server for old devices

For a scanner or appliance that writes into a Windows 11 24H2 share, the inbound requirement is on the PC. Prefer a device firmware fix or a designated file server share chosen on purpose, rather than lowering inbound signing on user desktops. Remember that Windows Server 2025 does not require inbound signing by default (per Microsoft's signing page). Check the current value on the target server before deciding.

What not to do

• Do not push "disable signing" and "enable insecure guest logons" estate-wide through the default domain policy. It weakens every SMB connection on every machine to accommodate one device.
• Do not lower signing on domain controllers or remove the SYSVOL and NETLOGON requirements. Domain controllers required signing long before 24H2.
• Do not re-enable SMB1 to reach a device unless it is a time-boxed, isolated exception with a replacement plan. SMB1 always allows guest fallback.
• Do not connect to shares by IP address or CNAME and then treat the resulting NTLM fallback as a signing problem. Use the proper name.
• Do not treat 0x80070035 as proof of a signing problem. It is also the generic "can't reach it" result.
• Do not store share passwords in scripts or command lines while testing. Use an interactive prompt or the job's credential store.

Limitations

• No lab test was run for this article. Error strings, event IDs and setting names come from Microsoft and Samba documentation.
• Microsoft's pages are inconsistent on Windows Server 2025 inbound signing (hardening overview versus signing-behaviour page). Check the live value.
• The audit event IDs 31998/31999 and 3021/3022 are listed by Microsoft without a per-ID mapping to signing or encryption.
• The Samba behaviour quoted applies to the current upstream Samba manual. NAS vendors ship their own builds and interfaces, and not every vendor exposes the same options.
• The Get-SmbConnection documentation example does not show a signing property, so this article does not depend on one.
• Performance effects of signing are not covered. For SMB throughput tuning, see the published SMB tuning article.
• SMB over QUIC, SMB client encryption mandates, NTLM blocking for SMB and the SMB authentication rate limiter are related 24H2/Server 2025 changes, but are not the subject of this article.

Acceptance checklist

• [ ] Exact error captured from the failing client and classified (signing, guest, network, credentials)
• [ ] Client (and, if relevant, server) RequireSecuritySignature and EnableInsecureGuestLogons recorded, with their source (default or GPO)
• [ ] SmbClient/Security events reviewed (31017; 31018/31022 for existing exceptions)
• [ ] Reachability on TCP 445 proven before signing was blamed
• [ ] Device capabilities checked: signing, named users, SMB versions, firmware
• [ ] Fix applied on the device where possible (signing on, guest off, named account)
• [ ] Any Windows exception limited to named machines, recorded with owner and end date, with rollback steps written
• [ ] Successful connection confirmed with a named credential (Get-SmbConnection)
• [ ] Auditing used (or planned) on named machines covering both SMB directions, over a window that includes infrequent jobs, with retention checked; combined with guest evidence and acceptance tests before wider rollout

References

All accessed 2 November 2026.

• Microsoft Learn, "Control SMB signing behavior": edition-specific defaults (Windows 11 24H2 Enterprise/Pro/Education outbound and inbound; Windows Server 2025 outbound only; Home neither), error codes, guidance against disabling signing, Get-/Set-SmbClientConfiguration and SmbServerConfiguration commands. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing
• Microsoft Learn, "Overview of Server Message Block signing": RequireSecuritySignature registry values and policies, EnableSecuritySignature ignored for SMB2+, "signed when either side requires", Kerberos vs NTLM and IP/CNAME guidance, auditing settings and event IDs. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing-overview
• Microsoft Learn, "SMB security hardening": signing default change, previous SYSVOL/NETLOGON scope, guest fallback disabled, Windows 11 Pro guest change, SMB1 firewall changes, related features. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-security-hardening
• Microsoft Learn, "How to enable insecure guest logons in SMB2 and SMB3": defaults by edition and version, guest cannot sign or encrypt, events 3023, 31017, 31018, 31022, recommendation not to enable. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/guest-access-in-smb2-is-disabled-by-default
• Microsoft Tech Community, Storage at Microsoft, "Accessing a third-party NAS with SMB in Windows 11 24H2 may fail" (May 2024): two changes, error messages, ordered remediation from safest to least safe, SMB1 notes, reporting address. https://techcommunity.microsoft.com/blog/filecab/accessing-a-third-party-nas-with-smb-in-windows-11-24h2-may-fail/4154300
• Microsoft Tech Community, "Windows Insider build 26090 brings small changes for SMB": signing and encryption auditing settings and event locations. https://techcommunity.microsoft.com/blog/filecab/windows-insider-build-26090-brings-small-changes-for-smb/4100200
• Microsoft Learn, "Get-SmbClientConfiguration". https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbclientconfiguration
• Microsoft Learn, "Get-SmbConnection": connection properties including Dialect, Encrypted, Credential. https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection
• Samba, smb.conf(5) manual: server signing values and SMB2 behaviour, map to guest, server min protocol. https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

Related articles

• How to diagnose and tune Windows SMB file services on VMware
• Firewall Rules Stopped After a Move? Check the Profile
• Group Policy Not Applying: gpresult, Events and SYSVOL

• Scheduled Jobs After Migration: Prevent Duplicate Work

• Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used

• Before Enforcing LDAP Signing and Channel Binding: Find Every Unsigned Bind

Learning notes

1. Windows 11 24H2 (Enterprise, Pro, Education) requires SMB signing outbound and inbound; Windows Server 2025 requires it outbound (check inbound on your build); Home requires neither.
2. A session is signed if either side requires it; guest sessions cannot be signed, so required signing also ends guest access.
3. STATUS_INVALID_SIGNATURE points at signing; the "unauthenticated guest access" message or 3227320323 means the session became guest (guest-only share, or a bad credential mapped to guest); 0x80070035 alone proves nothing. Confirm on the device before replacing anything.
4. Fix the device first (signing on, named account, firmware, replacement); the 24H2/Server 2025 audit settings find non-signing devices that audited machines actually contact during the window, so add acceptance tests for known devices and infrequent jobs.
5. Any Windows exception is per machine, recorded, time-boxed and reversible, because the client signing switch affects every server that machine talks to.