ERROR_DOWNGRADE_DETECTED (0X000004F1) – Security Downgrade Attack

Cause #1: SMB Signing Disabled on the Client or Server

The culprit here is almost always SMB signing. This error shows up when a Windows 10 or 11 machine tries to connect to a file share or a Domain Controller, but the server doesn't require SMB signing. The client expects it – you've got it enabled in Group Policy – but the server says "nah, I'll take unsigned traffic." The OS screams "downgrade detected" and kills the connection with 0X000004F1.

I've seen this most often after a security audit where someone enabled "Microsoft network client: Digitally sign communications (always)" on a workstation but forgot to flip the same switch on the file server. Or you've got a legacy NAS box that just doesn't support SMB 2.0 signing at all.

Fix it in Group Policy:

1. Open gpedit.msc on the client (or via domain GPO).
2. Go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Find Microsoft network client: Digitally sign communications (always) – set it to Disabled.
4. Also check Microsoft network server: Digitally sign communications (always) – set it to Disabled if the server doesn't support signing.
5. Run gpupdate /force and reboot.

If you can't change the server, you can also disable signing on the client via registry. But that's a band-aid, not a fix. Real fix is to get the server updated or enable signing there too.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 0 /f

Don't bother with disabling IPv6 or messing with the firewall – that never helps. The problem is signing mismatch, not a network path issue.

Cause #2: TLS Version Downgrade – Client Won't Negotiate Down

Second most common: your app or service is trying to connect to a remote endpoint that only speaks TLS 1.0 or 1.1, but the local machine has those disabled via registry or Group Policy. Windows 11 and Server 2022 default to TLS 1.2 and 1.3 only. When the server offers TLS 1.0 as the highest common version, the client sees that as a downgrade attempt and throws 0X000004F1.

I've seen this with old IIS servers, legacy SMTP relays, and even some VPN concentrators. The event log will show Schannel error 36888 with the downgrade flag.

Fix: enable TLS 1.0 and 1.1 temporarily, or better yet, patch the remote server. If you're on a domain, push this registry key to the client:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

But seriously – only do this as a temp workaround. I'd rather you update the app or server.

Cause #3: Corrupted Security Policy or GPO Processing Failure

Less common but I've seen it: the local security policy database (secedit.sdb) gets corrupted, or a Group Policy update fails halfway through. Windows then can't verify which security protocols are allowed, panics, and flags everything as a potential downgrade.

This usually happens after a botched Windows Update or a forced power-off during a Group Policy refresh. You'll see the error pop randomly when opening file shares or running net use.

Fix is to reset the local security policy:

1. Open an admin command prompt.
2. Run secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose
3. Wait for it to finish – takes a minute.
4. Reboot.

If that doesn't work, delete the secedit.sdb file manually:

net stop seclogon
cd %windir%\security\database
ren secedit.sdb secedit.old
secedit /configure /cfg %windir%\inf\defltbase.inf /db secedit.sdb /verbose
net start seclogon

Then reboot. That's cleared it for me on a few Server 2016 boxes that went sour after a failed patch Tuesday.

Quick Reference Table