SMB signing became mandatory and your NAS stopped working: signing, encryption, guest or SMB1?

A user upgrades to Windows 11, version 24H2 or later. The next morning their network drive is gone. The scanner cannot deliver to its watch folder. The little NAS box in the corner of the office throws an error nobody has seen before. Nothing on the device changed except the operating system version, and yet three different things broke.

They broke for three different reasons. Windows 11 tightened three independent Server Message Block (SMB) client controls at roughly the same time, and each one refuses a different class of device. This post explains what each control does, how to tell which one fired, and how to make a narrow exception for exactly one of them without switching off the other two.

The problem: three failures, one upgrade, no useful error

SMB is the protocol behind Windows file and printer sharing. When you open \\server\share, SMB is what carries the request. Windows plays two roles at once. It is an SMB client when it reaches out to a file server, and an SMB server when something reaches in to it. The two roles have separate settings, and confusing them is the single most common reason a fix does not stick.

Microsoft documents three changes that land on the client side of that pairing.

First, signing. Microsoft's guidance states that Windows 11, version 24H2 Enterprise, Pro and Education require both outbound and inbound SMB signing, Windows Server 2025 requires outbound signing only, and Windows 11, version 24H2 Home requires neither. Before this, Windows only required signing when talking to shares named SYSVOL and NETLOGON, or when talking to a domain controller.

Second, guest access. Since Windows 10, version 1709 and Windows Server 2019, the SMB client will not use the Guest account to reach a remote server and will not fall back to Guest after bad credentials. Microsoft extended that to Pro editions in Windows 11 Pro Insider Preview build 25267 and all later builds.

Third, SMB1. Microsoft's documentation is blunt: Windows 11 does not contain the SMBv1 server or client by default after a clean installation.

Each control produces a distinct symptom. Here is the mapping, using the error strings exactly as Microsoft publishes them.

Why it happens: what signing, encryption, guest and SMB1 each do

Before configuring anything, it is worth being able to say out loud what each of these four things is. They are not degrees of the same setting. They are four different mechanisms.

SMB signing: tamper detection

SMB signing puts a cryptographic hash of the whole message into the SMB header. Microsoft's overview describes the mechanism plainly: if someone tampers with the message in transit, the data does not match the hash. The hash also includes the identities of sender and receiver, which is what breaks relay attacks. The signing key is derived from the session key, and the session key is derived from the authentication that just happened. That is why Microsoft recommends Kerberos over NTLMv2, and why it recommends against connecting by IP address or CNAME record, since both of those push you onto NTLM.

The algorithms have moved on over time. SMB1 signed with MD5. SMB 2.02 moved to HMAC-SHA-256. SMB 3.0 introduced AES-CMAC. Windows Server 2022 and Windows 11 introduced AES-128-GMAC signing. Signing detects tampering. It does not hide the contents of your files from anyone watching the wire.

SMB encryption: confidentiality

SMB encryption is the one that hides the contents. Microsoft describes it as end-to-end protection against eavesdropping on untrusted networks, requiring SMB 3.0 or later, and configurable per share, for a whole file server, or when mapping a drive. Windows Server 2022 and Windows 11 introduced AES-256-GCM and AES-256-CCM on top of the existing AES-128-GCM and AES-128-CCM. AES-128-GCM is what gets negotiated by default with SMB 3.1.1.

Beginning with Windows 11, version 24H2 and Windows Server 2025, the SMB client can also require encryption for every outbound connection, which brings it to parity with signing. That is a much harsher requirement than signing, and it is off by default.

Insecure guest logon: the unauthenticated fallback

An insecure guest logon is a file server telling the client "I do not have an account for you, come in as Guest". Microsoft's policy documentation explains why this is being closed off: because the logon is unauthenticated, SMB signing and SMB encryption are both disabled, so the connection is open to adversary-in-the-middle attacks, and anything written to that server is potentially readable by anyone on the network. The same documentation notes that while insecure guest logons are uncommon in an enterprise, they are frequently used by consumer network attached storage (NAS) appliances acting as file servers.

That sentence is the whole story for most of these tickets. The cheap NAS in the branch office was configured years ago with guest access because it was easier than making accounts, and Windows will no longer play along.

SMB1: gone, and not coming back quietly

SMB1 is the 1980s-era dialect. It is deprecated, it signs with MD5, and Microsoft has not installed it by default since Windows 10, version 1709. In Windows 11 neither the client nor the server component is present after a clean install. It survives only as an optional Windows feature you have to deliberately add back, and Microsoft's documentation asks you not to.

The chain: what calls what, in order

Understanding where in the sequence a connection dies tells you which control fired, so it is worth walking the flow. When Windows opens \\contoso-nas\photos:

1. The application calls into the Multiple UNC Provider, mup.sys, which decides which redirector owns the path.
2. MUP hands the path to the SMB redirector, which sits on top of the Redirected Drive Buffering Subsystem, rdbss.sys.
3. mrxsmb.sys is the SMB mini-redirector wrapper and engine. It negotiates. mrxsmb20.sys handles SMB 2.x and 3.x. mrxsmb10.sys would handle SMB1, and on Windows 11 it is simply not on disk.
4. Negotiate settles on a dialect. This is where an SMB1-only device dies, because there is no dialect both sides support.
5. Session Setup authenticates. This is where the guest control fires, because the server offers Guest and the client refuses.
6. Signing and encryption requirements are evaluated against what the server advertised. This is where STATUS_INVALID_SIGNATURE comes from.
7. Tree Connect attaches to the share. Encryption required by the share, rather than by the client, shows up here.

On the inbound side, the same connection arriving at a Windows box is handled by srvnet.sys and srv2.sys, with srvsvc.dll providing the Server service itself.

The binaries, and where they live

Microsoft's SMB troubleshooting documentation lists these files by name, which makes them safe to reference in a support case rather than guessed at.

The registry surface, both trees

Two service parameter keys hold the runtime state. The client tree is LanmanWorkstation, the server tree is LanmanServer. Microsoft documents the signing values on both.

Microsoft also documents the summary rule that catches people out: SMB is signed when either side sets RequireSecuritySignature to 1. Signing is only skipped when both sides have it at 0. There is no negotiation to lose.

Policy-written values land in a different place entirely. Group Policy and Intune write to HKLM\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation and ...\LanmanServer, per the CSP documentation. So when you are auditing a device, read both locations. An empty policy key means nothing is being enforced centrally, and whatever you see in the service parameters key is the local or shipped state.

The Event Viewer catalog

SMB has four channels per side, and they are not interchangeable. The security-relevant client events live in one of them.

Services and the SMB1 optional feature

There is no scheduled task under \Microsoft\Windows\ that drives SMB signing, encryption or guest behaviour. These are kernel-mode decisions taken at connection time, read from the registry and policy state. If you were looking for a task to trigger, there is not one, and that is worth knowing so you stop looking.

How to verify: naming the control that rejected the connection

Work outward from the device. Read the effective client configuration first, because it is the shortest path to an answer.

The command below asks the SMB client for its live security posture. Every one of these properties is exposed by Get-SmbClientConfiguration, which reads the effective state rather than the registry, so it reflects policy as well as local settings.

Now read the other side of the same device, because a Windows box is also a server. If a legacy scanner cannot deliver to this machine, this is the half that matters.

Next, look at what actually got negotiated. This is the step people skip, and it is the most useful one, because it turns an argument about settings into a fact about a connection. Open the problem share first and leave it open, then run the command. If you have no connections, the table is empty and proves nothing.

Dialect and Encrypted are documented properties of the MSFT_SmbConnection object in the Get-SmbConnection reference. Signed is present on the class on current builds and is genuinely useful, but the published cmdlet example does not list it, so treat it as observed rather than contract and do not build detection logic that breaks if it disappears.

If you would rather see the stored state than the effective state, open the two service parameter keys directly. This matters when you need to know whether a value was written by policy or shipped with the OS.

Then go to the event log. This is where the guest and SMB1 controls identify themselves by number.

You can query the same thing without clicking. The command below pulls only the events that name a control, over the last week.

Finally, if the errors are ambiguous, turn on the audit settings. Microsoft added these in Windows 11, version 24H2 specifically to find third-party devices that claim SMB 3.1.1 support but cannot sign or encrypt. That is precisely the NAS scenario.

The audit switches are the one deliberate exception to the read-only theme of this section, because they write configuration. Microsoft documents them as follows.

The fix: one exception per control, not a blanket rollback

The right first move is always the file server, not the client. Microsoft's guidance says so directly for signing: adjust the settings on your third-party SMB server to allow signing, and it explicitly does not recommend disabling SMB signing as a workaround for third-party servers. Most NAS firmware from the last several years has an SMB signing toggle and a way to create a real user account. Use those, and this section becomes unnecessary.

When you genuinely cannot, scope the exception to the one control that is failing. What follows is a separate procedure per control.

Control 1: SMB signing - Group Policy

Signing lives in Security Options, not in Administrative Templates. This trips people up because everything else on this page is in Administrative Templates.

1. Select Start, type gpedit.msc and press Enter. For a domain policy use Group Policy Management (gpmc.msc) instead and edit or create a Group Policy Object.
2. Navigate to Computer Configuration › Windows Settings › Security Settings › Local Policies › Security Options.
3. To change the outbound requirement, open Microsoft network client: Digitally sign communications (always).
4. Select Disabled to stop requiring outbound signing, or Enabled to require it. Select OK.
5. For the inbound requirement, open Microsoft network server: Digitally sign communications (always) and set it the same way.
6. Leave Microsoft network client: Digitally sign communications (if server agrees) alone. It maps to EnableSecuritySignature, which is ignored for SMB2 and later.
7. Run gpupdate /force on a target device, then confirm with Get-SmbClientConfiguration | FL RequireSecuritySignature.

The PowerShell equivalents, straight from Microsoft's documentation, are Set-SmbClientConfiguration -RequireSecuritySignature $false for outbound and Set-SmbServerConfiguration -RequireSecuritySignature $false for inbound. Windows Admin Center exposes the server side under Settings › File Shares (SMB server) › SMB signing, but Microsoft notes the client side for outbound connections can only be changed through Group Policy and PowerShell.

Control 1: SMB signing - Intune

In Intune, signing comes through the Settings Catalog as a Local Policies Security Options setting, not as a Lanman Workstation setting.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices › Configuration and select Create, then New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog, then select Create.
4. Name the profile something that says what it does and why, for example SMB signing exception - legacy NAS pilot.
5. Select Add settings and search the picker for Digitally Sign Communications.
6. From the Local Policies Security Options category, select Microsoft Network Client: Digitally Sign Communications (Always). The equivalent OMA-URI is ./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/MicrosoftNetworkClient_DigitallySignCommunicationsAlways, where 1 is Enable and 0 is Disable.
7. Set the toggle to the value you want, then continue through Scope tags.
8. On Assignments, assign to a group containing only the affected devices. Do not assign to All Devices.
9. Review + create. Confirm on a device with Get-SmbClientConfiguration | FL RequireSecuritySignature.

Control 2: insecure guest logons

This one is an Administrative Template, and the policy name is the opposite of what you might expect: you enable insecure guest logons to make the NAS work.

1. Select Start, type gpedit.msc and select Edit group policy.
2. Under Local Computer Policy, navigate to Computer Configuration › Administrative Templates › Network › Lanman Workstation.
3. Open Enable insecure guest logons, select Enabled, then select OK. That writes AllowInsecureGuestAuth.
4. In the same folder, enable Audit insecure guest logon so you can see every time the exception is used.
5. Disable both the signing and the encryption requirements as well. Microsoft states that both must be disabled in Group Policy in order to use guest logons, because a guest logon cannot be signed or encrypted.
6. Confirm with Get-SmbClientConfiguration | FL EnableInsecureGuestLogons, which should return True.

The PowerShell equivalent is Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force. In Intune, the same setting is in the Settings Catalog under the Lanman Workstation category.

1. Create a Settings catalog profile as above.
2. Search the settings picker for insecure guest.
3. Select Enable Insecure Guest Logons. The CSP path is ./Device/Vendor/MSFT/Policy/Config/LanmanWorkstation/EnableInsecureGuestLogons, where the default is 0 and 1 enables guest logons.
4. Add Audit Insecure Guest Logon from the same category and enable it. Its CSP path is ./Device/Vendor/MSFT/Policy/Config/LanmanWorkstation/AuditInsecureGuestLogon, and it requires Windows 11, version 24H2 or later.
5. Assign to the narrowest possible device group and create the profile.

Control 3: SMB1

SMB1 is not a policy toggle. It is a Windows optional feature that has to be installed, and Microsoft's documentation asks you not to install it.

Before reinstalling anything, try the documented alternatives. Microsoft's guidance is to contact the vendor for firmware supporting SMB 2.02 or later, and points at the SMB1 Product Clearinghouse for a list of vendors and their fixes. If the requirement is really an application behaviour rather than the protocol, there is a share flag called leasing mode: Set-SmbShare -LeasingMode None disables modern leases and oplocks on a single share, which is sometimes all the legacy application actually needed. Microsoft cautions that this should only be used on shares a third-party application requires it on, because removing oplocks and leases causes instability and data corruption in most applications.

If Explorer's Network node is the actual complaint rather than a specific share, that is the Computer Browser service, which was removed along with SMB1. Microsoft's documented replacement is to start Function Discovery Provider Host and Function Discovery Resource Publication, set both to Automatic (Delayed Start), and enable network discovery when prompted. That uses WS-Discovery instead of NetBIOS browsing.

Control 4: the encryption mandate, if you are the one who turned it on

Client-side required encryption is not a default, so if it is on, somebody enabled it. It is worth knowing where, because it produces failures that look exactly like signing failures but survive disabling signing.

1. Open the Group Policy Management Console, then edit or create the GPO you want to use.
2. In the console tree, select Computer Configuration › Administrative Templates › Network › Lanman Workstation.
3. Right-click Require encryption and select Edit.
4. Select Enable to mandate it, or set it to Disabled or Not configured to remove the requirement, then select OK.
5. Confirm the effective state with Get-SmbClientConfiguration | Format-List -Property RequireEncryption.

The PowerShell form is Set-SmbClientConfiguration -RequireEncryption $true. In Intune the same setting is Require Encryption in the Lanman Workstation Settings Catalog category, at ./Device/Vendor/MSFT/Policy/Config/LanmanWorkstation/RequireEncryption, and it requires Windows 11, version 24H2 or later. Microsoft's own warning on this setting is worth repeating: be careful deploying SMB encryption organisation-wide, because legacy servers such as Windows Server 2008 R2 do not support SMB 3.0, and some third-party servers support SMB 3.0 without supporting encryption.

Which surface owns which setting

Two related surfaces worth naming for completeness. Dialect floors and ceilings are real policies: MinSmb2Dialect and MaxSmb2Dialect exist on both the Lanman Workstation and Lanman Server CSPs, with 514 meaning SMB 2.0.2 and 785 meaning SMB 3.1.1, and Microsoft notes they do not prevent use of SMB1 if that component is still installed. Setting a minimum dialect of 785 is a cleaner way to force modern SMB than any of the workarounds above. And SMB compression, which is configured with Set-SmbClientConfiguration -RequestCompression or the Use SMB Compression by Default policy in Lanman Workstation, is documented as supporting both SMB signing and SMB encryption, so it is not a suspect when a session fails to establish.

Defender, Attack Surface Reduction, WDAC and the Endpoint Security profiles are genuinely not involved in any of this. SMB signing, encryption, guest fallback and SMB1 are all enforced by the SMB stack itself using the registry and policy state described above, so there is no Defender profile setting to check and no exclusion that would change the outcome. Similarly, there is no per-post log file on disk: SMB does not write a text log. The channels in Event Viewer, and the ETL traces you collect with netsh trace or the TSS toolset that Microsoft's troubleshooting guidance describes, are the whole logging story.

Proof it worked: a real posture report from a 25H2 device

The companion script for this post reads every surface above in one pass and ends with a plain-English verdict naming the control that would reject a legacy server. It is strictly read-only: no Set-, New-, Remove-, Enable- or Disable- call touches a device setting, and it neither installs nor removes the SMB1 feature.

The output below is a genuine run on a Windows 11 Enterprise, version 25H2 device, build 26200, with identifiers replaced. It is trimmed to the sections that matter for this post.

The same run then reports the connection state and the verdict. On this device no share was mounted at the time, and the script refuses to treat that as a pass, which is the behaviour you want from a diagnostic.

Two findings from that run are worth calling out, because they are the kind of thing a settings table will never tell you.

First, on this device the client requires signing and the server does not. Microsoft's signing guidance states that Windows 11, version 24H2 Enterprise, Pro and Education require both outbound and inbound SMB signing. On this live Windows 11 Enterprise 25H2 build, Get-SmbServerConfiguration reports RequireSecuritySignature : False and the LanmanServer parameters key holds RequireSecuritySignature = 0. That is an observed discrepancy with the documented statement, not a claim about what Microsoft intends. The practical lesson is the important part: do not assume the inbound half is on because the documentation groups the two together. Read the server side separately on your own build before you promise anyone that inbound signing is enforced.

Second, the SMB1 optional feature enumeration on this build returns a fourth entry, SMB1Protocol-Deprecation, alongside the three documented ones. Microsoft does not document that feature name in the detect-enable-disable article, so treat it as observed and undocumented. Do not write detection logic that depends on it, because an undocumented feature name can change in any update.

The script also demonstrates the fail-loud rule. Run it without elevation and Get-WindowsOptionalFeature -Online and the event channel queries fail. Rather than printing a tidy report with four blank sections, it collects the failures and exits 1.

What "worked" looks like in the end depends on which control you scoped an exception for. For signing, Get-SmbConnection shows the previously missing server with a real dialect and Signed : False. For guest, a 31022 appears in SMBClient/Security where you used to get 31017. For SMB1, event 32002 replaces 32000. In every case the evidence is a change in the negotiated state or the event ID, not merely the absence of a complaint from the user.

No community deep-dive on this specific combination of controls verified against the citation list used for this series, so this post carries Microsoft sources only rather than an unverified MVP reference.

References

1. Overview of Server Message Block signing in Windows - how signing works, the policy locations, the RequireSecuritySignature and EnableSecuritySignature values, and the signing and encryption auditing event IDs.
2. Control SMB signing behavior - the per-edition defaults, the STATUS_INVALID_SIGNATURE and guest error strings, and the Group Policy, PowerShell and Windows Admin Center procedures.
3. Enable insecure guest logons in SMB2 and SMB3 - the guest default behaviours per version and the 31017, 31018, 31022 and 3023 event IDs.
4. Configure the SMB client to require encryption in Windows - the Windows 11 24H2 client encryption mandate, its policy path and its PowerShell parameter.
5. SMB Security Enhancements - SMB encryption, cipher suites, AES-128-GMAC signing, pre-authentication integrity and events 1003 and 1005.
6. SMBv1 Not Installed by Default in Windows Server and Windows - the SMB1 removal behaviour, the error strings, events 32000 and 32002, leasing mode and the Explorer Network replacement.
7. Detect, enable, and disable SMBv1, SMBv2, and SMBv3 in Windows - the optional feature names, the registry surface, the DependOnService change and SMBv1 auditing.
8. Guidance for troubleshooting SMB - the SMB client and server binary inventory and the TSS data collection procedure.
9. LanmanWorkstation Policy CSP and LanmanServer Policy CSP - the OMA-URI paths, the ADMX mappings and the dialect values.
10. Get-SmbConnection and Get-SmbClientConfiguration - the cmdlet references and their documented output properties.
11. Accessing a third-party NAS with SMB in Windows 11 24H2 may fail - the Microsoft Storage team's own write-up of this exact scenario.